大模型 Agent 架构选型指南：ReAct vs Plan-and-Execute，小白程序员必看

本文详细解析了两种主流大模型 Agent 架构：ReAct 和 Plan-and-Execute，并通过分析环境不确定性、任务长度、任务依赖和副作用等变量，提供了一套实用的架构选型指南，帮助程序员根据具体业务场景选择最合适的架构，从而构建更稳定、高效的 Agent 系统。

一、先从控制流理解两种架构

ReAct：走一步，看一步

ReAct（Reasoning and Acting，推理与行动）是一种大语言模型 Agent 的任务执行范式，它让模型在执行过程中交替进行推理、行动和环境观察，根据每次行动获得的新信息持续更新判断与后续动作，直到完成任务。典型过程是：

本质上是一个循环，用公式可以表示为这样：

每得到一个新信息，模型都重新参与决策。例如帮我查一下为什么线上接口突然变慢。ReAct 可能这样工作：

最开始 Agent 并不知道最终会查到哪里。这类问题非常符合 ReAct，因为后面的动作高度依赖前面的 Observation（观察结果）。

二、Plan-and-Execute：先画路线，再走路线

Plan-and-Execute 是一种将任务规划与任务执行分离的 Agent 架构。系统先由 Planner（规划器）把用户目标拆解为一组有顺序或依赖关系的子任务，再由 Executor（执行器）逐步完成这些任务，并根据执行结果决定继续、调整计划或重新规划，直到完成最终目标。结构则变成：

这里实际上出现了两个不同层次的智能 Planner 负责“做什么”，Executor 负责“怎么做”。

LangChain 对这种架构的定义也是如此，Planner 产生多步骤计划，Executor 接收其中一个步骤并通过工具完成它，执行结果不符合预期时，可以再次进入 Planner 重新规划。这就出现了一个非常关键的架构差异。

三、ReAct 和 Plan-and-Execute 的本质区别

维度	ReAct	Plan-and-Execute
控制方式	动态决策	计划驱动
规划粒度	下一步	整个任务或一个阶段
规划状态	隐式	显式
环境适应能力	很强	取决于 Replan
长任务能力	容易漂移	更稳定
全局目标保持	较弱	较强
工具调用	通常每轮重新判断	可由 Executor 直接执行
并行能力	原始模式较弱	天然适合 DAG 并行
中间状态	对话历史为主	Task State / Plan State
可观测性	Action 轨迹	Plan + Task + Action 轨迹
失败恢复	继续循环	单任务重试 / Replan
审批控制	较难	很自然
长期任务	一般	更适合

这里需要特别纠正一个经常出现的说法：

Plan-and-Execute 一定比 ReAct 更慢、更贵。

这个判断放在早期 Agent 实现里有一定依据，但如果直接套到现在的架构上，就不太准确了。

早期的 Plan-and-Execute 通常会多出一次甚至多次规划调用：先让模型生成 Plan，再逐步执行，每完成若干步骤之后，还可能重新调用 Planner 判断计划是否需要调整。LangChain 在 2023 年最早介绍这种架构时，也明确提到过额外模型调用带来的延迟和成本。

所以从最简单的调用次数来看，早期结构很容易变成：

如果 Planner 和 Executor 都使用同一个昂贵的大模型，这种实现当然有可能比一个简单的 ReAct Agent 更贵。但问题在于，ReAct 本身也并不是只调用一次模型。

一个典型 ReAct Agent 在每轮工具调用之前，都要重新让模型根据当前上下文判断：

当前发生了什么当前发生了什么

上一次工具调用返回了什么上一次工具调用返回了什么

下一步应该调用哪个工具下一步应该调用哪个工具

工具参数应该是什么工具参数应该是什么

当前任务是否已经完成当前任务是否已经完成

所以一个执行五步工具调用的 ReAct，很可能实际运行成这样：

也就是说，ReAct 的成本往往跟“决策轮数”一起增长，更重要的是随着任务不断执行上下文也会越来越长。每一轮模型调用不仅要处理当前工具执行的结果，还可能重新读取前面已经发生过的大量历史信息。所以 ReAct 的实际成本通常受到两个变量共同影响：

模型调用次数 × 每次调用的上下文长度

这也是为什么一些长任务里的 ReAct Agent，Token 消耗会非常明显，而现代 Plan-and-Execute 的设计思路已经发生了变化。它不要求每一个执行步骤都再次调用同一个大模型。Planner 可以先把任务拆解清楚，然后把大量确定性的执行工作交给普通代码、工具、小模型或者独立 Worker。

例如：

这里真正昂贵的大模型主要负责三件事情：

规划：理解整体目标并拆解任务；

重规划：当执行结果与预期不一致时调整后续路径；

整合：根据所有执行结果生成最终输出。

中间大量执行步骤，则未必需要强模型全程参与。

例如：

这时候 Plan-and-Execute 反而可能减少强模型调用次数。假设一个任务包含 10 个比较确定的执行步骤，纯 ReAct 可能需要嗲用 10 次左右的“模型决策 + Tool”，而 Plan-and-Execute 可能只需要一次规划 + 若干次普通工具调用或 Worker 执行 再加一次最终结果整合。

如果执行过程中计划没有失效，昂贵模型可能只需要参与两三次。因此，两种架构真正应该比较的，并不是简单的 谁的流程步骤更多 谁就更节省 Token，而是应该比较 强模型到底在多少个决策节点参与，以及每一次调用需要携带多少上下文。

这也是现代 Agent 架构里一个非常重要的优化方向 把“智能决策”和“确定性执行”分开。

需要模型判断的地方让模型参与，已经确定怎么执行的地方，尽量直接交给代码和工具完成。

LangGraph 在讨论 Planning Agent 时也专门强调过这一点通过先规划再执行，可以降低高能力模型的调用频率，同时把部分子任务交给更小、更便宜的模型，从而改善整体延迟与成本。

所以更准确的说法应该是：

