面试官问 Planning 由谁完成，真正考察的是你能否区分模型的推理能力和 Agent 框架的运行时能力。生产系统里，它们通常不是替代关系，而是协作关系。
先拆开 Planner 与 Runtime 的职责
大模型更擅长理解开放目标、识别约束、拆解任务和根据 Observation 调整后续路径，因此 Planner 往往由模型驱动。但模型输出的计划只是候选结构，不天然具备可执行性、一致性或恢复能力。
Agent 框架或自研 Runtime 更适合定义 Plan Schema、保存步骤状态、解析依赖、调度可执行节点、执行 Tool、Checkpoint、处理超时和控制预算。框架可以承载 Planning，却不会自动替你生成正确计划。
常见实现方式不是只有一种 Planner
ReAct 在每一步根据当前 Observation 决定下一个 Action，没有独立完整计划，适合路径短、反馈密集的任务。Plan-and-Execute 先生成结构化计划，再由 Executor 执行，适合步骤较多、需要展示进度和依赖的任务。
固定 Workflow 或 DAG 完全由开发者预先编排，适合稳定、可枚举的业务流程。复杂任务还可以使用分层 Planner：高层模型拆目标，低层执行器处理具体步骤；Multi-Agent Planning 则让不同角色提出、审查或执行计划。
生产环境通常采用混合规划
完全自由的模型规划灵活，但容易产生不可执行步骤、重复动作、权限越界和计划漂移；完全固定的 Workflow 稳定，却难以处理开放目标。
常见折中是外层用确定性状态图控制阶段和权限，局部节点允许模型拆解或路由；Runtime 对计划做 Schema 校验、工具可用性检查和预算评估，必要时再让模型局部修正。
Replanning 必须由新事实触发
当 API 无权限、资源不存在、用户增加约束或证据推翻原假设时，原计划才真正失效。此时应保留已完成步骤，只修改受影响的后续部分。
如果每执行一步都重新生成全部计划，系统会付出额外 Token 和延迟，也更容易重复已经完成的动作。Runtime 应记录 replan reason、旧计划版本和新计划差异，便于 Trace 和回放。