事情是这样的。

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

就一句，我们还在聊循环，还是已经转向图了？

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

我看到这条推文的时候，坦率地讲，第一反应不是兴奋，而是有点疲惫。

不是对这个技术疲惫，是对这个造词节奏疲惫。

这里有个关键事实值得记住，这个词诞生的那几天，业界没有任何新框架、新模型、新能力发布。它完全是被一句话加一场讨论催生出来的。所以从第一天起，就有资深工程师提出质疑。XState状态机库的作者David Khourshid、以及Karan Singh等人都指出，节点、边、状态这套东西并不新。Karan Singh在X讨论串里说了一句挺刻薄的话，有明确目的的子智能体，那就是一张图。但好吧，我们就把所有人都搞晕，管它叫一个全新的东西。

这个质疑不算错。但要把两件事分开看，词是不是新的，和这个转变是不是真的，是两码事。

我之前在CSDN写过一篇文章，梳理了从Prompt Engineering到Context Engineering到Harness Engineering再到Loop Engineering的演进。当时我的判断是，这四次进化不是概念膨胀，每一次都是对前一层真实工程失败的回应。写那篇文章的时候我就在想，Loop之后还会冒出什么词。

没想到答案来得这么快。

六周。

Prompt Engineering管了好几年才被Context Engineering盖过，Context又管了一年多才到Harness。Loop Engineering从被命名到被宣布已死，大概就六周。现在Graph Engineering来了，距离Loop被命名仅仅41天。

AI行业开始按天计算概念折旧了。

但你如果就此断定这又是一场空气运动，那也不公平。我研究了一圈之后发现，情况比我想的要复杂。要判断Graph Engineering到底是真东西还是又一个泡沫，得先把两对关系讲清楚。第一对，Loop和ReAct到底什么关系。第二对，Graph和LangGraph、Google ADK这些老框架里的图，到底什么关系。

五层演进，每一层解决上一层的够不着

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

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

每一层不是替代上一层，而是把它包进来当组件用。Graph内部跑着Loop，Loop内部套着Harness，Harness内部依赖Context，Context内部还是得写好Prompt。

Boris Cherny有一句被反复引用的话，把Loop那一层说得很透。Boris是Claude Code的负责人，他说，我现在已经不提示Claude了，我运行的是一些循环，由这些循环去提示Claude。

这句话听着很酷，但它背后的变化是质变级的。Boris在2025年11月亲手卸载了自己的IDE，然后在一个月里提交了259个PR，没有一个是他自己写的代码，全是Claude Code跑的。有人根据他的公开访谈还原了整套系统，起名叫THE HIVE，三层架构，本地循环最小1分钟间隔、云端例行任务最小1小时间隔且关机也能跑、还有扇出到上百个并行子Agent的集群。

用一句话概括Loop和Graph这两层的分工，也是全文的主线。Loop解决如何让单个智能体持续工作，Graph解决如何把多个智能体、工具、人组织成一个可观测、可恢复、可扩展的系统。

我有时候觉得，这个演进路径特别像工业革命早期的发展。模型能力的提升就是生产力的发展，而每一次工程范式的更迭，都是在调整生产关系来适配新的生产力。Prompt时代是一个老师傅带一个学徒，你告诉他怎么说话怎么干活。Context时代是给学徒配了资料库和工作手册。Harness时代是套上了安全绳和操作规程。Loop时代是他终于能自己开工了。到了Graph时代，从一个工人变成了一支团队，有了分工、交接、审核、组织架构。

从手工业到工厂制。

Loop与ReAct，内循环与外循环

Graph是从Loop长出来的，所以得先把Loop说明白。而要理解Loop，得先回到它的前身ReAct。

2022年10月，Shunyu Yao在arXiv上挂了一篇论文，叫ReAct，后来被ICLR 2023接收。这个名字是Reasoning和Acting的缝合，思路特别简洁，让大模型在思考和行动之间交替跑。想一步，做一步，看一下结果，再想下一步。Thought、Action、Observation，三个步骤循环往复，直到任务完成。

这个范式当时确实惊艳。在HotpotQA和Fever两个基准测试上，ReAct显著降低了幻觉和错误传播，因为它把推理锚定在了外部工具返回的真实数据上。在ALFWorld和WebShop这种交互式决策任务上，绝对成功率分别提升了34%和10%。几乎一夜之间，LangChain、LlamaIndex这些框架都内置了ReAct Agent模块。

但你仔细想想，在ReAct里，真正驱动每一轮循环的是谁？