Plan-and-Execute 会增加规划本身的成本，但它同时提供了减少执行阶段大模型参与频率的机会。对于短任务，ReAct 往往更简单；对于长任务和多步骤任务，Plan-and-Execute 反而可能在 Token、延迟和模型成本上更有优势。

决定成本的可能不是架构名称，模型调用次数、上下文长度、模型规格、工具执行比例，以及任务是否需要频繁重新规划 等因素可能才是实际成本支出的重点。

四、影响业务选型的第一个变量：环境不确定性

这是老李认为最重要的判断标准，可以把任务分成两种。

第一类：路径未知

这类任务的特点是：你知道最终要解决什么问题，但一开始并不知道答案藏在哪里，也无法提前确定完整的执行路径。

例如：为什么支付失败率突然从 0.1% 上升到 8%？

看到这个现象时，我们只能先确认“支付失败率异常升高”，但真正的故障点可能出现在整个调用链中的任何位置。

问题可能来自网关超时，也可能是数据库连接池耗尽、Redis 异常、第三方支付接口抖动、证书过期、网络故障，甚至只是刚刚上线的一次配置修改。在开始排查之前，很难可靠地生成一条完整计划，比如先查 A，再查 B，然后查 C，最后一定能够找到原因。

因为前一步得到的 Observation（观察结果），会直接决定下一步应该采取什么 Action（行动）。

假设第一步先查看支付服务监控，发现数据库请求耗时明显升高，那么 Agent 的注意力就会转向数据库，整个流程就变成了：

但如果第一步得到的结果完全不同，例如发现数据库一切正常，而第三方支付接口的错误率突然升高，那么后续调查路径就会立即发生变化，就成了：

这就是这类任务最核心的特征，执行路径不是预先确定的，而是在获取信息的过程中逐渐形成。

从控制流来看，它更接近一个持续反馈的闭环流程：

因此，这种任务可以称为高环境不确定性任务。这里的“环境不确定性”并不是指系统随机，而是指 Agent 在当前时刻掌握的信息不足以确定后续完整执行路径，必须不断从外部环境获取新证据，再动态决定下一步。

这才是 ReAct 最擅长的场景，ReAct 不要求一开始就把整条路线规划完整，而是通过 Reason → Action → Observation → Reason 不断缩小问题空间。

像一些开放性的问题，比如下面这些通常都天然适合 ReAct 模式：

线上故障排查线上故障排查

未知 Bug 定位未知 Bug 定位

开放式信息搜索开放式信息搜索

客服问题诊断客服问题诊断

运维异常分析运维异常分析

根据实时数据不断调整策略的工具调用任务

这类业务的选型逻辑可以概括成这样的一个流程：

因此，当一个任务表现出明显的“先探索，再决定下一步”特征时，ReAct 往往比固定计划更有优势。因为这里需要的并不是我们提前准备写好的确定性路线图，恰恰需要的是一个能够根据现场证据持续调整方向的决策闭环。

第二类：路径基本已知

这类任务通常有一个明显特征，目标虽然复杂，但完成目标所需要的主要步骤，在任务开始之前基本就能够预判出来。

典型的如：对这个 GitHub 项目做一次架构分析，并生成技术报告。面对这种任务，我们通常能够提前拆出一条相对稳定的执行路径：

这里的关键点在于，前面某一步即使发现了新的细节，通常也不会彻底改变整个任务结构。比如分析目录后发现项目采用插件化架构，后续仍然需要继续研究核心模块、依赖关系、数据流和部署方式，最多也只是调整某几个步骤的关注重点。

也就是说，这类任务的执行路径具有较强的结构稳定性。

如果仍然使用纯 ReAct，让模型在每完成一个步骤之后都重新判断“下一步应该做什么”，就会出现大量重复决策，就像下面这样：

如果你说使用 React 的这些判断能够工作吗？当然可以了，但其中相当一部分决策其实早在任务开始时就已经可以很明确了。

例如：

README 看完之后，大概率仍然要看目录结构；

目录结构分析完之后，大概率仍然要找核心模块；

核心模块确认之后，依赖和数据流依然需要继续分析；

最终仍然需要汇总证据并形成报告。

如果用 ReAct 模式就会产生，模型会不断重复回答一个已经有较稳定答案的问题，下一步应该做什么？

对于一个需要十几个步骤甚至几十个步骤的任务，这种重复决策会逐渐累积成额外的模型调用、Token 消耗和执行延迟。

Plan-and-Execute 更适合把这种“已知结构”提前显式化：

Planner 在开始阶段就完成了一次全局判断，这个任务需要完成哪些工作，这些工作之间是什么关系？随后 Executor 按照计划逐步推进。如果某一步执行结果正常，就继续执行下一步，只有当发现新的信息足以改变整体路径时，才需要触发 Replan。

这样，系统中的大模型决策会从 每走一步，都重新决定往哪里走 变成了 先确定主路线，执行过程中只在必要时调整路线，对于路径稳定的任务，这种方式会明显减少无意义的决策循环，还能提高执行的稳定性。

还可以进一步把任务拆成可并行的结构。例如，完成基础代码扫描之后，模块分析、依赖分析和部署分析往往可以同时进行：

这也是 Plan-and-Execute 的一个重要优势：计划一旦显式存在，任务之间的依赖关系就可以被识别出来，系统能够据此进行并行执行、失败重试和状态跟踪。

因此，我们总结出路径基本已知的任务通常具有几个共同特征：

可以提前列出大部分主要步骤

各步骤之间的依赖关系相对稳定

某一步的结果通常只影响局部细节

整体任务目标不会频繁改变整体任务目标不会频繁改变

任务往往包含较多步骤，执行时间也更长

像下面这些场景通常更适合 Plan-and-Execute：

项目架构分析；项目架构分析

深度研究与报告生成；深度研究与报告生成

大规模代码迁移；大规模代码迁移

数据分析流程；数据分析流程

技术尽调；技术尽调

