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 基础设施安全层的渐进式发现和网关保护。

Graph Engineering on AI博士 万戈