详细解释
Plan-and-Execute（规划-执行范式） 一句话定义：别让 Agent 像 ReAct 那样每走一步才想下一步要干嘛（边想边做容易走到沟里去），而是先花 200ms 「把整个任务的步骤清单一次性列出来」（比如做一个用户调研报告的 7 步计划），评审通过之后，再按清单一个一个步骤去执行，每执行完一步更新一下计划状态即可。2024 年之前主流是 ReAct（Thought-Action-Observation 循环），2024 年下半年开始 LangGraph、CrewAI、AutoGen 这些新框架几乎全部默认用 Plan-and-Execute 作为复杂任务的主范式，就是因为它在「5 步以上的长任务」上完成率比 ReAct 高 30% 至 40%。
Plan-and-Execute 的鼻祖是 2023 年 5 月的 HuggingGPT 论文和 2023 年 9 月的 TaskWeaver（微软亚研），之后 LangChain 提出的 LangGraph StateGraph 把这个模式工程化了——整个 Agent 是一个状态机，状态里有 plan: Step[]、current_step_idx: int、step_results: Map<step_id, result> 三个核心字段。整个生命周期只在最开始跑一次 Planner，之后每次循环只跑 Executor 拿一个 step 去执行，不会每步重新规划。
唯元智创 的 Agent 平台默认就支持 Plan-and-Execute 模式：把任务丢进去先调用大规划器（GPT-4o / Claude Opus）输出 steps: [{id, name, tool, input_schema, depends_on}] 的 JSON 计划，然后由调度器按依赖关系 DAG 拓扑排序执行，支持并行分支、人工审批节点、失败重试策略；工程师也可以把「已有的业务工作流」固化成 Plan 模板直接复用，不用每次让 LLM 重新规划。
Plan-and-Execute vs ReAct vs 纯 Prompt Chaining：三种范式选型表
| 维度 | Plan-and-Execute | ReAct（边想边做） | Prompt Chaining（静态链） |
|---|---|---|---|
| 任务步数 | 5 步以上，步骤间可能有并行依赖 | 2-5 步，串行即可 | 固定 2-10 步，结构完全确定 |
| 任务确定性 | 半结构化：目标确定但路径不确定（如「调研竞品」） | 完全非结构化：走一步看一步（如「调试一段报错代码」） | 完全结构化：每个分支提前写死（如「客服工单处理」） |
| 核心优点 | 长任务完成率高；进度可追踪（用户能看到「第 3/7 步正在执行」） | 灵活，遇到意外可以动态改路径 | 成本最低、延迟最低、最可控可测 |
| 核心缺点 | 计划错了后面全错（垃圾进垃圾出） | 容易走偏、容易死循环、不可预测 | 对计划外情况无应对能力 |
| 完成率（10 步任务） | 约 70% 至 85% | 约 30% 至 50% | 95%+（前提是任务确实在静态分支覆盖内） |
| 成本倍数 vs 单模型 | ×3 至 ×8 | ×5 至 ×15 | ×1.2 至 ×3 |
| 推荐选型场景 | 调研、写作、数据分析报告、多步骤工具调用 | 代码调试、开放环境探索 | 所有能写死流程的生产业务 |
90% 企业落地的正确组合：外层用 Plan-and-Execute 负责整体大框架（给用户看进度），Plan 里每一个具体 Step 内部不是 ReAct，而是用「静态 Prompt Chaining + 工具调用」的确定性小链。这样兼顾灵活性和可控性，不会出现 Step 内部 ReAct 走偏的情况。
规划器（Planner）设计的三个关键细节
细节 1：规划输出必须严格是 DAG（有向无环图）JSON，绝不允许自然语言计划。错误的 Planner 输出：「第一步去 Google 搜索，第二步整理信息，第三步写报告」——执行器根本不知道怎么解析。正确的 Planner 输出必须长这样：{"steps": [{"id":"s1","name":"搜索竞品A官网","tool":"web_search","input":{"query":"竞品A pricing 2025"},"depends_on":[]}, {"id":"s2","name":"搜索竞品B官网","tool":"web_search","input":{"query":"竞品B pricing 2025"},"depends_on":[]}, {"id":"s3","name":"合并价格对比表","tool":"format_table","input":{"a_result":"{{s1.result}}","b_result":"{{s2.result}}"},"depends_on":["s1","s2"]}, {"id":"s4","name":"生成对比报告","tool":"llm_write","input":{"table":"{{s3.result}}"},"depends_on":["s3"]}]}。有了 DAG + depends_on，执行器自动知道 s1 和 s2 可以并行跑，s3 等前两个结束，s4 等 s3，调度逻辑零手写。
细节 2：必须加「计划评审 + 修正」环节。Planner 第一次输出的计划经常有漏步骤（比如忘记「先登录再查数据」）或工具调用错误（让文件搜索工具去调数据库）。所以规划之后必须再加一步 Plan Reviewer：把计划 + 可用工具列表 + 用户目标一起给 Reviewer 模型，问「这个计划有没有遗漏关键步骤、有没有工具用错、预计总步数是否超过 15 步」，有问题就把 Review 意见反馈给 Planner 重写一次。只花 10% 的额外成本，就能把后续执行失败率砍一半。
细节 3：计划必须支持人类在环（Human-in-the-Loop）的「计划确认」和「执行中修改」。Agent 规划好的 10 步计划如果涉及花钱（调付费 API、生成广告、群发邮件）、删数据、对外发消息，必须把计划展示给用户点「确认执行」才开始跑；并且执行到第 5 步的时候用户发现第 7 步不需要了，可以随时打断修改计划。没有人工审批的 Plan-and-Execute 在企业里 100% 会出事故（比如 Agent 自己规划了一步「给所有客户发推广邮件」并真的执行了）。