失败记录该删还是该留把 Agent 的“从错误中学习”落成上下文设计清单聊 Agent 的上下文工程大多数文章的注意力都花在两件事上怎么提高 KV 缓存命中率、怎么压缩历史对话省 token。这两个问题当然重要但有一个更基础的设计决策常常被跳过——当工具调用失败、返回报错和堆栈跟踪时这些“垃圾信息”是该从上下文里清掉还是原样保留直觉上删掉似乎更合理报错信息又长又臭占上下文窗口还可能“污染”模型。但 Manus 团队在他们的博客《AI代理的上下文工程构建Manus的经验教训》里给出了相反的答案把错误的尝试保留在上下文中。这篇就沿着这条线索对照 AWS 官方博客《Agentic AI 基础设施实践系列三Agent 记忆模块》的记忆分层做法把这个决策整理成一份可操作的清单。一、为什么失败记录值得保留Manus 博客中的原话很直白根据他们的经验改善代理行为最有效的方法之一“出奇地简单”——把错误的尝试留在上下文里。当模型看到一个失败的行动以及由此产生的观察结果或堆栈跟踪时它会隐式地更新其内部信念改变其先验降低重复相同错误的可能性。这个机制其实不需要任何额外工程LLM 是自回归的上下文学习器上下文里“行动 → 报错 → 调整后的行动”这样的序列本身就是一次 in-context 的纠偏示范。你不用写一行“请不要重复之前的错误”模型自己就会学。Manus 团队还提出了一个更深的观点错误恢复是真正代理行为的最明显指标之一但在大多数学术工作和公共基准测试中这一点仍然代表性不足——这些评测通常只关注理想条件下的任务成功。换句话说一个只会顺风的 Agent 不算完整的 Agent。二、别只删错误还要小心“过度正确”的另一面保留错误有一个配套问题上下文里成功的样本也不能太多、太相似。Manus 博客专门警告了少样本示例的陷阱——语言模型是优秀的模仿者如果上下文充满了类似的“行动-观察对”模型会倾向于遵循该模式即使这不再是最优的。他们举的例子很具体用 Manus 审查 20 份简历时Agent 常会陷入一种节奏仅仅因为上下文里看到过就重复类似的行动导致偏离、过度泛化甚至幻觉。这给我们的启示是上下文的“多样性”和“信息量”同样重要。删掉失败记录省下来的那点 token可能远抵不上模型重蹈覆辙的代价但堆满雷同的成功记录同样会让 Agent 变得机械。三、两套记忆错误该留在哪一层光说“保留”还不够得回答“留多久”。AWS 官方博客的 Agent 记忆模块实践提供了一个有用的分层框架短期记忆 对话记录注入。开发者可以在每次生成回复前调用list_events获取短期记忆的对话记录附加到 LLM 的提示中以维护对话连续性。这正对应错误记录的主要存放位置——当前会话的上下文里模型直接“看见”失败过程。长期记忆 语义检索沉淀。对于跨会话的信息用retrieve_memories接口通过语义查询长期记忆例如查询某用户的偏好或某主题的事实知识再把检索到的内容纳入提示。在 AWS AgentCore Memory 的设计中调用CreateEvent保存新事件后预置策略会异步运行 LLM 分析内容产生按命名空间和类型事实、摘要、偏好组织的长期记忆记录每条记录有唯一 ID 供检索开发者也可以通过自定义记忆策略提供自己的提示词只提取某类领域知识。对应到错误处理就有了三层去处当前会话内失败的调用、报错、堆栈跟踪原样保留在上下文中供模型隐式更新先验跨会话但结构化反复出现的错误模式可沉淀为“事实型”长期记忆比如“该 API 的 v2 端点在此环境下返回 404需使用 v1”用户/领域层面与特定环境、特定用户习惯相关的错误教训进入偏好类记忆。四、什么错误值得留一份判断清单结合两篇资料可以给出这样的决策框架可恢复且模型可从中推断原因的错误 → 保留原文。报错信息含参数名、状态码、堆栈的模型能据此修正下一次行动这类是 Manus 经验的核心受益场景。纯粹的环境抖动网络超时等→ 可压缩保留。保留“失败了 大致原因”即可完整重试日志可以精简避免占满窗口。重复出现 ≥2 次的错误模式 → 候选沉淀为长期记忆。单次错误留在会话内即可如果同一类错误跨任务反复出现说明它值得成为跨会话知识。包含敏感信息或超大体积的输出 → 遮蔽而非删除。Manus 博客提到“遮蔽而非移除”的原则——错误记录同样适用可以遮蔽内容但保留“此处曾失败”的事实标记。五、别忘了两个工程约束保留错误记录有两个现实的工程前提一是缓存稳定性。Manus 博客强调上下文要只追加append-only避免修改之前的操作或观察并确保序列化是确定性的——许多语言的 JSON 序列化不保证键顺序稳定会悄悄破坏缓存。这意味着错误记录一旦写入上下文就不要事后“美化”或删改这既是学习需要也是缓存需要。二是上下文预算。AWS 博客给出了一个实际做法在长文档处理的 Agent 项目中当上下文超过指定限额时触发基于 LLM 的压缩机制。也就是说“保留错误”不等于无限保留——应该有一个压缩流程且压缩时应优先保留错误及其教训压缩雷同的成功记录。六、适用范围与局限需要说明的是这套做法有边界报错必须“可解读”。如果工具返回的错误信息本身无信息量比如只有 error模型无从更新先验保留价值有限。改进工具的错误输出格式是保留策略的前置条件。压缩由 LLM 执行时可能丢掉错误细节。AWS 方案中的压缩与记忆提取都依赖模型归纳过程中具体报错参数可能被泛化掉重要教训建议显式沉淀而非依赖自动压缩。跨会话泛化有风险。把某次环境下的错误教训写成长期记忆换环境后可能失效甚至误导长期记忆条目最好附带条件说明。两篇资料分别是 Manus 的工程经验总结和 AWS 的基础设施实践分享属于厂商的一手经验而非对照实验结论具体收益数字需要在你自己的场景中验证。小结“失败该删还是该留”看似是个省 token 的小问题实际上是在选择你的 Agent 的学习方式删掉错误得到一个每次都从零开始、可能重复跌倒的执行器保留错误得到一个会隐式更新先验、越用越顺手的代理。答案并不意外地偏向保留——但要用对地方会话内原样保留、跨会话有选择地沉淀、始终遵守 append-only 与上下文预算约束。错误恢复能力可能正是区分“能跑的脚本”和“真正的 Agent”的那条线。参考资料以下链接为本文使用的公开资料。事实依据与检索摘录保存在本地记录中资料内容与适用范围以原始页面为准。AI代理的上下文工程构建Manus的经验教训Agentic AI 基础设施实践系列三Agent 记忆模块 | 亚马逊AWS官方博客