ReAct on AI博士万戈

Agent 架构全景图：从单次调用到多 Agent 协作，我盘点的 8 种设计！

admin@yesmiracle.net (万戈) — Fri, 14 Aug 2026 00:00:00 +0000

如果你最近在关注 Agent 圈，一定见过这些词：ReAct、Plan-then-Execute、Reflection、Graph、Multi-Agent、MCP……

看得越多，越容易懵：这些到底有什么区别？我该用哪个？它们是一回事吗？

这篇文章，我想用第一人称，把我做 Agent 基础设施这几年来理解的架构全景梳理一遍。从最简单的单次调用，到最复杂的图编排，一共 8 种设计。 每种我都会说清楚：核心循环长什么样、适合什么场景、工程上最头疼的问题是什么。

如果你更关心多 Agent 怎么协作，可以看我之前写的多Agent 系统架构设计系列（编排模式、通信层、演进路径、Agent 即服务共四篇）。这篇先讲「单 Agent 内部」的地基。

先给一张全景图

架构	核心循环	复杂度	典型场景
单次调用	问→答	★	翻译、结构化输出
ReAct	想→做→看→想	★★	通用工具调用
Plan-then-Execute	计划→执行	★★★	复杂任务拆解
Reflection	执行→反思→修正	★★★	高准确率要求
记忆增强	循环+记忆层	★★★★	长期任务、个性化
工具增强	发现→选→调	★★★★	工具密集场景
多 Agent	多循环协作	★★★★★	专业分工
图编排	节点+条件边	★★★★★	复杂工作流

复杂度不代表「高级」。很多生产系统，反而应该从最简单的开始。

1. 单次调用：最朴素，也最容易被低估

User → LLM → Response

没有循环。一次推理，模型自己决定要不要调工具，一次完成。

我刚做 Agent 的时候，总觉得要搞个复杂循环才叫 Agent。后来发现，大量真实需求（翻译、抽取、分类、结构化输出）一次调用就够了。 加循环反而引入不确定性。

工程难点反而是「简单」：怎么让输出稳定？怎么约束格式？答案通常是函数调用 + 强约束解码，而不是上循环。

2. ReAct：最经典的 Agent 循环

思考 → 行动 → 观察 → 再思考 → …

ReAct（Reasoning + Acting）是 Agent 圈的「Hello World」。模型每轮先想「我要做什么」，然后调用工具，观察结果，再继续思考。

这是绝大多数 Agent 框架的默认形态。它的精髓在于：把推理过程显式地写进上下文，让模型自己决定下一步。

工程难点有三个：

上下文膨胀：每轮对话都在累积，10 步之后 token 可能翻几倍
停止条件：什么时候该退出？步数上限、自洽性检查、还是用户确认？
错误恢复：工具调用失败，重试？换方案？还是直接放弃？

做过 Agent 的人都知道，ReAct 的坑几乎全在这三件事上。

3. Plan-then-Execute：先想清楚，再动手

[规划] 把任务拆成步骤 → [执行] 按步骤逐个做 → 汇总结果

ReAct 是「边想边做」，Plan-then-Execute 是「先想后做」。模型先输出一份完整的任务拆解，然后像执行清单一样逐个完成。

好处是可预测。每一步做什么都是预先规划好的，中途不会跑偏。而且每个子步骤可以用 ReAct 作为内层循环，形成「计划 + 行动」的两层结构。

我自己的经验：凡是涉及「多步骤、有依赖关系」的任务（比如写代码、做调研），先规划再执行，成功率明显高于裸 ReAct。 规划本身就是一次免费的「预演」。

4. Reflection：会自我反思的 Agent

执行 → 评估 → 发现问题 → 重新执行 → …

ReAct 跑完一轮就结束？Reflection 不这么认为。它加了一个「事后检查」环节：让模型评估自己的输出，发现问题，再迭代一轮。

典型实现是 Actor + Evaluator 分离：一个 Agent 干活，另一个 Agent 挑毛病，然后回到干活 Agent 手里修正。听起来简单，但效果往往出奇地好——很多「最后一轮质量差」的问题，其实就是缺一次反思。

