果然 Loop 工程后面，新的又来了：Graph 工程

AI工程热词迭代加速，从Loop到Graph仅隔33天！文章剖析概念转变与定义争议。
核心内容：
1. AI热词迭代现象：Loop到Graph工程的快速切换
2. Graph工程多元定义：执行图、组织图、治理图等解读
3. 核心观点：工程对象转向多单元关系，Graph非全新概念

6 月 15 日，一篇文章在结尾处抛出了一个悬念：你押的那一层，三个月后还露在水面上吗？

今天是 7 月 24 日，距离那篇文章发布刚刚过去 39 天。当时还给了三个月期限，没想到 Graph 的招牌早就挂出来了。

7 月 18 日，距离上一篇仅隔 33 天，OpenClaw 作者 Peter Steinberger 在 X 上丢出一句话：“还在谈 Loop，还是已经转向 Graph 了？”

4 个半小时后，Hamel Husain 发布了一篇标题极具冲击力的 X Article：《Loop Engineering Is Dead. Enter Graph Engineering》。Loop 工程已死，Graph 工程登场。

特意点进去看了一眼，正文几乎是空的：一张图，一个句号。

这不是一套方法论，而是一场非常成功的命名行为。

更荒诞的是，Addy Osmani 那篇将 Loop Engineering 系统写成方法论的文章，发布时间是 6 月 7 日。从这轮讨论中最有代表性的 Loop 长文，到标题写着“Loop 已死”的文章，只相隔 41 天。

截至今天，这轮 Graph Engineering 热词被点燃，也才过去 6 天。

Prompt 工程的红利期还能按年算，Context 工程按一年算，Harness 按月算，到了 Loop 和 Graph，AI 行业连热词的折旧都开始按天算了。

刚刚学会 Loop 工程的 AI 工程师的嘴替：

“上个月让我写 Loop，这个月让我画 Graph。下个月是不是该学 Hypergraph 了？”

别急着报名下一门课。

把 7 月 24 日之前最有代表性的文章、框架和论文翻了一遍，得到的第一个结论仍然是：

真正发生变化的，是工程对象从“一个循环怎么跑”，转向了“多个工作单元之间怎么发生关系”。

先把最容易搞错的地方扔掉

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

。

谁先做，谁后做；哪些工作可以并行；哪个结果交给谁；谁有权否决；失败了退回哪一步；哪一步必须等人批准；状态放在哪里；钱烧到多少必须停——这些才是核心。

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

LangChain 讲的是

：节点做事，边决定下一步，共享状态保存系统此刻知道什么。

X 上最流行的解释讲的是

：不同节点承担不同岗位，边表达分工、交接和依赖。

Carlos Perez 在《From Loop Engineering to Graph Engineering?》里讲的则更接近

：优化 Loop、审计 Loop、回滚 Loop、反指标 Loop 彼此监督，防止一个 Loop 把错误指标越优化越漂亮。

为了不偷换概念，下面把执行图当作工程底座；组织图是对节点分工的解释，治理图是对权限、审计和升级关系的扩展。三者有关，但不是同一个术语的三份标准定义。

还有一个截至今天必须说清楚的边界：

一个 Agent 可以串行穿过一张图，多个 Agent 也可以各跑各的，彼此没有明确依赖、状态交接和否决关系。一个节点可以是 Agent，也可以是普通代码、工具、规则、评估器或者人类审批。Agent 数量是编制问题，Graph 是组织关系问题。

但这些不同定义最终撞上的，其实是同一个瓶颈：

把这句话抄下来：

Loop 没死，它只是被塞进了节点

Graph 工程最懒的一种讲法，是画一条升级阶梯：Prompt → Context → Harness → Loop → Graph，然后宣布上一层已经过时。这在技术上就不成立。

