1. 项目概述当AI开始拥有“记忆”最近在折腾AI Agent开发的朋友估计都绕不开一个核心难题如何让AI记住东西不是那种对话里“嗯嗯啊啊”的短期上下文而是真正像人一样能记住过去几小时、几天甚至几周的关键信息并在需要时精准调取。这直接决定了Agent是只能执行简单指令的“一次性工具”还是能处理复杂、长周期任务的“智能伙伴”。我最近深度研究并实践了Gliding Horse这套记忆系统它来自Agent Harness框架。这个名字很有意思“滑翔的马”听起来既优雅又充满力量感。它的设计理念非常吸引我让AI的记忆管理像CPU管理内存一样高效、分层、有序。这不再是简单地把对话历史往向量数据库里一扔了事而是构建了一套从瞬时工作记忆到长期归档记忆的完整架构。简单来说Gliding Horse试图解决的是当前AI Agent领域的“记忆失忆症”。你训练了一个很棒的Agent它能写代码、能分析数据但当你让它基于昨天的讨论继续修改方案或者让它记住你的个人偏好时它往往表现得像个金鱼。Gliding Horse就是给这条“金鱼”装上了一个分层的记忆硬盘和一套智能的索引系统。这套系统适合谁如果你是AI应用开发者、产品经理或者对Agent架构感兴趣的技术爱好者想要构建能真正“持续学习”和“个性化”的智能应用那么理解Gliding Horse背后的思想会比单纯调用某个API更有价值。它提供的是一个设计范式而不仅仅是一个工具。2. 核心架构解析三层记忆与CPU式管理Gliding Horse的核心在于其清晰的三层记忆架构。这并非凭空想象而是借鉴了计算机体系结构中经典的存储层次结构寄存器-缓存-内存-硬盘并将其巧妙地映射到AI的认知过程中。2.1 三层记忆结构详解第一层是工作记忆Working Memory。这相当于CPU的寄存器和L1/L2缓存。它的容量极小但速度极快存取延迟极低。在Gliding Horse中工作记忆直接与Agent的“思考循环”绑定保存着当前任务执行所需的全部即时信息当前目标、上一步的输出、工具调用的结果、以及从长期记忆中提取出来的最相关片段。它的生命周期很短通常只存在于一个任务执行周期内。设计的关键在于“极致的相关性”和“极低的延迟”确保Agent“手边”永远有最需要的信息。注意工作记忆的设计最容易犯的错误是“塞得太满”。有些实现会把整个会话历史都放进去这会导致核心信息被淹没推理速度下降。Gliding Horse的策略是主动过滤和摘要只保留对当前推理步骤有直接因果或逻辑关联的信息。第二层是短期记忆Short-Term Memory。这对应着计算机的主内存RAM。它的容量比工作记忆大得多可以保存最近一段时间例如过去24小时或最近100轮对话的完整交互历史。短期记忆是构成会话连续性的基础。用户会觉得Agent“记得刚才聊过什么”主要就是靠这一层。它的实现通常基于向量数据库如Chroma, Weaviate或高性能键值存储通过向量相似度检索来快速找到与当前查询相关的历史片段。第三层是长期记忆Long-Term Memory。这就是计算机的硬盘或SSD了。它用于存储需要永久或长期保留的信息比如用户的个人档案、领域专业知识、项目核心文档、以及从过往经历中提炼出的“经验教训”。长期记忆的挑战不在于存储而在于高效的索引和唤醒。Gliding Horse在这里引入了“记忆凝结”的概念不是简单存储原始对话而是定期对短期记忆中的内容进行总结、去重、打标形成结构化的“记忆晶体”存入长期记忆。例如连续十次对话中用户都提到了“喜欢用Markdown写文档”这个偏好就会被凝结成一个标签为[用户偏好文档格式]的记忆晶体存入长期记忆。2.2 “像CPU一样思考”的管理策略分层只是基础如何让数据在各层之间高效流动才是Gliding Horse的精髓也是其“CPU式”思维的体现。加载Loading当Agent开始处理一个新任务或用户输入时它首先会从长期记忆中根据任务目标和个人画像检索出可能相关的“记忆晶体”集合。这个过程就像程序启动时从硬盘加载必要的数据段到内存。然后结合短期记忆中最近的上下文筛选出最相关的信息注入到工作记忆中供核心推理逻辑使用。这个加载过程是预测性的旨在让Agent“有备而来”。存储Storing任务执行过程中产生的新信息思考过程、工具返回结果、用户反馈会首先写入工作记忆。一个任务步骤完成后系统会判断哪些信息具有超越当前任务的保留价值。如果是重要的中间结论或事实会写入短期记忆如果是具有普遍意义的模式、用户确认的偏好或任务最终成果则会在任务结束后通过“凝结”过程提炼并存入长期记忆。替换与淘汰工作记忆在每个推理步骤后都可能被清空或大部分替换只保留跨步骤的状态信息。短期记忆采用滑动窗口或LRU最近最少使用策略淘汰旧的对话轮次。长期记忆虽然理论上永久保存但也会通过重要性评分和访问频率对记忆晶体进行归档或降级防止无效信息污染检索池。这种主动、预测性的内存管理使得Agent能够将有限的“注意力带宽”集中在最相关的信息上大大提升了复杂任务处理的效率和连贯性。3. 核心组件与实现拆解理解了架构我们来看看Gliding Horse是如何用具体组件实现这套理念的。它不是一个单一模块而是一个由多个协同工作的子系统构成的“记忆中枢”。3.1 记忆编码器与向量化策略记忆的存储前提是编码。Gliding Horse没有采用单一的编码方式而是根据记忆类型和用途进行差异化处理。对于事实与知识主要使用嵌入模型如text-embedding-3-small进行密集向量化。这是实现语义检索的基石。关键技巧在于分块Chunking策略。对于长文档不能简单粗暴地按固定字数切分。Gliding Horse会优先在段落、标题等语义边界进行切分并为每个块生成一个概括性的“摘要标题”这个标题也会被单独向量化用于粗筛从而提高长文档检索的精度和效率。对于事件与过程除了向量化还会提取结构化元数据。例如一个“完成用户注册”的记忆其元数据可能包括{类型: 任务 状态: 成功 涉及实体: [用户A 数据库] 时间戳: 2023-10-01 10:00 耗时: 2.3秒}。这些元数据可以用于基于属性的快速过滤“给我找出所有失败的任务”与基于向量的语义检索“用户遇到注册问题”形成互补。对于偏好与模式采用关键词/标签化与轻量化向量结合。例如“用户偏好深色模式”这个记忆会被打上[UI 偏好 深色模式]的标签同时生成一个轻量向量。检索时可以先通过标签快速缩小范围再用向量做精细匹配。3.2 记忆检索器从相似度到相关性检索是记忆系统的“CPU缓存命中”环节。Gliding Horse的检索器不是简单的“向量相似度排序”而是一个多阶段、重排名的管道。召回阶段根据当前查询并行地从不同记忆层和索引中召回候选记忆。可能同时查询短期记忆的向量索引、长期记忆中特定标签下的记忆晶体、以及基于元数据的过滤结果。这一步追求“全”避免遗漏。粗排阶段对召回的所有候选记忆进行快速打分。打分函数不仅仅是余弦相似度而是融合了语义相关性向量相似度得分。时间衰减越近的记忆得分权重越高这模拟了人类的记忆规律。访问频率经常被用到的记忆可能更重要。记忆强度在存入时根据重要性手动或自动赋予的权重。精排阶段将粗排后的Top-K个记忆比如20个连同当前的完整上下文工作记忆中的内容一起送给一个大语言模型LLM进行重排序和摘要。让LLM判断“在这些记忆中哪些对回答当前问题或完成当前步骤最直接、最关键”LLM可以理解更复杂的逻辑关系比如因果关系、矛盾关系这是单纯向量匹配做不到的。注入阶段将精排后的Top-N个记忆比如5个以结构化的格式如“根据之前的记录1... 2...”注入到Agent的提示词Prompt中成为工作记忆的一部分。实操心得很多团队在实现检索时只做到第一步就结束了导致检索结果虽然“相似”但不“有用”。加入LLM重排步骤虽然增加了一次API调用但对最终任务成功率的提升非常显著尤其是在复杂决策场景下。你可以从较小的K值如10开始实验平衡效果与成本。3.3 记忆凝结与遗忘机制这是赋予AI“成长性”和“管理性”的关键。记忆凝结这是一个离线或低优先级后台任务。系统会定期如每天扫描短期记忆寻找可以“凝结”的模式。例如摘要凝结将关于同一个主题的多次分散对话总结成一段连贯的叙述。偏好提取从用户多次的选择或肯定中抽象出一条明确的偏好规则。模式发现识别出任务执行过程中的常见成功路径或失败陷阱。 凝结后的“记忆晶体”会被赋予更丰富的元数据和更高的初始强度值存入长期记忆。这个过程大大压缩了记忆的存储体积并提升了记忆的质量。遗忘机制没有遗忘的记忆系统最终会被垃圾信息拖垮。Gliding Horse实现了软遗忘和硬遗忘。软遗忘通过记忆强度衰减实现。长期不访问的记忆其强度会随时间缓慢下降。在检索时强度是打分因子之一强度过低的记忆很难被召回相当于被“封存”了。硬遗忘提供手动或基于规则的API允许主动删除特定记忆。例如可以设置规则“当用户明确说‘忘记我刚才说的’时删除最近三轮对话中用户提供的所有信息。”这符合数据隐私和用户控制的需求。4. 在Agent Harness中的集成与实践Gliding Horse并非一个孤立运行的系统它是为增强Agent Harness框架中的Agent能力而设计的。理解它的集成方式才能更好地应用。4.1 与Agent核心循环的协作在一个典型的基于Agent Harness的Agent运行周期中Gliding Horse在以下节点被触发任务初始化Agent收到主任务或用户输入。此时记忆系统启动加载流程根据任务描述和用户ID从长期和短期记忆中检索相关背景预加载到工作记忆的“上下文”区域。每一步推理前在Agent决定下一步行动思考、调用工具、回复前工作记忆会结合上一步的结果再次向短期/长期记忆发起一次快速检索确保拥有最新的相关信息。这类似于CPU的缓存预取。每一步推理后将这一步产生的重要结果工具执行结果、新的推理结论作为新记忆写入工作记忆并标记其潜在价值。任务结束时触发记忆的存储流程。对整个任务流中标记为高价值的信息进行凝结并决定其归宿进入短期或长期记忆。同时清理本次任务的工作记忆为下一个任务做准备。这种深度集成使得记忆的读写成为Agent推理流程中无缝的一部分而不是事后附加的日志功能。4.2 状态管理与上下文维护Agent在运行中会维护一个会话状态Session State。Gliding Horse的工作记忆本质上是这个会话状态中最活跃、最核心的部分。实现时需要精心设计这个状态对象的结构例如class AgentSessionState: def __init__(self, user_id, session_id): self.user_id user_id self.session_id session_id self.current_goal None # 当前目标 self.working_memory { context: [], # 从记忆系统加载的上下文 step_history: [], # 本轮任务已执行的步骤历史 tool_results: [], # 工具调用结果缓存 derived_facts: [] # 推理得出的中间事实 } self.short_term_memories [] # 指向短期记忆的引用或ID记忆系统需要能够读取和更新这个状态。当从记忆系统检索时结果会被注入到working_memory[context]中。当存储记忆时系统会从step_history,tool_results等字段中提取有价值的信息。4.3 配置参数与性能调优部署Gliding Horse时有一系列参数需要根据实际场景调优参数组关键参数说明调优建议检索相关top_k_recall召回阶段候选记忆数量通常50-100。太小易遗漏太大增加重排负担。top_n_final最终注入工作记忆的记忆条数通常3-7条。受限于LLM上下文窗口需保证核心信息不超限。similarity_threshold向量相似度最低阈值过滤掉明显不相关的记忆。可从0.7开始实验。记忆凝结condensation_interval凝结任务运行间隔根据业务活跃度设置如每小时或每天。min_occurrence_for_preference形成偏好所需的最少出现次数避免偶然事件被误判为偏好通常3。遗忘机制decay_rate记忆强度衰减率控制记忆“保质期”。值越大忘得越快。forget_strength_threshold硬遗忘的强度阈值低于此值的记忆可被自动清理。性能调优的核心原则是平衡检索的召回率与精度、记忆的丰富度与检索速度、存储的完整性与成本。建议从一个小而具体的场景开始设定可量化的评估指标如任务完成率、用户满意度、平均响应延迟然后进行A/B测试逐步调整参数。5. 实战构建一个具有记忆的智能客服Agent理论说得再多不如动手试一下。我们设想一个场景为一个SaaS产品构建一个智能客服Agent它需要记住用户的产品使用历史、过往的工单问题以及沟通中透露的个人偏好。5.1 场景定义与记忆规划首先我们需要规划这个客服Agent需要哪些记忆长期记忆用户档案公司规模、所属行业、订阅版本、关键联系人。这是静态基础信息。产品知识产品文档、常见问题解答、更新日志。这是领域知识。历史问题模式从解决过的工单中凝结出的“某行业客户常遇到A问题解决方案是B”这类经验。短期记忆本次会话记录当前对话的完整历史。近期交互过去7天内该用户的所有咨询记录。工作记忆当前问题描述用户本次提交的具体问题。已尝试方案在本轮对话中Agent已经推荐或尝试过的解决方案。加载的相关背景从长/短期记忆中检索到的与该用户、该问题相关的所有信息。5.2 分步实现与代码要点我们使用伪代码结合Python风格来描述关键步骤。步骤1初始化记忆系统与Agent# 初始化记忆存储这里用字典模拟实际应用需连接数据库 long_term_store VectorStore(indexuser_profiles) # 存储用户档案向量 short_term_store VectorStore(indexsession_history) # 存储会话向量 memory_consolidator MemoryConsolidator() # 记忆凝结器 # 初始化客服Agent并注入记忆系统客户端 class CustomerSupportAgent: def __init__(self, memory_client): self.memory memory_client self.working_memory {}步骤2用户发起咨询时的记忆加载def handle_user_query(self, user_id, query): # 1. 从长期记忆加载用户档案和可能相关的知识 user_profile self.memory.recall_long_term(user_id, query) relevant_knowledge self.memory.recall_knowledge_base(query) # 2. 从短期记忆加载近期会话 recent_chats self.memory.recall_short_term(user_id, limit5) # 3. 将所有相关信息整合注入工作记忆 self.working_memory[context] format_context( user_profile, relevant_knowledge, recent_chats ) self.working_memory[current_query] query # 4. Agent基于丰富的工作记忆开始推理... response self.reason_and_act() return response步骤3在推理过程中动态检索假设Agent在推理中决定要检查某个特定错误码的解决方案。def reason_and_act(self): # ... 部分推理逻辑 if need_check_error_code(ERR_1001): # 动态从记忆特别是知识库中检索该错误码的详细信息 error_details self.memory.recall_by_metadata( storeknowledge_base, filters{type: error_code, code: ERR_1001} ) # 将检索结果动态加入工作记忆 self.working_memory[retrieved_details] error_details # ... 继续推理并生成回复步骤4会话结束后的记忆存储与凝结def end_session(self, user_id, session_log, resolution_summary): # 1. 将完整的会话日志存入短期记忆 self.memory.store_short_term(user_id, session_log) # 2. 如果问题得到解决凝结经验 if resolution_summary[status] resolved: new_experience self.memory_consolidator.condense( problemsession_log[problem], solutionresolution_summary[solution], user_contextself.working_memory[context] ) # 将凝结后的经验存入长期记忆的“问题模式”库 self.memory.store_long_term(solution_patterns, new_experience) # 3. 识别并存储用户偏好例如用户多次要求“把解决方案发我邮箱” detected_preferences extract_preferences(session_log) for pref in detected_preferences: self.memory.store_long_term(user_preferences, pref, user_id)5.3 效果评估与迭代部署后我们需要评估这个“有记忆”的客服Agent的效果效率指标平均解决时间是否缩短转接人工坐席的比例是否下降质量指标用户满意度评分CSAT是否提升同一用户重复提问同一问题的频率是否降低记忆有效性指标Agent在回复中主动引用历史信息的比例是多少这些引用是否准确相关通过监控这些指标我们可以反过来调整记忆系统的参数例如如果发现Agent经常引用不相关的旧信息可能需要提高相似度阈值或改进凝结策略如果发现无法记住关键偏好可能需要降低偏好提取的阈值。6. 常见陷阱、挑战与优化策略在实际部署Gliding Horse或类似记忆系统时我踩过不少坑也总结出一些优化策略。6.1 典型问题与排查清单问题现象可能原因排查步骤与解决方案Agent回复变慢1. 检索的候选集(top_k_recall)过大。2. 记忆凝结任务阻塞主线程。3. 向量索引未优化查询慢。1. 监控检索各阶段耗时缩小top_k_recall。2. 将凝结改为异步后台任务。3. 检查向量数据库性能考虑使用HNSW等更快的索引算法。记忆检索不准确总找旧/错信息1. 向量嵌入模型与任务不匹配。2. 缺少元数据过滤仅靠语义相似度。3. 记忆强度衰减过快重要记忆被“软遗忘”。1. 在领域数据上微调嵌入模型或更换更适配的模型。2. 在检索中结合时间、类型等元数据过滤器。3. 调整衰减率或对重要记忆设置初始高强度。长期记忆膨胀存储成本高1. 所有信息都存为长期记忆缺少凝结和摘要。2. 没有有效的遗忘机制。1. 强化凝结流程只存结构化、去重的“晶体”。2. 实施基于访问频率和强度的自动归档策略。Agent表现不一致时好时坏1. 检索结果具有随机性尤其是相似度边缘的记忆。2. 工作记忆加载的内容每次略有差异影响推理。1. 在精排阶段使用LLM重排提升结果稳定性。2. 确保工作记忆的初始化流程是确定性的例如固定检索条数并按综合评分严格排序。用户感到隐私担忧1. Agent过于具体地引用了历史对话细节。2. 无法提供“忘记”某些信息的机制。1. 在回复时对引用信息进行适度概括而非直接引用原文。2. 必须提供硬遗忘API并确保数据物理删除。6.2 高阶优化技巧混合检索策略不要只依赖向量检索。对于用户ID、时间范围、事件类型等精确匹配查询先用传统数据库如SQL过滤再用向量检索在结果子集中做语义匹配可以极大提升效率和准确率。记忆重要性预测在存储记忆时用一个轻量级模型甚至是一组规则预测该记忆未来的重要性并赋予其初始强度。例如用户明确说“这个很重要”的语句其初始强度应设为最高。上下文感知的检索检索查询不应只是用户当前的一句话。而应将当前工作记忆中的任务目标、已执行步骤等也作为查询的一部分让检索更贴合Agent当前的“思维状态”。测试与评估体系建立记忆系统的专项测试集。例如构造一系列需要记忆才能回答的问答对“我昨天说的那个方案是什么来着”定期跑测试监控准确率变化。6.3 关于成本与规模的考量记忆系统尤其是依赖大模型进行重排和凝结的系统会增加计算和API调用成本。在规模应用时需考虑缓存策略对高频但不变的记忆如产品知识其检索结果可以缓存一段时间。异步与批处理记忆凝结、强度衰减计算等任务完全可以放在异步队列中定时批处理不影响实时交互。分级存储访问频率极低的长期记忆可以从昂贵的向量数据库迁移到更廉价的对象存储中仅保留其元数据和索引在快速存储里。Gliding Horse记忆架构为我们设计实用的AI Agent提供了一个强大的蓝图。它告诉我们AI的记忆不是附属功能而是核心能力。实现它需要细致的工程设计和持续的调优但带来的回报是Agent能力质的飞跃——从一个健忘的“任务执行器”变成一个真正有延续性、有个性化的“智能体”。