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

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

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

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

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

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

先理解各自的核心思想

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

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

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

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

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

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

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

现在翻译回技术语言：

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

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

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

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

引出的工程问题也不同：

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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