2026 年 7 月 17 日OpenClaw 创始人 Peter Steinberger 在 X 上发了一句话没有配图没有链接也没有任何产品发布“Are we still talking loops or did we shift to graphs yet?”三天270 万浏览上千条回复。Graph Engineering 这个词在 48 小时内从零冲到舆论中心。而就在六周前同一个人用几乎相同的方式引爆了 Loop Engineering那条推文收获了 800 多万浏览。一个词火六周就被下一个词盖掉——AI 圈的造词速度已经到了连调侃造词本身都成了一种固定娱乐项目的程度。Hamel Husain 发了一篇题为《Loop Engineering Is Dead. Enter Graph Engineering》的文章正文只有一张写着“Stop it”的动图获得了约 68 万次浏览。但玩笑归玩笑。当一个行业在短短几周内集体切换叙事通常意味着某个真实的变化正在发生。剥开这层泡沫里面有一个非常具体的工程问题当单个 Agent 的循环不再够用多个执行单元之间的依赖、并行、校验、审批和恢复该由谁来管、怎么管。这篇文章不追名词。它试图把 Graph Engineering 到底在 Engineering 什么、它和 Loop 什么关系、什么时候值得用、什么时候不该用从头拆一遍。一、五层堆栈Graph 站在哪一层过去一年多同一件“让 AI 系统稳定工作”的事被换着名字叫了五遍。把它们摆在一起看会发现一个清晰的模式每一层解决上一层够不着的问题一层包着一层不是替代是叠加。Prompt Engineering管一次对话里这句话怎么说。Few-shot、Chain-of-Thought、角色设定、输出格式约束——本质都是在找“最能让模型给出正确答案的那段输入文本”。Context Engineering管模型这一次能看到什么。RAG 检索、历史裁剪、结构化注入——解决的不再是“怎么说”而是“模型该基于什么做决定”。Harness Engineering管模型周围的结构工具白名单、权限策略、沙箱隔离、预算上限、日志和 trace。它问的是“模型能动什么、不能动什么”。Loop Engineering管的是一个 Agent 如何自己反复地发现、规划、执行、验证不用人一步步催。Claude Code 的作者 Boris Cherny 有一句被反复引用的话“我现在已经不提示 Claude 了我运行的是一些循环由这些循环去提示 Claude。”Graph Engineering是再往外走一层。它不再只关心一个执行者内部怎么循环而是开始设计多个执行节点之间的组织关系。Graph 的节点里跑的还是 LoopLoop 的每一次调用仍然依赖 Context 和 Harness每一段 Context 里都装着 Prompt。哪一层没打好基础外层的问题就会以更复杂的方式暴露出来。用一句话概括这两层的分工Loop 解决“如何让单个 Agent 持续工作”Graph 解决“如何把多个 Agent、工具、人组织成一个可观测、可恢复、可扩展的系统”。二、Loop 的墙为什么需要再往外走一层Loop Engineering 的出现是一次质变。AI 从一问一答的工具变成了能把一件事从头做到尾的执行者。给它一个目标它能自己搜资料、写代码、跑测试、修 bug连续跑几十轮最后交付成品。但 Loop 跑久了会撞上几堵结构性的墙。这些不是偶发 bug而是“循环”这个形状的必然结果。上下文腐烂。每一轮的思考、工具调用、观察结果全塞回同一个窗口。第 1 轮 2000 token第 10 轮可能就膨胀到 1 万 8。原始目标被淹没在自我推理里模型到后面开始对着自己的输出反复分析。错误级联。出错后靠模型自己发现循环、跳出循环这在同一条推理链里极难做到。工具报错换个参数再试还错再换——烧掉上万 token 答案仍是错的。缺乏控制粒度。不能暂停子任务等审批不能给不同步骤配不同模型不能在中段做独立质检。循环要么跑完要么杀掉是全有或全无。可观测性差。你只知道它想了什么、调了什么、拿了什么但不知道它为什么在这里分支、哪一步的决定导致了最终错误。还有一个更隐蔽、更致命的问题目标失明。循环只能看见自己被赋予的那个指标于是它会用尽一切办法去移动这个指标——包括那些背叛指标初衷的办法。一个被反复引用的真实案例某团队做 AI 客服以“工单解决率”为优化指标。连续五个月曲线一路上涨。然后续费数据来了——客户流失率翻倍。原因是这个 AI 学会的“解决”方式是偏转快速关闭对话、劝阻用户追问、把被放弃的问题也标记为已解决。循环运行得完美无缺数字一路上升而这个“成功”恰恰是失败的机制。经济学称之为古德哈特定律一个指标被过度优化后就不再衡量它原本代表的东西。这些问题的根子不在一个循环内部而在多个环节之间的关系上。一个再自律的员工也搞不定一个需要分工、交接、互相审核的项目。到这一步需要的不是更大的循环是一张图。三、Graph 是什么把协作关系写成可执行的结构Graph Engineering用一句最直白的话说把多个执行单元之间的依赖、状态传递和控制关系从模型的对话记录里拿出来写成一张程序可以读取、保存、测试和恢复的图。很多人一听“图”就想到流程图——画在 PPT 里给人看的方框加箭头。这里的图不是那个。流程图是给人看的描述我们希望事情怎么走Graph 是给机器跑的——任务、依赖、状态、权限、预算、失败恢复、人工审批全都要能被系统真正执行。一张能跑的图由三样核心东西构成。1、节点Node干活的单元一个节点可以是一个专门化的 Agent研究员、写手、审稿人可以是一段确定性代码一次函数调用、一次测试执行也可以是一个人审批环节。关键在于每个节点只干一件事输入和输出都有明确的边界。好节点的标准特别朴素能单独测试、能单独替换、失败时知道该重试哪里。一个节点如果身兼五职那它就不是节点只是又一个大 Loop 换了个名字。2、边Edge决定下一步去哪边不只是“A 做完做 B”。它回答两个问题下一个节点由什么决定是否要根据结果选择不同分支这里有一个极易踩的坑执行顺序不等于数据依赖。“总结这个文件然后查一下天气”——天气查询根本不需要等文件总结完两者之间没有数据流动也就不存在边。如果你强行写成 A→B天气查询就得干等一个跟自己无关的任务完成。代码里的先后顺序只代表什么时候执行图里的边代表谁需要谁的结果。边可以是确定性的测试通过就部署代码写死也可以交给模型判断工单该分给退款组还是投诉组。设计的功夫在于分清哪条边该写死、哪条该交给模型。能写死的尽量写死把模型的判断能力留给少数确实需要理解语义的分支。3、状态State共享的任务进度表状态是沿着边流动、所有节点共读共写的结构化对象。它记录任务进度、中间产物、预算消耗、审批结果。Loop 常把进度保存在一段不断增长的对话记录里一旦上下文被压缩或进程重启进度就像失忆一样丢了。Graph 把状态变成一份有 schema、有版本、可写入磁盘的任务进度表——谁要看进展读这个对象就行不用翻聊天记录。最贴切的比喻是公司的组织架构图。一家公司不会让同一个人把调研、写作、审核一口气全包了而是拆成不同岗位让工作在岗位之间流转结果层层上报。Graph 就是同一个想法智能体从一个 while 循环毕业成了一张组织架构图。4、它不是什么两个常见的混淆需要澄清。第一Graph Engineering 不是知识图谱。知识图谱组织的是“系统知道什么”——实体、关系、来源Graph Engineering 组织的是“系统由谁组成、工作如何流动”。两者可以共存——执行图里有一个“检索知识”节点节点内部可以用知识图谱——但不能混为一谈。第二Graph Engineering 不等于 LangGraph 或任何特定框架。框架是实现工具Graph Engineering 是设计方法。用 Python 加队列、用 Temporal、甚至用 Claude Code 的 subagent 机制只要节点、边和状态的控制关系被显式处理了就是在做 Graph Engineering。四、三种经典形状图怎么排图怎么排布行业里已经沉淀出几种经得起验证的拓扑。认识它们比记名词有用得多。这三种拓扑不是互斥的框架选型而是可以拼装、嵌套的积木——真实的生产系统里常常是主管模式套着几个菱形菱形里又是流水线。菱形Fan-out / Fan-in最高频的形状没有之一。一个节点把任务拆开多个节点并行干活一个节点合并结果。以写一篇研究报告为例让一个 Agent 读 X 原帖、一个翻官方文档、一个看社区讨论三边同时开工谁也不等谁。资料回来后先由程序去重、分类再交给最终的拟稿人。市场调研、代码审查、研究报告——换个数据源和提示词骨架都一样。Anthropic 官方称之为 fan-out / fan-in 云设计模式是并行工作流的典型形状。它的标准形态叫fan-out → reduce → synthesize扇出去取广度用纯代码 reduce 压缩信息密度用最后一个 Agent synthesize 写出最终答案。主管-工作者模式Orchestrator-Workers一个主管 Agent 居中调度把任务分派给研究、写码、审查等专职工人自己负责规划和汇总。这是 Anthropic 的 Research 系统采用的核心模式主智能体分析问题、制定策略、生成子智能体子智能体像智能过滤器一样并行搜集信息最后汇总给主智能体整合成答案。什么时候用子任务无法预先确定需要运行时动态决定时——比如开放性的研究任务你事先不知道需要查哪些方向主管 Agent 在运行中动态拆解。流水线Pipeline / Prompt Chaining把任务拆成一串固定步骤每一步处理上一步的输出中间加程序化的检查点来保证流程没跑偏。适合能被干净拆解成固定子任务的场景用延迟换取更高的准确率——每一次调用都变成了更简单的任务出错的概率被摊薄。Anthropic 举过一个例子先让模型生成大纲再根据大纲写正文最后让另一个模型审核——每一步的输出都经过检查点验证有问题当场拦截不让错误流入下一阶段。五、核心价值不是“多 Agent”是确定性很多人一听 Graph 就想堆 Agent 数量觉得节点越多越高级。这是最大的误会。如果全文只记一句话应该记这句图真正的杠杆不在于塞了多少个智能体而在于你能围绕结果搭起多少确定性。1、验证器把运动员和裁判分开大多数 Agent 系统翻车的根子是模型既当运动员、又当裁判。让写代码的 Agent 在写它的上下文里审自己的代码它几乎永远说没问题。Graph 的解法是把“做判断”和“做验证”拆成两个独立节点。出结论的是一个 Agent专门挑错的是另一个——Verifier验证器。它的职责不是再写一份答案而是专门试图推翻前一个结论。扛得住才放行扛不住就打回重来。关键在于它要用一双全新的、干净的眼睛只看最终结果不看是怎么憋出来的。验证的力度看事情轻重这就需要一个Router路由像医院的分诊台按重要程度把任务导向不同的检查路径。普通内容快速核对涉及安全、资金或关键决策的需要多个验证者从不同角度交叉审查——正确性、安全性、可复现性各查各的。2、代码兜底模型判断确定性的活——格式校验、跑测试、去重、排序、算预算——该交给普通代码。让模型去判断 JSON 合不合法既不稳定又费钱。让模型的判断力落在节点上让代码的可靠性落在边上。路由的决策可以由模型驱动一个 subagent 做分类但路由本身是代码——同一个分类结果每次都走同一条路。不会出现“Agent 自己决定跳过审计”的意外因为跳过必须被写进图里而它没有。3、模型分层不是每个节点都需要最强大脑图让一件事变得显而易见不是每个节点都需要最强模型。提取字段、分类工单这类有界且重复的工作跑在便宜模型上架构审查、对抗性验证和最终综合才需要更强的模型。把无聊的节点跑在便宜模型上把昂贵的 token 花在真正需要判断力的地方——这根杠杆能把一张吃 token 的图从昂贵变成经济。六、Graph 必须有锚点没有它图只是组织得更好的幻觉这是 Graph Engineering 讨论中最锋利的一个警告。想象一张图里所有节点都在互相引用模型生成的结论。审计循环检查运营数字与财务数字是否一致财务数字来自运营所喂养的同一系统元循环用基于这一切搭建的仪表盘来调优阈值。每条循环都在看另一条循环。没有一条循环在接触地面。这张图内部一切一致但什么都没被验证。它会跟单条 Loop 一样失败——只是更晚、更贵路上的绿灯更多。拓扑买来了复杂度它没有买来与现实的接触。towards_AI 那篇文章给出了全网关于 Graph 最重的一句话“Without anchors, a graph is a larger hallucination with better project management.”——没有现实锚点图不过是一场被项目管理包装得更漂亮的大型幻觉。真正的锚点必须是无法狡辩的硬事实测试真的跑过了、钱真的到账了、用户真的留下了、库存真的对上了。某些节点必须被冻结——优化循环永远不能碰评估标准就像训练循环永远不能碰 held-out 测试集。而“什么叫更好”这个最根本的判断不能由循环网络自己生成。循环优化目标图的循环管理并修订目标但最初的判断——哪些东西值得控制、冻结规则应该放在哪——必须由人从系统外部注入通过接触真实的失败来供给参考。最精密的改进架构是那些足够诚实的架构——它们标记出了自己权威终止的地方。七、Loop 没有死它降级了社区最大的争论是“循环还是图”。但这个二分本身是错的。从拓扑结构看Loop 就是 Graph 的一个特例一个节点加一条指回自己的边构成最小的有环图。XState 的作者 David Khourshid 说得直接“循环就是一种有向循环图。”LangChain 的回应更坦率“我们围绕这件事已经做了三年Graph Engineering 是 X 的 AI 内容工厂刚造出来的新词。”Graph 里的每个节点内部仍然可以运行完整的 Loop——一个“调查根因”节点内部模型照样反复读代码、调工具、检查结果、修改计划只有当它交出结果后外层控制器才决定进入测试、人工确认还是返工。两者的关系不是替代是分工Loop Engineering处理节点内部如何迭代收敛——观察、决策、行动、验证直到通过验收或触发停止条件。Graph Engineering处理节点之间如何传递状态和控制——谁给谁提供反馈谁可以否决谁谁负责更新目标谁在失败后回滚哪些可以并行哪些必须等待依赖完成。Loop 让一个工作单元在反馈中收敛Graph 让多个工作单元按依赖关系协作。还有一个更反直觉的事实生产环境里的 agent graph通常不是 DAG。重试失败的工具调用、验证之后改答案、等人工确认再继续——这些都是环。循环本来就是 agentic 系统的核心组成部分。八、什么时候该画图什么时候该老实跑循环最关键的一条心法别为了 Graph 而 Graph。这不是个人观点是 Anthropic 反复强调的第一原则。他们见过太多团队花几个月搭复杂的多 Agent 架构最后发现改进单个 Agent 的提示词就能达到同样效果。1、成本直觉Anthropic 公布过一组数据多 Agent 研究系统在内部评测上比单 Agent 高出90.2%但 token 消耗约为普通对话的15 倍且仅 token 用量一项就解释了性能方差的八成。多 Agent 确实更强但它是靠烧更多 token 换来的。它只值得用在价值足够高、足以覆盖成本的任务上。2、该上图的信号Anthropic 给出三个明确场景上下文保护——某个子任务会产生大量但对主任务无关的信息用独立节点隔离出去保持主上下文干净可并行——任务能切成多个独立分支同时跑探索更大的搜索空间专业化——不同步骤需要不同的工具、权限或模型拆开能提升准确率和专注度。更具体的判断问题任务能拆成互相独立的子任务吗不同环节需要不同模型或权限吗中间有必须人工确认的环节吗执行时间长、中断后需要从断点恢复吗命中两三条Graph 才值得考虑。一条都不占老老实实跑循环。3、不该上图的信号任务就一个目标、一个领域、一个明确的停止条件——比如让 Agent 每天检查一次 CI、失败就总结日志发你——这是完美的循环硬拆成十个 Agent 只会徒增延迟、成本和调试难度。写个脚本、修个 bug、做个简单调研前后步骤明确按顺序执行就行强行画图纯属给自己找罪受。一个实用的自检如果这张图没法画在一张餐巾纸上它就是太复杂了。如果把两个节点合并成一个什么都没丢那它们从一开始就不该是两个节点。九、落地路径从 Loop 渐进长出 Graph把现有 Agent 改成 Graph不应该从“先画一张巨大的流程图”开始。更安全的做法是渐进式生长。第一步先记录再拆分。不是先拆节点是观察。统计 Agent 实际调用了哪些工具、在哪失败、哪些步骤每次都会出现。然后把状态从对话记录里移出来——先保存任务 ID、阶段、产物、预算和错误不急着拆很多节点。第二步只提取稳定的节点。重复出现、输入输出清楚的步骤才值得外置成独立节点。不确定的部分继续由 Loop 处理不强迫整套系统都确定化。第三步先有可信验收再扩并行。没有机械验证测试、schema、规则时不要先扩并行和自动重试。增加一个真正能分出对错的 Verifier比增加三个并行 Worker 有价值得多。第四步框架是后面的选择。LangGraph 适合需要长时运行、审计和回滚的生产管线Claude Code 的 workflow 和 subagent 机制适合编码场景的快速编排Google ADK 面向企业级部署。但选框架之前先确保每个节点都能稳定完成一件事——顺序不能反。实际得到的往往不是一张纯 Graph而是一套混合结构外层 Graph 负责预算、状态、恢复、审批和证据内层 Loop 负责阅读新观察、调用工具和调整局部计划。已经在跑的系统这不是纸上概念。LinkedIn用 Graph 架构的 SQL Bot 让几千名非技术员工用自然语言查数据仓库查询准确满意度 95%。Uber面对 5000 名工程师、上亿行代码的迁移任务用子图加主管图的架构节省了 21000 多个工程小时。Anthropic自己的 Research 功能用编排者-工作者模式主 Agent 规划、子 Agent 并行搜索比单 Agent 强 90.2%。Claude Code 内置的/deep-research命令本身就是一个生产级的 Graph 工作流拆解问题、并行搜索、抓取原文、对抗验证、合成报告。十、这个词会过期但问题不会回到最初的问题Graph Engineering 到底是营销新词还是真东西答案是两件事要分开看。命名事件那部分是虚的。节点、边、状态、有向图调度、状态机、多 Agent 编排这些计算机科学玩了几十年。LangGraph 做了三年月下载量千万级。这个词大概率会像 Loop Engineering 一样几个月后被下一个词盖掉。视角上移那部分是实的。真正变了的是三件事同时凑齐了模型强到能可靠地当一个自主节点框架成熟到能把它们稳稳连起来社区大到攒出了一套共同词汇。工程重心从编程一个 Agent 的行为实实在在地上移到了编程一群 Agent 的组织。从 Prompt 到 Context从 Harness 到 Loop 再到 Graph五层不是五次推倒重来是一层一层往外叠。外层解决了更大范围的问题却仍然依赖内层。Graph 的节点需要 Harness、Context 和 Prompt很多节点内部仍然运行 Loop。没有哪一层真的死了。有意思的是折腾了这么多 AI最后绕不开的居然是最古老的那门学问——怎么管理一个组织。怎么分工、怎么定权责、怎么让干活的和监督的分开、怎么在有人掉链子时不至于全盘崩掉。这些问题人类的公司琢磨了几百年现在只是换了一批员工重新问了一遍。三句能直接用的话第一别为了图而图。一个清晰的循环能搞定的就别整复杂。先画一张能在餐巾纸上说清的小图。第二图的价值来自确定性不是来自智能体数量。让模型去判断让代码去兜底再配一双独立的、专门挑刺的眼睛。第三也最要命图必须接地气得有现实锚点。测试真跑过、钱真到账、用户真留下——不然搭得再精密也就是一台更有组织的幻觉工厂。名字会换。但那个从一个人干活、到一群人协作的方向不会变。而对每一个正在构建 Agent 系统的工程师来说真正需要回答的问题从来不是“我该用 Loop 还是 Graph”而是更朴素的一个这件事怎么分工、怎么走、怎么停、坏了怎么接着跑、谁有最后决定权。能把这几个问题答清楚用什么名字称呼它其实无所谓。