Planning 与 Goal
给了目标自由发挥的 Agent，目标的质量就是它表现的上限。
Goal：把任务写成可验收的合同
Agent 的失败常常不是执行失败，而是目标模糊导致的“自以为完成了”。好的 Goal 有三个特征：
- 有明确的完成标准。“修复这个 bug”不如“修复这个 bug，并让
pytest tests/全部通过”。可执行、可机器判定的验收标准（测试通过、lint 干净、页面可打开）让 Agent 能自我校验。 - 有边界。明确不做什么同样重要——“只改
auth模块，不要动数据库 schema”能防止 Agent 热心过头的连带重构。 - 有上下文锚点。相关文件、背景约束、参考实现。Coding Agent 实践里常见的
AGENTS.md/CLAUDE.md文件，本质就是把长期有效的 Goal 上下文固化在仓库里。
目标含糊时先反问
成熟 Agent 的一个标志行为：在动手前澄清含糊的需求。给 Agent 配备“信息不足时先提问”的指令，比让它带着错误假设跑二十分钟再返工便宜得多。
Planning：三种规划形态
有了目标，规划解决“怎么走”。按计划与执行的交错程度，分三种形态：
1. 先规划后执行（plan-then-execute）。开始前产出完整计划，再逐步执行。适合结构清晰、中途变数少的任务。风险在于计划基于初始认知，执行中发现的新事实可能让整个计划作废。
2. 交错规划（interleaved planning）。每完成一步，基于最新观察调整后续计划。这是 Coding Agent 的主流形态：Claude Code 的 plan mode 先与用户对齐方案，执行中再动态调整 todo 列表。代价是每次调整都要消耗推理预算。
3. 动态 todo 管理。把计划物化为一份显式的任务清单（文件或工具状态），Agent 每步更新、勾销。它不只是给模型“提醒”自己——更重要的是在上下文压缩后，清单是唯一幸存的任务结构。
text
┌─────────┐ ┌─────────┐ ┌─────────┐
│ Goal │──▶ │ Plan │──▶ │ Execute │──┐
│ 验收标准 │ │ 任务清单 │ │ 逐步执行 │ │ 观察/反馈
└─────────┘ └────┬────┘ └────┬────┘◀─┘
▲ │ 偏差/新信息 │
└──────────────┴────Replan────┘推理预算就是规划预算
规划质量与“思考深度”直接相关，而思考深度是可以购买的：
- 推理模型在规划类任务（架构设计、多文件改动顺序）上显著优于普通模型，但更慢更贵。
- 先规划后执行的隐藏收益：规划用强模型、执行用便宜模型，两种预算分开花。
- 计划本身要落盘。写进文件或清单的计划，可以在上下文被压缩后重新读入——计划是抵抗遗忘的锚。
与编排的分工
Planning 决定“做什么、什么顺序”，但它默认只有一个执行者在跑。当任务可以拆给多个执行者并行、或单窗口装不下整个任务时，就需要 Harness 提供的运行环境与多智能体协作——这正是接下来两章的主题。