编排不创造智能，Graph Engineering也是伪命题

7月中旬，OpenClaw创始人Peter Steinberger发了一条九个字的推文："我们还在谈循环吗，还是已经转到图了？"

两天之内260万浏览量。有人写讣告："循环工程已死，Graph Engineering万岁。"有人画架构图，把Agent排成组织架构的样子。有人开始用"从while循环毕业到了组织架构图"来形容这次跃迁。

Graph engineering的主张是：单Agent跑循环已经不够了，你需要设计多个Agent之间的协作拓扑。谁负责什么，谁的产出交给谁审查，路由怎么走，要像设计一个公司的组织架构一样来设计Agent之间的关系。

听起来很自然。人类团队是分工协作的，AI团队是不是也该这样？

但这个看似合理的直觉，经不起追问。

两种图，拆开看

Graph engineering里有两种图。

第一种叫Org Graph，静态的，长期存在的。预先定义好：有一个调研Agent、一个编码Agent、一个审查Agent，调研做完交给编码，编码做完交给审查，审查不过退回编码。角色固定，路径固定，除非重新部署否则不会变化。

第二种叫Work Graph，动态的，临时的。每个任务生成一个，Agent在运行时自己决定下一步交给谁，节点可以分裂、合并、新增、消失。拓扑结构不是事先画好的，是运行时涌现出来的。

两种图听起来都有道理。但拆开之后，两个问题就浮出来了。

先看Org Graph。节点是Agent，边是预设的，路由是确定的。跟传统工作流有什么区别？

老实说，没什么区别。连业内人士自己都看出来了。有人直接评论说："有明确职责的子Agent就是一个Graph。但没错，我们非要搞混大家，把它叫成一个全新事物。"学术论文里也是这么建模的：Agent被表示为工作流图中的节点，运行Agent就等价于图遍历。

Org Graph就是工作流，只是每个节点从确定性函数变成了大模型。叫什么名字是命名营销问题，不是架构创新问题。

再看Work Graph。如果拓扑是运行时涌现的，那你在"engineer"什么？

你没有在设计一张图。你在设计的是每个节点上Agent的能力、工具和判断逻辑。图是Agent行为的投影，不是一个独立的设计对象。你在做的事情，和在单Agent架构下仔细设计一个Agent的提示词、工具集、上下文策略，本质上是同一类工作。

"Graph engineering"这个名字有误导性。它让你以为核心工作是设计拓扑，但核心工作还是在每个节点上。

多Agent真的比单Agent更强吗

不管是Org Graph还是Work Graph，graph engineering的底层假设都是一样的：把任务分给多个Agent来做，效果会更好。

这个假设需要从第一性原理来检验。

多Agent和单Agent的唯一结构性差异是什么？是把一个统一的上下文拆成了多个隔离的上下文。所以问题变成了：什么时候"拆上下文"本身能创造价值？

拆上下文有一个确定的成本：Agent之间传递信息会有损耗。在《不要随便用子代理模式》里我们分析过这个问题：后端Agent决定改API格式，主Agent转述给前端Agent时信息被压缩，"JSON改成protobuf"可能被压缩成"后端接口有更新"，前端Agent拿到模糊信息继续按JSON解析，结果翻车。信息在传递中不可能100%保真，除非接口是严格结构化的。

所以判断标准很清晰：拆开上下文的收益，是否大于信息传递的损耗。

直觉上，你可能觉得有很多场景拆开是值得的。但学术研究给出了一个令人意外的答案。

Xu等人2026年的论文《Rethinking the Value of Multi-Agent Workflow》在7个基准测试上发现，单Agent通过多轮对话就能达到同构多Agent工作流的性能，而且因为KV cache复用还有效率优势。单Agent甚至可以匹配经过自动优化的异构工作流的性能。

Tran和Kiela用信息论的数据处理不等式论证了为什么单Agent在固定计算预算下应该更高效。他们的结论更直接："多Agent系统报告的许多优势，与其说来自架构本身的好处，不如说是未被控制的计算量和上下文效应。"

换句话说，很多人以为多Agent更强，其实只是因为多Agent花了更多token。你给单Agent同样的token预算，让它多想一会儿，效果一样好甚至更好。

2026年4月有一篇论文做了一个更直接的实验：同样的token预算，让一个模型自己安静地想，和让多个"角色"Agent互相讨论，前者效果更好。在《从Trae SOLO谈多智能体的困局》里我们提过这个发现：你给同一个强模型同样多的思考资源，一个人想比几个人传话更靠谱。

那graph engineering的支持者可能会说：我们的卖点不只是"多Agent"，我们还有对抗性审查、持续运行、结构化分工。这些卖点值得逐个检验。

逐个检验多Agent的卖点

卖点一：对抗性的独立审查

一个Agent写代码，另一个Agent独立审查，"第二双眼睛"能发现问题。这个直觉来自人类团队的code review实践：写代码的人容易对自己的方案产生路径依赖，第三方审查者能看到盲区。

