1. Agent 记忆系统的整体设计思路拆解1.1 为什么 Agent 需要“记忆”这个独立模块很多人第一次做 Agent 开发时会把记忆和上下文混为一谈觉得“我把历史对话全塞进 prompt 里不就是记忆了吗”。这个思路在 demo 阶段能跑通但一旦进入真实业务问题立刻暴露token 成本飙升、关键信息被淹没在噪声里、模型开始“记错”或者“编造”之前没发生过的事。我在实际项目里踩过最典型的一个坑是一个客服 Agent 在连续对话 30 轮之后把用户三周前随口提的一句“我最近在考虑换工作”当成了当前诉求开始推荐招聘网站。问题根源不是模型不行而是我们把“原始对话流”直接当成了“记忆”。记忆的本质不是存储而是筛选、压缩和结构化。它要解决的核心问题是在有限的上下文窗口里如何让 Agent 在正确的时刻拿到正确的信息。所以一个合格的 Agent 记忆系统至少要承担四件事写入什么值得记、存储记在哪里、以什么形式、检索什么时候取、取多少、更新旧信息怎么失效、冲突怎么处理。这四件事任何一件没做好Agent 的表现都会断崖式下跌。1.2 记忆、上下文、Skills、Harness 四者的关系这四个词经常被混着用但它们在架构上是不同层次的东西我用一个类比说清楚记忆Memory是“硬盘”是长期沉淀下来的经验、事实、偏好。上下文Context是“内存”是当前这一轮推理真正能看到的内容。Skills是“肌肉记忆”是封装好的、可复用的能力单元比如“查天气”“发邮件”“跑一段 SQL”。Harness是“神经系统”是调度这一切的运行时框架负责把记忆取出来、拼进上下文、调用 Skills、再把结果写回记忆。我见过不少团队把 Skills 当成记忆用把一堆工具描述塞进系统提示词里结果上下文被撑爆模型反而不知道该调哪个。正确的做法是记忆负责“知道什么”Skills 负责“会做什么”Harness 负责“什么时候做什么”上下文是它们交汇的临时工作台。理解这个分层后面的设计才不会乱。1.3 双网络记忆模型的取舍逻辑热词里出现了“双网络记忆模型”这其实对应认知科学里的一套成熟思路把记忆分成两个网络一个负责快速、具体、情景化的短期记忆一个负责慢速、抽象、语义化的长期记忆。落到工程上我通常这样落地维度短期记忆网络长期记忆网络存储内容当前会话的原始交互、临时状态提炼后的事实、偏好、结论存储介质内存 / Redis / 会话表向量库 / 关系库 / 文件生命周期会话结束即清理或归档长期保留定期衰减检索方式按时间顺序直接读取语义相似度 元数据过滤典型容量几千到几万 token无上限靠检索控制为什么要分两个网络因为它们的读写模式完全不同。短期记忆要求“快、全、顺序”长期记忆要求“准、省、可检索”。用一套存储硬扛两种需求最后一定是两头不讨好。我自己的项目里短期记忆用 Redis 存最近 N 轮长期记忆用向量库存提炼后的条目中间靠一个“提炼器”做桥接效果比单一存储稳定得多。2. 记忆的写入、存储与检索核心细节2.1 什么信息值得写入长期记忆这是最容易被忽视、却最影响效果的一环。我的经验是不要什么都记也不要等会话结束才批量记。实时判断 异步提炼是更稳的组合。值得写入长期记忆的信息通常符合以下特征之一稳定性事实用户的身份、偏好、长期目标比如“用户偏好简洁回复”“用户是后端工程师”。可复用结论之前解决过的问题及其方案比如“这个报错是因为时区配置”。明确指令用户显式要求记住的内容比如“以后都用中文回复我”。高频实体反复出现的项目名、人名、系统名。反过来以下内容我一般不建议写入长期记忆一次性的寒暄、临时的情绪表达、已经被推翻的中间结论、以及任何涉及隐私敏感且无明确授权的内容。实操上我会用一个轻量的“记忆评分”逻辑给每条候选记忆打分超过阈值才写入。评分维度包括信息密度、未来复用概率、是否与已有记忆冲突。这个评分可以用规则做也可以用小模型做成本都不高。2.2 存储格式为什么结构化比纯文本更抗造早期我图省事长期记忆直接存自然语言句子检索出来直接拼进 prompt。跑了一段时间发现两个问题一是检索命中率不稳定二是多条记忆之间容易自相矛盾模型不知道该信哪条。后来改成结构化存储每条记忆至少包含这些字段{ id: mem_20240115_001, content: 用户偏好使用 Python 而非 JavaScript 做数据处理, type: preference, source: session_8821, created_at: 2024-01-15T10:23:00Z, last_accessed: 2024-02-01T09:10:00Z, confidence: 0.85, status: active, supersedes: null }这样设计的好处是检索时可以按type过滤按confidence排序按last_accessed做衰减遇到冲突时用supersedes字段标记新旧关系。结构化不是为了好看是为了让记忆系统具备“可管理性”。纯文本记忆一旦积累到几百条你根本没法维护。2.3 检索策略相似度不是唯一标准很多人做记忆检索直接上向量相似度 top-k取前 5 条塞进上下文。这个做法在简单场景够用但在真实业务里经常翻车。原因很简单语义相似不等于当前有用。我现在用的检索策略是“多路召回 重排”语义召回向量相似度取 top 20保证覆盖面。时间召回最近 7 天被访问过的记忆单独取一批。类型召回根据当前任务类型强制拉取对应类型的记忆比如做代码任务时优先拉“技术偏好”类。重排把三路结果合并用一个轻量打分函数排序综合考虑相似度、时间新鲜度、访问频率、置信度。打分公式我一般写成这样score 0.5 * similarity 0.2 * recency 0.2 * frequency 0.1 * confidence权重不是固定的要按业务调。比如客服场景更看重新鲜度知识库场景更看重相似度。这个公式的价值不在于精确而在于让检索结果可解释、可调优出问题时你能知道是哪一路召回的锅。注意检索出来的记忆条数不是越多越好。我实测下来超过 8 条之后模型对每条记忆的“注意力”会被稀释反而容易忽略关键信息。宁可少而精不要多而杂。3. 上下文管理与 Skills 的协同实操3.1 上下文窗口用完了怎么办“1m 上下文是什么意思”“大模型上下文窗口用完了怎么办”这类问题本质是在问同一件事上下文是稀缺资源怎么分配。我的处理原则是分层管理而不是等它满了再想办法。具体做法是把上下文分成几个固定区块每个区块有预算区块内容建议预算占比系统提示角色、规则、输出格式10%长期记忆检索出的结构化记忆15%短期记忆最近 N 轮对话30%Skills 描述当前可用工具说明10%当前任务用户本轮输入 相关文档35%当总预算超限时按优先级裁剪先压缩短期记忆把早期轮次做摘要再精简 Skills 描述只保留当前任务相关的最后才动长期记忆。永远不要动系统提示和当前任务这两块是 Agent 的“锚”。我见过一个团队的做法很聪明他们给每轮对话打一个“信息熵”分数熵低的轮次比如“好的”“收到”直接丢弃熵高的轮次保留原文。这样在不损失关键信息的前提下能省下 20% 到 30% 的上下文。3.2 Skills 的封装粒度怎么定Skills 封装太粗一个 Skill 干十件事模型调用时参数填不对封装太细几十个 Skill 塞进上下文模型选择困难。我的经验是一个 Skill 对应一个明确的动作意图参数不超过 5 个。举个例子“发送邮件”这个能力我见过有人封装成一个 Skill参数包括收件人、抄送、主题、正文、附件、优先级、回复地址……结果模型经常漏填。更好的做法是拆成“起草邮件”和“发送邮件”两个 Skill前者负责内容生成后者只负责投递每个 Skill 的参数都控制在 3 个以内。Skills 的描述也有讲究。不要写“这个工具可以用来查询天气”要写“查询指定城市的当前天气输入城市名返回温度和天气状况”。描述要包含触发条件、输入格式、输出格式这三样齐全模型调用准确率能提升一大截。3.3 Harness 在其中的调度职责Harness 这个词在热词里反复出现很多人问“harness 和 agent 区别”。我的理解是Agent 是“决策者”Harness 是“执行环境”。Agent 决定要做什么Harness 负责把这件事真正跑起来。一个合格的 Harness 至少要管这些事上下文组装按预算把各区块拼成最终 prompt。Skills 注册与路由维护可用 Skill 列表处理调用请求。记忆读写在合适的时机触发记忆检索和写入。错误处理与重试Skill 调用失败时的降级策略。可观测性记录每一步的输入输出方便排查。我自己的项目里Harness 是一个独立进程Agent 逻辑跑在里面但和 Harness 的调度层解耦。这样做的好处是换模型、换记忆库、加 Skill都不用动 Agent 的核心逻辑。Harness 的稳定性直接决定了整个 Agent 系统的稳定性。4. 常见问题与排查技巧实录4.1 记忆冲突与“创伤记忆”的处理热词里有个词叫“创伤记忆”虽然是个调侃说法但它指向一个真实问题Agent 把一次失败经历记成了永久规则导致后续行为过度保守。比如某次调用某个 Skill 超时了Agent 就记下“这个 Skill 不可靠”之后再也不调用它。我的处理方式是给记忆加“时效性”和“适用范围”两个维度。失败类记忆默认 7 天衰减且只在相同上下文下生效。同时引入“反例覆盖”机制当同一 Skill 连续成功 3 次自动降低之前失败记忆的权重。记忆系统要有“遗忘”和“修正”的能力否则它会越用越偏执。4.2 上下文超长导致的行为漂移“dify 工作流 上下文超长”是个高频问题。上下文一长模型容易出现三种漂移忘记系统提示、忽略早期指令、开始重复输出。排查时我一般按这个顺序查先看系统提示是不是被挤到了很靠前的位置模型对开头和结尾的内容注意力最高中间容易被忽略。再看短期记忆有没有做摘要如果全是原文噪声太大。最后看 Skills 描述是不是全量塞进去了只保留当前任务相关的即可。一个实用技巧是在上下文中间位置插入一条“提醒锚点”比如“注意以上是背景信息当前任务是……”。这条锚点能显著降低模型跑偏的概率成本几乎为零。4.3 记忆跨设备、跨账号迁移的坑“一台电脑上 workbuddy 中的各项记忆配置如何用到另一台电脑”“换账号如何获得原来账号的记忆”这类需求本质是记忆的可移植性问题。我的建议是记忆一定要和账号解耦和存储层绑定。具体做法是把记忆存成标准格式的文件或数据库记录导出时带上完整的元数据类型、时间、置信度、来源。导入时做一次去重和冲突检测不要直接覆盖。我踩过的坑是直接复制数据库文件结果两边的 ID 生成规则不同导致大量重复记忆。后来改成导出 JSON、导入时按内容哈希去重才稳定下来。4.4 常见问题速查表现象可能原因排查方向Agent 记不住之前说过的话短期记忆未写入或检索失败检查写入时机和检索召回率Agent 记错了信息记忆冲突未处理检查 supersedes 字段和置信度上下文频繁超限预算分配不合理按区块统计 token 占比Skill 调用参数错误描述不清晰或参数过多精简参数补充输入输出格式行为越来越保守失败记忆未衰减引入时效性和反例覆盖换设备后记忆丢失记忆与本地绑定改为标准格式导出导入提示排查记忆问题时先把“检索出来的原始记忆”打印出来看一遍80% 的问题在这一步就能定位。不要一上来就怀疑模型。5. 记忆更新与长期演进的实操心得5.1 记忆衰减与权重调整记忆不是存进去就一劳永逸的。我一般给每条记忆设一个“新鲜度”分数随时间衰减被访问时回升。衰减曲线用指数衰减比线性衰减更符合实际freshness base * exp(-λ * days_since_last_access)λ 的取值按业务定客服场景可以取 0.1衰减快知识库场景取 0.01衰减慢。检索时把 freshness 作为打分的一个因子这样老记忆不会永远霸占上下文新记忆也有机会被用到。5.2 记忆的定期整理与合并记忆积累到一定量之后会出现大量语义重复的条目。比如“用户喜欢简洁回复”“用户不喜欢啰嗦”“用户偏好短答案”这三条其实是一件事。我一般每周跑一次整理任务用聚类把相似记忆合并成一条保留置信度最高的表述。这个整理任务本身也可以用 Agent 来做让它读一批记忆输出合并建议人工确认后执行。整理不是为了省空间是为了让检索结果更干净减少模型在矛盾信息之间纠结的概率。5.3 从“记忆”到“经验”的升级路径最后说一个我一直在实践的方向把零散的记忆升级成可复用的“经验”。记忆是“用户上次问了什么”经验是“这类问题应该怎么处理”。前者是数据后者是策略。具体做法是当同一类记忆反复出现比如同一个报错被问了 5 次就触发一次“经验提炼”把处理过程抽象成一个 Skill 或者一条规则写进长期记忆的高优先级区。这样 Agent 下次遇到同类问题不用重新推理直接调用经验即可。这才是记忆系统真正的价值让 Agent 越用越聪明而不是越用越臃肿。我在实际项目里观察到一个现象当记忆系统做到“写入有筛选、存储有结构、检索有重排、更新有衰减”这四件事之后Agent 的对话轮次平均能延长 3 到 5 倍而不出现明显的行为退化。这个提升不是来自模型本身而是来自记忆管理的工程细节。踩过几次坑之后我越来越确信Agent 的上限由模型决定但下限由记忆和上下文管理决定。把这块做扎实比盲目追新模型带来的收益更稳定。