一个 Agent 正在执行"查找某家公司最近一年的公开融资记录，并整理成表格"的任务。
Planner 给出的计划很顺：先搜索公司信息，再查询融资新闻，最后汇总。可执行到第二步时，Tool 返回了空结果。Executor 再试一次，还是空。问题来了：应该继续 Retry，换参数再搜，还是直接 Replan？
更麻烦的是，假如 Tool 返回的信息证明 Planner 一开始的假设就是错的呢？
这类问题看起来是在讨论 Retry、Replan、Planner 和 Executor 的职责，背后真正的问题其实只有一个：当现实反馈和原计划开始偏离时，一个 Agent 应该如何判断"继续执行"还是"重新思考"？
如果这个判断机制没有设计好，再聪明的 Planner，也可能把 Agent 带进死胡同。
Replan 的触发条件，不应该是"失败"，而应该是"计划失效"
很多 Agent 系统最容易犯的错误，是把 Replan 理解成一种高级版的 Retry。
Tool 调用失败了，Replan。
搜索没有结果，Replan。
参数写错了，Replan。
这样做的问题是，Planner 会被大量局部故障反复唤醒，系统变得昂贵、迟缓，而且计划不断抖动。
真正应该触发 Replan 的，不是某一步"没有成功"，而是出现了足够证据说明：
继续按照当前 Plan 执行，已经很难达到原目标。
比如计划要求先获取 A，再利用 A 查询 B。如果 A 的接口只是临时超时，计划逻辑没有问题，Retry 就够了。
但如果执行后发现 A 根本不存在，后面的 B、C、D 全部依赖 A，那么问题已经不在当前 Tool，而在整个路径。
可以把两者理解成导航。
你开车去机场，遇到一个红灯，不需要重新规划路线，只需要等一下。这是 Retry。
如果前方道路已经封闭，而且后续三公里都无法通行，就应该重新导航。这才是 Replan。
所以判断 Replan 最重要的问题不是：
"这一步失败了吗？"
而是：
"这个失败有没有破坏原计划成立的前提？"
这个区别，会直接决定一个 Agent 是稳定执行，还是遇到一点波动就反复推翻自己。
Tool 返回空结果，先判断"没找到"意味着什么
Tool 返回空结果，是 Agent 设计里非常典型的灰色地带。
因为空结果至少可能代表四种不同情况：
查询条件写错了；
搜索范围太窄；
数据源暂时异常；
目标信息确实不存在。
这四种情况虽然表面上都是 []，处理方式完全不同。
假设 Agent 要查"某用户最近 30 天的订单"。
第一次返回空结果，如果使用的是复杂过滤条件，可以先减少约束重新查询。这属于 Retry，因为你仍然相信原来的任务路径正确，只是在修正执行参数。
第二次换了一组合理参数仍然为空，可以尝试另一个等价数据源。这仍然可能属于 Retry，只不过是工具层面的恢复。
但如果多个可靠来源都说明这个用户根本没有订单，那么继续查询就没有意义了。
此时需要重新检查原计划。
原计划也许是：
"找到最近订单 → 查询物流 → 判断是否延期。"
现在"最近订单"这个前提已经不成立，后面两步自然失去意义。Agent 应该 Replan，例如改成：
"确认无订单 → 检查任务是否指向了错误账户 → 必要时向用户询问。"
因此，Retry 和 Replan 可以用一个很实用的标准区分：
如果改变的是"怎么做这一步"，优先 Retry；如果必须改变"接下来做哪些步骤"，就进入 Replan。
这个标准比单纯统计失败次数可靠得多。
当 Tool 和 Plan 冲突时，事实应该高于计划
更危险的情况，不是 Tool 没返回结果，而是 Tool 返回了一个 Planner 没预料到的结果。
比如 Planner 假设：
"用户已经创建了项目，所以先读取项目配置，再修改部署参数。"
Executor 调用 Tool 后却发现：项目根本不存在。
这时如果 Executor 仍机械执行下一步，就会出现一种很典型的 Agent 故障：计划已经脱离现实，执行器却还在忠实完成计划。
Plan 不应该被理解成命令，更像是一组基于当前信息做出的假设。
Planner 在生成计划时拥有的信息永远有限。Tool 执行之后，系统获得了新的事实。只要新的事实可信度更高，就应该允许它推翻旧假设。
比较合理的信息优先级是：
最新可验证事实 > 计划中的假设 > Planner 的推测。
这也解释了为什么 Agent 不能只有"计划---执行"两层。
中间还需要一个判断过程：
当前 observation 是否符合 Plan 的预期？
如果不符合，是局部异常，还是计划假设错误？
这个变化是否会影响后续步骤？
Replan 并不是 Planner 对自己工作的"返工"，而是 Agent 吸收新信息的正常机制。
一个完全不 Replan 的 Agent，本质上是在假装环境不会变化。
Planner 生成错误计划，不能只靠 Planner 自己发现
还有一个容易被忽略的问题：Planner 如果一开始就错了，谁来发现？
如果答案还是 Planner，就会出现逻辑上的漏洞。
Planner 认为自己的计划合理，因此生成了这个 Plan。执行过程中如果没有外部反馈机制，它通常也没有理由突然意识到自己错了。
真正能发现错误的人，往往是离现实最近的 Executor。
例如 Planner 安排：
-
获取文件；
-
解析文件；
-
从文件中提取联系人；
-
给联系人发送邮件。
Executor 执行第一步后发现文件已经被删除。
这时候 Executor 获得了 Planner 当时并不知道的信息。
因此，一个可靠的 Agent 系统需要把"发现计划失效"的职责分散出去。
Planner 负责提出路线。
Executor 负责观察执行现实。
Tool 提供环境反馈。
Validator 或控制层判断目标是否仍然可达。
这样设计之后，Planner 就不再是系统里唯一的"聪明角色"。
这很像一家公司的项目管理。制定季度计划的人不可能预见所有变化。真正发现供应商延期、客户需求变化、接口不可用的人，往往是执行现场的人。
如果现场的人只能报告"任务失败"，却没有机制指出"原计划已经不成立"，组织只会不断重试错误方案。
Agent 也是一样。
Executor 可以改动作，但不应该悄悄改目标
那么 Executor 到底有没有权修改 Plan？
答案取决于修改的层级。
如果任何微小变化都必须调用 Planner，系统会非常僵硬。例如 API 限流后等待几秒、搜索关键词稍作调整、同一个 Tool 更换分页参数，这些都没必要重新规划。
Executor 应该拥有一定的局部自治权。
一个实用的边界是：
Executor 可以修改战术，不能私自修改战略。
换参数、换等价 Tool、增加一次校验、调整步骤顺序，只要不改变目标和关键假设，可以由 Executor 自己处理。
但如果要删除关键步骤、改变任务目标、采用完全不同的信息来源，或者新的动作会带来明显成本和风险，就应该交回 Planner Replan。
例如用户要求："比较 A 和 B 两份合同的付款条款。"
Executor 发现 A 文件格式无法解析，于是换一个解析器，这是局部调整。
如果 Executor 找不到 A，却自行决定："那我只分析 B"，这就已经改变了任务含义。它没有权偷偷做这个决定。
一个好的 Executor，不应该只是 Plan 的遥控机械臂，也不应该成为另一个隐藏 Planner。
它需要的是有限授权。
一个更实用的判断框架：先问三个问题
真正落到系统设计上，可以给 Executor 一个很简单的决策顺序。
遇到异常结果时，先问：
这一步还有没有合理的替代执行方式？
有，就先 Retry，例如改参数、换等价工具、修正格式。
再问：
新的 observation 有没有破坏后续步骤依赖的前提？
没有，就继续执行。
有，就停止沿原路径前进。
最后问：
后续还能通过局部调整完成原目标吗？
如果只是局部调整，Executor 可以处理。
如果需要重新选择路径，就交给 Planner Replan。
这个流程最大的价值，在于它没有把 Retry 和 Replan 当成两个机械动作，而是把它们放进一个证据驱动的控制循环：
Plan → Execute → Observe → Evaluate → Continue / Retry / Replan。
真正成熟的 Agent，并不是能够提前生成一份完美计划。
因为现实环境中，完美计划几乎不存在。
更重要的能力，是知道什么时候继续相信自己的计划，什么时候承认环境已经提供了新的证据。
所以设计 Replan 机制时，与其规定"失败三次就 Replan"，不如建立一个更清晰的原则：局部执行失败，修复执行；计划前提失效，修复计划。
Planner 负责提出下一条可行路线，Executor 负责让计划与现实不断对齐。两者之间真正重要的，不是谁拥有更大的权力，而是谁能够最早发现：我们现在走的这条路，已经不是通向目标的那条路了。