但在AI场景下有一个前提被忽略了：如果两个Agent用的是同一个底层模型，它们有同样的知识盲区和推理偏好。Claude写的代码让另一个Claude审查，如果代码里有某种Claude系统性忽视的问题，比如某类并发边界条件，审查的那个Claude大概率也会忽视。

人类的code review之所以有效，是因为不同的人有不同的知识背景、不同的经验盲区、不同的审美偏好。两个同模型的Agent不具备这种差异性。

真正有价值的对抗性审查只有两种：要么用不同的模型（Claude写、Gemini审），让模型差异来制造真正的"第二双眼睛"；要么用确定性的验证工具（测试套件、类型检查器、linter）。后者回到了一个更朴素的结论，也是我们在《循环工程到底在干什么》里反复强调的：真正兜底的是测试，不是另一个Agent。

卖点二：持续运行的独立进程

多个Agent各自维护长期状态，像微服务一样常驻运行。比如一个Agent持续监控市场数据，一个管理风险敞口，一个处理交易执行。

这个方案有一个不容忽视的物理学直觉：没有外部校准信号的系统，运行时间越长，累积偏差越大。

每个Agent的每一步决策都有微小的偏差概率。这些偏差在长时间运行中复合增长。更麻烦的是，多个Agent各自漂移的话，它们之间的接口假设也会逐渐脱节。一开始约定好的JSON格式，随着Agent各自的行为漂移，可能一边开始在某个字段里塞入它认为有用但对方不理解的信息，另一边开始忽略某个它认为不重要的字段。

所以这种架构要想不跑偏，必须有两样东西：定期的人工校准，以及可量化的性能指标来探测漂移。但如果你必须定期人工介入，那它跟"人在关键节点看一眼"的简单方案相比，并没有显著的架构优势。

卖点三：结构化接口让分工精确高效

如果Agent之间的通信可以被结构化到几乎无损，比如传JSON而不是传自由文本，那拆开就不会有信息损耗。

这个前提本身是对的。但具体场景一展开就会发现一个有意思的事情。

CI/CD流水线：代码生成Agent输出一个PR，测试系统跑测试返回pass/fail，部署系统拿构建产物上线。接口是结构化的，分工是清晰的。但你仔细看：测试系统需要是Agent吗？不需要，它就是一个跑测试的脚本。部署系统需要是Agent吗？不需要，它就是一个部署流水线。唯一需要大模型判断力的只有代码生成那一步。

数据处理管线也类似：提取Agent输出结构化JSON，转换程序按schema操作，验证程序检查格式。大部分节点是确定性的传统程序，不需要Agent的自主判断能力。

这恰好跟我们在《根本不存在"专业Agent"这个东西》里的分析对上了：Agent层有现成的开源方案，真正该投入的是工具和领域知识。很多时候，系统里真正需要大模型智能的节点只有一两个，其余都是确定性的工具和程序。

把传统程序包装成Agent不会让系统更聪明，只会让每个节点多背一份系统提示词和工具定义的开销。在《不要随便用子代理模式》里我们算过这笔账：每个Agent至少要消耗10000 token的系统提示词加载。如果这个节点的全部工作就是跑一个测试脚本，那这10000 token纯粹是浪费。

卖点四：安全隔离

一个Agent能读客户敏感数据但不能执行管理操作，另一个有管理权限但看不到客户数据。

这是我认可的唯一一个多Agent使用理由。但它的本质是安全架构，跟智能没有任何关系。你用多Agent不是为了让系统更聪明，是为了让权限不互相污染。这是一个合理的工程需求，但不支撑graph engineering作为一种"新范式"的叙事。

四个卖点检验完，结论是：多Agent在智能层面不提供任何单Agent做不到的东西。Xu等人的论文用实验数据证实了这一点，Tran和Kiela的论文从信息论上解释了为什么这是必然的。少数合理的多Agent场景（安全隔离、总上下文确实超出单Agent承载能力）是工程上的权宜之计，跟"智能"无关。

动态路由的真相：你还没想清楚

这是整篇文章最关键的一节。

Work Graph的核心特点是Agent在运行时自己决定路由走向。这被宣传为一种比工作流更高级的东西。但换个角度看。

如果路由逻辑可以用规则表达，"测试通过就下一步，不通过就退回去改"，那它就是一个工作流，你根本不需要Agent来做这个判断，一个if-else就够了。

如果路由逻辑真的需要Agent来判断，"这个结果的质量够不够好，需不需要换个方向重新来"，那问题在于：这类判断恰恰是模型最不可靠的能力。在《循环工程到底在干什么》里我们论证过：你没法把"品味"编译成一个返回true或false的函数。同样也没法让一个Agent可靠地判断另一个Agent的产出"够不够好"。

