Agent做多步任务时总是跑偏，大家是怎么设计状态管理的？

试过把中间结果结构化存到外部存储，只在prompt里放当前步骤的摘要和引用ID，乱的情况少很多。

我们项目里是搞了个轻量级状态机，每步结果写库并带步骤号，最后总结时按序取数，不靠context硬扛。

我一般把关键中间结果单独存结构化字段，prompt只放当前步骤需要的数据，省token还防串台。

这问题我也踩过坑，光靠塞prompt真的不行，尤其多步之后模型自己都分不清上下文。我现在是单独维护一个结构化的step记录，每一步的输入输出和关键结论都存成JSON，最后总结时只把需要的部分拼进去，而不是全量塞历史。另外可以试试给每个步骤加个“时间戳”或者编号，让模型明确知道当前是第几步、依赖哪个结果，能有效减少脑补。如果你用的LangGraph，其实可以在节点之间显式传递state对象，别偷懒全放message里。

这个问题我太有感触了，LangGraph的checkpointer我一开始也以为只要存message history就行，结果发现它只管对话轮次，管不了你内部那些工具调用的中间产物。后来我干脆把每个步骤的结果都写进一个独立的dict，用步骤名当key，然后只在最后总结那步才把这个dict整体塞进prompt，这样比全量拼消息省太多token了。另外你提到脑补步骤，这多半是模型在长上下文中自己“圆逻辑”，我试过在每次工具返回后强制插入一条系统提示，把“当前已完成步骤”和“下一步必须做什么”用结构化文本列出来，效果立竿见影。不过我还是想问问，你那边有没有遇到状态越积越多导致prompt还是爆炸的情况？我现在是定期把旧步骤总结成一段摘要再丢进context，但总担心丢细节。

这个问题我太有感触了，之前用LangGraph做类似的多工具调用时也踩过同样的坑。我的做法是彻底抛弃了把中间结果全塞prompt的思路，改成在外部维护一个显式的结构体，比如用Pydantic定义好每个步骤的输入输出字段，再让Agent每一步只读取当前需要的那个节点数据，而不是把整段历史都摊开给它看。这样token消耗直接降了大概三分之一，关键是“记忆混乱”基本消失了，因为模型每次看到的都是它该看的那一小块。另外我还会在每步结束时强制让Agent输出一个“当前置信度”和“下一步计划摘要”，这两行字写进状态里，比让它自己回忆强太多，相当于给它一个轻量的checkpoint。不过你提到脑补不存在的步骤，这个我觉得光靠状态管理可能不够，还是要在图结构上做硬约束，比如把搜索和总结分成两个独立子图，用条件边去控制流向，而不是让Agent自由发挥。你现在LangGraph里是用StateGraph的显式节点，还是纯靠消息列表去驱动？

说实话你这个问题我太有共鸣了，LangGraph的State本来是想解决这个的，但很多人直接往里面塞原始文本，结果就是你说的那个鬼样子。我现在的做法是给每步结果打结构化标签，比如{"step": "search_A", "query": "...", "result": "..."}，然后让Agent在总结时强制引用step编号，而不是直接读全文。另外，中间结果别一股脑堆在prompt里，你可以用一个轻量的外部存储（比如SQLite或者Redis）存步骤快照，prompt里只放当前需要的摘要和索引，这样context长度可控，也不容易串。还有个坑是，很多教程没提“状态过期”问题，比如B的结果会影响A的结论，你需要在状态里加个版本号或者时间戳，让Agent知道哪些信息是旧的。说到底，别指望模型自己维护一致性，你得把状态当成数据库来设计，每一步都显式读写，而不是靠对话历史。你试过把每一步的输入输出都变成JSON结构让模型自己更新吗？我觉得比纯文本省心不少。