Agent Planner 生成的计划为什么不能直接执行？怎么校验和动态重规划

面试官问：“Planner 已经把任务拆成步骤了，为什么还要做计划校验？”

一个很危险的回答是：“因为大模型偶尔会幻觉，所以再让模型检查一遍。”

问题不只在于模型可能写错，而在于“计划”连接了自然语言目标和真实工具。一份看起来顺畅的计划，可能引用不存在的工具、漏掉必要前置步骤、使用无来源参数、超过预算，甚至包含当前用户无权执行的动作。它如果直接进入 Executor，模型的一次语言错误就会变成系统行为。

因此，LLM Planner 输出的是候选计划，不是执行授权。工程系统要把候选计划变成可检查对象，逐层验证，再一次释放一个可以安全执行的节点。

先给出 30 秒回答

Planner 输出的计划可能漏步、依赖冲突、引用不存在的工具、缺少参数来源或包含越权动作，所以不能直接交给执行器。我会先约束它输出结构化计划，再依次检查字段完整性、依赖图、工具与参数、权限、预算和完成条件。执行中如果新的 Observation 让某个前提失效，就冻结已验证结果，只重规划受影响节点；用户目标改变、关键状态不可信或工具能力整体变化时，才全量重建。每份计划、状态和重规划原因都带版本进入 Trace，写操作另外记录幂等键与副作用状态，避免计划变化后重复执行。

这段回答把四个层次说清了：计划是数据、校验分层、重规划有范围、执行有历史。

为什么“步骤写得合理”还不够

人阅读计划时容易被语言流畅度影响。模型写出“先收集资料，再做比较，最后生成报告”，逻辑似乎没有问题，但执行器仍然不知道：收集哪些资料、使用哪个工具、输入从哪里来、怎样判断收集完成、资料缺失时怎么办。

可执行计划必须回答机器问题，而不是只回答人类的阅读问题。

计划可能引用不存在的能力

模型根据训练知识写出一个工具名，并不代表当前系统真的注册了它。即使名字存在，版本和参数也可能不同。工具注册表才是能力事实来源。

计划可能漏掉必要步骤

教学场景中，模型计划直接“读取记录并发送结果”，但业务要求先做身份和数据权限检查。漏掉的不是优化步骤，而是不能绕过的边界。

计划中的参数可能没有来源

模型写出日期、对象 ID 或过滤条件，却无法指出来自用户输入、当前状态还是工具结果。参数看起来合法，也可能是猜出来的。