很多团队在单体 Agent 试点阶段，会把重试想得很简单：失败了就再跑一次，工具报错了就重新调一次，请求超时了就让模型继续往下推理。早期 Demo 里这种做法也许还能凑合，但一旦 Agent 开始接工具、写状态、跨会话执行并产生真实副作用，所谓“重试”就不再是一次无害尝试，而可能变成重复扣费、重复发信、重复写入和上下文漂移的源头。
让单体 Agent 的重试变得安全，真正关键的不是更激进的重试策略，而是持久状态。结合 LangGraph 对 persistence 的设计、Anthropic 对工具使用的约束，以及 Toolformer 对工具调用价值与边界的启发，我们更应该把状态快照、工具契约、会话边界和运行时适配层前置定义；对 TaskPilots 的独立运行 Agent 来说，这正是单体 Agent 从“能跑”迈向“能恢复”的分水岭。
为什么这个问题重要
只要 Agent 会调工具并改真实世界，重试就不再是纯技术细节
单体 Agent 早期最容易给人一种错觉：它只有一个智能体，没有复杂编排，所以失败后直接重来应该很安全。但只要它开始调用搜索、写 CRM、发邮件、创建工单、更新权限或生成外部回执，重试就会立刻触碰业务状态。系统若不知道上一步到底做到了哪里，再次执行就可能把同一动作重复落地。
这也是为什么持久状态不是多 Agent 才需要的能力。单体 Agent 一样会跨请求、跨工具、跨时间边界运行，而运行历史一旦没被可靠保存，后面的每一次恢复都只能靠猜。
无状态重试会把失败从偶发异常放大成持续偏航
很多团队真正先踩到的坑，并不是模型答错，而是模型在错误的历史上继续答对了“下一步”。比如工具已经成功写入，但本地没记下来；或者模型刚拿到半截工具返回值就中断，恢复时又把同一调用重新发了一遍。此时系统表面上是在恢复，实际上是在不断制造新状态。
持久状态的作用，不是单纯保存聊天记录，而是给运行时提供一个可确认的事实层。只有先确认事实，再决定是否重试，单体 Agent 的恢复才可能稳定。
适用场景
最适合从单体 Agent 起步、但已经进入真实业务回路的团队
这套方法最适合那些还没上多 Agent 编排，却已经开始把单体 Agent 接进真实业务系统的团队。典型场景包括：客服 Agent 调工具查询与更新工单、运营 Agent 批量生成并发布内容、内部助手跨会话查知识库和企业系统、销售 Agent 跟进 CRM 并发送客户邮件。它们的共同点是：结构还不复杂，但后果已经很真实。
如果你的系统已经出现“同一个请求失败后不知道该不该重跑”“工具返回成功但状态没跟上”“长会话里越跑越乱”这些信号，说明单体 Agent 已经到了必须补状态层的时候。
不适合的是一次请求内即可闭环、无副作用的轻量实验
如果 Agent 当前只是做摘要、问答或建议生成，既不跨会话，也不调用有副作用的工具，那么完整的持久状态设计可能会显得偏重。此时直接重试通常也不会留下真实后果，重点应该放在提示与输出质量，而不是运行时恢复。
一个简单判断标准是：失败后重新跑一次，是否可能改变外部世界，或者让系统自己也说不清已经做过什么。如果答案是否定的，可以暂时保持轻量；如果答案是肯定的，就该尽快把状态层补起来。
推荐系统结构
先把工具契约、状态快照和会话边界拆清楚
更稳健的单体 Agent 运行时，至少要把三类东西拆开保存：一是工具契约，包括输入结构、输出结构、幂等键和失败语义；二是状态快照，包括当前目标、已完成步骤、工具结果引用和下一步待执行点；三是会话边界，包括这次运行属于哪条会话、何时开始、是否允许跨会话继承状态。只有这些层次分清楚，重试时系统才能判断该重放哪一步，而不是把整段历史再跑一遍。
LangGraph 的 persistence 思路之所以重要，就在于它把运行看成可恢复状态，而不是一段易失推理流。放到单体 Agent 里，这意味着“模型上下文”不应是唯一真相，状态快照才是。
在 TaskPilots 中，让独立运行 Agent 先恢复状态，再恢复推理
映射到 TaskPilots，独立运行 Agent 不应在恢复时直接把上次对话喂回模型继续生成，而应先读取最近状态快照、校验上次工具调用结果、确认当前会话和权限上下文，再决定是否继续推理、是否重试工具、还是是否升级人工。换句话说，恢复顺序应是“先恢复事实，再恢复思考”。
同时，工具链也应通过统一适配层接入，让每个工具都带有清晰的输入输出契约、错误类型和幂等边界。这样单体 Agent 即便只有一个执行体，也能拥有相对可靠的运行时骨架。
风险与失效点
最常见的失控，是无状态重试和未校验工具结果叠在一起
最危险的情况，不是一次失败，而是失败后系统既没有状态快照，又没有验证工具结果，就直接重来。此时重试不仅不能恢复，反而会制造重复动作、覆盖正确结果，或者把原本局部的错误扩散成整段会话偏航。
另一个高频问题是权限扩散。单体 Agent 在长会话里不断累积上下文和工具能力，如果没有明确会话边界与状态清理，旧权限、旧意图和旧结果很容易在后续重试里被误继承，让系统越跑越不像一次受控执行。
高影响步骤必须保留人工兜底和审计证据
并不是补了持久状态就可以把所有重试都自动化。涉及资金、客户承诺、权限开通、配置变更、外部通知等高影响动作时，系统仍应保留人工确认或至少保留显式审计证据。原因很简单：状态能帮助系统知道发生了什么，但不代表每次重试都值得自动继续。
真正稳健的运行时，不只是“能自动恢复”，还应具备“知道何时不该自动恢复”的能力。人工接管点正是为了在这种边界上接住系统。
验证指标
上线前重点验证恢复路径，而不只是成功路径
在发布前，最该测的不是 happy path，而是至少三类恢复场景：工具调用成功但本地状态未写入、工具调用失败且返回不完整、会话中断后跨请求恢复。每一类都要检查系统是否能从最近快照恢复、是否会重复执行副作用、以及是否能明确知道下一步该做什么。
如果条件允许，还应故意注入网络超时、半成功返回和脏状态样例，因为单体 Agent 的真实问题常常出在“做了一半”的中间态，而不是彻底失败。
上线后持续跟踪成功率、失败率、恢复时间和状态一致性
上线后建议至少跟踪四类指标：执行成功率、工具失败率、从失败到恢复完成的中位时间，以及恢复后状态一致性错误的比例。这几项分别对应任务可用性、工具质量、恢复效率和状态层可信度。
此外，还值得单独观察“因重复重试导致的副作用事件数”和“人工接管后发现快照不足”的比例。前者说明状态设计还不够稳，后者说明运行时保存的事实还不足以支撑安全恢复。
下一步 / FAQ
下一步先给现有单体 Agent 画出最小状态模型
最实用的第一步，不是立刻接入更复杂的编排框架，而是先把当前单体 Agent 的最小状态模型列出来：每次运行的 ID、当前步骤、已完成工具调用、关键结果引用、待执行动作、权限上下文和人工接管标记。只要这份清单做出来，你们通常就会立刻发现现在的系统到底缺哪几块事实层。
把这层状态补齐后，再去优化重试策略、工具适配和会话体验，往往会比继续堆 Prompt 更有效。因为单体 Agent 真正缺的，常常不是更强推理，而是更稳运行时。
FAQ
问：只有单体 Agent，也值得做持久状态吗？
答：值得。是否需要持久状态，取决于是否接了真实工具、是否跨会话、是否会产生副作用，而不是取决于你有几个 Agent。
问：保存完整对话历史是不是就够了？
答：不够。对话历史有助于理解语义，但恢复安全重试需要的是运行时状态，例如步骤、工具结果、幂等键和权限上下文。
问：这样会不会把系统做得太重？
答：会增加一些运行时设计成本，但通常远低于重复副作用、错误恢复和事后排障的代价。对已经进入真实业务的单体 Agent，这层投入通常很值。
问：什么时候该从单体 Agent 升级到多 Agent 或工作流系统？
答：当你的状态模型、工具链和恢复逻辑已经明显超出单体 Agent 的可控范围时，再考虑升级。很多团队真正的下一步，不是先上多 Agent，而是先把单体 Agent 的运行时做好。