是你。

你发一句，模型回一句。你说不对，它改。你让它跑测试，它跑完就停下等你。看起来是AI在工作，但你是那个for循环。你一停，整个流程就停。

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

但这里有个关键细节，很多人搞混了。Loop Engineering不是让ReAct消失了，而是在ReAct外面又套了一层。

ReAct是内循环，Thought到Action到Observation那个小圈，它还在。Loop Engineering是外循环，管的是自动化触发、状态持久化、独立验证、多Agent协调这些ReAct根本没有的东西。

ReAct有三个致命问题，在它自己的论文里没有解法。第一，没有确定性退出条件。模型说做完了就算完了？生产环境不行，你得有测试真的跑过、文件真的存在、用户真的确认。第二，不处理中途输入变化。用户在第5轮加了新需求，ReAct没法判断这是补充当前任务还是开新任务。第三，没有防死循环保护。模型卡住了就会无限重试，烧掉你的API预算。

Loop Engineering的真正贡献，就是在外面这层加上了确定性的护栏。代码可以否决模型的判断，就算模型说做完了，代码还要独立验证。状态写到磁盘上而不是上下文窗口里，因为Agent会遗忘，仓库不会。

Google工程师Addy Osmani把Loop Engineering的组件拆成了六块。Automations是心跳，cron定时或事件触发，让Agent自己找活干。Connectors通过MCP协议接上GitHub、Slack、数据库这些外部系统。Worktrees用git worktree给并行Agent各自独立的工作目录。Skills把构建步骤、目录结构、编码规范写进SKILL.md，每次循环开头读一遍，不用从零开始。Sub-Agents把造的和查的分开，用全新的模型实例来判断完成度，而不是让造的人自评。Memory把已试、已通过、待办的状态持久化到磁盘文件，跨天续跑。

有个实验室跑了47个真实Agent循环，总共花了1.77美元，得出几个关键发现。验证函数比提示词重要，精确的停止条件比如pytest必须通过，比模糊的条件快31%、便宜7%。子Agent验证比自评强44%的bug检出率，低47%的误报率。有状态的循环完成率91%，无状态的只有58%。前三轮迭代吃掉70%的token但只完成30%的活，这是暖机成本。

所以Loop和ReAct的关系，不是替代，是嵌套。ReAct是砖，Loop是用砖盖的房子。

说真的，这个区分很重要。因为如果你搞不清这个关系，就会觉得Graph Engineering也不过是又造了个词。但如果你理解了Loop是从ReAct外面长出来的，那你就能理解，Graph是从Loop外面又长出来的。

Loop撞上的五堵墙

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

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

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

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

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

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

除了这五点，还有一个更隐蔽、更值得警惕的问题，叫目标失明。

循环只能看见自己被赋予的那个指标，于是它会用尽一切办法去移动这个指标，包括那些背叛指标初衷的办法。有个被反复引用的真实案例。某团队做AI客服，以工单解决率为优化指标。连续五个月，曲线一路上涨。然后续费数据来了，客户流失率翻倍。

原因是这个AI学会的解决方式是偏转，快速关闭对话、劝阻用户追问、把被放弃的问题也标记为已解决。循环运行得完美无缺，数字一路上升，而这个成功恰恰是失败的机制。

经济学称之为古德哈特定律，一个指标被用力优化后，就不再测量它原本代表的东西。

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

到这一步，需要的不是更大的循环，是一张图。

Graph的解剖学，四个元素与三种形状

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

剥掉术语，一张能跑的图，形式上可以写成四个部分。G等于V节点、E边、S状态、P策略。

V节点是干活的单元，一进一出只干一件事。可以是一个专门化智能体，比如研究员、写手、审稿人，也可以是一个确定性步骤，比如一次函数调用、一次工具调用。E边是节点之间的路由，回答接下来去哪。可以是直通、条件分支、扇出、扇入，也可以是回环，审稿不过就退回重写。S状态是沿着边流动、大家共读共写的那个对象，记录任务、证据、预算、产物、检查点。它把一堆各干各的智能体捏合成一个系统。P策略约束谁能创建节点、调用工具、修改图、产生副作用，谁能查库、谁能发邮件、谁必须等人批。

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

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

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

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

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

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

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

Anthropic的五种工作流模式

Anthropic在2024年12月发了那篇「Building Effective Agents」，总结了五种可复用的工作流模式。这份资料是目前最权威的一手参考，因为它来自和几十个团队一起做智能体的真实经验。

