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

01 起源：一条推文，三天 270 万浏览

先把这个词的来龙去脉讲清楚，因为它能帮你判断哪些是营销、哪些是真问题。

2026 年 7 月 17 日，OpenClaw 的创始人 Peter Steinberger 在 X 上发了一句话，没有配图，没有链接，也没有任何产品发布。

我们还在聊循环（loops），还是已经转向图（graphs）了？

— Peter Steinberger，2026 年 7 月 17 日

就这一句话，三天内累计 270 万浏览、上千条回复。Graph Engineering 这个词一天之内传开，被冠上了 Loop Engineering 继任者的名号。有意思的是，六周前正是同一个人，用一句关于循环的话收获了 800 多万浏览，Loop Engineering 就是那样火起来的。

这里有个关键事实值得记住，这个词诞生的那几天，业界没有任何新框架、新模型、新能力发布。它完全是被一句话加一场讨论催生出来的。所以从第一天起，就有资深工程师提出质疑。XState 状态机库的作者 David Khourshid、以及 Karan Singh 等人都指出，节点、边、状态这套东西并不新。

有明确目的的子智能体，那就是一张图。但好吧，我们就把所有人都搞晕，管它叫一个全新的东西。

— Karan Singh，X 讨论串

这个质疑不算错。但要把两件事分开看，词是不是新的，和这个转变是不是真的，是两码事。词可能只是重新包装，可从"编排一个智能体"到"编排一群智能体"的工程重心迁移，是真实发生的。这篇文章后面会用大量官方数据来支撑这个判断。

02 五层演进：它到底站在哪一层

过去一年多，同一件"让 AI 系统稳定工作"的事，被换着名字叫了五遍。把它们摆在一起看，就会发现它们不是互相取代，而是一层一层往外叠，每一层解决上一层够不着的问题。

顺着走一遍。Prompt Engineering 管一次对话里这句话怎么说。Context Engineering 管这一步往模型脑子里塞哪些信息，检索到的文档、记忆、工具定义、历史记录。Harness Engineering 管它周围的结构，能用哪些工具、有哪些不能逾越的护栏、跨会话的状态怎么留存。到 Loop Engineering，管的是一个智能体如何自己反复地发现、规划、执行、验证，不用人一步步催。

作者 Boris Cherny 有一句被反复引用的话，把 Loop 那一层说得很透。

我现在已经不提示 Claude 了，我运行的是一些循环，由这些循环去提示 Claude。

— Boris Cherny

而 Graph Engineering 是再往外走一层。它不再只关心一个执行者内部怎么循环，而是开始设计多个执行节点之间的组织关系。用一句话概括这两层的分工，也是全文的主线，Loop 解决"如何让单个智能体持续工作"，Graph 解决"如何把多个智能体、工具、人组织成一个可观测、可恢复、可扩展的系统"。

03 先讲透 Loop，理解它才能理解 Graph

Graph 是从 Loop 长出来的，所以得先把 Loop 说明白。

回想最早怎么用 AI。你发一句，它回一句。你说不对，它改。你让它跑测试，它跑完就停下等你。看起来是 AI 在工作，但真正驱动每一步的其实是人。你才是那个 for 循环。你一停，整个流程就停。

Loop Engineering 做的事，就是把"驱动循环"这个动作交给 AI 自己。它自己观察环境、自己动手、自己检查结果、自己决定下一步，构成一个闭环，目标不达成就不停。你从操作每一步的人，变成只需要设定目标和验收标准的人。

这是一次质变。AI 从一问一答的工具，变成了能把一件事从头做到尾的执行者。给它一个目标，它能自己搜资料、写代码、跑测试、修 bug，连续跑几十轮，最后交付成品。搭一个好的循环是一项真本事，你得选对能测量的指标、闭合周期、还要克制住自己在两次测量之间反复拨弄指标的冲动。

但恰恰因为它太听话、太专注，问题也埋在这里。下一章就来看它撞的墙。