批量文档处理；批量文档处理

有明确阶段划分的企业工作流

可以用一个简单的判断流程来理解：

所以，当任务表现出明显的“先规划整体结构，再逐步完成各阶段工作”特征时，Plan-and-Execute 通常会更加合适。它的价值就在于提前把已经能够确定的部分固定下来，让模型把推理资源留给真正存在不确定性的地方。

很多小伙伴可能要问了，这不就是工作流嘛，其实不太一样，Plan-To-Execute 可以看作是一个动态的工作流，整个大链路都有模型参与，只是整体的工作方向没变。而普通的 Workflow 是预定义工作流，模型可以参与到每个阶段内部。

五、第二个变量：任务长度

任务长度会直接影响 Agent 的稳定性，尤其是当一个任务需要经历多个阶段、持续较长时间时，ReAct 的控制方式会开始暴露出明显问题。

如果一个任务只有三步，比如只包括读取文件、打开文件和写入文件这种很简单的任务，这种情况下，ReAct 通常非常顺手。

Agent 每执行一步，根据最新结果决定下一步，整个上下文还比较短，用户目标也很容易保持在模型的注意范围内。

问题一版出现在任务逐渐变长之后，例如，一个任务需要连续完成十几个步骤：

在纯 ReAct 模式下，每完成一步，模型都需要重新基于当前上下文判断下一步该做什么。随着执行不断推进，模型实际需要同时维护的信息就会越来越多：

用户最初希望完成什么用户最初希望完成什么

当前执行到哪个阶段当前执行到哪个阶段

前面已经完成了哪些工作前面已经完成了哪些工作

哪些问题仍然没有解决哪些问题仍然没有解决

哪些中间结果只是局部现象哪些中间结果只是局部现象

当前动作与最终目标之间还有什么关系

一开始这些信息很容易管理，但任务执行时间越长，上下文中的日志、工具结果、分析过程和中间结论也会不断累积。于是 ReAct 的每一轮推理，都会逐渐变成一个更复杂的问题，大模型会在一大段历史上下文里，重新判断当前状态，并决定下一步。

这里会出现三个典型风险，第一个是 Context Growth（上下文膨胀）。

每一次 Tool 调用都会产生新的 Observation，这些 Observation 又会进入下一轮 Reason。执行几十轮之后，上下文可能变成：

模型此时需要从大量历史信息中重新提取当前真正重要的状态。这不仅增加 Token 消耗，也会提高遗漏关键信息的概率，甚至你最初的Prompt的各种规则都会被大模型遗忘。

第二个风险是 Goal Drift（目标漂移）。

长任务执行过程中经常会遇到局部问题，例如测试失败、依赖冲突、某个工具报错或者某段代码无法编译。Agent 很容易把注意力逐渐集中到这个局部问题上：

例如，用户最开始的任务可能只是为一个项目增加 OAuth 登录。执行过程中发现某个测试框架配置有问题，Agent 开始修测试框架；修测试框架又发现依赖版本冲突，继续处理版本冲突之后，已经连续执行了很多轮。

这些事情可能都有价值，但 Agent 很容易逐渐失去对原始目标的全局判断 OAuth 登录到底做到什么程度了？

这就是典型的 Goal Drift。就行老李最近在开发的 SerenaDesktop 工具，发现 Codex 在执行过程中，为了修复一个上游 lib 库的bug，耗费了好几个小时用来打补丁，甚至直接把上游的 lib 库拉到了本地 vendor 目录重新实现了一遍😂。

第三个问题是 状态越来越依赖上下文本身。

纯 ReAct 经常把“任务执行到了哪里”隐含在对话历史和工具调用记录里。这就意味着 Agent 如果想知道哪些任务已经完成了，就需要重新从历史上下文中推断。

而 Plan-and-Execute 则处理方式会不一样，这种模式会更加倾向于把这部分状态显式的保存下来：

此时任务状态已经从模型上下文里抽离出来，成为独立的 Execution State（执行状态）。Agent 不需要每一轮重新推断我任务做到哪里了？它可以直接读取当前任务状态，直接拿到目标任务、已完成任务、待执行任务以及失败任务等。

于是整个控制结构会变得更加稳定：

这里有一个非常重要的架构变化，任务状态从“模型自己记住”变成了“系统显式维护”，对于长任务来说，这个变化往往比 Planner 本身更重要。一个任务的可靠性很多时候并不是大模型的规划能力差，恰恰是因为系统没有明确的状态记录。

因此，任务长度越长对显式状态管理的需求越强。可以大致理解成：

所以，当任务开始具备以下特征时，就应该谨慎使用纯 ReAct 作为顶层控制架构：

执行步骤明显增多执行步骤明显增多

任务包含了多个阶段任务包含了多个阶段

中间结果或状态需要长期保存

任务执行中可能被暂停和恢复

执行过程中需要失败重试执行过程中需要失败重试

需要持续跟踪完成进度需要持续跟踪完成进度

整个任务可能运行几十分钟甚至数小时

这类任务更适合让 Plan-and-Execute 或 Task Graph（任务图）承担顶层控制，而 ReAct 可以继续留在局部 Worker 内部，用来解决某个具体子任务。

例如：

这样我们就可以同时利用两种模式的优势 顶层通过显式 Plan 保持长期目标和任务进度，局部通过 ReAct 保留探索能力和环境适应能力。

随着任务逐渐从“几步操作”扩展到“多阶段长任务”，这种分层控制通常会比纯 ReAct 更稳定，也更容易实现恢复、审计和并行执行。

六、第三个变量：任务之间有没有依赖关系

当一个任务被拆成多个子任务之后，下一步要看的就是 这些子任务之间是什么关系？

有些任务必须严格按照顺序执行，因为后一步依赖前一步的结果，另一些任务彼此独立，可以同时进行。这个差异会直接影响 Agent 的执行效率。