Prompt Chaining，提示链，把任务拆成一串步骤，每步处理上一步的输出，中间可加检查点。适合任务能干净拆成固定子任务的场景，用延迟换准确率。

Routing，路由，先给输入分类，再导向专门的后续处理，实现关注点分离。适合输入种类多的场景，用一套提示优化一种会拖累另一种。

Parallelization，并行，把任务切成独立分支同时跑，再汇总。就是前面说的菱形。适合子任务能独立或需要多个视角交叉验证的场景。

Orchestrator-Workers，主管到工人，主智能体动态拆解任务、分派给子智能体、汇总结果。适合子任务无法预先确定、需要运行时动态决定的场景。

Evaluator-Optimizer，评估到优化，一个生成、一个评估打分，循环迭代直到达标。适合有明确评价标准且迭代能带来明显提升的场景。

这五种模式，其实就是把上一章的三种形状展开得更细。路由对应分诊台，主管到工人对应组织架构，评估到优化对应下面要讲的验证器。

Anthropic特别强调了一个态度，先找最简单的方案，只在真正需要时才增加复杂度。很多应用其实用单次调用加检索加几个例子就够了，根本不需要上智能体，更别说上图。

他们还给了框架一个中肯提醒。LangGraph、Bedrock、Rivet这些框架能简化调用、解析工具、串联调用这些底层活，让你快速起步。但它们往往加了一层抽象，把底下的提示和响应盖住了，反而更难调试，也容易诱使你在简单方案就够用时把系统搞复杂。建议先直接用LLM API，很多模式几行代码就能实现，要用框架也务必搞懂它底下的代码。

有意思的是，Anthropic管这些叫Workflows，一个字都没提graph。甚至连Claude Code在2026年5月上的多Agent编排功能，也命名为Dynamic Workflows，完全没有蹭graph这个热词。

确定性的杠杆，不是堆智能体

如果全文只记一句话，就记这句。图真正的杠杆，不在于塞了多少个智能体，而在于你能围绕结果搭起多少确定性。

很多人一听Graph就想堆多智能体，觉得节点越多越高级，这是最大的误会。要理解为什么，得先看清大多数智能体系统翻车的根子，模型既当运动员，又当裁判。

让写代码的智能体在写它的上下文里审自己的代码，它几乎永远说没问题。

Graph的解法是把做判断和做验证拆成两个独立节点。出结论的是一个智能体，专门挑错的是另一个，叫Verifier。它的职责不是再写一份答案，而是专门试图推翻前一个结论，扛得住才放行，扛不住就打回重来。关键在于它要用一双全新的、干净的眼睛，只看最终结果，不看是怎么憋出来的。

检查的力度要看事情轻重，这就需要一个Router，像医院的分诊台，按重要程度把任务导向不同的检查路径。普通观点快速核对，重要数据和安全结论则要多角度交叉审。常见的验证有三种打法。

对抗式，派多个怀疑者分头去驳同一个结论，多数没驳倒才算它站得住。多视角，换不同角度查，正确性、安全性、能否复现，各查各的。评委制，多个方案并行打分，选出优胜者，再吸收亚军里的好东西。

但光靠智能体互相验证还不够。最硬的确定性来自两个地方，代码和现实。确定性的活，格式校验、跑测试、去重、排序、算预算，就该交给普通代码。让模型去判断JSON合不合法，既不稳定又费钱。

这就是那句被反复引用的话，让模型的判断力落在节点上，让代码的可靠性落在边上。

如果一张图里，所有节点都在互相引用模型生成的结论，没有一个节点真的去碰一下现实，那它只是一台更精致的自嗨机器。有人称之为一个项目管理做得更好的、更大的幻觉。

真正的锚点，必须是那些无法狡辩的硬事实。测试真的跑过、钱真的到账、用户真的留下、库存真的对上、线上指标真的恢复。至于更好到底指什么，这个必须由人来定，因为图里每个循环都预设了它。

这是老工厂不需要面对的问题，因为人不会自己骗自己到那种程度。但模型会。。。

同一个任务，Loop和Graph怎么做

前面讲了不少概念，节点、边、扇出扇入、验证器、干净上下文。这一章用一个具体任务把它们全串起来，同时和Loop做一次正面对比。这个例子来自Anthropic和社区反复用到的经典场景，因为它足够小又足够典型。

任务是这样的，做一份每日研究简报。每天早上，读几个信源上关于某个主题的最新内容，写成一页纸的摘要，并且在发到你邮箱之前，先核对一遍准确性。

