从 Loop 到 Graph：一个热词背后的真实工程演进

一、思考

2026年7月17日，OpenClaw作者Peter Steinberger在X上发了一句话，一共12个单词：

“Are we still talking loops or did we shift to graphs yet?”

没有技术定义，没有架构图，没有代码示例。就是一句调侃。

四个半小时后，Hamel Husain发了一篇文章，标题气势磅礴：《Loop Engineering Is Dead. Enter Graph Engineering》。点进去一看，正文几乎空的一张图，一个句号。

然后整个AI圈子就炸了。

LangChain联合创始人Harrison Chase在7月22日发推说：“Graph engineering surfaced this weekend, kicked off by this tweet. It‘s the latest term to come out of X’s AI content factory.”连他本人都承认这是一场“概念工厂”的产物。

从Loop Engineering的系统性方法论文章（6月7日）到“Loop已死”的宣言（7月18日），中间只隔了41天。Prompt Engineering的红利期还能按年算，Context Engineering按年算，Harness按月算。到了Loop和Graph，AI行业连热词的折旧速度都开始按天计算了。

有工程师在评论区自嘲：“上个月让我写Loop，这个月让我画Graph。下个月是不是该学Hypergraph了？”

但笑归笑，这个热词确实击中了一个真实存在的问题。

二、认知

这轮讨论里的Graph，不是知识图谱，不是GraphRAG，也不是图神经网络。

它说的是一张执行图——谁先做、谁后做、哪些工作可以并行、哪个结果交给谁、谁有权否决、失败了退回哪一步、哪一步必须等人批准、状态放在哪里、钱烧到多少必须停。

更麻烦的是，目前大家嘴里说的Graph Engineering，根本就不是同一件东西。

LangChain讲的是执行图：节点做事，边决定下一步，共享状态保存系统此刻知道什么。X上最流行的解释讲的是组织图：不同节点承担不同岗位，边表达分工、交接和依赖。Carlos Perez讲的则更接近治理图：多个Loop彼此监督，防止一个Loop把错误指标越优化越漂亮。

三者有关，但不是一个术语的三份标准定义。

还有一个边界必须说清楚：Graph不等于多Agent。一个Agent可以串行穿过一张图，多个Agent也可以各跑各的、彼此没有明确交接。一个节点可以是Agent，也可以是普通代码、工具、规则、评估器，或者一个坐在屏幕前审批的人。

三、Graph到底是什么？

图工程听着玄乎，拆开看其实只有三样东西。

第一样是节点（Node）。每个节点就是一个干具体活的单元，可以是一个有专门职责的智能体（研究员、写手、审稿人），也可以是一段确定性代码（函数调用、工具请求、数据读取）。关键就一条：每个节点只干一件事。

第二样是边（Edge）。节点之间怎么走。边可以是直的，A干完交给B。可以是有条件的，审稿通过就发布，不通过就退回去重写。可以是一分多个节点同时点燃三个节点并行去跑。也可以是多合一，三份结果汇回到一处。

第三样是共享状态（Shared State）。它是那个顺着边一路流动的对象，装着任务本身、目前写到哪儿了、有哪些笔记、审出了什么结论。每个节点都从它这里读，也往它这里写。有了这份共享记录，一堆各干各的智能体才算真正连成了一个系统，而不是一个转头就忘的临时群聊。

说白了，图工程就是给智能体画一张组织架构图。一家公司不会让同一个人把调研、写作、审核一口气全包了，而是拆成不同岗位，让活儿在岗位之间流转。智能体的图，走的是同一个道理。

四、Loop

绝大多数人第一次搭AI Agent，最后都会收敛到同一个形状：一个while循环，反复调用模型，往prompt里堆上下文，直到上下文窗口塞满。

这个循环长什么样？伪代码大概六行就能写完：

while not done: prompt = 系统提示 + 历史对话 + 当前任务 resp = LLM调用(prompt) if 包含工具调用: 执行工具，结果存入对话历史 else: 输出结果，标记完成

Steve Kinney深入研究了Claude Code、Codex、Cursor、Vercel AI SDK、LangGraph等多个主流框架的源代码后，得出了一个结论：每一个AI代理框架，都收敛到了同一个架构上——一个while循环。

Loop值得它的统治地位。它简单到一句话能教完，便宜到随手就能搭，而且确实有效。对于范围清晰的单目标任务修一个bug、总结一篇文档、清洗一份数据，这已经足够。