例如，用户提出帮我分析一个市场机会，并给出综合判断。Planner 可能将任务拆成三部分，先搜索竞品，再查询市场数据，最后查询内部业务数据。这三个任务彼此之间没有直接依赖，它们只需要在最终综合分析之前全部完成就行。

因此，它们的实际依赖关系更接近这样：

这里已经能够看到一个很重要的结构这些 任务之间形成了一张依赖图。

搜索竞品、查询市场数据和查询内部数据没有前后顺序，因此可以并行执行，但综合分析则依赖前三项结果，所以必须等它们完成之后才能开始。

如果使用一个简单的串行 ReAct 循环，执行过程很可能变成这样：

假设三个查询分别需要 8 秒、10 秒和 12 秒，那么仅仅等待这些工具调用，理论上的串行时间就接近 秒 ，但从业务依赖上看，它们完全可以同时并行执行。

如果采用依赖图调度：

调度器可以同时启动前三个任务，这样整个阶段的耗时更接近 秒，而不是 30 秒。这里体现出的已经不仅是“规划”，还包括了任务调度。

02

DAG 到底解决什么问题？

DAG，全称 Directed Acyclic Graph，即有向无环图。在 Agent 系统里，可以把每一个节点理解成一个 Task，每一条边理解成任务之间的依赖关系。

例如：

这表示Task A 和 Task B 可以同时执行，Task C 依赖 A 和 B，Task D 又依赖 C。于是调度器可以自动判断：

这比一个简单的任务列表多了一层非常重要的信息 任务之间的依赖关系。

03

简单 Plan 和 DAG Plan 的区别

一个普通 Plan 可能只是简单的罗列出 Task 1、Task 2、Task 3、Task 4 等等。

这种结构能够表达出“有哪些任务”，但很难准确表达任务依赖关系，比如 Task 2 是否依赖 Task 1？ Task 2 和 Task 3 能不能同时执行？ Task 4 需要等待哪些任务？等等。

DAG 会把这些关系显式化：

于是 Executor 不再只是简单地取下一个任务执行。它可以根据依赖状态判断 现在有哪些任务已经 Ready，可以立即执行了？

04

执行模型也会随之变化

简单 Plan-and-Execute 往往是：

任务多了以后，这种结构仍然可能存在大量不必要的串行等待。引入 DAG Scheduler（有向无环图调度器）之后，执行模型会变成：

Scheduler 的核心职责是不断检查有哪些任务已经完成，还有哪些任务仍然有未满足的依赖，或者哪些任务已经满足全部前置条件，甚至还得检查哪些 Ready Task 可以立即并行启动。

这时候 Agent 已经从简单的从 Plan 到一个个执行 演化成更复杂的 Plan → Dependency Graph → Scheduling → Parallel Execution，也就是 Plan-and-Execute + DAG Scheduler。

任务之间的关系越复杂，显式依赖图的价值越高。比如软件开发任务中：

这里就不适合简单按照 A → B → C → D → E → F → G 全部串行执行。更合理的执行方式是：

先完成需求分析先完成需求分析

数据库设计和 API 设计根据依赖关系向下推进

条件满足后，前后端就可以并行开发了

等待前后端完成后再进行集成测试

最后执行整体验证最后执行整体验证

因此，判断一个复杂任务是否需要 DAG，可以重点看三个问题：

1

子任务之间是否存在明确依赖？

2

是否存在多个可以同时执行的独立任务？

3

串行执行是否产生大量等待时间？

如果答案大多为“是”，简单的任务列表就已经不够了，应该开始考虑 Task Graph（任务图）或者 DAG Scheduler。

LangGraph 在讨论 LLMCompiler 这类 Planning Agent 时，也采用了类似的思路：Planner 生成带有依赖关系的任务，调度器根据依赖状态尽可能提前启动可执行任务，从而减少串行等待。

所以，从 Agent 架构演进来看，可以把这一层理解为：

Planner 解决“需要做什么”，DAG 描述“任务之间是什么关系”，Scheduler 决定“哪些任务现在就可以执行”。

当任务规模开始扩大后，这三个职责分开，往往会比简单的 Plan-and-Execute 更容易获得稳定的并行能力和可控的执行顺序。

七、第四个变量：任务是否具有副作用

=================

前面几个变量主要决定 Agent 怎么规划、怎么执行，以及任务之间能不能并行。但一旦 Agent 开始真正修改外部世界，问题就会发生变化。

这里说的“副作用”，实际指的是 Agent 的某个 Action 会对系统状态产生真实改变，比如：

修改了代码文件修改了代码文件

写了数据库；写了数据库；

创建或删除云资源创建或删除云资源

修改配置修改配置

提交 Git Commit

创建 Pull Request

发布服务发布服务

发送邮件发送邮件

执行支付执行支付

删除数据等删除数据等

这些操作和“查日志”“读文件”“搜索资料”有明显区别。读取失败，大多数情况下重新执行一次就行了，写操作一旦执行，可能已经改变了系统状态，重复执行甚至会产生新的问题。

例如，一个代码 Agent 接到任务想把项目从 Java 17 升级到 Java 21，并完成测试和提交。如果使用非常自由的 ReAct 控制流，执行过程可能是这样子：

从“模型能不能完成任务”来看，这种方式完全可能成功。真正恶心的是执行过程中出现的问题，执行到一半之后，外部系统会变成一个持续变化的状态：

这时候，一个生产级 Agent 平台必须能够准确回答这些问题：

Agent 计划修改哪些资源？

当前已经执行到哪一步？当前已经执行到哪一步？

哪些步骤只是读取，哪些步骤会产生写入？

某一步失败之后是否允许自动重试？

重试会不会造成重复写入？重试会不会造成重复写入？

哪些操作需要人工批准？哪些操作需要人工批准？

Agent 被强制退出之后应该从哪里恢复？

已执行操作是否需要补偿或回滚？

最终状态有没有通过验证？最终状态有没有通过验证？

这些问题已经超出了单纯“模型下一步怎么推理”的范畴，进入了执行治理。

