Agent丨Agent 的 Planning 模块有哪些主流实现方式，Step-by-step 和 Plan-and-execute 有什么区别？

type

Post

status

Published

date

May 29, 2026

slug

agent54

summary

一、Planning 模块到底是什么？

在传统 RAG 应用中，流程通常是：

用户问题 → 检索 → 拼上下文 → 生成答案

而 Agent 场景更复杂：

用户目标 → 理解目标 → 拆任务 → 判断是否需要工具 → 调用工具 → 观察结果 → 更新计划 → 继续执行或结束

所以 Planning 模块不是单独的一句 prompt，而是 Agent Runtime 中的一个决策层。

从工程角度看，一个生产级 Planner 至少要输出四类信息：

输出	作用
`goal`	当前任务最终要达成什么
`steps`	拆成哪些可执行步骤
`dependencies`	哪些步骤必须先后执行，哪些可以并行
`constraints`	权限、安全、成本、时间、人类审批边界

二、主流 Planning 实现方式

1. Prompt-level Step-by-step：最轻量的隐式规划

这是最早、也最常见的方式。典型 prompt 是：

或者更工程化一点：

这种方式不一定生成一个显式计划文件，而是让模型在回答或工具调用过程中逐步展开推理。ReAct 就是这类思想的经典代表，它将 reasoning trace 和 action 交错生成，让模型在每一轮中根据观察结果决定下一步动作。ReAct 论文指出，这种 interleaved reasoning/action 能帮助模型更新行动计划、处理异常，并通过外部环境获取信息。(arXiv)

典型结构是：

它的优点是实现简单、适应性强，适合搜索、问答、调试、小规模代码修改。但缺点也明显：它通常只规划下一步，而不是先规划全局路径。LangChain 对 ReAct-style agent 的分析也提到，这类 agent 往往每次工具调用都需要一次 LLM 决策，而且模型只为一个子问题做局部计划，可能产生次优轨迹。(LangChain)

2. Explicit Plan Mode：先计划、再审批、后执行

这是 Claude Code、OpenCode 等 AI Coding Agent 中非常典型的模式。

Claude Code 的 Plan Mode 会让 Claude 先阅读文件、运行探索性命令、生成计划，但不直接编辑源代码。计划完成后，用户可以选择继续规划、批准计划并进入不同执行模式，甚至可以把计划送到 Ultraplan 的浏览器界面中评论、修改和选择执行位置。(Claude Code)

OpenCode 的设计也类似：它有内置的 build 和 plan agent，build 是默认开发 agent，plan 是只读分析与代码探索 agent，默认拒绝文件编辑，并在运行 bash 命令前请求许可。(GitHub)

这种模式最大的工程价值是：把“思考”和“行动”拆开。

Planning 阶段使用更强模型、更大推理预算、更严格只读权限；Execution 阶段使用更便宜或更快模型执行代码修改。Claude Code 的 opusplan 模型配置就体现了这种思想：Plan Mode 中使用 Opus 进行复杂推理与架构决策，执行模式中自动切到 Sonnet 做代码生成和实现。(Claude Code)

3. Plan-and-execute：Planner 与 Executor 分离

Plan-and-execute 是 Agent 规划模块中最重要的一类架构。LangGraph 曾专门总结三种 plan-and-execute 风格：Plan-and-execute、ReWOO、LLMCompiler，并指出它们相对于 ReAct 的优势包括减少大模型调用次数、节省成本、让 Planner 显式思考完整任务路径。(LangChain)

基础版 Plan-and-execute 通常由两个组件组成：

组件	职责
Planner	根据用户目标生成多步计划
Executor	针对每个 step 调用工具、检索、写代码、运行测试
Replanner	根据执行结果决定是否继续、重排计划或结束

一个简化实现如下：

这种架构适合复杂代码修改、研究报告、多工具工作流、长链路自动化。缺点是：如果初始计划错了，Executor 可能会“认真地执行错误计划”，所以必须有 Replanner、Verifier 或 Human-in-the-loop。

4. ReWOO：带变量引用的计划

ReWOO 可以理解为更结构化的 Plan-and-execute。它不是简单输出自然语言步骤，而是让 Planner 生成带变量引用的任务序列，例如：

LangGraph 对 ReWOO 的解释是，Planner 可以用 #E2 这样的语法引用前序结果，Worker 再按顺序执行任务并把输出绑定到变量，最后由 Solver 汇总答案。这样每个任务只需要拿到它必要的输入，而不必把全部上下文都塞给模型。(LangChain)

适合场景：

多步研究、RAG 问答、多源数据分析、依赖前序结果的工具链。

5. LLMCompiler / DAG Planner：把计划变成任务图