问题是任务变复杂的时候。

一个Agent在循环里既做研究、又写稿、又审稿、又发布，会发生什么？研究的内容混进分析，代码无视审查意见，Agent同时干四份活却只有一个上下文窗口的预算。它会早期步骤的细节丢掉，产出一个看起来完整、一碰就碎的东西。

这不是模型能力不够，单个任务它都能做好。问题出在架构上：你让一个人同时当研究员、分析师、工程师和审稿人，全在一段对话里完成。

具体来说，循环架构有几个躲不掉的麻烦：

第一，慢。全程串行执行，明明后端、前端、测试能三路一起跑，也得排着队一个干完再干下一个。

第二，没有检查点。执行到第40步突然中断，要么从头重跑，要么自己钻进上下文里一点点翻。

第三，暂停麻烦。没有保存进度，中间很难停下来等人工审批，隔天再从断点接着干。

第四，“中间信息遗忘”。长对话中早期关键约束被大量中间内容淹没，模型注意力衰减。有文章用一个微服务拆分任务举例：Agent执行30轮后，“关键的API兼容约束被淹没在中间位置的对话历史中”，Agent直接修改了接口签名。

还有一个更隐蔽的问题。一个循环只能看见自己的指标，所以它会找到一切办法移动指标包括背叛指标初衷的那些办法。一支客服团队花一个季度搭建了AI聊天机器人的反馈循环，以工单解决率为指标，连续五个月看着曲线爬升。然后续约数据到了，客户流失率翻倍，机器人学会的“解决”方式是偏转：快速关闭对话、劝阻追问、把被放弃的问题标记为已解决。循环完美运行，数字一路上升，而循环的成功恰恰是失败的机制。

这就是古德哈特定律：一个指标被用力优化到一定程度，就会停止测量它曾经代表的东西。

五、那么，Graph和Loop到底是什么关系？

先给一个最直接的答案：Loop没死，Graph也不新。

你可以把一个Loop理解成一张最小的Graph，只有一个节点、一条边，而且这条边指回自己。Graph上每个Agent节点的内部，跑的还是那个熟悉的思考循环。

所以这俩根本不冲突。

Loop Engineering解决的是单个Agent如何反复思考、调用工具和修正结果。Graph Engineering解决的是多个执行单元如何拆分、并行、汇合和返工。

前者管节点内部，后者管节点之间。

53AI创始人杨芳贤在分析这轮讨论时给出了一个更精准的判断：真正发生变化的，是工程对象从“一个循环怎么跑”，移到了“多个工作单元之间怎么发生关系”。

LangChain团队的Sydney Runkle和Harrison Chase在回顾LangGraph三年发展时也表达了类似的看法。他们说，抛开流行语不谈，“将代理系统表示为图，是一种非常合理的方式来利用LLM的力量。具体来说，它允许你（作为构建者）将你对系统应该如何工作的预想，施加到更受约束的路径上，而不是仅仅依赖LLM的判断。”

这其实就是把领域知识编码成“认知架构”。就像提示词包含领域知识，把你的Agent和通用ChatGPT区分开来，图本身也是一种认知架构。

六、实际案例：Graph在真实世界里长什么样

案例一：AI资讯日报

假设你要做一个“每日AI资讯报告”系统，自动找到重要新闻、读取视频逐字稿和论文、排除重复消息、核对关键事实、最后把成稿存进Obsidian。

如果用Loop做，就是一个Agent从头干到尾：找新闻→读原文→核对事实→写稿→改错字。任务一多，这位“员工”就开始忙不过来，一边翻资料，一边记数字，还要考虑文章结构，能记住的上下文越来越满。

用Graph做，就是组个团队：有人找资料，有人核对事实，有人写稿，还有人负责挑错。研究员把笔记喂给写手，写手交给审稿人，审稿人这里挂一条有条件的边，通过就发布，不通过就退回重写。

状态一路往下流，越流越厚：研究员的笔记跟着到了写手手上，写手的初稿又跟着到了审稿人那里。每个节点各司其职，没有一个人需要记住所有事。

案例二：微服务拆分重构

阿里云一篇技术文章用一个具体的开发任务做样本：重构单体user-service，拆分为认证、画像、偏好三个独立微服务，全程保持对外API兼容。

在循环驱动型架构下，Agent在一个长对话里从头跑到尾。没有检查点，中途API超时就全部丢失。上下文线性堆积，前置约束被淹没。执行30轮后，模型直接改了接口签名。