05

副作用会放大重试风险

假设 Agent 查询接口失败了，通常重新查询一次问题不大，但如果 Action 是要求给客户退款 100 元。执行结果出现网络超时，这可不代表退款没有实际发生。

实际情况下可能出现：

这类步骤就必须具备更严格的执行语义，例如：

Idempotency（幂等）

Retry Policy（重试策略）

State Verification（状态确认）

Compensation（补偿操作）

因此，具有副作用的 Action 不能简单套用如果失败了就再执行一次的逻辑。系统必须明确知道这个动作的风险属性。

06

副作用越强，越需要显式 Execution Plan

如果 Agent 在执行之前先生成完整计划，系统就可以提前看到它准备做什么。

还是用刚才Java版本升级的问题为例，例如：

这时候系统可以在真正执行之前进行一次 Risk Check（风险检查）。

于是每一个 Task 都可以带有明确的执行属性。例如：

Task	操作	风险	是否可自动重试	是否审批
读取配置	Read	低	是	否
修改 pom.xml	Write	中	条件允许	否
删除数据库表	Destructive	高	否	是
部署生产环境	Deploy	高	否	是
查询部署状态	Read	低	是	否

这样一来，Planner 负责描述“准备做什么”，执行系统负责决定“允许怎么做”。

07

人工审批应该放在高风险边界上

对于生产环境操作，让人工审核 Agent 的每一步通常会严重降低自动化价值。比如，你用Codex /gobl 模式开起来一个重构任务，结果每一步都让你确认，你会崩溃的，更合理的方式，是在真正产生高风险副作用之前设置 Approval Gate（审批关卡）。

比如这样子：

这样，Agent 可以自动完成大量低风险工作，只在真正跨越风险边界时请求人工介入。

08

长任务还需要 Checkpoint

当一个带副作用的 Agent 执行几十分钟甚至几个小时之后，中途崩溃是必须考虑的情况。

假设执行过程为：

如果系统在部署之前崩溃，恢复之后不能简单重新从第一步开始。因为前四个步骤已经产生真实状态。因此，需要把执行进度持久化成 Checkpoint（检查点）：

此时恢复逻辑依赖的是持久化状态，而不是让模型重新阅读全部聊天历史，再猜测执行到了哪里。

09

有些操作还需要 Compensation（补偿）

更加复杂的场景里，传统意义上的 Rollback（回滚）甚至都做不到。就比如创建订单后需要扣减库存，再执行支付最后给用户发优惠券。如果最后一步失败，可能无法简单把所有系统恢复到之前的数据库快照。

这时需要为不同步骤定义 Compensation Action（补偿动作）：

这已经非常接近分布式事务里的 Saga（长事务补偿）思想。所以当 Agent 能够操作真实业务系统时，很多成熟的软件工程原则会重新变得重要， Agent 可以负责决策，但执行过程仍然需要事务、幂等、审计、权限和状态机来兜底。

10

因此，生产级结构往往会逐渐演化成这样

到了这个阶段，只靠显式 Plan 的价值已经不仅体现在“让 Agent 更容易记住下一步”。它还提供了一个非常重要的控制面，让系统能够围绕 Plan 增加：

权限控制；权限控制；

风险分级；风险分级；

人工审批；人工审批；

幂等控制；幂等控制；

重试策略；重试策略；

Checkpoint；Checkpoint；

失败恢复；失败恢复；

回滚与补偿；回滚与补偿；

审计记录；审计记录；

最终结果验证。最终结果验证。

因此，副作用越强，对显式 Plan 和 Execution State 的需求通常也越高。可以用一个简单的判断关系理解：

因此，一个很实用的架构原则是：副作用越大，执行过程越应该显式化。

读取日志时，Agent 可以拥有较高的自主权；修改代码时，需要记录变更与验证结果；涉及生产部署、资金、数据删除等高风险操作时，则应该进一步加入审批、幂等、检查点和补偿机制。

八、业务选型可以归纳成一个二维模型

前面讨论了路径确定性、任务长度、任务依赖和副作用几个变量。如果只挑两个最适合作为第一层判断的指标，老李更倾向于以下两点：

任务长度：任务需要执行多少个阶段、持续多久；

环境不确定性：后续动作在多大程度上依赖执行过程中不断获得的新信息。

把这两个变量放在一起，可以得到一个比较实用的选型模型：

这个模型并不是严格的架构边界，更适合作为第一轮筛选，先判断任务大致落在哪个区域，再结合依赖关系、副作用、并行性和恢复要求进一步设计。

左下：路径确定 + 短任务

这类任务通常连 Agent 都不需要。例如 查数据库 → 调接口 → 生成 PDF → 发送邮件，整个过程的步骤、顺序和异常处理都可以提前定义，运行时也几乎不需要模型重新判断下一步。

这种场景直接使用 Workflow（工作流）往往更合适。

代码能够确定完成的事情，优先交给代码完成。这样延迟更低、成本更稳定，行为也更容易测试和审计。

像定时生成报表任务，数据同步任务或文件格式转换，如果这里引入 Agent，通常只会增加不确定性，尤其是报表统计，统计的对错你都不知道。

右下：路径未知 + 短任务

当任务规模不大，但执行路径需要根据实时结果动态决定时，ReAct 就很合适。

例如：

简单线上故障排查简单线上故障排查

企业内的搜索问答企业内的搜索问答

临时信息收集临时信息收集

数据查询与分析数据查询与分析

MCP 工具调用MCP 工具调用

智能客服中的问题诊断等智能客服中的问题诊断等

比如你同事问为什么这个接口请求失败了？ Agent 可能会先查日志，发现认证错误，随后检查 Token，发现 Token 已经过期，于是继续查询认证服务状态。

整个任务也许只需要三五轮，但每一步都依赖上一轮 Observation。这种场景没必要先生成一个复杂 Plan，直接通过Reason → Action → Observation 快速探索，通常效率会更高。

