先说结论：Agent聊着聊着把前面说过的忘了，十有八九不是模型笨，是你的上下文没管好。我们做客服机器人那阵子被这事坑了快两周，记一下。

场景很典型。用户开头报了订单号、说自己是华南区的，聊到第五六轮问"那我这单啥时候发货"，Agent反手来一句"请提供您的订单号"。用户当场就炸了，说我刚说过。

一开始我以为是模型上下文窗口不够，把窗口调大，没用。后来打日志才发现，问题出在我每轮只把最近2轮对话塞进去——为了省token,我自作聪明做了个"只留最近N轮"的截断。结果用户开头给的关键信息（订单号、地区）在第三轮就被截没了。

改法分三步，按重要性排：

1. 关键实体单独抽出来存，别混在对话历史里截。我加了个轻量的"会话变量"，第一次识别到订单号/手机号/地区就写进去，每轮拼prompt时这几个字段固定带上，不参与截断。这一步解决了八成问题。

2. 历史压缩，别硬截。超过一定轮数，把早期对话让模型自己总结成一段话（"用户是华南区VIP，咨询订单X发货时间，已确认地址无误"），新对话接在摘要后面。比硬切干净多了。

3. system里写清楚"已知信息"。把抽出来的变量回填进system提示，明确告诉它"你已经知道用户订单号是X,不要再问"。

讲个我当时踩的真坑：摘要那步一开始我让它每轮都总结一次，结果首字延迟从八百毫秒飙到两秒多，用户体感卡。后来改成"超过6轮才触发一次摘要"，平时不动，这才平衡过来。所以别无脑上摘要，它是有成本的。

还有个细节容易忽略——多轮里用户改主意了怎么办。比如他先说要发顺丰，后面改成京东，你的会话变量得能覆盖更新，不能只写不改。我们这块漏了一版，导致改了地址还按老地址提示，又返工。

工具我没自己从头撸框架。会话变量、历史摘要、多轮编排这些，我是在一个零代码就能搭智能体的平台上拖出来的，可视化配节点，省了写一堆胶水代码的事。说实话它的多轮记忆也不是开箱完美，会话变量的过期策略得自己想清楚（用户隔天再来，这些变量留不留、留多久），平台不会替你做这个决定。

最后一句经验：上下文管理的核心不是"塞得越多越好"，是"该记的牢牢记住，不该带的别带"。token是有限的，信息密度才是关键。

（模型/API我走的讯飞 MaaS，现成调，没自己部署算力，省心。）