为什么单轮表现很好，聊到第五轮就开始跑偏

很多智能体在演示时表现不错：问一句答一句，答案准确、格式漂亮。可一旦进入真实业务对话，到第三、第五轮就开始出现三类症状——忘了前面说过什么、把两件事的信息混在一起、反复追问已经回答过的内容。这不是模型能力问题，而是上下文与记忆的设计问题。

一次对话里，模型能看到的只有当前这次请求带上去的内容。它没有「记忆」，所谓记忆全都是工程侧在每次请求前拼装出来的。拼什么、拼多少、按什么顺序拼，直接决定了多轮体验。以下三层是最基本的拆分方式，做 AI 智能体定制开发时如果不把这三层分开设计，后面几乎所有问题都会纠缠在一起。

三层混在一起的典型后果是：把用户偏好当成企业规则回答，或者把企业制度塞进用户档案。区分标准很简单——会随人变的进第二层，会随制度变的进第三层，只对本次对话有效的留在第一层。判断错了，写入就会污染长期数据，而这种污染很难被发现，因为它只在特定人群的特定问题上才表现出来。

上下文预算：先分额度，再谈拼装

上下文窗口看起来很大，但真正能用的远少于标称值。一次请求的消耗大致包括：系统提示词、工具定义、检索到的知识片段、历史轮次、当前问题、预留的输出空间。其中工具定义和系统提示词是固定开销，往往占到三成以上。

裁剪顺序里有一个反直觉的点：历史轮次不能整段砍，要砍中间的闲聊，留最早的任务约束。因为用户在第二轮说的「预算不超过 5 万」「只考虑本地供应商」这类条件，往往比第八轮的寒暄重要得多。实务做法是把历史分成三段：开头 2 轮（任务定义）、最近 6 轮（当前进展）必须保留，中间部分压缩成 3-5 行摘要。

摘要本身也有坑。让模型自由摘要，它倾向于保留自己说过的话，而不是用户强调的条件。所以摘要要用结构化模板，明确要求输出四项：用户目标、硬约束、已确认结论、待确认事项。这四项之外的都可以丢。

写入策略：什么该记，什么绝不入记忆

记忆的价值取决于写入的克制程度。写得越随意，检索时噪声越大，最后反而拖累回答质量。建议按四类分别处理：

• 必写：用户明确表达的身份与角色、长期有效的偏好（语言、单位、格式）、已办结事项的结论与编号、明确说过的「以后都这样」。
• 条件写：本次未完成的任务状态，写入时带过期时间（建议 7-30 天），过期自动失效，避免下次对话时模型接着上次的话头答非所问。
• 不写：过程中的试探性表述、被用户否定的方案、模型自己的推理过程。这类内容写进去，下次检索时会被当成事实引用。
• 绝不写：证件号码、银行账号、完整住址、健康与家庭情况等敏感信息。业务流程里确实需要时，只在当次会话内使用，落库前做脱敏或只存摘要标识。

实践中最稳的是第三种为主、第二种兜底的组合。关键节点由业务定义，比如「确认报价」「提交申请」「客户明确拒绝」，节点一确认就写一条记忆，条目少、语义强，检索命中率高。会话结束时再补一次兜底抽取，处理那些没走到节点就结束的对话。

记忆冲突与过期：三个字段解决大部分问题

长期记忆一旦开始积累，就会出现自相矛盾的条目：三月记的「偏好语音沟通」，八月改成「只用文字沟通」；去年记的「负责华东区」，今年调岗到华南。如果不处理，模型会随机引用其中一条。

解决方式不需要复杂算法，三个字段就够：生效时间、来源轮次、置信度。冲突时按「时间新者优先、来源为用户明示者优先、置信度高者优先」的顺序裁决，三条都相同时取最近写入。检索阶段只召回同一主题下最新的 1-2 条，不要把所有历史条目一起塞进去。

过期策略建议按类型分层：偏好类记忆 12 个月复审，任务状态类 7-30 天失效，身份与角色类跟随组织变动事件更新（不要靠时间推断）。另外必须提供删除入口——用户要求删除某条记忆时，要能真正删掉并留下操作记录，这既是体验要求，也是合规要求。

还有一个常被漏掉的场景：同一个用户在不同渠道（客户端、企业内应用、外部渠道）来的对话，记忆是否共享。建议共享，但渠道带来的权限差异要在检索前过滤——低权限渠道不能召回高权限事项的记忆，否则会通过记忆泄露信息。

五类翻车复盘