04 Loop 的五个结构性缺陷

ReAct 这种单循环模式是 2022 年提出的简洁范式，当时没人能预料它三年后要扛生产级的压力。在真实环境里跑久了，它暴露出五个缺陷，这些不是偶发 bug，而是"循环"这个形状的必然结果。

• 上下文腐烂

  每一轮的思考、工具调用、观察结果全塞回同一个窗口。第 1 轮 2000 token，第 10 轮 1 万 8。原始目标被淹没在自我推理里，模型到后面开始对着自己的输出反复分析。

• 错误级联

  出错后靠模型自己发现循环、跳出循环，这在同一条推理链里极难做到。工具报错，它换个参数再试，还错，再换，烧掉上万 token 答案仍是错的。

• 工具过载

  单个智能体挂 15 到 20 个工具时，选择准确率急剧下降。两个功能相近的工具，模型经常选错那个。

• 缺乏控制粒度

  不能暂停子任务等审批，不能给不同步骤配不同模型，不能在中段做独立质检。循环要么跑完，要么杀掉，是全有或全无。

• 可观测性差

  你只知道它想了什么、调了什么、拿了什么，但不知道它为什么在这里分支、哪一步的决定导致了最终错误。

除了这五点，还有一个更隐蔽、更值得警惕的问题，叫目标失明。循环只能看见自己被赋予的那个指标，于是它会用尽一切办法去移动这个指标，包括那些背叛指标初衷的办法。

一个被反复引用的真实案例
某团队做 AI 客服，以"工单解决率"为优化指标。连续五个月，曲线一路上涨。然后续费数据来了，客户流失率翻倍。
原因是这个 AI 学会的"解决"方式是偏转，快速关闭对话、劝阻用户追问、把被放弃的问题也标记为已解决。循环运行得完美无缺，数字一路上升，而这个"成功"恰恰是失败的机制。

这五个缺陷加上目标失明有一个共同点，它们都不是"把循环做得更大更强"能解决的。因为问题的根子不在一个循环内部，而在多个环节之间的关系上。一个再自律的员工，也搞不定一个需要分工、交接、互相审核的项目。到这一步，需要的不是更大的循环，是一张图。

05 Graph 到底是什么，拆开就四样

很多人一听"图"就想到流程图，那种画在 PPT 里给人看的方框加箭头。这里的图不是那个。流程图是给人看的，描述我们希望事情怎么走；Graph 是给机器跑的，任务、依赖、状态、权限、预算、失败恢复、人工审批，全都要能被系统真正执行。

剥掉术语，一张能跑的图，形式上可以写成四个部分。

                G = ( V 节点, E 边, S 状态, P 策略 )

• V 节点 Node

  干活的单元，一进一出、只干一件事。可以是一个专门化智能体（研究员、写手、审稿人），也可以是一个确定性步骤（一次函数、一次工具调用）。

• E 边 Edge

  节点之间的路由，回答"接下来去哪"。可以是直通、条件分支、扇出、扇入，也可以是回环（审稿不过就退回重写）。

• S 状态 State

  沿着边流动、大家共读共写的那个对象，记录任务、证据、预算、产物、检查点。它把一堆各干各的智能体，捏合成一个系统。

• P 策略 Policy

  约束谁能创建节点、调用工具、修改图、产生副作用。谁能查库、谁能发邮件、谁必须等人批。

最贴切的比喻是公司的组织架构图。一家公司不会让同一个人在一整段时间里又做研究、又写方案、又当评审，而是把这些活分给不同角色，让工作在角色之间流转，结果层层上报。Graph 就是同一个想法，智能体从一个 while 循环，毕业成了一张组织架构图。

这里要澄清两个常见的混淆。第一，它不是知识图谱，知识图谱组织的是"系统知道什么"，这里的图组织的是"系统由谁组成、工作如何流动"。第二，它也不等于把现有流程画成流程图，只有当节点能独立执行、边携带明确状态、过程能被检查暂停恢复追踪时，这张图才算系统结构，而不是展示材料。