Google的研究发现，多Agent协作在顺序推理任务上反而降低了39%到70%的性能。这个数字很说明问题：当多个Agent需要基于彼此的产出做判断时，错误在链条上累积，最终结果反而比一个Agent独立思考更差。

但最关键的追问是：为什么你需要Agent来判断路由？

大多数情况下，答案是：因为你还没搞清楚这个流程应该怎么走。

在《用大模型来开发，不等于要交付AI产品》里我们讨论过一种做法：先让大模型来处理，不预设规则，跑一段时间积累case。然后回头分析这些case，发现清晰的模式之后，把规律提取出来固化成确定性的规则。大模型完成了"探路"的使命之后就退场了。

动态路由属于同一种情况。你之所以需要Agent来决定"下一步交给谁"，是因为你对这个业务流程的理解还不够深。一旦你跑了足够多的case，发现90%的情况走的都是A→B→C这条路径，你就应该把它固化成工作流，不再需要Agent来做路由决策。

所以"需要Agent自己判断路由"不是一种架构优势，而是一种阶段性的无奈。动态路由是通向固定流程的过渡状态，不是终态。

Work Graph不是比工作流更高级的东西，恰恰相反，是比工作流更不成熟的东西。成熟的流程应该是固定的。

AI系统的两种真实架构

既然graph engineering不是一种新范式，那AI系统的架构到底该怎么想？

与其在Agent之间画拓扑图，不如先回答一个更基本的问题：决策权放在哪里。

所有AI系统最终都落入两种架构之一。

第一种：Agent为中心。 80%的决策由Agent做，人设计工具和固定规则来增强Agent的能力边界。Claude Code就是这种模式。Agent自主规划、执行、验证，遇到需要的时候调用工具，人在关键节点确认方向。

第二种：工作流为中心。 80%是固定流程，只在少数不可穷举的节点让Agent介入做判断。传统软件的主体没变，只是在关键决策点引入了AI的灵活性。

你对业务流程了解得越清楚，就越应该用第二种。面对的问题越开放、越不确定，就越需要第一种。

在《用大模型来开发，不等于要交付AI产品》里我们讨论过：几乎每个专业领域都有成熟的操作流程和规范。建筑有建筑的规范，财务有财务的准则。既然流程是现成的，你要做的就是把它编码成软件，而不是让Agent从头去探索该怎么处理。大多数工业化交付的产品，应该用第二种架构。

Graph engineering的Org Graph其实就是第二种架构，只是用多个Agent替代了工作流节点上的传统函数。Work Graph就是第一种架构的多Agent版本。它们不是第三种架构，只是前两种的变体。

而且在大多数情况下，这两种架构里的Agent只需要一个。在《根本不存在"专业Agent"这个东西》里我们分析过：所有垂类Agent拆开看都是"通用Agent加配置"。Agent这层有现成的开源方案，你要投入的不是Agent之间的编排，而是工具和领域知识。

在《从Trae SOLO谈多智能体的困局》里我们也论证过：多Agent声称要解决的几个问题，工具权限、文件范围、上下文隔离，用单Agent的配置项就能实现。一个allowedTools参数，一个allowedDirectories配置，一个/compact命令。三个简单方案解决三个简单问题，不需要引入多Agent编排的全套复杂度。

编排不创造智能

回到最开始的问题。Graph engineering画了一张Agent之间的关系图，但它没有回答最关键的问题：每个节点上的决策质量是怎么来的？

如果每个节点上的Agent本质上都是同一个通用大模型加一段角色提示词，那你画再精巧的拓扑，系统也不会因此变得更聪明。就像在一个公司里画再多的汇报线和审批流程，如果每个岗位上坐的人能力都一样，组织架构图的复杂度不等于组织的智慧。

Graph engineering在优化系统的结构，但系统的瓶颈不在结构上。瓶颈在模型的判断力和上下文的质量上。

这条规律其实贯穿了过去几个月的整条概念轮替线。从prompt engineering到context engineering到harness engineering到loop engineering到graph engineering，每一个概念都试图通过外部编排来弥补模型能力的不足。但模型能力的进化速度远快于编排方法论的成熟速度。每一个"弥补方案"都还没来得及站稳脚跟，它要弥补的那个不足就被模型自身消化了。

你的精力不应该花在编排Agent之间的连接方式上。应该花在两件事上：第一，想清楚你的业务流程中，哪些判断可以固化成规则、哪些必须留给Agent、哪些必须留给人。这是决策权的分配问题，是架构设计的真正核心。第二，把该固化的老老实实固化成确定性的程序。在《用大模型来开发，不等于要交付AI产品》里我们说过，大模型是你的生产力工具，不是你的产品组件。你用它来加速开发和发现规律，但最终交付的产品尽可能是确定性的。

结构只是壳子。灌进去什么质量的判断力，就出来什么质量的产出。不管明天又冒出什么新的engineering，这条规律不变。