代价是 token 消耗翻倍，而且反思轮次要有上限，否则会陷入自我怀疑循环。

5. 记忆增强：给循环加一个「硬盘」

循环 ←→ 短期记忆（当前上下文）
     ←→ 长期记忆（向量检索）
     ←→ 经验记忆（技能库）

前面的架构都假设「一次任务一次会话」。但真实世界的 Agent 需要记住：上次用户说过什么、这个项目的背景是什么、我上次踩过什么坑。

记忆增强架构把记忆拆成三层：

短期：当前会话上下文，随循环滚动
长期：跨会话的事实，用向量库检索
经验：从历史中沉淀的「技能」，下次直接复用

我做的 Hermes 就是这么设计的——memory 存长期事实，skills 存可复用的方法论，两者在每个循环里自动注入。记忆不是缓存，是 Agent 的「人格连续性」。

6. 工具增强：MCP 时代的主角

工具注册 → 发现 → 选择 → 执行 → 结果处理

当工具数量从 3 个涨到 300 个，问题就从「模型会不会调工具」变成了「模型怎么知道有哪些工具、该调哪个」。

这一层是我做 MCPZERO 的主场，也是这两年变化最大的地方：

MCP 把工具变成标准协议，Agent 不再为每个工具写适配器
渐进式发现（progressive discovery）让 Agent 按需加载工具，而不是启动时全部塞进上下文
安全网关 在工具调用节点上做校验——参数合法性、权限边界、危险操作拦截

工具增强的核心矛盾是：工具越丰富，Agent 越强大，但上下文越拥挤、攻击面越大。 这层架构的价值，就是在这三者之间找平衡。

7. 多 Agent：一群专家，还是一个全能？

Orchestrator → 派活 → Worker 们 → 汇总

当一个 Agent 的上下文装不下所有技能，就拆成多个专业 Agent：一个负责调研，一个负责写代码，一个负责审查，一个 Orchestrator 负责调度。

多 Agent 的复杂度是质的飞跃——状态一致性、死锁、谁做最终决策、Agent 之间怎么「说话」。我之前的系列文章用了四篇才讲完这块，这里不展开。

一句话总结我的观点：多 Agent 是最后的手段，不是第一选择。 单 Agent + 好工具，能解决 80% 的问题。

8. 图编排：把 Agent 变成状态机

[分析] → [路由] → [搜索] → [综合] → [校验]
              ↓           ↑
          [问用户] ────────┘

前面几种架构，流程都是隐式的——模型在循环里自己决定下一步。图编排反过来：用显式的有向图定义每一步。 节点是处理单元，边是条件路由，支持并行、分支、人工介入。

好处是可控、可预测、可审计。坏处是死板——图是预先画好的，模型只能在节点内部发挥，碰到图没覆盖的情况就抓瞎。

我的判断：图编排适合「流程已知、稳定性优先」的生产场景（比如企业审批流、风控流水线）；探索型任务（比如研究、写代码）更适合让模型自己走 ReAct。

混合架构才是现实

说了 8 种，但真实的生产系统几乎都是混合的：

底层是 ReAct 循环（核心引擎）
上层叠 Plan 或 Graph（编排层）
中间挂 记忆层（上下文管理）
外围接 工具层（MCP 注册）
复杂的再加 多 Agent 协作

比如我平时用的 Hermes：ReAct 驱动核心，memory + skills 提供持久化，cron + delegation 做编排，MCP 接外部工具。它不是一个「单一架构」，而是每层选最合适的模式。

写在最后

盘完这 8 种架构，我最大的感受是：架构是手段，不是目的。

不要因为「Graph 听起来高级」就用 Graph，不要因为「多 Agent 很酷」就强行拆。先想清楚你的任务特征：是线性的还是分支的？需要记忆吗？工具多不多？要不要人工介入？

从最简单的架构开始，遇到瓶颈再加复杂度——这是我在 Agent 基础设施这条路上，用无数个深夜换来的经验。

希望这份全景图，能帮你在架构选型时少走一点弯路。

如果你对 Agent 安全网关、MCP 渐进式发现这些底层架构感兴趣，欢迎关注 MCPZERO（mcpzero.io）——我正在做的开源 Agent 基础设施项目。