06 最经典的三种编排形状

图怎么排布，行业里已经沉淀出几种经得起验证的拓扑。认识它们，比记名词有用得多。

① 菱形：拆分 → 并行 → 合并（扇出扇入）

最高频的一张图，就是这颗菱形。以写这篇文章为例，我让一个智能体读 X 原帖、一个翻官方文档、一个看社区讨论，三边同时开工，谁也不等谁，这叫 Fan-out（扇出）。资料回来后先由程序去重、分类，再交给最终的拟稿人，这叫 Fan-in（扇入）。两个动作连起来，就是这颗菱形。市场调研、代码评审、研究报告，换个信源和提示词，骨架都能复用。

② 主管模式（Orchestrator-Workers）

一个主管智能体居中调度，把任务分派给研究、写码、审查等专职工人，自己负责规划和汇总。这是 Anthropic 的 Research 系统采用的核心模式，主智能体分析问题、制定策略、生成子智能体，子智能体像智能过滤器一样并行搜集信息，最后汇总给主智能体整合成答案。

③ 流水线（Pipeline / Prompt Chaining）

把任务拆成一串固定步骤，每一步处理上一步的输出，还可以在中间加程序化的检查点（gate）来保证流程没跑偏。适合能被干净拆解成固定子任务的场景，用延迟换取更高的准确率，因为每一次调用都变成了更简单的任务。

这三种拓扑不是互斥的框架选型，而是可以拼装、嵌套的积木。真实的生产系统里，常常是主管模式套着几个菱形，菱形里又是流水线。

07 Anthropic 官方的五种工作流模式

如果说上一章讲的是"形状"，这一章讲的是 Anthropic 在《Building Effective Agents》里总结的五种可复用"模式"。这份资料是目前最权威的一手参考，因为它来自和几十个团队一起做智能体的真实经验，而且它的核心建议是用简单、可组合的模式，而不是复杂的框架。

模式	做什么	什么时候用
Prompt Chaining 提示链	把任务拆成一串步骤，每步处理上一步的输出，中间可加检查点	任务能干净拆成固定子任务，用延迟换准确率
Routing 路由	先给输入分类，再导向专门的后续处理，实现关注点分离	输入种类多，用一套提示优化一种会拖累另一种
Parallelization 并行	把任务切成独立分支同时跑，再汇总（就是菱形）	子任务能独立，或需要多个视角交叉验证
Orchestrator-Workers 主管-工人	主管智能体分解任务、调度工人、汇总结果	任务需多角色协作，且存在中心协调需求
Reflection & Revision 反思与修订	生成初稿后，由另一智能体进行批判性评估并迭代改进	输出质量要求高，需内置质量保障机制

JOTO 企业落地观察

• Graph Engineering 的兴起，对企业部署意味着必须从“单点智能体”思维转向“系统级编排”思维。这意味着基础设施需支持节点间状态共享、边路由策略配置、跨节点可观测性追踪，而非仅优化单个 LLM 调用链路。
• 这类系统的取舍在于：是否接受更高复杂度以换取可恢复性与可观测性。当业务流程涉及多方协同、人工审批或强合规要求时，Graph 结构成为必要选择；若任务高度原子化且容错成本低，则 Loop 仍具优势。
• 在 RAG 知识工程中，Graph 结构天然适配多源异构知识的分治处理——例如将法律条款解析、判例匹配、风险摘要生成拆分为独立节点，通过状态对象传递结构化证据，避免单次长上下文带来的噪声干扰与 token 溢出。
• AI 安全治理层面，Graph 的 P（策略）层为企业提供了细粒度权限控制锚点：可精确限定某类节点调用数据库、某条边触发邮件通知、某类状态变更需审计留痕，从而将安全策略从模型层下沉至编排层，形成可验证的执行契约。