01 起源一条推文三天 270 万浏览先把这个词的来龙去脉讲清楚因为它能帮你判断哪些是营销、哪些是真问题。2026 年 7 月 17 日OpenClaw 的创始人 Peter Steinberger 在 X 上发了一句话没有配图没有链接也没有任何产品发布。我们还在聊循环loops还是已经转向图graphs了— Peter Steinberger2026 年 7 月 17 日就这一句话三天内累计 270 万浏览、上千条回复。Graph Engineering 这个词一天之内传开被冠上了 Loop Engineering 继任者的名号。有意思的是六周前正是同一个人用一句关于循环的话收获了 800 多万浏览Loop Engineering 就是那样火起来的。这里有个关键事实值得记住这个词诞生的那几天业界没有任何新框架、新模型、新能力发布。它完全是被一句话加一场讨论催生出来的。所以从第一天起就有资深工程师提出质疑。XState 状态机库的作者 David Khourshid、以及 Karan Singh 等人都指出节点、边、状态这套东西并不新。有明确目的的子智能体那就是一张图。但好吧我们就把所有人都搞晕管它叫一个全新的东西。— Karan SinghX 讨论串这个质疑不算错。但要把两件事分开看词是不是新的和这个转变是不是真的是两码事。词可能只是重新包装可从编排一个智能体到编排一群智能体的工程重心迁移是真实发生的。这篇文章后面会用大量官方数据来支撑这个判断。02 五层演进它到底站在哪一层过去一年多同一件让 AI 系统稳定工作的事被换着名字叫了五遍。把它们摆在一起看就会发现它们不是互相取代而是一层一层往外叠每一层解决上一层够不着的问题。Graph 是目前最外面的一层但它建立在前四层都做好了的前提上顺着走一遍。Prompt Engineering管一次对话里这句话怎么说。Context Engineering管这一步往模型脑子里塞哪些信息检索到的文档、记忆、工具定义、历史记录。Harness Engineering管它周围的结构能用哪些工具、有哪些不能逾越的护栏、跨会话的状态怎么留存。到Loop Engineering管的是一个智能体如何自己反复地发现、规划、执行、验证不用人一步步催。作者 Boris Cherny 有一句被反复引用的话把 Loop 那一层说得很透。我现在已经不提示 Claude 了我运行的是一些循环由这些循环去提示 Claude。— Boris Cherny而Graph Engineering是再往外走一层。它不再只关心一个执行者内部怎么循环而是开始设计多个执行节点之间的组织关系。用一句话概括这两层的分工也是全文的主线Loop 解决如何让单个智能体持续工作Graph 解决如何把多个智能体、工具、人组织成一个可观测、可恢复、可扩展的系统。03 先讲透 Loop理解它才能理解 GraphGraph 是从 Loop 长出来的所以得先把 Loop 说明白。回想最早怎么用 AI。你发一句它回一句。你说不对它改。你让它跑测试它跑完就停下等你。看起来是 AI 在工作但真正驱动每一步的其实是人。你才是那个 for 循环。你一停整个流程就停。Loop Engineering 做的事就是把驱动循环这个动作交给 AI 自己。它自己观察环境、自己动手、自己检查结果、自己决定下一步构成一个闭环目标不达成就不停。你从操作每一步的人变成只需要设定目标和验收标准的人。Loop 就像一个自律的员工自己开工、自己复盘、自己改进直到把事办成这是一次质变。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扇入。两个动作连起来就是这颗菱形。市场调研、代码评审、研究报告换个信源和提示词骨架都能复用。Anthropic 官方称之为 fan-out / fan-in 云设计模式是并行工作流的典型形状② 主管模式Orchestrator-Workers一个主管智能体居中调度把任务分派给研究、写码、审查等专职工人自己负责规划和汇总。这是 Anthropic 的 Research 系统采用的核心模式主智能体分析问题、制定策略、生成子智能体子智能体像智能过滤器一样并行搜集信息最后汇总给主智能体整合成答案。③ 流水线Pipeline / Prompt Chaining把任务拆成一串固定步骤每一步处理上一步的输出还可以在中间加程序化的检查点gate来保证流程没跑偏。适合能被干净拆解成固定子任务的场景用延迟换取更高的准确率因为每一次调用都变成了更简单的任务。流水线在关键节点加检查点把复杂任务拆成一串更简单、更可控的调用这三种拓扑不是互斥的框架选型而是可以拼装、嵌套的积木。真实的生产系统里常常是主管模式套着几个菱形菱形里又是流水线。07 Anthropic 官方的五种工作流模式如果说上一章讲的是形状这一章讲的是 Anthropic 在《Building Effective Agents》里总结的五种可复用模式。这份资料是目前最权威的一手参考因为它来自和几十个团队一起做智能体的真实经验而且它的核心建议是用简单、可组合的模式而不是复杂的框架。模式做什么什么时候用Prompt Chaining提示链把任务拆成一串步骤每步处理上一步的输出中间可加检查点任务能干净拆成固定子任务用延迟换准确率Routing路由先给输入分类再导向专门的后续处理实现关注点分离输入种类多用一套提示优化一种会拖累另一种Parallelization并行把任务切成独立分支同时跑再汇总就是菱形子任务能独立或需要多个视角交叉验证Orchestrator-Workers主管-工人主智能体动态拆解任务、分派给子智能体、汇总结果子任务无法预先确定需要运行时动态决定Evaluator-Optimizer评估-优化一个生成、一个评估打分循环迭代直到达标有明确评价标准且迭代能带来明显提升这五种模式其实就是把上一章的三种形状展开得更细。路由对应分诊台主管-工人对应组织架构评估-优化对应下一章要重点讲的验证器。Anthropic 特别强调了一个态度先找最简单的方案只在真正需要时才增加复杂度。很多应用其实用单次调用加检索加几个例子就够了根本不需要上智能体更别说上图。Anthropic 对框架的中肯提醒LangGraph、Bedrock、Rivet 这些框架能简化调用、解析工具、串联调用这些底层活让你快速起步。但它们往往加了一层抽象把底下的提示和响应盖住了反而更难调试也容易诱使你在简单方案就够用时把系统搞复杂。建议先直接用 LLM API很多模式几行代码就能实现要用框架也务必搞懂它底下的代码。08 核心价值不是多智能体是确定性这一章最重要。如果全文只记一句话就记这句图真正的杠杆不在于塞了多少个智能体而在于你能围绕结果搭起多少确定性。很多人一听 Graph 就想堆多智能体觉得节点越多越高级这是最大的误会。要理解为什么得先看清大多数智能体系统翻车的根子模型既当运动员又当裁判。让写代码的智能体在写它的上下文里审自己的代码它几乎永远说没问题Graph 的解法是把做判断和做验证拆成两个独立节点。出结论的是一个智能体专门挑错的是另一个叫Verifier验证器。它的职责不是再写一份答案而是专门试图推翻前一个结论扛得住才放行扛不住就打回重来。关键在于它要用一双全新的、干净的眼睛只看最终结果不看是怎么憋出来的。验证器蹲在边上是整张图里性价比最高的一个节点检查的力度要看事情轻重这就需要一个Router路由像医院的分诊台按重要程度把任务导向不同的检查路径。普通观点快速核对重要数据和安全结论则要多角度交叉审。常见的验证有三种打法。对抗式派多个怀疑者分头去驳同一个结论多数没驳倒才算它站得住。多视角换不同角度查正确性、安全性、能否复现各查各的。评委制多个方案并行打分选出优胜者再吸收亚军里的好东西。但光靠智能体互相验证还不够。最硬的确定性来自两个地方代码和现实。确定性的活格式校验、跑测试、去重、排序、算预算就该交给普通代码让模型去判断 JSON 合不合法既不稳定又费钱。这就是那句被反复引用的话让模型的判断力落在节点上让代码的可靠性落在边上。全网关于 Graph 最重的一句警告如果一张图里所有节点都在互相引用模型生成的结论没有一个节点真的去碰一下现实那它只是一台更精致的自嗨机器有人称之为一个项目管理做得更好的、更大的幻觉。真正的锚点必须是这些无法狡辩的硬事实测试真的跑过、钱真的到账、用户真的留下、库存真的对上、线上指标真的恢复。至于更好到底指什么这个必须由人来定因为图里每个循环都预设了它。09 一个完整例子同一个任务Loop 和 Graph 怎么做前面讲了不少概念节点、边、扇出扇入、验证器、干净上下文。这一章用一个具体任务把它们全串起来同时和 Loop 做一次正面对比。这个例子来自 Anthropic 和社区反复用到的经典场景因为它足够小、又足够典型。任务是这样的做一份每日研究简报。每天早上读几个信源上关于某个主题的最新内容写成一页纸的摘要并且在发到你邮箱之前先核对一遍准确性。听起来很简单我们分别用两种方式来做。做法一一个臃肿的 Loop最直觉的做法是让一个智能体在一个循环里把所有事都干了。它搜信源、把原始搜索结果一股脑塞进上下文、起草简报、然后审查自己的草稿。问题就出在这个过程里。等它开始审查的时候它的上下文已经是一锅粥了原始的搜索网页、写了一半的句子、还有它自己之前的推理全都糊在一起。它是在写出这份草稿的同一个上下文里审查它等于让作者给自己判卷几乎必然盖个通过章。而且因为循环天生是顺序的它只能一个信源一个信源地读慢。做法二一张三节点的小图同样的任务拆成三个节点状态在它们之间干净地流动。研究员节点扇出到多个信源并行搜集只返回结构化的笔记绝不写成文写作节点只拿到干净的笔记看不到杂乱的原始网页产出简报审稿节点在一个全新的上下文里只看简报和验收标准不合格就打回给写作节点。左边一个循环把上下文越滚越脏、自己审自己右边三个节点各自上下文干净审稿用全新的眼睛你能直接看出小图买到了什么上下文是分开且干净的写作节点从不被搜索垃圾淹没是真正的审查而不是自己给自己盖章审稿是全新的眼睛是并行搜集而不是一个个来还有一条能当作图读懂的清晰路径而不用从一长段对话记录里反推。但小图也不是白来的诚实地说这张图也是有代价的Loop 那种臃肿做法没付这个代价。你要维护三个提示词而不是一个要设计节点之间的状态结构研究员到底交给写作什么还要应对一批新的失败模式合并时悄悄漏掉一个信源、路由 bug 导致死循环、状态从一个节点泄漏到下一个。这个例子最关键的一句对于一份每天都要跑的简报这些额外开销换来的是实打实的质量提升值。但对于一个只跑一次的任务它就是纯粹的税。这笔账就是要不要从 Loop 升级到 Graph 的全部决策。把两种做法并排列出来差异就一目了然了。对比维度臃肿 Loop三节点小图上下文全糊在一起越滚越脏每个节点各自干净、隔离审查作者审自己几乎必过全新上下文真正挑错搜集一个个信源顺序读慢多信源并行扇出快可读性一长段对话记录靠反推一张能读懂的图成本一个提示词起步低三个提示词 状态结构起步高适合只跑一次的任务每天都跑、要质量的任务来源Anthropic《Building Effective Agents》与社区 loop vs graph 案例10 什么时候该用什么时候不该最关键的一条心法别为了 Graph 而 Graph。这不是我的个人观点而是 Anthropic 反复强调的。他们见过太多团队花几个月搭复杂的多智能体架构最后发现改进单个智能体的提示就能达到同样效果。先看一组来自 Anthropic 官方的硬数据帮你建立成本直觉。数据含义90.2%多智能体研究系统在内部评测上超过单智能体的幅度15×多智能体系统的 token 消耗约为普通对话的 15 倍80%仅 token 用量一项就解释了性能方差的八成来源Anthropic《How we built our multi-agent research system》这组数字说明了一个残酷的权衡多智能体确实更强但它是靠烧更多 token 换来的。所以它只值得用在那些价值足够高、足以覆盖成本的任务上。Anthropic 给出了三个明确该用多智能体的场景也是判断该不该上图的三把尺子。上下文保护某个子任务会产生大量超过 1000 token但对主任务无关的信息用独立子智能体隔离出去保持主上下文干净。可并行任务能切成多个独立分支同时跑探索比单智能体更大的搜索空间尤其适合广度优先的研究搜索。专业化不同步骤需要不同的工具、提示或专注度拆开能提升工具选择的准确率和任务专注度。反过来如果任务就一个目标、一个领域、一个明确的停止条件那清晰的单个 Loop 就是最优解。比如让智能体每天检查一次仓库 CI、失败就总结日志发你这是完美的循环硬拆成十个智能体只会徒增延迟、成本和调试难度。判断只需先过一道最简单的坎。先问自己这一个问题命中好几条信号才值得动手搭图最后一条治理红线图允许任务怎么拆、怎么合现场灵活调整这叫工作图可以快变。**但谁有权改数据库、谁能绕过审批这类长期权限绝不能让模型现场发挥**这叫角色图必须慢变、可审计。否则搭出来的不是智能系统而是一场随时会爆的生产事故。11 框架对比与真实生产案例Graph Engineering 早就不是纸上概念。LangGraph、Google ADK、微软 AutoGen 这些框架在这个词出现前两年就在用节点、边、共享状态构建智能体了。换句话说你要是用过它们中的任何一个其实已经在做图工程只是没这个叫法。先看这几个主流框架的定位差异。框架编排模型状态管理同任务 token适合场景LangGraphLangChain有向图 条件边内置检查点 时间旅行约 2000长时运行、需审计、需回滚的生产管线CrewAI角色化 crews任务输出序列传递约 3500规范化的角色协作分工AutoGen微软对话式 GroupChat对话历史为主约 8000多模型对话协调的探索性任务Google ADK结构化图架构分层协调 A2A 协议—code-first、企业级、可部署 Vertex AI来源DataCamp 2026 框架对比 · 各框架官方文档这里有个细节值得展开为什么同一个任务LangGraph 吃 2000 tokenAutoGen 要 8000。差别来自图这个结构它把智能体之间的对话变成了状态转换省掉了它们互相转述背景的那一大堆废话。这也解释了为什么 LangGraph 成了企业生产的事实标准月下载量千万级。LangGraph 的杀手锏用它官方文档的原话说是持久化执行durable execution。它的机制值得单独讲一下因为这是单个 Loop 永远给不了的能力。LangGraph 官方文档检查点机制编译图时挂上一个 checkpointer它就会在每个超级步super-step结束时把整个图的状态存一份快照。这带来四个能力人在回路图可以在任意节点暂停等人检查、修改、批准后再从断点恢复记忆多轮交互间保留上下文时间旅行调试回到任意历史检查点重放、甚至分叉出新路径容错某个节点失败从最后一个成功的步骤重启而不是从头再来。更妙的是一个叫待写入pending writes的设计当同一个超级步里有个节点失败了其他已经成功的节点的输出会被留存下来恢复时不用重跑那些成功的节点。这些工程细节才是让智能体从能演示变成能上生产的关键。说几个真实案例。LinkedIn 的 SQL Bot让几千名不懂代码的员工用大白话查数据仓库。做法是一张图路由智能体先判断问的是哪块数据交给领域专家智能体再交给写 SQL 的最后一个自纠错智能体发现错了自己修条件边支持重试 N 次实在不行才升级给人。结果查询准确满意度 95%。Uber 的代码迁移面对 5000 名工程师、上亿行代码。他们用子图给不同语言、不同仓库各起一个专门子智能体上面一个主管图协调提交前先解决冲突。检查点机制让系统能扛住 CI 抽风、代码冻结、维护窗口这些必然的中断。结果节省 21000 多个工程小时。用 LangGraph 的还有 Klarna、摩根大通、Replit 这一票公司。此外Anthropic 的 Research 功能也是同一个思路用编排者-工作者模式主智能体规划、子智能体并行搜索官方数据说它比单智能体强 90.2%。这些都不是 demo是实打实跑在生产上、服务真实用户的系统。12 它和老工作流、ReAct 到底什么关系最后回答一个理论问题也是资深工程师最爱争的一个这不就是回到 ReAct 之前的老工作流了吗答案是形似神不似。要讲清楚得看它前面两代长什么样。老工作流的路径是死的、每个节点也是写死的代码像固定流水线遇到没预料的情况完全不会拐弯。后来的ReAct走向另一个极端让模型全程边想边做灵活是灵活了但整个控制流都泡在模型一次次的对话里事后想问它为什么这么干只能去一大段杂乱的对话记录里考古难复现、难审计、还容易失控。老工作流和 ReAct 是稳与活的两个极端Graph 把它们拆到两层同时拿到Graph 的巧妙是把稳和活拆到两层去解决而不是二选一。让边和整体结构固定下来所以可治理、可审计、每次分类走同一条路让节点内部保留自主所以够灵活、能应对具体问题。这正好呼应了 Anthropic 那个官方定义工作流是通过预定义代码路径编排的系统智能体是由 LLM 动态决定自己流程的系统而 Graph 恰恰是两者的融合用预定义的边框住动态的节点。所以它回到的只是老工作流的形内核完全不同老工作流的节点是死代码Graph 的节点里住着能自主推理的智能体。这不是原地打转而是螺旋上升把 ReAct 的灵活收进了一副可治理的骨架里。13 总结它到底是不是真东西绕了一大圈回到最初的问题。Graph Engineering到底是营销新词还是真东西。我的判断是它是一次命名事件加一次视角上移。命名事件那部分是虚的。节点、边、状态、有向图调度、状态机、多智能体编排这些计算机科学玩了几十年了LangGraph、ADK、AutoGen 也实打实做了两年多。这个词大概率会像 Loop Engineering 一样几个月后被下一个词盖掉。视角上移那部分是实的。真正变了的是三件事凑齐了模型强到能可靠地当一个自主节点、框架成熟到能把它们稳稳连起来、社区大到攒出了一套共同词汇。工程重心从编程一个智能体的行为实实在在地上移到了编程一群智能体的组织。这个转变是真的它能造出单个循环永远造不出来的系统。有意思的是我们折腾了半天 AI最后绕不开的居然是最古老的那门学问怎么管理一个组织。怎么分工、怎么定权责、怎么让干活的和监督的分开、怎么在有人掉链子时不至于全盘崩掉。这些问题人类的公司琢磨了几百年现在只是换了一批员工重新问了一遍。三句能直接用的话第一别为了图而图。一个清晰的循环能搞定的就别整复杂先画一张能在餐巾纸上说清的小图。这是 Anthropic 反复强调的第一原则。第二图的价值来自确定性不是来自智能体数量。让模型去判断让代码去兜底再配一双独立的、专门挑刺的眼睛。第三也最要命图必须接地气得有现实锚点。测试真跑过、钱真到账、用户真留下不然搭得再精密也就是一台更有组织的幻觉工厂。名字会换但那个从一个人干活、到一群人协作的方向不会变。学AI大模型的正确顺序千万不要搞错了2026年AI风口已来各行各业的AI渗透肉眼可见超多公司要么转型做AI相关产品要么高薪挖AI技术人才机遇直接摆在眼前有往AI方向发展或者本身有后端编程基础的朋友直接冲AI大模型应用开发转岗超合适就算暂时不打算转岗了解大模型、RAG、Prompt、Agent这些热门概念能上手做简单项目也绝对是求职加分王给大家整理了超全最新的AI大模型应用开发学习清单和资料手把手帮你快速入门学习路线:✅大模型基础认知—大模型核心原理、发展历程、主流模型GPT、文心一言等特点解析✅核心技术模块—RAG检索增强生成、Prompt工程实战、Agent智能体开发逻辑✅开发基础能力—Python进阶、API接口调用、大模型开发框架LangChain等实操✅应用场景开发—智能问答系统、企业知识库、AIGC内容生成工具、行业定制化大模型应用✅项目落地流程—需求拆解、技术选型、模型调优、测试上线、运维迭代✅面试求职冲刺—岗位JD解析、简历AI项目包装、高频面试题汇总、模拟面经以上6大模块看似清晰好上手实则每个部分都有扎实的核心内容需要吃透我把大模型的学习全流程已经整理好了抓住AI时代风口轻松解锁职业新可能希望大家都能把握机遇实现薪资/职业跃迁这份完整版的大模型 AI 学习资料已经上传CSDN朋友们如果需要可以微信扫描下方CSDN官方认证二维码免费领取【保证100%免费】
Loop Engineering 已死？ 一文带你了解Graph Engineering
01 起源一条推文三天 270 万浏览先把这个词的来龙去脉讲清楚因为它能帮你判断哪些是营销、哪些是真问题。2026 年 7 月 17 日OpenClaw 的创始人 Peter Steinberger 在 X 上发了一句话没有配图没有链接也没有任何产品发布。我们还在聊循环loops还是已经转向图graphs了— Peter Steinberger2026 年 7 月 17 日就这一句话三天内累计 270 万浏览、上千条回复。Graph Engineering 这个词一天之内传开被冠上了 Loop Engineering 继任者的名号。有意思的是六周前正是同一个人用一句关于循环的话收获了 800 多万浏览Loop Engineering 就是那样火起来的。这里有个关键事实值得记住这个词诞生的那几天业界没有任何新框架、新模型、新能力发布。它完全是被一句话加一场讨论催生出来的。所以从第一天起就有资深工程师提出质疑。XState 状态机库的作者 David Khourshid、以及 Karan Singh 等人都指出节点、边、状态这套东西并不新。有明确目的的子智能体那就是一张图。但好吧我们就把所有人都搞晕管它叫一个全新的东西。— Karan SinghX 讨论串这个质疑不算错。但要把两件事分开看词是不是新的和这个转变是不是真的是两码事。词可能只是重新包装可从编排一个智能体到编排一群智能体的工程重心迁移是真实发生的。这篇文章后面会用大量官方数据来支撑这个判断。02 五层演进它到底站在哪一层过去一年多同一件让 AI 系统稳定工作的事被换着名字叫了五遍。把它们摆在一起看就会发现它们不是互相取代而是一层一层往外叠每一层解决上一层够不着的问题。Graph 是目前最外面的一层但它建立在前四层都做好了的前提上顺着走一遍。Prompt Engineering管一次对话里这句话怎么说。Context Engineering管这一步往模型脑子里塞哪些信息检索到的文档、记忆、工具定义、历史记录。Harness Engineering管它周围的结构能用哪些工具、有哪些不能逾越的护栏、跨会话的状态怎么留存。到Loop Engineering管的是一个智能体如何自己反复地发现、规划、执行、验证不用人一步步催。作者 Boris Cherny 有一句被反复引用的话把 Loop 那一层说得很透。我现在已经不提示 Claude 了我运行的是一些循环由这些循环去提示 Claude。— Boris Cherny而Graph Engineering是再往外走一层。它不再只关心一个执行者内部怎么循环而是开始设计多个执行节点之间的组织关系。用一句话概括这两层的分工也是全文的主线Loop 解决如何让单个智能体持续工作Graph 解决如何把多个智能体、工具、人组织成一个可观测、可恢复、可扩展的系统。03 先讲透 Loop理解它才能理解 GraphGraph 是从 Loop 长出来的所以得先把 Loop 说明白。回想最早怎么用 AI。你发一句它回一句。你说不对它改。你让它跑测试它跑完就停下等你。看起来是 AI 在工作但真正驱动每一步的其实是人。你才是那个 for 循环。你一停整个流程就停。Loop Engineering 做的事就是把驱动循环这个动作交给 AI 自己。它自己观察环境、自己动手、自己检查结果、自己决定下一步构成一个闭环目标不达成就不停。你从操作每一步的人变成只需要设定目标和验收标准的人。Loop 就像一个自律的员工自己开工、自己复盘、自己改进直到把事办成这是一次质变。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扇入。两个动作连起来就是这颗菱形。市场调研、代码评审、研究报告换个信源和提示词骨架都能复用。Anthropic 官方称之为 fan-out / fan-in 云设计模式是并行工作流的典型形状② 主管模式Orchestrator-Workers一个主管智能体居中调度把任务分派给研究、写码、审查等专职工人自己负责规划和汇总。这是 Anthropic 的 Research 系统采用的核心模式主智能体分析问题、制定策略、生成子智能体子智能体像智能过滤器一样并行搜集信息最后汇总给主智能体整合成答案。③ 流水线Pipeline / Prompt Chaining把任务拆成一串固定步骤每一步处理上一步的输出还可以在中间加程序化的检查点gate来保证流程没跑偏。适合能被干净拆解成固定子任务的场景用延迟换取更高的准确率因为每一次调用都变成了更简单的任务。流水线在关键节点加检查点把复杂任务拆成一串更简单、更可控的调用这三种拓扑不是互斥的框架选型而是可以拼装、嵌套的积木。真实的生产系统里常常是主管模式套着几个菱形菱形里又是流水线。07 Anthropic 官方的五种工作流模式如果说上一章讲的是形状这一章讲的是 Anthropic 在《Building Effective Agents》里总结的五种可复用模式。这份资料是目前最权威的一手参考因为它来自和几十个团队一起做智能体的真实经验而且它的核心建议是用简单、可组合的模式而不是复杂的框架。模式做什么什么时候用Prompt Chaining提示链把任务拆成一串步骤每步处理上一步的输出中间可加检查点任务能干净拆成固定子任务用延迟换准确率Routing路由先给输入分类再导向专门的后续处理实现关注点分离输入种类多用一套提示优化一种会拖累另一种Parallelization并行把任务切成独立分支同时跑再汇总就是菱形子任务能独立或需要多个视角交叉验证Orchestrator-Workers主管-工人主智能体动态拆解任务、分派给子智能体、汇总结果子任务无法预先确定需要运行时动态决定Evaluator-Optimizer评估-优化一个生成、一个评估打分循环迭代直到达标有明确评价标准且迭代能带来明显提升这五种模式其实就是把上一章的三种形状展开得更细。路由对应分诊台主管-工人对应组织架构评估-优化对应下一章要重点讲的验证器。Anthropic 特别强调了一个态度先找最简单的方案只在真正需要时才增加复杂度。很多应用其实用单次调用加检索加几个例子就够了根本不需要上智能体更别说上图。Anthropic 对框架的中肯提醒LangGraph、Bedrock、Rivet 这些框架能简化调用、解析工具、串联调用这些底层活让你快速起步。但它们往往加了一层抽象把底下的提示和响应盖住了反而更难调试也容易诱使你在简单方案就够用时把系统搞复杂。建议先直接用 LLM API很多模式几行代码就能实现要用框架也务必搞懂它底下的代码。08 核心价值不是多智能体是确定性这一章最重要。如果全文只记一句话就记这句图真正的杠杆不在于塞了多少个智能体而在于你能围绕结果搭起多少确定性。很多人一听 Graph 就想堆多智能体觉得节点越多越高级这是最大的误会。要理解为什么得先看清大多数智能体系统翻车的根子模型既当运动员又当裁判。让写代码的智能体在写它的上下文里审自己的代码它几乎永远说没问题Graph 的解法是把做判断和做验证拆成两个独立节点。出结论的是一个智能体专门挑错的是另一个叫Verifier验证器。它的职责不是再写一份答案而是专门试图推翻前一个结论扛得住才放行扛不住就打回重来。关键在于它要用一双全新的、干净的眼睛只看最终结果不看是怎么憋出来的。验证器蹲在边上是整张图里性价比最高的一个节点检查的力度要看事情轻重这就需要一个Router路由像医院的分诊台按重要程度把任务导向不同的检查路径。普通观点快速核对重要数据和安全结论则要多角度交叉审。常见的验证有三种打法。对抗式派多个怀疑者分头去驳同一个结论多数没驳倒才算它站得住。多视角换不同角度查正确性、安全性、能否复现各查各的。评委制多个方案并行打分选出优胜者再吸收亚军里的好东西。但光靠智能体互相验证还不够。最硬的确定性来自两个地方代码和现实。确定性的活格式校验、跑测试、去重、排序、算预算就该交给普通代码让模型去判断 JSON 合不合法既不稳定又费钱。这就是那句被反复引用的话让模型的判断力落在节点上让代码的可靠性落在边上。全网关于 Graph 最重的一句警告如果一张图里所有节点都在互相引用模型生成的结论没有一个节点真的去碰一下现实那它只是一台更精致的自嗨机器有人称之为一个项目管理做得更好的、更大的幻觉。真正的锚点必须是这些无法狡辩的硬事实测试真的跑过、钱真的到账、用户真的留下、库存真的对上、线上指标真的恢复。至于更好到底指什么这个必须由人来定因为图里每个循环都预设了它。09 一个完整例子同一个任务Loop 和 Graph 怎么做前面讲了不少概念节点、边、扇出扇入、验证器、干净上下文。这一章用一个具体任务把它们全串起来同时和 Loop 做一次正面对比。这个例子来自 Anthropic 和社区反复用到的经典场景因为它足够小、又足够典型。任务是这样的做一份每日研究简报。每天早上读几个信源上关于某个主题的最新内容写成一页纸的摘要并且在发到你邮箱之前先核对一遍准确性。听起来很简单我们分别用两种方式来做。做法一一个臃肿的 Loop最直觉的做法是让一个智能体在一个循环里把所有事都干了。它搜信源、把原始搜索结果一股脑塞进上下文、起草简报、然后审查自己的草稿。问题就出在这个过程里。等它开始审查的时候它的上下文已经是一锅粥了原始的搜索网页、写了一半的句子、还有它自己之前的推理全都糊在一起。它是在写出这份草稿的同一个上下文里审查它等于让作者给自己判卷几乎必然盖个通过章。而且因为循环天生是顺序的它只能一个信源一个信源地读慢。做法二一张三节点的小图同样的任务拆成三个节点状态在它们之间干净地流动。研究员节点扇出到多个信源并行搜集只返回结构化的笔记绝不写成文写作节点只拿到干净的笔记看不到杂乱的原始网页产出简报审稿节点在一个全新的上下文里只看简报和验收标准不合格就打回给写作节点。左边一个循环把上下文越滚越脏、自己审自己右边三个节点各自上下文干净审稿用全新的眼睛你能直接看出小图买到了什么上下文是分开且干净的写作节点从不被搜索垃圾淹没是真正的审查而不是自己给自己盖章审稿是全新的眼睛是并行搜集而不是一个个来还有一条能当作图读懂的清晰路径而不用从一长段对话记录里反推。但小图也不是白来的诚实地说这张图也是有代价的Loop 那种臃肿做法没付这个代价。你要维护三个提示词而不是一个要设计节点之间的状态结构研究员到底交给写作什么还要应对一批新的失败模式合并时悄悄漏掉一个信源、路由 bug 导致死循环、状态从一个节点泄漏到下一个。这个例子最关键的一句对于一份每天都要跑的简报这些额外开销换来的是实打实的质量提升值。但对于一个只跑一次的任务它就是纯粹的税。这笔账就是要不要从 Loop 升级到 Graph 的全部决策。把两种做法并排列出来差异就一目了然了。对比维度臃肿 Loop三节点小图上下文全糊在一起越滚越脏每个节点各自干净、隔离审查作者审自己几乎必过全新上下文真正挑错搜集一个个信源顺序读慢多信源并行扇出快可读性一长段对话记录靠反推一张能读懂的图成本一个提示词起步低三个提示词 状态结构起步高适合只跑一次的任务每天都跑、要质量的任务来源Anthropic《Building Effective Agents》与社区 loop vs graph 案例10 什么时候该用什么时候不该最关键的一条心法别为了 Graph 而 Graph。这不是我的个人观点而是 Anthropic 反复强调的。他们见过太多团队花几个月搭复杂的多智能体架构最后发现改进单个智能体的提示就能达到同样效果。先看一组来自 Anthropic 官方的硬数据帮你建立成本直觉。数据含义90.2%多智能体研究系统在内部评测上超过单智能体的幅度15×多智能体系统的 token 消耗约为普通对话的 15 倍80%仅 token 用量一项就解释了性能方差的八成来源Anthropic《How we built our multi-agent research system》这组数字说明了一个残酷的权衡多智能体确实更强但它是靠烧更多 token 换来的。所以它只值得用在那些价值足够高、足以覆盖成本的任务上。Anthropic 给出了三个明确该用多智能体的场景也是判断该不该上图的三把尺子。上下文保护某个子任务会产生大量超过 1000 token但对主任务无关的信息用独立子智能体隔离出去保持主上下文干净。可并行任务能切成多个独立分支同时跑探索比单智能体更大的搜索空间尤其适合广度优先的研究搜索。专业化不同步骤需要不同的工具、提示或专注度拆开能提升工具选择的准确率和任务专注度。反过来如果任务就一个目标、一个领域、一个明确的停止条件那清晰的单个 Loop 就是最优解。比如让智能体每天检查一次仓库 CI、失败就总结日志发你这是完美的循环硬拆成十个智能体只会徒增延迟、成本和调试难度。判断只需先过一道最简单的坎。先问自己这一个问题命中好几条信号才值得动手搭图最后一条治理红线图允许任务怎么拆、怎么合现场灵活调整这叫工作图可以快变。**但谁有权改数据库、谁能绕过审批这类长期权限绝不能让模型现场发挥**这叫角色图必须慢变、可审计。否则搭出来的不是智能系统而是一场随时会爆的生产事故。11 框架对比与真实生产案例Graph Engineering 早就不是纸上概念。LangGraph、Google ADK、微软 AutoGen 这些框架在这个词出现前两年就在用节点、边、共享状态构建智能体了。换句话说你要是用过它们中的任何一个其实已经在做图工程只是没这个叫法。先看这几个主流框架的定位差异。框架编排模型状态管理同任务 token适合场景LangGraphLangChain有向图 条件边内置检查点 时间旅行约 2000长时运行、需审计、需回滚的生产管线CrewAI角色化 crews任务输出序列传递约 3500规范化的角色协作分工AutoGen微软对话式 GroupChat对话历史为主约 8000多模型对话协调的探索性任务Google ADK结构化图架构分层协调 A2A 协议—code-first、企业级、可部署 Vertex AI来源DataCamp 2026 框架对比 · 各框架官方文档这里有个细节值得展开为什么同一个任务LangGraph 吃 2000 tokenAutoGen 要 8000。差别来自图这个结构它把智能体之间的对话变成了状态转换省掉了它们互相转述背景的那一大堆废话。这也解释了为什么 LangGraph 成了企业生产的事实标准月下载量千万级。LangGraph 的杀手锏用它官方文档的原话说是持久化执行durable execution。它的机制值得单独讲一下因为这是单个 Loop 永远给不了的能力。LangGraph 官方文档检查点机制编译图时挂上一个 checkpointer它就会在每个超级步super-step结束时把整个图的状态存一份快照。这带来四个能力人在回路图可以在任意节点暂停等人检查、修改、批准后再从断点恢复记忆多轮交互间保留上下文时间旅行调试回到任意历史检查点重放、甚至分叉出新路径容错某个节点失败从最后一个成功的步骤重启而不是从头再来。更妙的是一个叫待写入pending writes的设计当同一个超级步里有个节点失败了其他已经成功的节点的输出会被留存下来恢复时不用重跑那些成功的节点。这些工程细节才是让智能体从能演示变成能上生产的关键。说几个真实案例。LinkedIn 的 SQL Bot让几千名不懂代码的员工用大白话查数据仓库。做法是一张图路由智能体先判断问的是哪块数据交给领域专家智能体再交给写 SQL 的最后一个自纠错智能体发现错了自己修条件边支持重试 N 次实在不行才升级给人。结果查询准确满意度 95%。Uber 的代码迁移面对 5000 名工程师、上亿行代码。他们用子图给不同语言、不同仓库各起一个专门子智能体上面一个主管图协调提交前先解决冲突。检查点机制让系统能扛住 CI 抽风、代码冻结、维护窗口这些必然的中断。结果节省 21000 多个工程小时。用 LangGraph 的还有 Klarna、摩根大通、Replit 这一票公司。此外Anthropic 的 Research 功能也是同一个思路用编排者-工作者模式主智能体规划、子智能体并行搜索官方数据说它比单智能体强 90.2%。这些都不是 demo是实打实跑在生产上、服务真实用户的系统。12 它和老工作流、ReAct 到底什么关系最后回答一个理论问题也是资深工程师最爱争的一个这不就是回到 ReAct 之前的老工作流了吗答案是形似神不似。要讲清楚得看它前面两代长什么样。老工作流的路径是死的、每个节点也是写死的代码像固定流水线遇到没预料的情况完全不会拐弯。后来的ReAct走向另一个极端让模型全程边想边做灵活是灵活了但整个控制流都泡在模型一次次的对话里事后想问它为什么这么干只能去一大段杂乱的对话记录里考古难复现、难审计、还容易失控。老工作流和 ReAct 是稳与活的两个极端Graph 把它们拆到两层同时拿到Graph 的巧妙是把稳和活拆到两层去解决而不是二选一。让边和整体结构固定下来所以可治理、可审计、每次分类走同一条路让节点内部保留自主所以够灵活、能应对具体问题。这正好呼应了 Anthropic 那个官方定义工作流是通过预定义代码路径编排的系统智能体是由 LLM 动态决定自己流程的系统而 Graph 恰恰是两者的融合用预定义的边框住动态的节点。所以它回到的只是老工作流的形内核完全不同老工作流的节点是死代码Graph 的节点里住着能自主推理的智能体。这不是原地打转而是螺旋上升把 ReAct 的灵活收进了一副可治理的骨架里。13 总结它到底是不是真东西绕了一大圈回到最初的问题。Graph Engineering到底是营销新词还是真东西。我的判断是它是一次命名事件加一次视角上移。命名事件那部分是虚的。节点、边、状态、有向图调度、状态机、多智能体编排这些计算机科学玩了几十年了LangGraph、ADK、AutoGen 也实打实做了两年多。这个词大概率会像 Loop Engineering 一样几个月后被下一个词盖掉。视角上移那部分是实的。真正变了的是三件事凑齐了模型强到能可靠地当一个自主节点、框架成熟到能把它们稳稳连起来、社区大到攒出了一套共同词汇。工程重心从编程一个智能体的行为实实在在地上移到了编程一群智能体的组织。这个转变是真的它能造出单个循环永远造不出来的系统。有意思的是我们折腾了半天 AI最后绕不开的居然是最古老的那门学问怎么管理一个组织。怎么分工、怎么定权责、怎么让干活的和监督的分开、怎么在有人掉链子时不至于全盘崩掉。这些问题人类的公司琢磨了几百年现在只是换了一批员工重新问了一遍。三句能直接用的话第一别为了图而图。一个清晰的循环能搞定的就别整复杂先画一张能在餐巾纸上说清的小图。这是 Anthropic 反复强调的第一原则。第二图的价值来自确定性不是来自智能体数量。让模型去判断让代码去兜底再配一双独立的、专门挑刺的眼睛。第三也最要命图必须接地气得有现实锚点。测试真跑过、钱真到账、用户真留下不然搭得再精密也就是一台更有组织的幻觉工厂。名字会换但那个从一个人干活、到一群人协作的方向不会变。学AI大模型的正确顺序千万不要搞错了2026年AI风口已来各行各业的AI渗透肉眼可见超多公司要么转型做AI相关产品要么高薪挖AI技术人才机遇直接摆在眼前有往AI方向发展或者本身有后端编程基础的朋友直接冲AI大模型应用开发转岗超合适就算暂时不打算转岗了解大模型、RAG、Prompt、Agent这些热门概念能上手做简单项目也绝对是求职加分王给大家整理了超全最新的AI大模型应用开发学习清单和资料手把手帮你快速入门学习路线:✅大模型基础认知—大模型核心原理、发展历程、主流模型GPT、文心一言等特点解析✅核心技术模块—RAG检索增强生成、Prompt工程实战、Agent智能体开发逻辑✅开发基础能力—Python进阶、API接口调用、大模型开发框架LangChain等实操✅应用场景开发—智能问答系统、企业知识库、AIGC内容生成工具、行业定制化大模型应用✅项目落地流程—需求拆解、技术选型、模型调优、测试上线、运维迭代✅面试求职冲刺—岗位JD解析、简历AI项目包装、高频面试题汇总、模拟面经以上6大模块看似清晰好上手实则每个部分都有扎实的核心内容需要吃透我把大模型的学习全流程已经整理好了抓住AI时代风口轻松解锁职业新可能希望大家都能把握机遇实现薪资/职业跃迁这份完整版的大模型 AI 学习资料已经上传CSDN朋友们如果需要可以微信扫描下方CSDN官方认证二维码免费领取【保证100%免费】