当任务中存在大量独立子任务时，串行执行会很慢。LLMCompiler 的思路是让 Planner 输出一个 DAG：每个节点包含工具、参数和依赖关系，调度器在依赖满足后并行执行。LangGraph 介绍 LLMCompiler 时提到，它由 Planner、Task Fetching Unit、Joiner 组成，Task Fetching Unit 会在依赖满足后调度任务，DAG 化可以减少工具调用等待时间。(LangChain)

这类设计更像传统工作流引擎，适合：

并行调研、多 API 聚合、批量文件分析、CI 检查、跨模块代码审查。

6. Multi-agent Planning：由主 Agent 规划，子 Agent 并行调查或执行

Claude Code 的 subagents、OpenAI Agents SDK 的 handoffs/agents-as-tools、OpenClaw 的 multi-agent routing 都属于这一类。

Claude Code 的 subagent 文档明确说明：每个 subagent 有自己的上下文窗口、自定义 system prompt、特定工具访问和独立权限；它适合把会污染主上下文的大量搜索、日志、文件读取工作隔离出去，只把摘要返回主 Agent。Claude Code 内置 Explore、Plan、general-purpose 等子代理，其中 Explore/Plan 都是只读工具，用来做代码搜索和规划前研究。(Claude Code)

OpenAI Agents SDK 则提供两种常见编排方式：handoffs 和 agents-as-tools。handoff 适合“专家接管对话”，agents-as-tools 适合“主 Agent 保持最终回答权，只把专家当成有边界的工具”。(OpenAI开发者)

OpenClaw 更偏“长期运行的个人 AI Gateway”。它支持多通道消息入口，并可以把不同 channel/account/peer 路由到不同 isolated agents，每个 agent 有自己的 workspace、state directory 和 session history；它还支持 sessions_spawn 生成隔离的后台子 agent session，并通过沙箱减少工具执行的影响范围。(OpenClaw)

这说明主流 Agent 系统正在从“单模型一步步干活”演进到：

主 Agent 负责规划与汇总，子 Agent 负责隔离调查、并行执行、专门验证。

7. Programmatic Planning：让模型生成“编排代码”

Anthropic 在 Programmatic Tool Calling 中提出：与其让模型一轮一轮请求工具，不如让 Claude 写出一段 Python 编排代码，在代码中显式表达循环、条件、并发、错误处理和数据转换；中间结果不必全部进入模型上下文，只把最终结果返回给 Claude。Anthropic 的示例中，Programmatic Tool Calling 可以把复杂研究任务平均 token 使用从 43,588 降到 27,297，约减少 37%。(Anthropic)

这类模式适合：

工具调用很多、数据处理密集、需要循环/并发/聚合的任务。

它可以看作 Planning 的一种高级形态：计划不是自然语言步骤，而是可执行控制流。

三、Step-by-step 和 Plan-and-execute 的核心区别

很多人会把 Step-by-step 和 Plan-and-execute 混在一起。它们最大的区别是：有没有显式、可审计、可调度的计划对象。

维度	Step-by-step	Plan-and-execute
规划方式	边想边做，每轮决定下一步	先生成全局计划，再逐步执行
计划形态	通常隐藏在推理过程或对话中	显式 plan、task list、DAG、plan file
工具调用	每一步都可能重新问 LLM	Executor 可按计划执行，必要时才 replan
成本	多工具任务中 LLM 调用多	大模型主要用于 plan/replan，可降成本
可控性	灵活但难审计	更容易审批、回滚、评估
适合任务	简单问答、轻量调试、探索性任务	复杂研发、多工具流程、长任务自动化
风险	容易局部最优、忘记全局目标	初始计划错误会被放大
典型代表	CoT、ReAct	Claude Plan Mode、LangGraph Plan-and-execute、ReWOO、LLMCompiler

可以用一句话总结：

Step-by-step 是“每一步都重新思考下一步”；Plan-and-execute 是“先制定路线图，再按路线图执行，并在必要时重规划”。

四、源码视角：一个生产级 Planner 应该怎么设计？

建议把 Planning 模块拆成 5 层。

1. Planner Prompt：不要只说“请一步步思考”

更好的 Planner Prompt 应该要求模型输出结构化计划，而不是自由发挥：

2. Plan Schema：让计划可验证

结构化计划的好处是可以做校验：

3. Executor：只执行当前 step，不重新解释全局目标

Executor 的 prompt 要尽量窄：

这样可以减少 Agent 在执行时“顺手改更多东西”的风险。

4. Verifier：执行后必须验证

代码类任务至少验证：

Claude Code 的权限系统强调：prompt 或 CLAUDE.md 只能影响 Claude 尝试做什么，真正允许或拒绝工具调用的是 Claude Code 的权限系统；deny/ask/allow 规则由 runtime 执行，而不是靠模型自觉。(Claude Code)

