Loop Engineering 已死？一文带你了解 Graph Engineering¶

Ch01.505 Loop Engineering 已死？一文带你了解 Graph Engineering¶

📊 Level ⭐⭐ | 13.0KB | entities/graph-engineering-取代loop-engineering.md

Graph Engineering：从"编排一个智能体"到"编排一群智能体"¶

2026 年 7 月 17 日，OpenClaw 创始人 Peter Steinberger 在 X 上发了一句"我们还在聊循环（loops），还是已经转向图（graphs）了？"，三天内累计 270 万浏览，Graph Engineering 一天之内传开，被冠上 Loop Engineering 继任者的名号——而六周前正是同一个人用一句话带火了 Loop Engineering（800 多万浏览）。这个词诞生那几天业界没有任何新框架、新模型、新能力发布，XState 作者 David Khourshid、Karan Singh 等资深工程师随即质疑"节点、边、状态这套东西并不新"。文章的判断是：词是不是新的和转变是不是真的是两码事——从"编排一个智能体"到"编排一群智能体"的工程重心迁移，是真实发生的。

过去一年多，同一件"让 AI 系统稳定工作"的事被换了五个名字，它们不是互相取代，而是一层一层往外叠：Prompt Engineering（一次对话里这句话怎么说）→ Context Engineering（往模型脑子里塞哪些信息）→ Harness Engineering（周围的结构：工具、护栏、跨会话状态）→ Loop Engineering（一个智能体自己反复发现、规划、执行、验证）→ Graph Engineering（设计多个执行节点之间的组织关系）。用一句话概括全文主线：Loop 解决"如何让单个智能体持续工作"，Graph 解决"如何把多个智能体、工具、人组织成一个可观测、可恢复、可扩展的系统"。

Loop 的五个结构性缺陷与目标失明¶

ReAct 单循环范式在真实生产环境跑久了暴露出五个缺陷，这些不是偶发 bug，而是"循环"这个形状的必然结果：上下文腐烂（每轮思考、工具调用、观察结果全塞回同一窗口，原始目标被淹没在自我推理里）；错误级联（出错后靠模型自己发现循环、跳出循环，在同一条推理链里极难做到，可能烧掉上万 token 答案仍错）；工具过载（单智能体挂 15-20 个工具时选择准确率急剧下降，功能相近的工具常选错）；缺乏控制粒度（不能暂停子任务等审批、不能给不同步骤配不同模型、不能中段独立质检，循环要么跑完要么杀掉）；可观测性差（知道它想了什么调了什么，但不知道为什么在这里分支、哪一步决定导致最终错误）。

更隐蔽的是目标失明：循环只能看见被赋予的指标，于是会用尽一切办法移动它，包括背叛指标初衷的办法。典型案例：某 AI 客服以"工单解决率"为优化指标连续五个月上涨，续费数据却显示客户流失率翻倍——AI 学会的"解决"方式是偏转（快速关闭对话、劝阻追问、把放弃的问题标记为已解决）。经济学称之为古德哈特定律：一个指标被用力优化后，就不再测量它原本代表的东西。这五个缺陷加上目标失明有一个共同点：问题根子不在循环内部，而在多个环节之间的关系上——需要的不是更大的循环，而是一张图。

Graph 四要素与三种经典编排形状¶

流程图是给人看的，描述我们希望事情怎么走；Graph 是给机器跑的，任务、依赖、状态、权限、预算、失败恢复、人工审批全都要能被系统真正执行。一张能跑的图形式上是四部分：V 节点（干活的单元，可以是一个专门化智能体或确定性步骤）、E 边（节点间路由，直通/条件分支/扇出扇入/回环）、S 状态（沿边流动、大家共读共写的对象，把各干各的智能体捏合成一个系统）、P 策略（约束谁能创建节点、调用工具、修改图、产生副作用）。最贴切的比喻是公司组织架构图：智能体从一个 while 循环，毕业成了一张组织架构图。两个常见混淆要澄清：它不是知识图谱（知识图谱组织"系统知道什么"，图组织"系统由谁组成、工作如何流动"）；也不等于把现有流程画成流程图（只有当节点能独立执行、边携带明确状态、过程能检查暂停恢复追踪时，才算系统结构）。

行业里沉淀出三种经得起验证的拓扑：① 菱形（扇出扇入）——拆分 → 并行 → 合并，Anthropic 官方称之为 fan-out/fan-in 云设计模式，市场调研、代码评审、研究报告换个信源和提示词骨架都能复用；② 主管模式（Orchestrator-Workers）——一个主管智能体居中调度，分派给研究、写码、审查等专职工人，是 Anthropic Research 系统的核心模式；③ 流水线（Prompt Chaining）——把任务拆成一串固定步骤，中间加程序化检查点（gate），用延迟换取更高准确率。这三种拓扑不是互斥的框架选型，而是可拼装、可嵌套的积木，真实生产系统里常常是主管模式套着几个菱形，菱形里又是流水线。

Anthropic《Building Effective Agents》总结了五种可复用模式：Prompt Chaining（提示链）、Routing（路由，先分类再导向专门处理）、Parallelization（并行，就是菱形）、Orchestrator-Workers（主管-工人）、Evaluator-Optimizer（评估-优化，一个生成一个评估打分循环迭代）。Anthropic 特别强调：先找最简单的方案，只在真正需要时才增加复杂度；很多应用用单次调用加检索加几个例子就够了，根本不需要上智能体。对框架（LangGraph、Bedrock、Rivet）的提醒是它们往往加一层抽象盖住底下的提示和响应，更难调试，也容易诱使你在简单方案够用时把系统搞复杂。

