Agent里多轮对话越聊越乱，有没有靠谱的上下文管理方案？

结构化存工具调用记录是关键，再配合分层记忆，比硬塞历史靠谱多了。

结构化存工具调用记录这个方向我觉得是对的，参数串场多半是因为历史里混了太多自然语言噪音。我们之前是把每轮tool call和结果单独抽出来，按时间戳维护一个状态机，只把当前任务相关的状态喂给模型，token省了不少。不过摘要压缩丢偏好那个问题，建议搞个分层的key-value记忆，用户明确改过的偏好单独存，比让模型从长文本里自己找靠谱。想问下你试过把最近几轮原始消息+更早的摘要混着用吗？比例怎么调比较稳？

我之前也被这个问题折磨过，试了一圈下来感觉单纯堆历史或者粗暴摘要确实不行。你现在这种“改时间”的偏好丢失，本质上是缺了一个状态追踪层，把用户意图的变更和当前任务的关键参数单独拎出来维护。我的做法是把对话历史、工具调用记录和“工作记忆”分开存，工作记忆是个结构化JSON，每次工具调用后强制更新，比如订餐厅后用户说改时间，就直接更新这个JSON里的时间字段，而不是靠模型从长对话里自己找。这样模型每次只需要读最近几轮加当前工作记忆，token省了，准确率也稳。至于长期偏好，建议定期把确认过的信息抽出来存到向量库里，但别全塞给模型，只在需要时检索。你可以看看LangChain的ConversationSummaryBufferMemory，但生产上我更推荐自己写个轻量状态机，或者参考一下CrewAI的上下文管理方式，他们有个叫做ContextRouting的机制。想再问下你，现在工具调用结果返回后，你是让模型自己提炼必要信息，还是直接把原始结果丢回历史里？这点我觉得影响也很大。

试试把工具调用结果单独存结构化状态，对话流只留轻量摘要，能省不少token。

我们项目用分层记忆，短期存会话，长期落库，靠向量检索拉取历史偏好，稳很多。

这个问题挺典型的，我踩过类似的坑。你说的把历史全塞system prompt确实是反模式，模型注意力会被稀释，工具参数串轮次基本就是这么来的。我现在用的做法是把上下文拆成几层：对话历史只保留最近N轮原文，更早的做结构化摘要而不是自然语言摘要，比如把用户偏好、已确认的约束、已完成动作存成JSON字段，这样细节不会丢。工具调用记录我强烈建议单独存，不要混在message历史里，每次只把当前任务相关的工具schema和最近一次调用结果注入，能省很多token也更稳。RAG存关键状态可行但别当万能药，检索噪音反而会引入新的串扰，适合存跨会话的长期偏好，不适合存当前任务的临时状态。可以看看LangGraph的checkpointer机制和MemGPT的思路，前者解决状态持久化，后者解决分层记忆调度，但生产里最后还是得自己写一层状态机来管槽位。你们现在是单Agent多工具还是多Agent拆分？如果是后者，上下文隔离会容易很多。

我最近也在踩这个坑，说下目前试下来比较管用的做法：把工具调用记录单独拎出来用结构化存，每轮只把当前任务相关的工具结果重新注入，别把所有历史都往里堆。另外维护一个独立的slot memory存用户偏好和已确认的状态，摘要只用来压缩闲聊部分，关键字段绝不走摘要。LangGraph的checkpoint机制配合状态机挺适合这种场景，可以把每轮的工具输入输出挂在graph state上，比硬塞prompt干净多了。

我们也在踩这个坑，后来干脆把工具调用记录从对话历史里拆出来，单独用结构化字段存每轮的参数和状态，只把当前任务相关的塞回prompt。摘要那块确实容易丢偏好，可以试试关键槽位不压缩，只对闲聊和中间推理做摘要。另外推荐看看LangGraph的checkpoint机制，它把状态和消息分开管理，多轮工具调用稳不少。

我之前也踩过这坑，后来改成把工具调用结果单独存成结构化状态，比如用JSON记录每轮的intent和参数，只把当前任务相关的片段喂给模型，历史对话只保留最近两轮原文。摘要确实容易丢细节，我现在是摘要加关键实体抽取一起做，用户改过的偏好单独存个变量。你可以看看LangGraph或者AutoGen里怎么做state管理的，思路挺清晰。

工具调用记录确实得单独结构化存，别混在对话历史里，不然模型很容易把参数张冠李戴。我们现在的做法是每轮只带最近几轮原文，再加一份结构化的任务状态（比如当前订单、用户偏好），摘要只用来压缩闲聊部分。关键状态走RAG或者干脆放个状态机里，比硬塞prompt靠谱多了。可以看看LangGraph那套checkpointer思路，状态和消息分开管会清爽很多。

工具调用记录单独结构化存，别混进对话历史，每轮按需注入当前任务相关的状态就行。

工具调用记录确实得单独结构化存，别跟对话历史混在一起，不然模型很容易把参数张冠李戴。我的做法是每轮只把当前任务相关的槽位和最近工具结果拼进prompt，历史对话用摘要加关键实体抽取，像用户改过的偏好就存成键值对而不是靠摘要。纯塞历史或者纯摘要都容易翻车，关键是把状态和对话解耦，LangGraph那套状态机思路可以参考下。

工具调用记录单独结构化存，别塞历史里，每轮只注入当前需要的状态就清爽多了。

工具调用记录单独结构化存确实管用，我们就是这么干的，比全塞上下文靠谱多了。

我们之前也踩过这个坑，后来把工具调用记录单独拎出来存成结构化状态，每轮只把当前任务相关的几条塞回去，效果好很多。摘要压缩确实容易丢细节，尤其是用户中途改的偏好，建议关键槽位单独维护，别全指望摘要。

这个坑我也踩过，多轮工具调用确实容易让模型把上下文搅成一锅粥。我后来是把对话历史拆成两层：一层是滚动窗口的原始消息，只保留最近几轮；另一层是结构化的状态存储，比如用户偏好、已确认的订单参数这些单独拎出来存成JSON，每轮按需注入，而不是全塞system里。这样token压力小很多，模型也不容易被无关历史带偏。摘要压缩确实会丢细节，我现在基本不用它做唯一手段，更多是把它当辅助，关键字段还是靠状态机或schema来维护。工具调用记录单独结构化存储这点很关键，尤其带改时间、改地址这种操作，直接把上一轮的tool_call和结果绑成一个事务块，下一轮只引用对应ID，模型就不容易串参数了。开源的话可以看看LangGraph的checkpointer和memory机制，它把短期状态和持久化分得比较清楚，配合自定义reducer能少写不少胶水代码。不过具体怎么分层还得看你的业务，像订餐厅这种强状态场景，可能状态机比纯RAG更稳。