让 AI 学会"先写计划再干活"：Agent 的规划执行（Planning）设计思路
AutoAgent 是"边干边改"，FlowAgent 是"先定计划再照着打"。两种思路，对应两种任务。
一、同一个需求，两种干法
你让 AI 做一件事：
"生成一篇技术文章，发布到 CSDN，然后微信公众号通知我。"
AutoAgent 的干法（上一篇的主角）：
分析员：拆任务、定策略 → 执行员：生成文章 → 质检员：写得行不行？不行重来
→ 再分析 → 再执行 → 质检通过 → 总结
FlowAgent 的干法（本篇主角）：
先盘工具：我手上有 CSDN发帖、微信通知、搜索 → 能干嘛、参数是啥
再写计划：第1步生成文章，第2步发CSDN，第3步发微信通知
拆成清单：{1: 生成文章, 2: 发布CSDN, 3: 微信通知}
照着干：一步一步执行，干完收工
一个像边走边想边修正的探路者，一个像先画作战图再照着打的指挥官。没有谁更好，只有谁更适合。
二、市面上的 Agent，其实就 4 种设计
在聊正文前，先看一张全景图——所有 Agent 执行链路，本质是这 4 类：
| # | 类型 | 怎么工作 | 典型场景 |
|---|---|---|---|
| 1 | 固定 N 个步骤 | 写死流程，一步步走 | 检索资料、发帖、通知 |
| 2 | 顺序循环调用 | 配一串客户端按序执行 | 简单、动作已分好的任务 |
| 3 | 智能动态决策 | 动态规划→执行→观察→判断完成→出结果 | 大多数市面上的 Agent |
| 4 | 规划分析决策 | 先盘工具能力→规划步骤→拆清单→依次执行 | 流程明确的多步骤任务 |
前 3 种大家比较熟，尤其是第 3 种（AutoAgent 那种）。第 4 种就是我们这篇的主角——它有点类似 manus 的工作方式：先想清楚，再动手。
三、规划执行：四步流水线
这套设计把"干活"拆成 4 个清晰的阶段：
用户一句话
│
▼
① 工具能力分析（只看不动手）
模型盘一下手里有哪些牌：MCP 工具清单、各自功能、参数要求
│
▼
② 规划执行步骤（结合诉求定计划）
模型产出："第1步：…；第2步：…；第3步：…"，明确每步用哪个工具
│
▼
③ 解析规划步骤（文字 → 可执行清单）
程序用正则把规划的 Markdown 拆成 Map：{第1步: 描述, 第2步: 描述, ...}
│
▼
④ 按顺序依次执行
执行器挨个执行每个步骤，调对应工具，干完收工
│
▼
完成 ✅
① 工具能力分析：先搞清楚手里有什么牌
这是整套设计最特别的一步——只分析，不执行。模型先看一遍可用 MCP 工具：搜索、CSDN 发帖、微信通知……每个工具能干嘛、要什么参数、匹配度多高。
为什么要这一步？因为模型自己背不出"这个环境里到底有什么工具"。工具是动态配置的，只有先"盘一遍"，后面的规划才不是瞎规划。这一步的输出，就是规划的依据。
② 规划执行步骤：写作战计划
拿着工具分析结果 + 用户需求，规划模型产出计划。注意这里有一个非常实用的防呆——工具白名单：
请根据以下规则重新生成规划：
1. 只使用验证报告中列出的有效工具
2. 工具名称必须完全匹配（区分大小写）
3. 每个步骤明确指定使用的MCP工具
4. 避免使用不存在或无效的工具
一句话：模型只能在白名单里挑工具，名字一个字不能错。 把"模型瞎编一个不存在的工具"这条路堵死。
③ 解析规划步骤：把文字变成清单
规划是模型输出的 Markdown 文本，这一步不靠模型，而是程序用正则硬解析：
Pattern stepPattern = Pattern.compile("### (第\\d+步：[^\\n]+)([\\s\\S]*?)(?=### 第\\d+步：|$)");
把"第1步/第2步/第3步"从文本里抠出来，存成有序 Map。让程序按约定格式解析，而不是让模型解析自己输出的格式——稳定、可控。
④ 按顺序执行：照着清单干活
执行器拿到步骤清单，挨个执行，每步都调用对应工具：
第1步：调模型生成文章内容
第2步：调 CSDN 工具 publish_article(title, content, tags)
第3步：调 微信 工具 send_message(message, recipient)
每步独立，失败不影响其他步（配合重试机制更稳）。
四、工程上是怎么搭出来的
这套设计的代码结构其实很简洁——三个角色 + 一个共享模型：
| 角色 | 人设 | 职责 |
|---|---|---|
| mcpToolsChatClient | MCP 工具管理专家 | 分析有哪些工具、怎么用（对应①） |
| planningChatClient | 任务规划助手 | 拆解任务、写执行计划（对应②） |
| executorChatClient | 任务执行助手 | 照计划调工具干活（对应④） |
三个角色共享同一个 chatModel（工具挂在这上面），但各自有独立的 system prompt（人设）、独立的记忆窗口、还能各自挂 RAG 知识库增强。再加一个工程细节：每步执行失败重试 3 次（executeWithRetry）。
五、AutoAgent vs FlowAgent：怎么选
这是读完两篇博客后最该想清楚的问题：
| 维度 | AutoAgent（动态循环） | FlowAgent（规划执行） |
|---|---|---|
| 节奏 | 走一步看一步，质检不过就回炉 | 先定全盘计划，再照着执行 |
| 质量保障 | 独立质检员反复打磨 | 靠清晰的步骤拆分 + 白名单 |
| 成本 | 高（多轮循环 = 多次推理） | 相对可控（一遍走完） |
| 适合 | 目标模糊、结果要打磨的任务 | 流程明确、步骤固定的任务 |
| 例子 | "检索资料并制定学习计划" | "生成文章→发CSDN→微信通知" |
选型心法：任务流程能预先列清楚的，用规划执行；任务结果"好不好"需要反复试的，用动态循环。复杂场景甚至可以把两者组合——规划执行打底，动态循环兜底。
六、别忽略的边界
作为学习沉淀，同样要泼冷水：
- 规划≠执行：计划是文字，执行是真实 tool_call，两者之间是松耦合的——规划里写了"用 CSDN"，执行器实际可能调别的或不调。生产级实现需要在执行器校验 tool_call 名称与规划是否一致。
- 工具清单可能写死：有的实现里"白名单"是硬编码的，不是动态从 MCP server 拉的。真正动态的工具发现才能配得上"先盘工具"的初衷。
- 步骤解析依赖格式约定：正则解析依赖模型按约定格式输出，模型不守规矩就解析失败（虽然代码里加了兜底匹配）。
七、总结
三句话收尾：
- Agent 不止一种玩法：动态循环（AutoAgent）和规划执行（FlowAgent）是两条主流路线，前者重质量、后者重流程。
- 规划执行的精髓：先盘工具（只看不动手）→ 再写计划（白名单约束）→ 硬解析成清单（不靠模型解析）→ 照着执行。每一步都尽量把"模型的自由发挥"压缩到最小。
- 选择比实现更重要：流程清楚的任务先规划后执行，结果难定义的任务走循环打磨——知道什么时候用哪种，才是真正的 Agent 设计能力。