Loop Engineering 和 Graph Engineering 到底有什么不同！一篇文章讲透两种 Agent 架构设计思想

admin@yesmiracle.net (万戈) — Fri, 14 Aug 2026 00:00:00 +0000

如果你这段时间关注过 Agent 框架的讨论，一定逃不开两个词：Loop Engineering 和 Graph Engineering。

有人把它们当成两个流派来争：哪个更好？哪个是未来？

也有人把它们混着用：明明是个 ReAct 循环，偏要说自己上了图编排。

我觉得这两个词被过度营销化，反而让真正做架构选型的人更困惑了。所以这篇我想换个角度——不站队，不吹捧，只对比。 从六个维度说清楚它们到底差在哪，以及更重要的：你该怎么选。

如果你还没看我的 Agent 架构全景图，建议先翻一下那篇。这篇是对全景图里「循环」和「图」两个概念的具体展开。

先理解各自的核心思想

别管那些花哨的术语，先用两个生活类比：

Loop Engineering，像你第一次去一个陌生的地方。

你打开地图导航，走一段，看一段，发现错了就重新规划路线。每一步都依赖上一步的结果，你不知道终点长什么样，但你知道下一步该往哪走。走错了？没关系，重新算路就是。

这是 「边走边看」 的模式——感知、思考、行动、观察，再感知。每一步的决策都基于当前状态，不需要全局蓝图。

Graph Engineering，像是装修房子的施工图。

画图纸的人已经把每一步都定死了：先拆旧墙，再布水电，贴瓷砖，最后软装。每个阶段之间有明确的先后顺序和依赖关系，不能跳过，不能乱序。如果水电验收不合格，图纸上已经画好了回退到布线的分支。

这是 「按图施工」 的模式——每个节点做什么、失败时走哪条边，都在图里提前定义了。

现在翻译回技术语言：

Loop：Agent 自己在运行中动态决策下一步。一个循环里包含多次 LLM 调用，每次根据最新的上下文调整方向
Graph：引擎在运行前定义好的拓扑。每个节点是确定的处理单元，边是条件路由，运行过程是沿着图从一个节点走到另一个节点

六个维度对比

1. 控制粒度

维度	Loop	Graph
控制范围	单步内（怎么想、怎么选工具）	步骤间（先做什么后做什么）
决策主体	LLM 自己	预定义的路由逻辑 + LLM 做节点内决策
自由度	高，模型自己决定顺序	低，拓扑固定死了

Loop 的自由度高，但意味着不可预测。Graph 的可预测性强，但灵活性差。

一个简单判断：如果你能接受「同一个问题两次可能走完全不同的路径」，选 Loop。如果不能，选 Graph。

2. 状态管理

Loop 的状态是隐式累积的——所有对话历史、工具返回结果，全堆在一个上下文里。这是它最大的工程挑战：上下文不断膨胀，模型容易迷失。

Graph 的状态是显式传递的——节点之间通过数据结构（比如 State 对象、消息队列、共享存储）传参。每个节点只需要知道输入和输出，不需要阅读整个对话历史。

引出的工程问题也不同：

Loop 的核心问题是：怎么在有限的上下文窗口里保留最重要的信息？（上下文压缩、摘要、滑动窗口）
Graph 的核心问题是：怎么设计节点间的数据契约？（接口定义、序列化、一致性）

3. 容错

Loop 的容错很简单粗暴：重试。 这一步模型回答错了、工具调用失败了？重新来过。最多加点随机性（temperature）或者换个 prompt。

Graph 的容错有更多选择：节点内部重试、走到失败分支、回退到上一个节点、甚至整条路径重新规划。每条边都可以定义不同的异常处理逻辑。

但选择多也意味着复杂度高——图编排的容错策略需要提前设计，不能像 Loop 那样现场发挥。

4. 可观测性

Loop 的可观测性就是 看日志。你把每步的思考、行动、观察记下来，就是一条执行轨迹。直观，但被动——你只能看到模型做了什么，很难「为什么走到这一步」。