复盘一：摘要吃掉关键约束。某采购助手项目，用户在第二轮说「只比价三家以上供应商的产品」，到第八轮模型给出了单家报价的建议。原因是历史压缩时摘要只留了「用户在询价」，丢了硬约束。改法是把硬约束单独抽成结构化字段，不参与摘要压缩，每轮都带上。

复盘二：记忆串人。同一台设备多人使用，用设备标识做记忆主键，导致 A 的偏好被 B 继承。改法是主键必须落到账号，无账号场景改用当次会话临时档案，会话结束即清。

复盘三：旧制度当现行。知识库里同一份制度存了三个版本，检索按相似度命中了旧版里更详细的条款。改法是文档入库时带生效日期与失效日期，检索时先按日期过滤，再做相似度排序。

复盘四：无限追问。模型每轮都问一次「请问您的订单号是多少」，用户已经回答过两次。根因是工具调用结果没有回写进历史，下一轮上下文里没有订单号。改法是工具结果作为独立消息追加进历史，并标记为「已确认事实」。

复盘五：上下文爆掉后静默降级。超限时框架自动截断，不报错，回答质量悄悄下滑，测试阶段完全看不出来。改法是给上下文长度设监控指标，超过 80% 就打点告警，并把「本轮历史被截断」写入日志。

这五类问题与模型强弱基本无关，全部是工程侧的记忆管理问题。安徽好牛软件有限公司在做智能体交付时，会把这几条作为上线前的必查项逐条核对，因为它们在演示环境里几乎不会出现，只在真实多轮使用中暴露。

验收指标：四个数看多轮质量

多轮能力不能靠人工聊几轮来验收，需要可统计的指标。四个够用：

其中重复追问率最值得先做，因为它实现成本最低——只要在日志里统计同一字段被问两次的次数，就能定位到记忆写入的断点。很多团队做完这一项，多轮体验就有明显改善，因为问题往往集中在两三个固定字段上。

成本这一项要提前算清楚。记忆不是免费的：每轮多带 800 token 的历史，一万次对话就是 800 万 token 的额外开销。所以在设计阶段就要定一个「上下文字数上限」，超过上限必须裁剪，而不是靠模型窗口硬撑。安徽好牛软件有限公司在评估阶段通常会建议客户先按日均对话量估一个月的调用成本，再决定记忆保留多久、检索几条。

常见问题解答

Q1：上下文窗口已经很大了，还需要单独做记忆吗？

需要，两者解决的不是同一个问题。窗口解决的是「一次能看多少」，记忆解决的是「跨会话还能不能想起来」。而且窗口越大，成本越高、噪声越多，长上下文里模型抓重点的能力反而下降。实务上的组合是：窗口用来放本次对话的完整轮次与检索结果，记忆用来放跨会话的稳定事实，二者通过检索而不是全量注入来衔接。

Q2：记忆存在向量库里可以吗？

可以，但不建议只存向量库。身份、角色、偏好这类需要精确匹配和更新的信息，用结构化表更可靠，因为要支持按用户查、按时间排序、按条删除。向量库适合存语义化的历史摘要，用于模糊召回。稳妥做法是双写：结构化表做事实源，向量库做检索索引，删除时两边同步。

Q3：用户说「你记错了」，但记忆里确实有这条，怎么处理？

以用户当前表述为准，并把旧条目标记为失效而不是直接删除。标记失效的好处是保留审计线索，也能避免下次又从别的地方召回到同一条。同时要有一个「记忆纠正」的写入路径，让用户的否定本身成为一条高置信度记忆，优先级高于之前的推断条目。

Q4：多轮对话里，工具调用结果要不要全部留在上下文？

不要全部留，但关键结果必须留且要结构化。建议只保留三样：调用了什么工具、关键返回值（如订单号、金额、状态）、是否成功。原始返回体（往往是几百行 JSON）在抽取完关键字段后就该丢弃，否则几轮下来上下文就被日志塞满了，真正有用的对话内容反而被挤掉。

Q5：怎么判断记忆设计是否合格，有没有快速自测方法？

有一个十分钟能做完的自测：找三个真实业务场景，每个场景设计 6-8 轮对话，其中必须包含「第二轮给出硬约束、第五轮引入干扰信息、第七轮回扣约束」的结构，然后跑三遍看结果是否稳定。如果三轮里有任意一轮丢了约束或串了对象，就说明记忆设计还不到位。这个方法比看架构图有效得多，因为它直接检验的是上下文拼装的真实效果。