主题
Planner / Executor：先决定怎么做，再认真把事做完
今天先记住
Planner / Executor 不是让 Agent “多想一会儿”这么简单，而是把“拆任务”和“执行步骤”分成两个职责。Planner 负责把用户目标拆成可检查的路线，Executor 负责按路线调用工具、观察结果、处理失败。它解决的不是玄学聪明，而是一个具体问题：长任务里，模型一边想一边做，很容易走到一半忘了原目标，或者把临时错误当成最终答案。
它在大地图里的位置
还是这条链路：
txt
用户目标
-> 上下文 / 记忆
-> 规划 / 决策
-> 工具调用 / 外部系统
-> 执行 / 观察结果
-> 评估 / 修正
-> 最终输出前面讲过工具、工作流、上下文、RAG 和向量数据库。今天的 Planner / Executor 位于“规划 / 决策”和“工具调用 / 执行”之间：它把“我要完成什么”翻译成“先查什么、改什么、验什么、什么时候停”。
如果工具调用是手，Planner 就是在动手前把步骤和边界写清楚；Executor 则负责别把锤子当钥匙用。
它到底是什么
Planner（规划器）输出的是计划，不是最终答案。一个好计划通常包含：目标、步骤、依赖、验收条件、可能的失败分支。
Executor（执行器）接收某一步，去读文件、查资料、调 API、写代码、运行测试，再把观察结果返回给系统。下一步可以照计划走，也可以因为观察结果而修正计划。
关键点是：Planner 的产物必须能被检查。比如“优化文档站”太虚；“读取现有侧边栏配置 -> 新增 2026-07-22 课程 -> 构建验证 -> 只提交相关文件”才是可执行计划。
为什么 Agent 里会用到它
长任务最常见的失败，是 Agent 直接进入执行状态：看到一个文件就改，看到一个错误就补，最后虽然忙了一圈，但没有回到用户真正的约束。
Planner / Executor 把失败位置变清楚：如果选题重复，是 Planner 没看历史；如果文件写错目录，是 Executor 没遵守路径；如果构建没跑就提交，是验收条件缺失。这样你不是笼统说“Agent 不稳定”，而是能指出系统哪一层没兜住。
怎么判断它有没有用
如果任务超过三四步，并且每一步会改变外部状态，比如写文件、发邮件、下单、提交代码，就应该显式规划。
如果任务只是“把这句话翻译成英文”或“解释一个报错”，Planner / Executor 大概率过重，一次模型调用就够。
如果计划没有验收条件，它只是待办清单，不是 Agent 计划。每一步至少要知道成功状态是什么。
如果 Executor 可以绕过 Planner 直接做高风险动作，比如删除文件、推送生产、群发消息，那权限边界没有放对。
最近冒出来的词
今天不追新词，先把主线概念讲稳。
一个小例子
txt
Input:
用户说：“生成并发布 2026-07-22 的 AI Agent Daily，接着上一课，不要重复。”
Process:
Planner:
1. 查已有 ai-agent 课程标题。
2. 对照框架路径，判断上一课是向量数据库，下一课应讲 Planner / Executor。
3. 写入 2026-07-22.md，标题不能是日期。
4. 构建 docs-preview。
5. 只提交新课程文件并 push。
Executor:
逐步读目录、写 Markdown、运行 npm run docs:build、git add 指定文件、commit、push。
Output:
新增 /ai-agent/2026-07-22 页面；
提交信息为 docs(ai-agent): add daily lesson 2026-07-22；
无关的未跟踪文件不会进入提交。这个例子可以用来判断真实系统：它有没有把“选题连续性、文件路径、构建验证、提交范围”放进计划，而不是写完正文就自信收工。
常见误区
- 以为 Planner 一定要输出很长计划。计划越长越容易失真，够指导下一批动作就行。
- 以为 Executor 只能机械执行。真正的 Executor 要把观察结果带回来，让系统判断是否改计划。
- 以为有 Planner 就不会犯错。Planner 也会漏约束，所以计划必须能被用户、规则或测试检查。
- 以为所有 Agent 都要拆成两个模型。小任务可以只是同一个模型里的两个阶段，不必过早做复杂架构。
今天自测
- 一个任务从几步开始值得显式做计划？
- 如果 Agent 跑了测试但提交了无关文件，这是 Planner 问题还是 Executor 问题？
- 为什么“先研究一下再处理”不是一个合格的 Planner 输出？