最直觉的做法，是让一个智能体在一个循环里把所有事都干了。它搜信源、把原始搜索结果一股脑塞进上下文、起草简报、然后审查自己的草稿。问题就出在这个过程里。等它开始审查的时候，它的上下文已经是一锅粥了，原始的搜索网页、写了一半的句子、还有它自己之前的推理，全都糊在一起。它是在写出这份草稿的同一个上下文里审查它，等于让作者给自己判卷，几乎必然盖个通过章。而且因为循环天生是顺序的，它只能一个信源一个信源地读，慢。

同样的任务，拆成三个节点，状态在它们之间干净地流动。研究员节点扇出到多个信源并行搜集，只返回结构化的笔记，绝不写成文。写作节点只拿到干净的笔记，看不到杂乱的原始网页，产出简报。审稿节点在一个全新的上下文里，只看简报和验收标准，不合格就打回给写作节点。

你能直接看出小图买到了什么。上下文是分开且干净的，写作节点从不被搜索垃圾淹没。是真正的审查而不是自己给自己盖章，审稿是全新的眼睛。是并行搜集而不是一个个来。还有一条能当作图读懂的清晰路径，而不用从一长段对话记录里反推。

但诚实地说，这张图也是有代价的，Loop那种臃肿做法没付这个代价。你要维护三个提示词而不是一个，要设计节点之间的状态结构，研究员到底交给写作什么，还要应对一批新的失败模式，合并时悄悄漏掉一个信源、路由bug导致死循环、状态从一个节点泄漏到下一个。

对于一份每天都要跑的简报，这些额外开销换来的是实打实的质量提升，值。但对于一个只跑一次的任务，它就是纯粹的税。这笔账，就是要不要从Loop升级到Graph的全部决策。

Graph与老框架的两年半时差

Graph Engineering这个词是2026年7月17日被一条推文催生的。但图这个结构，在Agent框架里已经存在了两年半。

LangGraph，LangChain下面的框架，2024年1月8日发布到PyPI。它从第一天就用StateGraph、节点、边、条件边、共享状态这套东西。它做的就是把应用建模成有向图，开发者定义状态结构、注册节点函数、设置边和条件路由，然后编译成一个可执行的应用。到Graph Engineering这个词出现的时候，LangGraph已经在PyPI上跑了两年半，v1.0在2025年10月发了GA，到2026年7月已经迭代到v1.2.9。

LangChain的联合创始人Harrison Chase在X上直接说了句，Graph Engineering是X的AI内容工厂产出的最新术语。LangChain自己发了一篇文章，标题叫「3 Years of Graph Engineering with LangGraph」。潜台词很明确，你们刚发明的词，我们干了三年了。

Google ADK也一样。2025年11月上了ThoughtWorks技术雷达的Assess环，2026年4月升到Trial环，同月发布的2.0版本引入了图执行引擎，有Graph对象、State节点、条件转换，和Graph Engineering定义的那套东西一模一样。这比Steinberger的推文早了三个月。

微软的AutoGen走的是另一条路。它2023年9月就发了初版，但最初不是图架构，而是事件驱动的GroupChat模式，靠对话协商来分工。它的特色是GroupChatManager当主持人，动态决定下一个该谁说话，不是固定轮转。但它的继任者Microsoft Agent Framework在2026年4月也转向了typed-graph workflow模型，消息传递变成了类型化的边在节点间路由数据，加了类型安全路由、检查点和人在回路支持。AutoGen自己在2025年10月进了维护模式。

CrewAI又不一样。它2024年初上线，走的是角色化路线，每个Agent有角色、目标、背景故事和工具权限，Crew是团队容器，靠顺序或层级流程编排。它不是图驱动，而是过程驱动。更简单的心智模型，但灵活性不如LangGraph。

还有一个更有意思的。Anthropic自己在2024年12月发了那篇「Building Effective Agents」，里面总结了五种工作流模式。这些模式说到底都是图拓扑，路由就是条件边，并行就是扇出扇入，评估到优化就是回环。但Anthropic管它们叫Workflows，一个字都没提graph。连Claude Code的多Agent编排功能也命名为Dynamic Workflows。

所以真相是什么？

Graph Engineering作为一个词，确实是新的。但作为一套工程实践，它至少存在了两年半。再往前推，Apache Airflow在2014年就用DAG做任务编排，Temporal用状态机管理分布式工作流，BPMN引擎像Activiti、Flowable、Camunda搞了几十年的流程图。AI圈只是把执行单元从代码换成了Agent，然后重新讨论了一遍。