这点非常关键：Planning 不是安全边界，权限系统才是安全边界。

5. Replanner：失败后不要盲目重试

Replanner 应该接收：

然后只允许三种输出：

五、结合 Claude Code、OpenCode、OpenClaw 的工程经验

Claude Code：Plan Mode + 权限 + 子代理

Claude Code 的 Plan Mode 是典型的“先研究、后批准、再执行”模式。它还支持 subagents，将调查任务放到独立上下文中，避免主上下文被大量文件内容污染；官方最佳实践也建议用 subagents 做 investigation，因为上下文是核心约束，子代理可以单独探索代码并只返回摘要。(Claude Code)

适合借鉴的点：

计划阶段只读；执行阶段才写入；权限由 runtime enforce；子代理用于隔离高噪声上下文。

OpenCode：plan/build 双 Agent + permission config

OpenCode 的 plan agent 是只读分析与代码探索，build agent 负责完整开发执行。OpenCode 权限系统支持 allow、ask、deny，并可按 agent 覆盖权限；文档中也给出了对 edit、bash 等工具的细粒度控制。(OpenCode)

示例配置：

不过 OpenCode 社区 issue 也暴露过 plan mode 通过 bash 间接写入的问题，例如在 plan mode 中执行 git commit --amend 或通过 shell 替换文件内容。(GitHub)

这给我们的启发是：

只禁止 edit/write 工具不够，还要限制 bash 中的写操作、危险命令和外部副作用。

OpenClaw：多代理路由 + 子会话 + 沙箱

OpenClaw 不是单纯 coding CLI，而是长期运行的个人 AI Gateway。它的 multi-agent routing 可以让多个 isolated agents 拥有各自 workspace、agentDir、session history；sessions_spawn 可以创建隔离后台子 agent；sandboxing 则把工具执行放进隔离后端以降低影响范围。(OpenClaw)

适合借鉴的点：

对长期运行 Agent 来说，Planning 不只发生在一次对话中，还要考虑 channel 路由、agent 隔离、session 生命周期、沙箱和工具策略。

六、如何选择 Planning 实现方式？

场景	推荐方式
简单问答、一次性搜索	Step-by-step / ReAct
小型代码修复	ReAct + Todo List
中大型功能开发	Plan Mode + Human Approval
多工具串行任务	Plan-and-execute
多源信息依赖	ReWOO
大量可并行子任务	DAG Planner / LLMCompiler
多角色协作	Manager + Subagents / Handoffs
高风险生产环境	Plan-first + Permission + Sandbox + Verifier
长期运行个人助理	Multi-agent routing + Session memory + Sandboxing

七、一个推荐的生产级 Planning 架构

核心原则：

Planner 只负责计划，不直接产生副作用。Executor 只执行当前 step，不擅自扩展目标。工具权限由 runtime 控制，不依赖 prompt 自觉。每个 step 都要有 observation 和 verifier。高风险动作必须经过审批或沙箱。长任务必须支持 replan、checkpoint、rollback。高噪声检索应交给 subagent，主上下文只保留摘要。

八、面试/项目中的一句话回答

如果面试官问：

Agent 的 Planning 模块有哪些主流实现方式？Step-by-step 和 Plan-and-execute 有什么区别？

可以这样回答：

Agent Planning 主要有几类实现：第一类是 Step-by-step/CoT/ReAct，让模型在每轮中边推理边决定下一步；第二类是显式 Plan Mode，先生成计划并让用户审批，再进入执行；第三类是 Plan-and-execute，把 Planner 和 Executor 分离，Planner 生成多步计划，Executor 执行每一步，并由 Replanner 根据 observation 调整；第四类是 ReWOO/LLMCompiler 这类结构化计划，把步骤做成变量依赖或 DAG，支持更低成本和并行调度；第五类是多 Agent Planning，由 Manager Agent 规划，子 Agent 分别调查、执行、验证。Step-by-step 更灵活，适合简单和探索性任务，但容易局部最优、难审计；Plan-and-execute 更适合复杂任务，因为它有显式计划、可审批、可调度、可验证，也更容易做权限控制和失败恢复。

九、总结

Agent Planning 的演进路径大致是：

真正成熟的 Agent 系统不会只依赖“请一步步思考”。它会把 Planning 变成一个工程模块：有结构化输出、有执行器、有权限系统、有验证器、有重规划、有上下文隔离、有人工审批。

这也是 Claude Code、OpenCode、OpenClaw、LangGraph 等系统共同体现出的方向：Planning 不再是模型内部的一段推理，而是 Agent Runtime 中可管理、可观测、可控制的核心能力。