Graph 的可观测性好很多：每个节点有明确的状态（等待中、运行中、已完成、失败），每步转换有明确的触发条件（条件边的评估结果）。你可以在任何一个时间点回答「当前在哪、已经走过了哪些节点、下一步可能去哪」。

这就是为什么对稳定性要求高的生产系统倾向于 Graph——可观测性强意味着可审计、可干预。

5. 开发效率

Loop 的起步极快。几行代码就能跑一个 ReAct Agent，甚至不需要框架：

while not done:
    thought = llm(history + tools)
    result = execute(thought.action)
    history.append(result)

Graph 需要提前设计拓扑，写节点定义、边逻辑、状态类型，调试起来也更麻烦——你得跑完整个图才能验证某条边对不对。

Loop 适合快速验证想法，Graph 适合把想法产品化。

6. 确定性

这是最根本的区别。Loop 的每一步输出都不确定——同一个 prompt 给两次，模型可能选不同的工具、走不同的流程。这是 LLM 的概率本性决定的。

Graph 的拓扑是确定性的——节点和边画好了，不管跑多少次，路径选项是一样的（虽然节点内部的 LLM 调用仍然概率）。

这和「可预测性」直接挂钩：Loop 适合容忍不确定性的场景，Graph 适合要求确定性的场景。

选型决策框架

在我看，这个问题不需要纠结。三条判断标准：

条件	倾向
任务流程可预期吗？	可预期 → Graph，不可预期 → Loop
需要人工介入吗？	需要 → Graph（天然支持 human-in-the-loop 节点），不需要 → Loop 也可以
需要并行吗？	需要 → Graph（自然支持分支并行），不需要 → Loop 更简单

翻译成人话：

做探索型任务（调研、写代码、数据分析）→ Loop 更好。因为你不知道过程中会发现什么，让模型自己调整方向更高效
做生产型流程（支付风控、内容审核、审批流转）→ Graph 更好。因为流程是确定的、需要审计、需要人工兜底
两者都有 → 混合。Graph 的大节点内部跑 Loop

现实是混合的

几乎所有生产级 Agent 系统，最后都是混合形态。

最经典的模式：Graph 的外壳，Loop 的内核。 整个系统的骨架用图定义（主干流程、分支路径、人工介入点），每个节点内部用 Loop 执行具体任务（节点内的 ReAct 循环）。

就像不是每个项目都适合瀑布流或纯敏捷一样，Loop 和 Graph 也不是二选一。先想清楚：你的任务，是可预期的施工图，还是边走边看的导航？

想明白了，选型就定了。

写在最后

写这篇对比，不是为了说 Graph 比 Loop 好——恰恰相反，我觉得很多场景用 Loop 就够了，上 Graph 反而是过度工程。

但如果你问我在生产系统里观察到什么趋势：大部分团队的问题不是「选错了」，而是「只用了一种」。 他们不知道 Loop 和 Graph 可以叠加使用，把本来能互补的能力做成了非此即彼的选择。

希望这篇能帮你跳出这个误区。

如果你对 Agent 循环和工具调用相关的底层架构感兴趣，欢迎关注 MCPZERO（mcpzero.io），我正在做 Agent 基础设施安全层的渐进式发现和网关保护。

ReAct on AI博士 万戈

Agent 架构全景图：从单次调用到多 Agent 协作，我盘点的 8 种设计！

先给一张全景图

1. 单次调用：最朴素，也最容易被低估

2. ReAct：最经典的 Agent 循环

3. Plan-then-Execute：先想清楚，再动手

4. Reflection：会自我反思的 Agent

5. 记忆增强：给循环加一个「硬盘」

6. 工具增强：MCP 时代的主角

7. 多 Agent：一群专家，还是一个全能？

8. 图编排：把 Agent 变成状态机

混合架构才是现实

写在最后

Loop Engineering 和 Graph Engineering 到底有什么不同！一篇文章讲透两种 Agent 架构设计思想

先理解各自的核心思想

六个维度对比

1. 控制粒度

2. 状态管理

3. 容错

4. 可观测性

5. 开发效率

6. 确定性

选型决策框架

现实是混合的

写在最后

ReAct on AI博士万戈