左上：路径明确 + 长任务

当任务比较长，但整体路径相对稳定时，Plan-and-Execute 开始体现优势。例如企业内需要深度研究，或者技术报告需要生成，或者大型项目需要迁移等。

假设任务是把一个 Java 17 项目升级到 Java 21。大致可以提前知道需要经历依赖分析、构建配置修改、代码兼容性处理、测试、构建和验证这些步骤。

执行过程中可能出现局部问题，但整体结构不会频繁变化。这时候先生成 Plan，再根据 Execution State（执行状态）逐步推进，可以减少每一步都重新思考“下一步干什么”的成本，同时也更方便实现进度管理、并行执行、失败恢复和审计。

因此，这一象限的核心需求通常是保持长任务的全局结构。

右上：路径未知 + 长任务

这是最复杂的一类，也是很多现代 Coding Agent（代码代理）、Research Agent（研究代理）和运维 Agent 真正面对的场景。

例如修复一个大型项目中的未知 Bug，并完成代码修改、测试和验证。

这里同时存在两个问题。

第一，任务很长，Agent 可能需要阅读代码、搜索调用链、分析日志、复现问题、定位根因、修改代码、执行测试，再根据测试结果继续调整。

第二，路径高度不确定，在真正调查之前，很难知道问题究竟来自数据库、并发控制、缓存、网络、配置还是业务逻辑。

如果一开始生成一个固定 Plan，然后机械执行到底，计划很快可能因为新证据失效。反过来，如果整个任务始终依赖纯 ReAct，让模型每一步都临时决定下一步，执行几十轮之后又容易出现上下文膨胀、目标漂移和状态失控。

因此，这类任务通常需要一种分层结构 Plan → Execute → Observe → Verify → Replan，顶层 Plan 负责维持长期目标和任务结构，局部 Executor 可以通过 ReAct 探索具体问题，一旦新证据改变了原来的判断，再触发 Replan。

可以把它简单理解成：

Plan：保证方向；

ReAct：处理局部不确定性；

Execution State：记录当前进度；

Replan：处理计划失效。

这也是为什么很多复杂 Agent 最终都会走向混合架构，而不是只使用一种模式。

所以，这个二维模型可以先给出一套非常粗粒度的判断：

路径确定 + 短任务，优先 Workflow。

路径未知 + 短任务，优先 ReAct。

路径明确 + 长任务，优先 Plan-and-Execute。

路径未知 + 长任务，更适合 Plan + ReAct + Replan。

不过这里还有一个很重要的补充：二维模型只能完成第一轮筛选。

进入具体工程设计之后，还要具体问题具体分析。很多时候业务的具体变量最终决定的，已经不只是“选 ReAct 还是 Plan-and-Execute”，而是整个 Agent Control Plane（Agent 控制面）应该设计到什么程度。

九、生产级 Agent，老李更建议使用混合架构

实际工程里，老李不会把 ReAct 和 Plan-and-Execute 当成互斥选择。上面我们也讲到了，现代意义的 Coding Agent 通常都是混合架构，因此更合理的脚骨应该是：

这里实际上是三层控制。

第一层：Strategic Planning（战略规划）

这一层负责的是整个任务的全局方向，它需要回答的问题通常是 为了完成用户目标，整个任务应该拆成哪些阶段，这些阶段之间是什么关系？

例如，用户要求修复一个大型项目中的登录异常，并完成验证。Planner 可能先生成一份高层计划：

1

分析问题现象；分析问题现象；

2

定位相关代码；定位相关代码；

3

确认根因；确认根因；

4

修改代码；修改代码；

5

编译项目；编译项目；

6

执行测试；执行测试；

7

Review（代码审查）；

8

输出最终结果。输出最终结果。

这里关注的是任务结构，而不是每一步具体应该调用哪个工具。

例如“定位代码”这个阶段，Strategic Planning 只需要明确需要找到与登录流程相关的实现，并确认关键调用链即可。至于后面究竟要搜索哪些关键词、读取哪些文件、分析哪些符号，可以交给具体 Worker 自己完成。

因此，这一层的主要职责可以概括为：

保持用户最终目标；保持用户最终目标；

拆解任务阶段；拆解任务阶段；

管理任务依赖；管理任务依赖；

确定执行顺序；确定执行顺序；

分配 Worker；分配 Worker；

维护整体 Plan State（计划状态）。

它控制的是整个任务的宏观路径。

第二层：Tactical ReAct（战术级 ReAct）

进入某一个具体 Task 后，就没有必要让 Planner 继续控制每一个细节。

例如当前任务是 修改登录模块中的 Token 校验逻辑。

这个任务虽然目标明确，但真正修改代码时仍然存在大量局部不确定性。Worker 可能先搜索相关代码：

这里每一步都可能受到前一步结果影响。

例如：

搜索结果发现实现不在预期模块

读取文件后发现还有一层中间封装

修改代码后编译失败修改代码后编译失败

编译通过但测试暴露新的边界条件

这些情况都很难在顶层 Plan 中提前写死，所以 Worker 内部更适合采用 ReAct 模式，它不断根据当前环境反馈调整下一步动作，直到完成这个局部 Task。

因此，Tactical ReAct 的职责更接近：

在局部任务范围内探索在局部任务范围内探索

动态选择工具动态选择工具

根据执行结果调整下一步根据执行结果调整下一步

解决编译错误、测试失败等局部问题

最终产出 Evidence / Result（证据与结果）

Strategic Planning 决定 我要完成“修改登录逻辑”这个任务，Tactical ReAct 负责 具体怎么把这个任务完成。

第三层：Replan（动态重规划）

局部执行过程中，有时会获得足以推翻原计划的新证据，例如最初的判断是登录超时可能来自数据库查询过慢。于是 Plan 中可能安排：

1

检查数据库查询；检查数据库查询；

2

优化 SQL；优化 SQL；

3

增加索引；增加索引；

4