在图执行架构下，任务被拆分为独立节点，通过有向边定义流转关系。全局统一State存储全部约束和中间结果，每个节点执行完自动落地。某个节点失败，从检查点恢复重新执行，不需要从头再来。

同一个LLM，同一个任务，不同架构的任务成功率可以相差3到5倍。

案例三：薪酬处理系统

一个开源的薪酬自动化系统展示了Graph在生产中的真实形态：每个月的运行是一个独立的LangGraph线程，图依次经过五个节点后停在“审批门”前，等待人工批准后才记录任何款项。

这种“图走到一半停下来等人工”的模式，在纯Loop架构里几乎无法优雅实现，要么一直耗着，要么中断后重新来。Graph通过内置的Human-in-the-Loop机制，把“人等机器”变成了“机器等人”。

案例四：知识库Agent

LangChain官方文档描述了一个典型的知识库Agent：使用三个子Agent进行搜索，一个GitHub Agent负责代码、issues和pull requests，一个Notion Agent负责内部文档和wiki，一个Slack Agent负责相关讨论串。

工作流有三个固定阶段：分类 → 搜索 → 合成。每个阶段由专门的节点负责，阶段之间有明确的交接逻辑。这不是让一个Agent猜该用什么工具、该查哪里，而是把搜索策略直接编码进了图的结构里。

七、但是，不要为了图而图

Graph的优势很明显，但过度工程化同样是问题。

LangGraph官方的建议非常务实：“当工作流有分支、循环、检查点或需要显式的图推理时使用LangGraph。当线性循环就足够时，避免使用图，因为图是认知开销。”

有篇文章的标题说得更直白：《The Useful Part of Graph Engineering Is Not the Graph》。Graph Engineering有用的部分，恰恰不在于“图”这个字本身。

事实上，Anthropic在2024年12月发布的工程总结《Building Effective Agents》里，早就完整整理了路由、并行化、主从编排以及评估-优化器这些多节点拓扑架构，但平实地把它们统称为工作流（Workflows）。即使到了2026年5月，Claude Code正式推出支持多Agent并发与自动化调度的大规模编排功能时，官方文档也依然将其命名为Dynamic Workflows，完全没有去蹭新名词的热度。

Grapeot.me上有一篇分析文章，标题是《为什么你必须立刻开始学习Graph Engineering？》，但内容恰恰在拆解这个概念被制造出来的过程。作者指出，如果剥离掉所有的宣发名词，Graph Engineering在计算模型和底层原语上其实没有发明任何新东西。早在2014年，Apache Airflow就已经在用DAG做任务编排了；Temporal也早就通过持久化状态机在管理复杂的分布式工作流。在Agent系统里用图来组织代码逻辑，技术创新的成分完全是零。

这场学习最大的价值，是帮你建立起对未来类似技术宣传的免疫力。

八、比较图

但更重要的是两个判断标准：

第一，看任务复杂度。如果你的任务可以用一句话说清楚、十步之内能做完，用Loop就够了。Graph是认知开销，没必要为了一碟醋包一顿饺子。

第二，看是否需要“组织”。如果你的系统里有多个角色需要分工、有明确的交接逻辑、需要人工审批、需要断点续传可考虑Graph。它本质上是一个可编程的组织架构，而不是一个“更高级的Loop”。

九、总结

从Loop到Graph，真正的变化不是技术上的革命，而是工程视角的转移。

Prompt Engineering关心的是“怎么说”。
Context Engineering关心的是“让模型看到什么”。
Harness Engineering关心的是“模型能用什么”。
Loop Engineering关心的是“任务怎样持续推进”。
Graph Engineering关心的是**“多个执行单元怎样共同负责”** 。

它们不是互相替代的关系，而是一层层向外扩展的工程对象。Prompt被放进Context，Context通过Harness送到模型面前，Harness支撑Agent Loop持续运行，多个Loop、工具、数据库和人再组成一张Graph。

模型变聪明，不等于系统变可靠。一个能力很强的Agent，可能依然拿错资料、调用错工具、在错误结果上反复重试。单点智能解决不了分工、交接、权限、验证和恢复这些问题。

越往后走，工程对象就越远离模型本身，越接近一个完整的生产系统。

所以，与其纠结“Loop死没死”“Graph新不新”，不如想清楚一件事：你正在解决的问题，到底是一个人的活，还是一群人的活？

一个人的活，交给Loop。一群人的活，画一张Graph。