A2 · 规划执行 · 蓝皮书 · 东方屹腾执行型 Agent
| 字段 | 值 |
|---|---|
| 主模式 | A2 规划执行 Plan-and-Execute（行动 × 编排） |
| 结合模式 | A1 工具调度 · G1 审批门 · M3 进度追踪 |
| 案例 | 上海东方屹腾科技 · HR/薪酬 SaaS · 服务 2 万+ 企业 · 执行型 Agent |
| 对应白皮书 | /zh/patterns/a2-plan-and-execute/ |
| 源 | 梁博 AICon 逐字稿 第五章 · PPT 第 16–19 页 |
| 一句话 | 当任务的几步有严格依赖、ReAct 走一步看一步会跨步漏步时，先把步骤规划成任务图钉死，再按图调度执行。 |
场景：这一格在案例里解决什么
东方屹腾要验证的第一个完整业务场景，是帮用户快速搭建薪资组：用户用自然语言说出薪资组诉求，系统从模板库里向量匹配出最贴合的薪资组模板，先给企业原有薪资组数据建好快照，确认快照建立后再导入模板，导入失败就用快照回滚。这一串动作的顺序不能乱，每一步都依赖前一步的结果，跟开场举的报销例子是同一类问题——「先创建申请、再上传发票、再提交审批、再查询结果」这种有严格递进依赖的多步事务。
这类场景下，光靠 ReAct 的「走一步看一步」不够稳。
落地演进：问题怎么把它逼出来
最早的设想很自然：把所有 API 描述成 Agent 能感知的工具，再在技能里描述每个场景该怎么编排，把「这个场景要先调哪步、再调哪步」作为叙事上下文喂给 Agent，期望它在 ReAct 里自己跑出正确顺序——调完第一步，观察到完成了，再调第二步。
听上去合理，实测不行。技能编排作为叙事上下文给到模型后，它有时能跑对顺序，有时会明显跨步或漏一步，导致整个任务不符合预期。根因还是 LLM 的不确定性：把执行顺序交给概率模型临场判断，就没法保证每次都对。
于是团队识别出还缺一种行动模式——规划执行。它的定位是把要完成的几步先明确规划下来钉死，而不是走一步看一步。顺序从模型的临场判断里拿出来，落进一份可调度、可审计的任务图。
关键设计：数据结构 / 控制信号 / 机制
规划执行的落地复杂度比 ReAct 高一个量级。ReAct 的核心控制结构本质上是一个带退出边界的链式循环，概念理解了，数据结构和逻辑很容易写出来。规划执行不一样，它要明确规划并管理连续多个任务的调度与依赖，得维护一套更复杂的任务规划与调度状态。
落地下来有几个核心构件。
- 任务 DAG 图：把目标分解成一张任务依赖图，独立任务可以并行展开，有依赖的任务按拓扑序串行。这跟传统的 DAG 调度（Airflow、Prefect 那一类）是同一个工程范式。
- 规划器、执行器、验收器：规划器产出任务图，执行器按图推进，验收器判断每个节点是否达成。三者分开，各管一段。
- 任务状态机：这是最花功夫的一块。每个任务节点有自己的状态（ready、in_progress、completed 等），下游节点要能被调度启动，前提是它依赖的上游节点全部 completed、且本节点状态为 ready。整套调度语义靠这台状态机驱动。
控制权在 Orchestrator 和具体行动模式之间流转。ReAct 跑着跑着如果发现任务脉络清晰了，可以明确规划成若干并行或串行任务，就把控制权交还 Orchestrator，切到规划执行模式。两种模式不是二选一，而是按任务的清晰程度切换。
踩过的坑与取舍
- 不要一次性生成一份漂亮 plan 然后就不动了。 真实世界会变、工具会失败、证据会补充，计划必须允许局部 replan，而不是全局重写。
- ReAct 与规划执行的边界要钉清楚。 脉络不清、需要边做边看的，走 ReAct。步骤明确、有严格依赖和状态传递的，走规划执行。把后者套到前者的场景上是过度设计，把前者用在后者的场景上则会跨步漏步。
- 状态机模型值得花一番功夫精巧设计。 这块是规划执行可靠性的地基，书里给得了概念抽象，给不了这种底层工程细节，是团队额外花了较多设计心血才做好的。
边界与指标
规划执行不是免费的。它引入了任务图、状态机、调度器这些重构件，只有当任务确实是「多步、有依赖、顺序错了就交付失败」时才值回票价。关键要盯的是：关键节点有没有 checkpoint、出错能不能局部 replan、独立任务有没有真正并行起来、以及一次规划产出多个任务后任务图全局状态的维护是否正确。
对应白皮书的哪几节
这是 A2 规划执行（行动 × 编排）的一个企业落地实例，对应白皮书里「核心机制」的 Planner / Executor / Orchestrator 三分，「最小骨架」的 PlanStep 依赖结构与 checkpoint，以及「容易出错的地方」里「一次性生成漂亮计划然后不再更新」那一条。案例把白皮书的抽象骨架填上了真实的任务状态机细节。
可迁移判据：别的 SaaS 什么条件下照搬
当你的场景满足这几条，就该上规划执行而不是硬扛 ReAct：任务步骤明确、步骤间有严格的依赖和状态参数传递、且跨步漏步会直接导致交付失败或破坏业务数据。反过来，内容生成型、步骤松散、容错度高的场景（先查资料再总结再生成报告那一类），ReAct 甚至简单的提示链就够了，不必引入任务图和状态机这套重机制。
另外有个顺带的红利值得提前规划进去：一旦把任务 DAG、状态机、调度器、执行器搭好了，关键任务的人审阻塞与续作（见 G1 审批门切片）就能水到渠成地接上去，不用再单独造一套阻塞机制。
一句话
规划执行的价值，是把「按什么顺序做」这件最不能交给概率的事，从模型的临场判断里拿出来，钉进一张可调度、可回滚、可人审的任务图。