LangChain 当然卖的就是 LangGraph，不是中立裁判。但它在 7 月 22 日发布的《3 Years of Graph Engineering with LangGraph》里，给出了目前最具体的技术定义：一个节点可以是普通代码、一次 LLM 调用、一个工具，也可以是一个内部自带 Loop 的完整 Agent；边决定下一步去哪里；状态在节点之间流动。测试失败，沿一条边退回修改节点——这条回边就是 Loop；资料不足，Agent 继续搜索——这是 Loop；等一个人批准，三天后从检查点恢复——前后仍然是 Loop。

所以生产里的 Agent Graph 往往根本不是 DAG，不是只能向前走的有向无环图。它必须有重试、返工、追问、暂停、恢复，当然也就必须有环。

说 Graph 取代 Loop，就像说“形状取代了圆”。Graph 包含 Loop，Loop 只是从整套系统的主角，变成了节点内部或者节点之间的一条回路。Loop 没被杀死，它被降职了。

真正变化的，不是 Graph，是节点

图当然不是新技术。状态机、工作流引擎、DAG 调度，在软件工程里已经活了几十年。LangGraph 早在 2024 年 1 月就已经公开，而且它当时解决的就是“如何给 Agent Runtime 建一张有环的状态图”。严格算到今天，已经运行了两年半。

2024 年的 ICML 论文 GPTSwarm，标题就叫《Language Agents as Optimizable Graphs》。它不只把 Agent 表达成图，甚至已经在优化节点提示词和节点之间的连接。

今年 4 月 13 日，arXiv 上又出现了一篇题目更加直白的论文：《From Agent Loops to Structured Graphs》。它调查了 70 套 Agent 系统，把 Loop 和 Graph 放进同一个调度框架。但论文自己也写得很诚实：这是一篇立场论文和设计提案，没有生产实现，也没有实证结果。

这正好说明两件事：第一，问题早就在；第二，方法论远没有定型。

所以不是 7 月 18 日那条推文发出来之后，世界突然发明了 Graph。

如果一定要给这波命名找一个新变量，LangChain 给出的最宽容解释是：

过去，一个节点通常只敢放确定性函数、一次 API 调用，最多一次 LLM 推理。现在，一个节点可以自己读资料、调工具、循环几十轮、生成工件、跑验证，再把一个相对完整的结果交给下一个节点。

过去图里装的是函数，现在图里开始装“数字员工”。

于是组织架构图第一次不只是挂在墙上，它开始运行了。

节点变成岗位：研究员、工程师、测试、审计、人类审批者；边变成组织关系：谁向谁汇报，谁给谁交付，谁能否决谁，什么条件下才能进入下一步；状态变成组织记忆：任务做到哪了、用了哪些证据、花了多少钱、拿到了什么权限、前面试过什么。

从这个角度看，Graph Engineering 根本不是“又一种 Agent 技巧”，它是把组织设计写进代码。

但多几个 Agent，不等于多几份智能

Graph 工程最容易制造的幻觉，就是看见五个 Agent 在屏幕上同时闪，就觉得自己拥有了一支数字军团。现实没这么浪漫。

Anthropic 公开过它的多 Agent Research 系统：一个 Lead Agent 负责拆任务，多个 Subagent 并行搜索，最后再交给 CitationAgent 核对引用。这已经是一张相当完整的动态 Graph。结果确实很好：在 Anthropic 的内部研究评测里，多 Agent 系统比单 Agent 高出 90.2%。但它还有另一组数字：多 Agent 系统消耗的 Token，大约是普通聊天的 15 倍。Anthropic 自己也明确说，这套结构适合可以广泛并行、信息量超出单个上下文窗口、任务价值足够高的研究问题。很多编码任务依赖紧、共享上下文多、难以真正并行，反而不适合。

Google Research 后来做了一次更受控的实验：比较 180 种 Agent 配置，覆盖单 Agent、独立多 Agent、中央编排、去中心化和混合结构。结果非常干脆。在可以拆开的金融分析任务上，中央编排比单 Agent 提升 80.9%。到了严格顺序执行的规划任务，所有多 Agent 结构都下降了 39% 到 70%。在这组实验里，没有中央校验的独立式多 Agent，最高把错误放大了 17.2 倍；中央编排则把这一数值控制在 4.4 倍。Google 的完整研究在这里。