执行测试；执行测试；

5

发布验证。发布验证。

但 Worker 在调查过程中发现真正的问题来自缓存一致性，数据库查询本身没有异常。这时候原来的后续任务已经失去了意义。如果系统继续按照的流程图优化 SQL → 增加索引 → 测试 机械执行，只会浪费时间甚至可能引入新的风险。

因此，新 Evidence 需要重新反馈给 Planner 发现了缓存不一致性问题，需要重新生效后续任务。Replanner 的作用就是判断 新信息是否已经足以改变原来的任务结构？

如果答案是否定的，可以继续执行当前 Plan，如果答案是肯定的，就需要修改后续任务，例如从优化数据库 → 增加索引 → 测试 调整成 分析缓存更新逻辑 → 修复一致性问题 → 增加测试 → 验证。

这一步保证了 Agent 不会被最初的 Plan 流程固定死。

三层控制其实对应两个不同尺度的反馈环

从整个任务来看，系统运行的是一个较慢的全局反馈循环：

它关心的是 整个计划还成立吗？ 而每一个 Execute 内部，又存在一个更快的局部反馈循环：

它关心的是 当前这个具体任务，下一步应该做什么？ 所以，一个更完整的 Agent 控制结构可以理解为：

从架构上看，这三个层次承担的是不同职责 Strategic Planning 管方向，Tactical ReAct 管局部探索，Replan 管纠偏。

这种分层还有一个很重要的好处：它避免让一个控制机制承担所有职责。如果所有事情都交给 ReAct，长任务容易失去全局结构；如果所有事情都交给 Plan，遇到环境变化又会显得僵硬。

把二者放在不同层级之后，整个系统会形成一种更稳定的控制方式 全局有计划，局部允许探索，证据变化时能够重新规划。

/

十、一个更实用的 Agent 架构选型规则

前面已经讨论了环境不确定性、任务长度、任务依赖和副作用。真正做业务选型时，老李不太建议用简单的“ReAct +1、Plan +1”来打分，因为这些变量的重要程度并不相同。

例如，一个任务有 8 个步骤，和一个任务会直接修改生产数据库，显然不是同一个量级的问题；存在几个并行子任务，也不能和“下一步完全依赖实时 Observation”简单等权。

更实用的方式，是按顺序判断几个关键问题。

首先看：这个任务真的需要 Agent 吗？

如果流程在开发阶段就能完整确定，例如“查数据 → 调接口 → 生成报告 → 发邮件”，那么 Workflow 往往已经足够。路径固定的任务交给代码执行，通常会获得更稳定的延迟、更低的成本和更清晰的异常处理。

只有当系统无法提前写死完整路径，需要模型根据执行结果持续做判断时，Agent 才真正开始产生价值。

接下来最重要的问题是：

下一步是否高度依赖上一轮执行结果？

如果答案是“是”，任务通常具有明显的探索性。

线上故障排查就是典型例子。Agent 先查监控，发现数据库延迟升高，才会继续查慢 SQL；如果监控显示数据库正常、第三方接口大量超时，后续路径就会完全不同。

这种短而动态的任务，ReAct 很合适。

如果任务的大部分步骤在开始之前已经能够推导出来，例如项目迁移、技术报告生成、大版本升级，那么更适合先生成 Plan，再按照计划推进。

这里还有一个容易被忽略的问题：任务一旦变长，选型重点就会从“怎么决定下一步”转向“怎么维护长期状态”。

一个十几分钟甚至数小时的任务，往往需要记录当前执行到哪里、哪些任务已经完成、哪些结果已经验证，以及中断后应该从哪里恢复。

所以长任务通常需要显式的 Plan State、Execution State 和 Checkpoint。局部 Worker 仍然可以使用 ReAct，但顶层不应该完全依赖对话历史来维持整个任务状态。

然后再看任务之间的关系。

如果所有 Task 都只能按顺序执行，普通 Plan-and-Execute 已经够用；如果多个任务之间存在明显依赖，并且其中一部分可以并行执行，那么架构就需要进一步升级到 Task Graph 或 DAG Scheduler。

这时候 Planner 解决“需要做什么”，依赖图描述“任务之间是什么关系”，Scheduler 决定“哪些任务现在已经可以执行”。

最后还要看 Action 是否具有真实副作用。

查日志、读文件、搜索资料这类操作失败了通常可以重新执行；修改数据库、部署生产环境、退款、删除资源则完全不同。

一旦 Agent 能够改变真实系统状态，架构就必须进一步考虑审批、幂等、重试、检查点、结果验证以及失败补偿。

因此，可以把整个选型过程压缩成下面这条主线：

所以从工程上看，真正有用的经验判断可以简化成几句话。

路径固定、执行确定，优先 Workflow。

任务较短，但路径需要根据现场结果动态变化，优先 ReAct。

任务较长，而且整体结构能够提前规划，优先 Plan-and-Execute。

任务又长、又动态，局部还存在明显探索性，就需要 Plan + ReAct + Replan。

如果再叠加复杂依赖和并行执行，就引入 Task Graph；如果还涉及生产修改、资金、数据删除等高风险操作，则继续增加 Approval、Checkpoint、Verifier 和 Compensation 等执行治理能力。

到了复杂 Agent 系统里，真正值得讨论的问题已经逐渐从：

“ReAct 还是 Plan-and-Execute？”

变成了三个更具体的问题：

哪一层负责长期规划？哪一层允许模型自由探索？什么情况下必须推翻原来的 Plan？

例如一个成熟的 Coding Agent，顶层可以由 Planner 和 Task Graph 维持整体结构，Worker 内部通过 ReAct 搜索代码、修改文件和执行测试，Verifier 判断结果是否满足目标；当新的 Evidence 证明原来的判断已经失效时，再交给 Replanner 调整后续计划。

这样形成的其实是一种分层控制思想：

Plan 负责维持全局方向，ReAct 负责处理局部不确定性，Replan 负责在证据变化后纠正方向。