框架对比与真实生产案例

Graph Engineering早就不是纸上概念。你要是用过LangGraph、Google ADK、AutoGen中的任何一个，其实已经在做图工程，只是没这个叫法。

这几个主流框架的定位差异很值得看。LangGraph用有向图加条件边做编排，内置检查点和时间旅行，同任务大约吃2000 token，适合长时运行、需审计、需回滚的生产管线。CrewAI用角色化crews做编排，任务输出序列传递，大约3500 token，适合规范化的角色协作分工。AutoGen用对话式GroupChat，对话历史为主，大约8000 token，适合多模型对话协调的探索性任务。Google ADK用结构化图架构，分层协调加A2A协议，适合code-first、企业级、可部署到Vertex AI的场景。

这里有个细节值得展开。为什么同一个任务，LangGraph吃2000 token，AutoGen要8000？差别来自图这个结构，它把智能体之间的对话变成了状态转换，省掉了它们互相转述背景的那一大堆废话。这也解释了为什么LangGraph成了企业生产的事实标准，月下载量千万级。

LangGraph的杀手锏，用它官方文档的原话说，叫持久化执行，durable execution。编译图时挂上一个checkpointer，它就会在每个超级步结束时把整个图的状态存一份快照。这带来四个能力。人在回路，图可以在任意节点暂停，等人检查、修改、批准后再从断点恢复。记忆，多轮交互间保留上下文。时间旅行调试，回到任意历史检查点重放，甚至分叉出新路径。容错，某个节点失败，从最后一个成功的步骤重启，而不是从头再来。

更妙的是一个叫待写入的设计。当同一个超级步里有个节点失败了，其他已经成功的节点的输出会被留存下来，恢复时不用重跑那些成功的节点。这些工程细节，才是让智能体从能演示变成能上生产的关键。

说几个真实案例。

LinkedIn的SQL Bot让几千名不懂代码的员工用大白话查数据仓库。做法是一张图，路由智能体先判断问的是哪块数据，交给领域专家智能体，再交给写SQL的，最后一个自纠错智能体发现错了自己修，条件边支持重试N次，实在不行才升级给人。查询准确满意度95%。

Uber面对5000名工程师、上亿行代码的迁移工程。他们用子图给不同语言、不同仓库各起一个专门子智能体，上面一个主管图协调，提交前先解决冲突。检查点机制让系统能扛住CI抽风、代码冻结、维护窗口这些必然的中断。节省了21000多个工程小时。

用LangGraph的还有Klarna、摩根大通、Replit这一票公司。Anthropic自己的Research功能也是同一个思路，用编排者到工作者模式，主智能体规划、子智能体并行搜索，官方数据说它比单智能体强90.2%。这些都不是demo，是实打实跑在生产上、服务真实用户的系统。

什么时候该上Graph，三条尺子

最关键的一条心法，别为了Graph而Graph。这不是我的个人观点，而是Anthropic反复强调的。他们见过太多团队花几个月搭复杂的多智能体架构，最后发现改进单个智能体的提示就能达到同样效果。

先看一组来自Anthropic官方的硬数据。多智能体研究系统在内部评测上超过单智能体90.2%。但多智能体系统的token消耗约为普通对话的15倍。仅token用量一项，就解释了性能方差的80%。

这组数字说明了一个残酷的权衡。多智能体确实更强，但它是靠烧更多token换来的。所以它只值得用在那些价值足够高、足以覆盖成本的任务上。Anthropic给出了三个明确该用多智能体的场景，也是判断该不该上图的三把尺子。

上下文保护。某个子任务会产生大量但对主任务无关的信息，超过1000 token的那种，用独立子智能体隔离出去，保持主上下文干净。可并行。任务能切成多个独立分支同时跑，探索比单智能体更大的搜索空间，尤其适合广度优先的研究搜索。专业化。不同步骤需要不同的工具、提示或专注度，拆开能提升工具选择的准确率和任务专注度。

反过来，如果任务就一个目标、一个领域、一个明确的停止条件，那清晰的单个Loop就是最优解。比如让智能体每天检查一次仓库CI、失败就总结日志发你，这是完美的循环，硬拆成十个智能体只会徒增延迟、成本和调试难度。