这组数据揭开了一件特别不性感、但特别重要的事：

任务天然可拆，它放大并行；任务强依赖、强顺序，它放大沟通税；任务边界清楚，它放大专业化；任务本来就糊，它放大组织混乱。

堆了二十个 Agent 的老板的嘴替：

“我以为招了二十个数字员工。跑完才发现，我只是把跨部门扯皮自动化了。”

一项 NeurIPS 2025 研究分析了七套开源多 Agent 系统的 1642 条执行轨迹。论文在所测基准上报告的失败率为 41% 到 86.7%。这些数字不能直接拿来给框架排座次，因为不同系统跑的任务并不相同。真正值得看的是，故障反复落在三类：规格与系统设计、Agent 之间失配，以及任务验证与终止。论文在这里。这三类故障，恰好就是 Graph 工程真正该干的活。

Graph 最危险的三种幻觉

第一种，流程图崇拜。很多人一听 Graph，就开始把所有路径提前画死：先 A，再 B，失败去 C，成功去 D。画完之后特别安心。问题是，真正开放的问题，路径往往只有干到一半才会出现。

LangChain 自己就承认，他们早期把 Deep Research 做成预定义 Graph，后来反而改回了更 Agentic 的 Core Loop。因为研究过程中该追哪条线、开几个子任务、什么时候收敛，根本无法事先全部钉死。

图适合表达稳定的依赖、权限和门禁，Loop 适合在不确定区域里探索。最好的系统不是 Graph 或 Loop 二选一，而是：

所以真正该被写死的，不是每一步，而是边界：哪些节点可以新建，谁能连向谁，什么状态必须留下，哪种动作必须升级。图可以在运行时长出来，宪法不能临时改。

7 月 21 日，iii 创始人 Mike Piccolo 给出了一个更狠的批评：Loop 和 Graph 都过度强调了推理的形状，而形状可能是最容易生成、也最容易被丢弃的部分。Agent 行业只是在围绕模型，重新发明一遍状态机、消息队列、重试、追踪和分布式系统。他当然也在卖自己的底层系统，有明确的产品立场。但他提出的测试很好：这张 Graph 跑通之后，给你的系统留下了什么？如果只留下一张截图和一份下次模型升级就要重写的 YAML，它就不是护城河。

第二种，Agent 人头崇拜。不是每个节点都应该放一个 Agent。能用规则判断的，不要让 LLM 判断；能用测试判死的，不要让另一个 Agent“凭感觉评审”；能从数据库查出来的，不要开三个 Agent 辩论。真正好的 Graph，往往看起来很无聊：大部分节点是确定性代码，只有少数真正需要判断、探索和生成的地方才放 Agent。不是在搭一场数字人综艺，而是在控制不确定性出现在哪里。

第三种，互相证明自己没错。Carlos Perez 对 Graph 最锋利的提醒是：一堆 Loop 彼此监督，也可能只是形成一个更复杂的自证系统。运营 Loop 看业务报表，审计 Loop 看财务报表，财务报表的数据又来自运营系统，三个 Loop 互相对得严丝合缝，所有灯都是绿的，客户却已经走光了。

所以 Graph 必须钉在某些无法靠内部话术篡改的现实锚点上：钱真的到账了吗？测试真的执行了吗？客户真的留下了吗？货真的送到了吗？还有一些规则必须冻结，不能让负责优化的 Agent 自己修改。否则它最先优化掉的，往往就是那个让它不及格的验收标准。

Graph 可以让错误变得更难发生，也可以让错误变得更有组织、更一致、更昂贵。区别就在它有没有碰到现实。

上一篇错了吗：验证与治理只是长成了 Graph

更有意思的是，LangChain 7 月 22 日刚发完 Graph 工程回顾，紧接着在 7 月 23 日又发布了《How We Benchmark Deep Agents》。后者强调，评估 Agent 不能只读最后那句“我做完了”。运行环境本身必须成为任务的一部分；验收脚本要检查它真正创建的文件、修改的状态和留下的工件；同一个任务还要重复运行，因为 Agent 天生带有方差。确定性单元测试，也不能因为有了端到端 Agent 评测就被扔掉。

