规划与重试：让 Agent 能收敛

读完这一节，你能做到

1. 说清 ReAct 与 plan-and-execute 的区别，并判断什么任务不该用 Agent。
2. 给重试划出边界：哪些错误能重试、哪些重试只会更糟。
3. 用四道闸把死循环堵住。
4. 让长任务在中途失败后能接着跑，而不是从头再来。

一、两种规划范式

ReAct：边想边做

想一步 → 调一个工具 → 看结果 → 再想下一步

优点是灵活，工具返回什么就调整什么。缺点是步数不可控，容易越走越远。

plan-and-execute：先规划再执行

一次生成 3-5 步计划 → 逐步执行 → 全部完成后汇总

优点是可控、可人工确认、可并行。缺点是计划一开始错了，执行时不会自己纠。

怎么选

问一句：这个任务的最佳路径，能不能提前写出来？

• 能 → 用计划驱动，本质是工作流，Agent 只负责填参数。
• 不能 → 用 ReAct，但要加预算。

生产上的常见形态

先让模型出计划，规则或人工校验计划是否合理，再逐步执行；每一步内部允许一次 ReAct 式的重试。这样既有可控性，也保留灵活度。

二、很多任务不该用 Agent

这是面试里最能体现判断力的一点。

任务特征	更合适的方案
步骤固定、顺序明确	工作流 / 状态机
需要强一致（转账、扣库存）	确定性代码 + 事务
输入结构化	规则引擎
只有"理解自然语言"这一步不确定	只在那一层用模型

判断原则：把模型限制在“必须靠理解才能做的那一步”，其余用代码。Agent 每多一次自主决策，就多一份不确定性。

多 Agent 什么时候值得

绝大多数场景单 Agent 加工具就够。只有三种情况值得拆：

1. 可并行：同时查物流、库存、评价，互不依赖，拆开能显著降延迟。
2. 权限不同：查询只读、执行有写权限。拆开是为了把权限边界画在服务级，而不是靠提示词。
3. 需要对抗：一个生成一个评审，能降低错误率。前提是评审方有明确的判定标准。

拆了之后要额外解决三件事：共享状态放哪、子任务失败怎么传播、成本怎么控（通常是单 Agent 的 1.5-3 倍）。子任务并行时，还要约定统一的输出结构与冲突规则，否则“合并”就退化成拼字符串。

三、重试的边界

重试不是"再试一次"，而是"这次失败的原因，重试会变吗"。

错误类型	能否重试	处理
超时、连接失败、限流	可以	退避 + 次数上限
参数不合法	不能	让模型改参数
权限不足	不能	终止并告知
业务拒绝（库存不足、状态不允许）	不能	换方案或终止
输出格式不符	可以	要求按 schema 重新输出

三个前提

1. 幂等：写操作有幂等键，否则重试就是重复提交。
2. 预算：重试次数与总耗时都有上限。
3. 退避：立即重试会加重下游压力。

一个真实场景

订单已创建但响应超时。这时直接重试会创建第二单——正确做法是拿幂等键查一次状态。

四、把死循环堵住：四道闸

1. 预算：最大步数、最大 token、最大工具调用次数，任一超限就终止。
2. 重复检测：同样的工具 + 同样的参数连续出现两次，直接打断。
3. 无进展检测：连续 N 步没有新增信息（结果相同或为空），判定卡住。
4. 强制收敛：到上限时要求给结论，或明确说"信息不足"，而不是继续调工具。

为什么会死循环

• 工具一直返回空，模型反复换关键词。
• 错误信息不明确，模型无法修正，只能重试。
• 目标本身不可达（权限不够），模型不知道。

对应的根治手段是提高工具返回信息的质量，而不是让提示词喊"不要重复"。

五、中断恢复

长任务（几十分钟、跨多个系统）不能靠一次模型调用跑完。

四件套

1. 状态落库：任务 id、当前步骤、每步输入输出、失败原因。
2. 步骤幂等：同一步重复执行不产生额外副作用。
3. 检查点：每步完成即提交，而不是全做完才写一次。
4. 恢复逻辑：启动时读状态，从最后未完成的步骤继续。

恢复时的三个坑

• 上一步"已发出但结果未知"（超时），必须查状态而不是重做。
• 中断期间外部数据变了，恢复前要重新校验前置条件。
• 恢复后不要重新规划整条链路，否则等于从头开始。

六、常见坑

1. 所有任务都上 ReAct。 步数不可控，成本不可预测。
2. 固定流程硬做成 Agent。 复杂度上去了，稳定性下来了。
3. 所有错误统一重试三次。 参数错误重试一百次也还是错。
4. 只靠提示词防重复。 没有预算和检测，模型照样绕圈。
5. 进度只存在对话里。 一断线全丢，重跑还重复副作用。
6. 超时后直接重做。 最常见的重复提交来源。

七、动手任务：自写 → AI 写 → 对比 → 取舍

四步不跳：① 自己写（限时，关掉补全）→ ② 让 AI 写同一题 → ③ 逐条比对 → ④ 说出保留谁的写法。

① 自己写

1. 给你的场景画一张"终止条件"表：步数上限、token 上限、重复判定、无进展判定。
2. 写出重试策略：哪些错误重试、退避怎么设、几次后放弃、失败后怎么告知用户。

② 让 AI 写同一题

把第 1 题交给 AI，补一句 按“闸门 → 触发条件 → 触发后动作”三列输出，不要只写“设置上限”。

③ 对比要盯的点

• 它有没有把"参数错误"也列进可重试？
• 终止后是"返回已有结果"还是"报错"？
• 有没有区分"重复动作"与"无进展"？

④ 一句话取舍

它给的方案在你这个业务里，哪一条会把正常流程也误杀？

八、自测

1. ReAct 与 plan-and-execute 各适合什么任务？
2. 怎么判断一个任务不该用 Agent？
3. 哪几类错误不能重试？为什么？
4. 死循环的四道闸分别是什么？
5. 死循环的根因通常在哪？
6. 长任务中断恢复需要哪四件套？

参考答案要点：探索性 vs 流程固定；步骤固定、需要强一致、输入结构化；参数错、权限不足、业务拒绝；预算、重复检测、无进展、强制收敛；工具返回的信息质量；状态落库、步骤幂等、检查点、恢复逻辑。

配套题目

★ 越多越该先背；点题目可看完整答案与深入版。

• ★★★★☆ ReAct 和 plan-and-execute 有什么区别？该怎么选？
• ★★★★☆ 多步任务失败时，哪些能重试、哪些绝对不能？
• ★★★★☆ 怎么防止 Agent 死循环和无限调用？
• ★★★☆☆ 多个工具调用时，并发与依赖顺序怎么编排？
• ★★★☆☆ 什么时候真的需要多 Agent？
• ★★★☆☆ 子任务并行执行后，结果怎么合并？