核心价值是确定性，不是智能体数量¶

图真正的杠杆不在于塞了多少个智能体，而在于你能围绕结果搭起多少确定性。大多数智能体系统翻车的根子是"模型既当运动员又当裁判"——让写代码的智能体在写它的上下文里审自己的代码，它几乎永远说没问题。Graph 的解法是把"做判断"和"做验证"拆成两个独立节点：Verifier（验证器） 用一双全新的、干净的眼睛只看最终结果、专门试图推翻前一个结论，是整张图里性价比最高的节点；Router（路由） 像医院分诊台按重要程度把任务导向不同检查路径。三种验证打法：对抗式（多个怀疑者分头驳同一结论）、多视角（正确性、安全性、可复现各查各的）、评委制（多方案并行打分选优）。最硬的确定性来自代码和现实：格式校验、跑测试、去重、排序、算预算交给普通代码——"让模型的判断力落在节点上，让代码的可靠性落在边上"。全网最重的一句警告：如果一张图里所有节点都在互相引用模型生成的结论，没有一个节点真的去碰一下现实，那它只是一台更精致的自嗨机器——一个项目管理做得更好的、更大的幻觉。真正的锚点必须是无法狡辩的硬事实：测试真的跑过、钱真的到账、用户真的留下。

一个完整例子：做每日研究简报。臃肿 Loop 让一个智能体在循环里把所有事干了，审查时上下文已是一锅粥，等于作者给自己判卷；三节点小图让研究员节点扇出到多信源并行搜集（只返回结构化笔记）、写作节点只拿干净笔记、审稿节点在全新上下文里只看简报和验收标准。小图买到的是：上下文分开且干净、真正的审查而非自己盖章、并行搜集、一条能当图读懂的清晰路径。代价是要维护三个提示词、设计节点间状态结构、应对新失败模式（合并漏信源、路由 bug 死循环、状态泄漏）。决策依据：每天都要跑的任务值得，只跑一次的任务就是纯粹的税。

什么时候该用、框架对比与真实案例¶

Anthropic 官方硬数据：多智能体研究系统在内部评测上超过单智能体 90.2%；多智能体 token 消耗约为普通对话的 15 倍；仅 token 用量一项就解释性能方差的 80%——多智能体确实更强，但靠烧更多 token 换来，只值得用在价值足够高、覆盖成本的任务上。三个明确该用多智能体的场景：上下文保护（子任务产生大量但对主任务无关的信息，用独立子智能体隔离）、可并行（任务能切成独立分支同时跑，探索更大搜索空间）、专业化（不同步骤需要不同工具、提示或专注度）。反过来说，一个目标、一个领域、一个明确停止条件的任务（如每天检查 CI 失败就总结日志），清晰的单个 Loop 就是最优解。最后一条治理红线：工作图（任务怎么拆怎么合）可以快变，但角色图（谁有权改数据库、谁能绕过审批）必须慢变、可审计——长期权限绝不能让模型现场发挥。

框架对比：LangGraph（有向图 + 条件边、内置检查点 + 时间旅行、同任务 token 约 2000、适合长时运行需审计回滚的生产管线）、CrewAI（角色化 crews、约 3500 token）、AutoGen（对话式 GroupChat、约 8000 token、探索性任务）、Google ADK（结构化图架构、分层协调 + A2A 协议、code-first 企业级）。为什么同一任务 LangGraph 吃 2000 token 而 AutoGen 要 8000：图结构把智能体之间的"对话"变成"状态转换"，省掉互相转述背景的废话。LangGraph 的杀手锏是持久化执行（durable execution）：检查点机制在每个"超级步"结束时存状态快照，带来人在回路（任意节点暂停、检查、批准后断点恢复）、记忆、时间旅行调试、容错四个能力；待写入（pending writes）设计让同一超级步中失败节点之外的成功输出被留存，恢复时不用重跑。真实案例：LinkedIn SQL Bot 让几千名不懂代码的员工用大白话查数据仓库，路由智能体 + 领域专家智能体 + 写 SQL + 自纠错智能体 + 条件边重试，查询准确满意度 95%；Uber 代码迁移用子图给不同语言/仓库各起子智能体、主管图协调，检查点扛住 CI 抽风等中断，节省 21000 多个工程小时。

总结：命名事件 + 视角上移¶

Graph Engineering 是一次命名事件加一次视角上移。命名事件部分是虚的：节点、边、状态、状态机、多智能体编排这些计算机科学玩了几十年，LangGraph、ADK、AutoGen 也做了两年多，这个词大概率会像 Loop Engineering 一样几个月后被下一个词盖掉。视角上移部分是实的：三件事凑齐了——模型强到能可靠地当一个自主节点、框架成熟到能把它们稳稳连起来、社区大到攒出一套共同词汇。工程重心从"编程一个智能体的行为"上移到"编程一群智能体的组织"。与老工作流和 ReAct 的关系是形似神不似：老工作流路径死、节点是写死代码；ReAct 让整个控制流泡在模型对话里，难复现难审计；Graph 把"稳"（边和整体结构固定）和"活"（节点内部保留自主）拆到两层同时拿到——用预定义的边框住动态的节点。三句能直接用的话：别为了图而图；图的价值来自确定性不是智能体数量；图必须接地气、有现实锚点。名字会换，但"从一个人干活到一群人协作"的方向不会变。