模型拥有的控制权越大，外围 Harness（执行框架）就会越重要。状态管理、权限控制、执行日志、Checkpoint、失败恢复、验证机制和可观测性等等各种因素，最终会决定了 Agent 能否从“可以完成任务”走向“能够稳定运行”。

最后

综合上述，任何一个业务系统从来不会是只有一种解决方案，也没有最完美的解决方案，更不会是非此即彼的解决方案。需要根据业务类型选择最适配的方案。以后再遇到有人说应该选 ReAct 还是 Plan-To-Execute 时，你可以根据这篇文章的思想好好跟他掰扯掰扯了。

大模型的知识又多又杂，到底怎么学？

做这行久了，被问最多的问题就一个：大模型的知识又多又杂，我到底先学啥？翻了一堆资料，看啥都像重点，结果啥都没学进去。今天把我自己一路摸出来的顺序捋一遍，零基础、应届生、转行的都适用。跟着走，至少方向不乱、不瞎忙，学完拿得出手。

第一阶段（10天）：初阶应用

这一阶段就一个目标：把大模型真正"玩明白"，不是只会聊天那种，而是能调教它、能用代码把大模型和业务接起来。

• 大模型 AI 能干什么？
• 大模型是怎样获得「智能」的？
• 用好 AI 的核心心法
• 大模型应用业务架构
• 大模型应用技术架构
• 代码示例：向 GPT-3.5 灌入新知识
• 提示工程的意义和核心思想
• Prompt 典型构成
• 指令调优方法论
• 思维链和思维树
• Prompt 攻击和防范
• …

第二阶段（30天）：高阶应用

这阶段正式进实战，目标很实在：做出两个能拿出手的东西——一个私有知识库，一个 agent 对话机器人。

• 为什么要做 RAG

• 搭建一个简单的 ChatPDF

• 检索的基础概念

• 什么是向量表示（Embeddings）

• 向量数据库与向量检索

• 基于向量检索的 RAG

• 搭建 RAG 系统的扩展知识

• 混合检索与 RAG-Fusion 简介

• 向量模型本地部署

• …

走完这 30 天，Python 或 JavaScript 背景的基本能独立做一套 RAG 应用，简历上也敢写"大模型应用开发"了。

第三阶段（约20天）：动手微调

学到这，你已经开始 “造” 模型了 —— 通过微调，搞出垂直领域的专用小模型。

• 为什么要做 RAG
• 什么是模型
• 什么是模型训练
• 求解器 & 损失函数简介
• 小实验2：手写一个简单的神经网络并训练它
• 什么是训练/预训练/微调/轻量化微调
• Transformer结构简介
• 轻量化微调
• 实验数据集的构建
• …

恭喜你，如果学到这里，你基本可以找到一份大模型 AI相关的工作，自己也能训练 GPT 了！通过微调，训练自己的垂直大模型，能独立训练开源多模态大模型，掌握更多技术方案。

到此为止，大概2个月的时间。你从 “只会用” 变成 “能造” 的 AI 小子。那么你还想往下探索吗？

想要入局AI大模型赛道、抢占行业红利的朋友，微信扫描下方CSDN官方认证二维码，即可100%免费领取全套学习资料！

第四阶段（20天）：商业闭环，部署落地

技术学完，落地才算数。这阶段带你搞明白大模型怎么真正跑起来、用起来。

• 硬件选型
• 带你了解全球大模型
• 使用国产大模型服务
• 搭建 OpenAI 代理
• 热身：基于阿里云 PAI 部署 Stable Diffusion
• 在本地计算机运行大模型
• 大模型的私有化部署
• 基于 vLLM 部署大模型
• 案例：如何优雅地在阿里云私有部署开源大模型
• 部署一套开源 LLM 项目
• 内容安全
• 互联网信息服务算法备案
• …

想要入坑大模型的朋友，给大家准备了一份2026 年最新 AI 大模型全套学习资料：

1、大模型系统化学习路线

2、大模型学习视频教程

3、大模型学习书籍&电子文档

4、AI大模型最新行业报告

5、大模型项目实战&配套源码

6、2026大模型大厂面试真题

7、为什么要学习大模型？

我国在A大模型领域面临人才短缺,数量与质量均落后于发达国家。2023年，人才缺口已超百万，凸显培养不足。随着AI技术飞速发展，预计到2025年,这一缺口将急剧扩大至400万,严重制约我国AI产业的创新步伐。加强人才培养,优化教育体系,国际合作并进是破解困局、推动AI发展的关键。

8、适合谁学？

• 传统后端 / Java / 前端开发，想转型 AI 应用
• 大学生、应届生，想拿更好的 offer
• 产品经理、运营，想武装职业竞争力
• 技术负责人，想给团队落地提效

学习是反人性的，但回报是真金白银。技术会更新，赛道会切换，但只要你先动手，机会就永远站在你这边。

9、这些资料真的有用吗？

这份资料由我和鲁为民博士(北京清华大学学士和美国加州理工学院博士)共同整理，现任上海殷泊信息科技CEO，其创立的MoPaaS云平台获Forrester全球’强劲表现者’认证，服务航天科工、国家电网等1000+企业，以第一作者在IEEE Transactions发表论文50+篇，获NASA JPL火星探测系统强化学习专利等35项中美专利。本套AI大模型课程由清华大学-加州理工双料博士、吴文俊人工智能奖得主鲁为民教授领衔研发。

资料内容涵盖了从入门到进阶的各类视频教程和实战项目，无论你是小白还是有些技术基础的技术人员，这份资料都绝对能帮助你提升薪资待遇，转行大模型岗位。

想要入局AI大模型赛道、抢占行业红利的朋友，微信扫描下方CSDN官方认证二维码，即可100%免费领取全套学习资料！

好了，就写到这。路线是死的，人是活的，卡住了随时来问我。觉得有用就点个收藏，别让它进收藏夹吃灰——动起来比啥都强。