最后还有一条治理红线。图允许任务怎么拆怎么合现场灵活调整，这叫工作图，可以快变。但谁有权改数据库、谁能绕过审批这类长期权限，绝不能让模型现场发挥，这叫角色图，必须慢变、可审计。否则搭出来的不是智能系统，而是一场随时会爆的生产事故。

Graph、ReAct与老工作流的三角关系

最后回答一个理论问题，也是资深工程师最爱争的一个。这不就是回到ReAct之前的老工作流了吗？答案是，形似，神不似。

要讲清楚，得看它前面两代长什么样。老工作流的路径是死的、每个节点也是写死的代码，像固定流水线，遇到没预料的情况完全不会拐弯。后来的ReAct走向另一个极端，让模型全程边想边做，灵活是灵活了，但整个控制流都泡在模型一次次的对话里，事后想问它为什么这么干，只能去一大段杂乱的对话记录里考古，难复现、难审计、还容易失控。

老工作流和ReAct是稳与活的两个极端。Graph的巧妙，是把稳和活拆到两层去解决，而不是二选一。让边和整体结构固定下来，所以可治理、可审计、每次分类走同一条路。让节点内部保留自主，所以够灵活、能应对具体问题。

这正好呼应了Anthropic那个官方定义。工作流是通过预定义代码路径编排的系统，智能体是由LLM动态决定自己流程的系统。而Graph恰恰是两者的融合，用预定义的边框住动态的节点。

所以它回到的只是老工作流的形，内核完全不同。老工作流的节点是死代码，Graph的节点里住着能自主推理的智能体。这不是原地打转，而是螺旋上升，把ReAct的灵活收进了一副可治理的骨架里。

命名是虚的，视角上移是实的

绕了一大圈，回到最初的问题。Graph Engineering，到底是营销新词，还是真东西。

我的判断是，它是一次命名事件，加一次视角上移。

命名事件那部分，是虚的。节点、边、状态、有向图调度、状态机、多智能体编排，这些计算机科学玩了几十年了，LangGraph、ADK、AutoGen也实打实做了两年多。这个词大概率会和Loop Engineering一样，几个月后被下一个词盖掉。

视角上移那部分，是实的。真正变了的是三件事凑齐了。模型强到能可靠地当一个自主节点。框架成熟到能把它们稳稳连起来。社区大到攒出了一套共同词汇。工程重心从编程一个智能体的行为，实实在在地上升到了编程一群智能体的组织。这个转变是真的，它能造出单个循环永远造不出来的系统。

有意思的是，我们折腾了半天AI，最后绕不开的居然是最古老的那门学问。怎么管理一个组织。怎么分工、怎么定权责、怎么让干活的和监督的分开、怎么在有人掉链子时不至于全盘崩掉。这些问题人类的公司琢磨了几百年，现在只是换了一批员工，重新问了一遍。

亚当·斯密在《国富论》里讲扣针工厂的分工，十个人分工做扣针，产量是一个人的几千倍。他讲的道理和今天Graph Engineering讲的分工，底层是一样的。只不过流水线上的工人变成了图里的节点，交接单变成了在边上流动的状态，质检员变成了Verifier节点。

但这里也有一个Graph特有的危险，是老工厂没有的。如果一张图里所有节点都在互相引用模型生成的结论，没有一个节点真的去碰一下现实，那它只是一台更精致的自嗨机器。真正的锚点必须是那些无法狡辩的硬事实，测试真的跑过、钱真的到账、用户真的留下。不然搭得再精密，也就是一台更有组织的幻觉工厂。

所以如果你问我，Graph Engineering到底是真是假，我的回答是，名字是假的，方向是真的。

三句能直接用的话。

第一，别为了图而图。一个清晰的循环能搞定的，就别整复杂，先画一张能在餐巾纸上说清的小图。这是Anthropic反复强调的第一原则。

第二，图的价值来自确定性，不是来自智能体数量。让模型去判断，让代码去兜底，再配一双独立的、专门挑刺的眼睛。

第三，图必须接地气。测试真跑过、钱真到账、用户真留下，不然搭得再精密，也只是更有组织的幻觉。

名字会换，这个词大概率几个月后就被下一个盖掉。但从一个人干活到一群人协作的方向，不会变。

毕竟，人类折腾了几百年才学会怎么组织一群人一起干活。现在轮到我们，学着怎么组织一群AI了。

以上，既然看到这里了，如果觉得不错，随手点个赞或收藏，如果想第一时间收到推送，也可以给我个关注⭐～
谢谢你看我的文章，我们下次再见。