Planner-Executor 拆分：什么时候该拆，什么时候该合

第一天，让单个模型同时做规划和执行，看起来很优雅。三个月后，trace 日志会讲一个不同的故事：Prompt 里负责规划的那部分在工具调用上下文中开始漂移，负责执行的那部分开始幻觉出从未被规划过的步骤。把两者拆开很少是直觉反应。但它经常是正确的选择。

拆分到底买到什么

专门的 Planner 跑在一个干净的上下文里——只有用户请求和可用的工具 schema——产出一份它无法用执行细节污染的计划。专门的 Executor 一次只接收一步、执行、汇报。两个组件都拿到了更小、更锋利的 Prompt。每一个都可以独立替换：便宜的 Executor 配上昂贵的 Planner 是一个真实的成本杠杆，没有拆分你拉不动这个杠杆。

拆分的代价

延迟。每步两次模型调用，Planner 需要修订时甚至三次。对于 2 秒以内的交互式场景，拆分的代价往往太高。诚实的答案是：短任务保留联合循环，只有当任务步数超过 5 步、或者你已经在生产环境观察到联合循环跑题时，才拆分。

Planner-Executor 拆分不是架构上的洁癖。它是对单模型循环在规模下表现出的某个具体失效模式的回应。