第 2 章 规划-执行-观察：先想清楚，再动手
为什么 Agent 会"边做边偏"
我们接着上一章那个修 bug 的场景往下想。
Agent 接到"帮我修用户登录 bug"这个任务后，如果没有任何约束，它的典型反应是：立刻开始读代码、猜问题、改文件。问题在于——它一边探索一边决定下一步，很容易被中途看到的东西带偏。
比如它读到一个可疑的函数，就停下来深挖，结果挖了半天发现跟登录 bug 没关系；或者它改到一半，看到另一个文件里有个"好像相关"的东西，就顺手改了，结果把本来好的功能改坏了。
这就像一个人做事没有计划，想到哪做到哪。短任务可能没事，任务一长、步骤一多，就跑偏了。
这一章讲三个递进的模式，专门对付这个问题：
- Plan-Then-Execute（先计划再执行）：让 Agent 先写出完整计划，再开始动手。
- Planner-Worker 分离：把"做计划"和"干活"拆给不同的 Agent，各司其职。
- 阶段分离（Discrete Phase Separation）：把"调研、规划、实现"分成隔离的阶段，每阶段单独开会话。
模式一：先计划再执行（Plan-Then-Execute）
问题
当"规划"和"执行"混在同一个循环里时，Agent 每做一步，都要看着上一步的结果来决定下一步。这带来两个麻烦：
- 容易跑偏：中间结果会带着 Agent 走向意想不到的地方。
- 不安全：更严重的是，如果中间结果来自不可信的外部数据（比如网页抓取的内容、某个工具的输出），它甚至可以"劫持"Agent 的决策——诱导 Agent 去调用不该调用的工具。这就是所谓的 prompt injection（提示词注入）的一种。
方案
把推理拆成两个明确的阶段：
- 规划阶段：Agent 在接触任何不可信数据之前，先写出一份固定的工具调用计划。
- 执行阶段：一个确定性的控制器，严格按计划执行。中间结果可以影响"参数"（比如搜什么关键词、传什么参数），但不能改变"做哪些步骤"。
一句话：战略决策在动手前就定了，执行阶段只管照做。
计划 = LLM.制定计划(任务) # 一份固定步骤清单
for 步骤 in 计划:
结果 = 工具.运行(步骤) # 结果只影响参数，不影响步骤
暂存(结果) # 输出被隔离，不反过来改计划证据
- 论文（Parisien 等人，2024）报告：先规划再执行，任务完成率提升 40%-70%，幻觉减少约 60%。
- Claude Code 的 "plan mode"（计划模式）就是这个思路的产品化：先让 Agent 出方案，人审阅、修改、批准后，Agent 才开始动手。对复杂任务，成功率能提高 2-3 倍。
- LangChain 也有对应的
PlanAndExecute组件，把 planner（规划器）和 executor（执行器）拆成两个 Agent。
怎么用
适合这类任务：动作集合是已知的，但参数是变化的。比如：
- 邮件和日历助手（动作就是"读邮件、发邮件、建日程"这些固定动作）
- SQL 助手（动作是查表、执行查询）
- 代码评审助手
一个实用建议："哪些任务需要先规划"的边界，会随着模型变强而移动。Anthropic 的 Boris Cherny 说过一段很实在的话——新模型更聪明了，以前需要规划的任务，现在一句话就能搞定。所以不要死守"所有任务都先规划"，要看你用的模型能力而定。
取舍
- 好处：控制流非常稳，不会被中间内容带偏。
- 代价：灵活性有限——如果任务本身很开放、需要边做边发现，死板的计划反而碍事。
- 要注意：虽然"做哪些步骤"被锁死了，但"步骤的输出内容"仍然可能被污染（比如让 Agent 生成的邮件正文里被塞进坏内容）。
模式二：Planner-Worker 分离
问题
Plan-Then-Execute 解决的是"单个 Agent 先想后做"。但如果任务是超大工程——几百万行代码、几百个文件、要做几个星期——单个 Agent 再会规划也撑不住。而且让很多 Agent 平级地一起干，会互相踩脚：
- 两个 Agent 可能改同一个文件，产生冲突。
- 谁都不愿意碰"难啃的硬骨头"，净挑简单安全的活干。
- 没有人对整体方向负责。
方案
把 Agent 分成上下两级，各管一摊：
- Planner（规划者）：负责持续探索代码库、拆解任务、制定计划。它自己还可以再派生子规划者，让规划这件事本身也能并行、递归。
- Worker（执行者）：从计划里领任务，然后专注地把它做完。不操心别的 Worker 在干嘛，也不操心全局——闷头干完，提交改动。
- Judge（裁判）：每个周期结束时，判断目标达成了没有，要不要进入下一轮。
每一轮都重新开始（带着上一轮的精炼结果，但上下文是新的），这样能对抗"越做越偏、钻牛角尖"的问题。
证据
- Cursor 团队在生产环境验证过：上百个 Agent 并发运行数周，处理超过 100 万行代码的巨型代码库。
- 学术界早就有了理论支撑：分层强化学习（Hierarchical RL）研究了几十年，核心思想就是"规划-执行分离"。
- Anthropic 的 initializer-maintainer、AMP 的 factory-over-assistant 等实现，都印证了这个模式的价值。
怎么用
适合这些场景：
- 巨型代码库：人类团队要干几个月的项目。
- 从零构建复杂系统：比如做一个浏览器、一个 Excel 的替代品。
- 大规模迁移：把整个项目的框架从 A 换到 B。
- 性能重写：为了速度，用另一种语言重写关键模块。
实施要点：
- 不同角色用不同模型：规划可能适合"思考型"模型，执行可能适合"编码型"模型，不必强求同一个。
- Worker 要隔离：让它只管自己的任务，别让它操心协调。
- 每轮重新开始：对抗长上下文的漂移。
取舍
- 好处：能处理单 Agent 完全撑不住的大工程；并行度高。
- 代价：架构复杂，需要额外的协调和裁判逻辑；对小型任务是大炮打蚊子。
- 注意：层级越深，越需要一个好的裁判来把关，否则错误会逐层累积。
模式三：阶段分离（Discrete Phase Separation）
问题
你有没有见过 Agent"一心三用"？一边调研需求，一边想实现方案，一边已经开始改代码了。结果往往是：调研不深入、计划很模糊、代码也不怎么样。
原因在于：在一个会话里同时做探索、思考、执行，会互相污染。上下文里塞满了各种优先级冲突的信息，Agent 没法专心做好任何一件事。
方案
把开发流程拆成彼此隔离的阶段，每个阶段用独立的会话、全新的上下文窗口，只专注于一个目标：
- 调研阶段：深入探索需求、现有代码、约束条件。只做背景调查，完全不考虑实现。
- 规划阶段：制定结构化的实现路线图，定义清晰的步骤和依赖。不被写代码分心。
- 实现阶段：按计划逐步执行，专注代码质量和功能。
最关键的原则：阶段之间只传递"精炼后的结论"，不传完整的对话历史。这样既防止了上下文污染，又保住了必要的信息流。
证据
这个模式来自 Ambral 团队的实践（Sam Stettner），Claude 官方博客也有分享。它本质上是对"上下文是宝贵资源"这一思想的直接应用——每个阶段用最合适的模型和最新的上下文，事半功倍。
怎么用
适合这些场景：
- 大而复杂的任务，需要先搞清楚"到底要做什么"。
- 需要严格按流程推进的工程（调研 → 方案 → 实现）。
- 当发现"一个会话里做太多事"导致质量下降时。
实施要点：
- 阶段之间用精炼摘要交接，而不是把整个对话搬过去。
- 不同阶段可以用不同模型（比如调研和规划用更强的推理模型，实现用更快的编码模型）。
取舍
- 好处：每个阶段质量更高；上下文干净；可以针对不同阶段选模型。
- 代价：交接需要额外设计（摘要怎么打、信息丢不丢）；对简单任务反而繁琐。
三个模式怎么选
| 场景 | 推荐模式 |
|---|---|
| 单个 Agent 做多步骤任务，容易跑偏 | Plan-Then-Execute |
| 超大工程，几百个文件几百万行代码 | Planner-Worker 分离 |
| 大而复杂、需要先调研再规划再实现 | 阶段分离 |
| 任务很小、模型很强 | 什么都不用，直接做 |
三个模式不是互斥的，常常组合使用：比如先阶段分离（调研/规划/实现），实现阶段内部再用 Plan-Then-Execute 锁死步骤，项目足够大时再套上 Planner-Worker 的层级。
实践清单
- 多步骤任务：先让 Agent 出计划，再批准执行
- 涉及不可信外部数据（网页、文件）时：必须锁死"做哪些步骤"
- 超大项目：拆成 Planner + Worker + Judge 三层
- 大而复杂的任务：按"调研 → 规划 → 实现"分阶段，只传精炼结论
- 阶段间用摘要交接，不用完整对话历史
- 记住：模型越强，需要显式规划的任务越少
本章小结
- Plan-Then-Execute：先计划后执行，锁死控制流，防跑偏防注入。
- Planner-Worker 分离：规划者拆任务，执行者闷头干活，裁判把关——专治超大工程。
- 阶段分离：调研、规划、实现各自开会话，只传精炼结论，防止上下文污染。
- 三个模式层层递进，也可以组合使用。
下一章，我们讲"让 Agent 学会检查自己的作业"——反思闭环（Reflection）模式族。