这两个日期挨在一起，几乎替这篇文章做了结论：

如果验证节点只会评价另一段文字，它仍然只是系统内部互相盖章。只有碰到真实工件和真实环境，才叫验证。

在上一篇文章里判断，Loop 之上的两块高地，是验证工程和运行时治理：第一，凭什么证明它做对了；第二，就算做对了，它凭什么被允许做。Graph Engineering 并没有推翻这条判断，恰恰相反，它把这两块高地画进了系统结构里。

验证不再是 system prompt 里一句“请认真检查”，而是一个独立节点；权限不再是 Agent 自己判断“我应该可以”，而是边上的通行条件；Token、时间和预算不再是口头提醒，而是状态里的硬字段；高风险动作不再等人碰巧看见，而是必须经过人类审批节点；失败不再把整段对话推倒重来，而是从检查点重试那个节点；证据不再藏在一面文本墙里，而是跟着状态一起向下游传递。

这才是 Graph 真正值钱的地方：

Graph 的重点不在节点，在边。一家公司真正的组织能力，也从来不在它有多少岗位，而在岗位之间怎么交付、怎么否决、怎么升级、怎么对共同事实达成一致。

谁会在 Graph 工程里真正赚到钱

如果你创业，别急着再做一个“拖拽式多 Agent 编排平台”。节点、连线、暂停恢复、并行调度、可视化 Trace，这些东西 LangGraph、OpenAI、Google、Microsoft 都会继续做成基础设施。Graph 的通用运行时、编排器和拖拽画布，会是最先沉下去的部分。连自动优化节点提示词和图连接的研究，也已经公开两年多了。

真正可能留下来的，是某个垂直行业里的“组织宪法”：什么算完成，什么证据有效，谁有权批准，哪条红线不能碰，失败如何回滚，什么状态必须留痕。

如果你投资，不要问一个项目有多少 Agent。问五个问题：单 Agent 的基线是多少？任务为什么值得拆？哪几个部分真的能并行？错误会在哪条边上传播？整张图最终钉在哪个现实锚点上？如果这五个问题答不上来，那不是 Graph Engineering，那是一场用 Token 烧出来的组织行为艺术。

如果你想转型，也别急着学怎么画节点。Graph Engineering 奖励的不是更会“和模型说话”的人，而是会做系统、做组织的人：懂状态机、幂等、故障域、权限、预算、验收、回滚，也懂哪些判断根本不能外包。

Prompt 时代，写一句好指令；Loop 时代，管理一个会干活的人；Graph 时代，开始设计一家公司。只是这家公司的员工，有些是 Agent，有些是代码，有些仍然是人。

写在最后：没等三个月

回到 6 月 15 日那条水平线。今天是 7 月 24 日，离上一篇文章相隔 39 天。可早在相隔 33 天时，Graph Engineering 这块新招牌就已经挂出来了。又过了 6 天，定义仍然没有统一，课程、指南、框架和反驳已经全来了。现实比预想中来得更快。

但这篇文章不是要告诉你：赶紧从 Loop 爬到 Graph，那里是下一块永远不会被淹的高地。恰恰相反，Graph 的通用运行时、编排器和可视化画布，也会迅速沉成基础设施。很快，模型不只替你跑 Loop，也会替你画 Graph。

真正不会被白送的，是图里那些来自现实的东西：你的组织认为什么是真的，谁有权否决，哪条边不能越过，什么代价不可接受。以及最上面那个，所有 Graph 都无法替你回答的问题：我们究竟想把这套系统带到哪里去。

Loop 让 Agent 学会了不停工作，Graph 让一群 Agent、代码和人，学会了像组织一样工作。但一个组织为什么存在，从来不是组织架构图自己算出来的。

所以下一次再有人发明一个新词，先别问要不要学。先看它把人的判断，又往上推了一层没有。因为当模型连 Graph 都替你画好之后，真正决定你价值的，只剩一个问题：