先记住这个答案
当任务步骤少且固定、工具单一、输入输出边界清晰、失败可由重试覆盖时，显式规划模块的收益趋近于零，反而引入额外延迟、token 开销与幻觉步骤风险。应优先用确定性的代码逻辑或提示词链完成，只有目标开放、步骤不可预判时才值得引入由 LLM 驱动的规划。
- 单工具短任务用直接工具调用更可靠
- 规划步骤会放大幻觉与额外 token 成本
- 步骤不可预判或需多工具时再引入规划
规划的机制性代价
每一步规划都要模型通过自回归生成步骤文本，延迟和 token 成本显著增加，而且计划未必可执行。短任务里真正有效的往往只有一两步，规划生成的文本却可能包含虚构的工具名或参数，这种幻觉在无规划时根本不会出现。
显式规划模块把控制权从确定性的代码路径转移到模型概率采样中。单工具短链路下，输入输出约束明确，直接调用工具一次或两次就能完成；硬加规划，不仅让每一步都在探索可能不存在的中间步骤，还破坏了对固定流程的确定性保证。
短询价任务的工程对比
假设某客服系统收到“订单号 A123 的运费是多少”，系统内部已有 getOrderStatus(orderId) 与 calcShipping(itemId, region) 两个工具，链路固定。第一种实现：代码直接调用两工具并对返回格式化；第二种：加一个“规划器”让 LLM 生成步骤列表再依次执行。
在该场景下，规划器往往会带来额外延迟，并可能虚构不存在的工具步骤；去掉规划器后，每次调用成本更低且成功率更稳定，因为固定逻辑下规划器没有发挥空间，反而可能插入伪步骤。
判断边界与翻车条件
任务步骤数较多且不可预判、涉及多个工具按条件选择或需要试探性执行时，去掉规划器会让 prompt 链失控，因为新的分支无法预先硬编码。另一种情况是单工具但对输入文本语义依赖复杂，比如自然语言的模糊条件需要多轮澄清，直接调用会放大错误理解。
经验判断法：若新需求不能写成固定顺序的函数调用，且没有代码能完成分支取舍，再考虑 LLM 规划。即便引入，也先把能确定的固定子序列写成代码，让规划器只负责处理剩余的不确定选择，并给规划器配沙盒来验证每个步骤真实可用。
容易答错的地方
- 认为规划模块能提升一切任务的准确性
- 规划在开放任务里确实有用，但在固定流程上反倒损害准确率，因为生成计划与工具调用都依赖同一模型，额外推理可能编出不存在的步骤。确定性控制流程才能保证精确。
- 把所有 agent 都默认套上“先规划再执行”模板
- 许多优秀生产系统只靠 prompt chaining 或路由即可完成需求，没有必要引入状态敏感的规划器。过度抽象让调试更复杂，也容易让步骤来回重试，增加成本与故障点。
面试官还会怎么问？
若任务步骤少于三步但有多个可用工具，该何时引入规划？
需先看选择是否可写成路由规则：对输入分类并映射到固定工具即可用确定性代码。若输入类别繁多或语义边界模糊，再用 LLM 做单次路由选择，不需要输出多步规划。
不加规划模块时幻觉风险会转移到哪里？
幻觉会转移到单次工具调用参数的生成上：模型可能虚构订单号字段。缓解方式是用结构化工具定义并从用户文本中提取必填参数，必要时加正则校验，比计划级幻觉更容易封堵。
长任务中是否也绝不加显式规划？
长任务若子步骤能被预先确定成固定流程图，就按代码顺序执行，也不需 LLM 规划。只有不可预知步骤的子部分才需要规划，规划范围应被限制在该子部分，而不是整个流程。
参考资料
示例用于理解所注明的运行环境与边界；延伸学习可结合原文中的更多案例。