600万人围观，Graph Engineering火了，一文看懂

来源：市场资讯

（来源：智东西）

AI应用风向标（公众号：ZhidxcomAI）

作者｜毕伟豪

编辑｜漠影

新瓶装旧酒？

智东西8月12日报道，最近，Agent圈又出现了一个新词：Graph Engineering。

但如果熟悉Agent，会发现这个“新词”并不陌生，Graph Engineering强调的核心概念，早已出现在LangChain团队2024年推出的LangGraph中。

那么，为什么Graph Engineering会在今天重新受到关注？

过去一年，Agent的能力边界不断扩大，社区开始讨论Loop Engineering：如何设计循环、管理状态、控制退出条件，让一个模型能够围绕目标持续执行。

但当任务愈发复杂，需要多个Agent协同完成时，新的问题出现了：如何组织这些不同的执行单元？

这正是Graph再次被需要的地方，它是一套用于描述复杂执行流程的方法，探索任务并行、节点验证、结果汇总、路径路由等任务执行的过程。

前段时间，海外博主Codez发布长文，试图总结一套从Loop演化为Graph的方法，截至发稿，这篇文章已有600多万阅读量。

智东西重新整理了这篇文章的核心内容，从任务拆分、节点设计、验证机制等方面，拆解Graph Engineering的核心方法。

一、什么时候该用Graph：四个信号，判断Loop是否已经到边界

过去几年，Agent圈不断出现新的工程术语：Prompt Engineering、Context Engineering、Loop Engineering、Graph Engineering。

它们看起来像一条升级路线，但更准确的理解是，这些不是替代关系，而是在解决不同层级的问题：Prompt处理单次调用，Context对应模型看到什么，Loop负责Agent持续执行，Graph则是让多个执行单元协同。

事实上，一个Loop本身就是最简单的Graph：节点（Node）与边（Edge）的组合，形象一些的话，就像流程图一样，节点就是一个工作步骤，是流程图中的那个方块，里面可以是某个任务，一个工具或者是Agent，而边则是连接节点的那条线，代表的是步骤之间的关系，走到哪、怎么走都由边来决定。

Graph组织Loop，而不是取代Loop，用不用Graph，要看Loop是否到达能力边界。

Graph Engineering最容易被误解的地方，是把它看成“增加更多Agent”，但Graph解决的是当一个任务包含多个执行单元时，如何安排它们之间的关系

从Codez的教程来看，是否值得引入Graph，可以观察这四个信号：

第一个信号：任务是否有可拆分的宽度。

Graph最适合处理一批彼此独立的工作。比如同时查询多个信源、审查多个文件、验证多个方案。这类任务如果串行执行，大量时间消耗在等待上；通过Graph，可以把这些节点同时展开。

反过来，如果任务本身是一条强依赖链，上一步决定下一步，那就没有必要强行拆分，这种情况下Graph增加的不是效率，是协调成本。

第二个信号：流程里是否存在“假边”。

被人为排成了顺序，并没有真正的数据依赖。比如“总结这份文件，然后查询天气”。总结结果并不会影响天气查询，这两个步骤之间其实不存在边。

Graph工程的第一步，就是找到这些无效连接，能删除的假边越多，就越说明原来的Loop还有并行空间。

第三个信号：单个Agent的上下文是否已经成为限制。

多Agent的目的，是让每个节点能够处理自己真正需要的信息。如果一个Agent能够装下全部背景，并完成任务，继续拆分任务只会增加成本。但当任务需要同时处理大量资料、多个角色视角时，把上下文拆开分配给不同节点，Graph才有意义。

第四个信号：任务是否需要额外的可靠性保障。

简单任务通常只需要生成结果，但代码迁移、研究分析、风险审查等场景，需要有人检查结果是否可靠。

Graph的优势在于，可以把验证器作为独立节点加入流程：一个节点负责生成，一个节点负责质疑，让系统从“一次生成”变成“生成+验证”的组合。

不过，所有判断最终都回到一条底线：先把一个Loop跑稳，再考虑Graph。

二、一眼看穿假边：Agent工作流为什么一半步骤在空等

第一件事，是分清两样东西：节点是一个工作单元，是一个Agent、一份边界明确的活、一个输入、一个输出。边则是一种依赖关系，这个节点的输出喂给那个节点做输入。

人们最容易犯的错是把“然后”当成边。“总结这个文件，然后告诉我天气”，这两步之间没有边，天气根本用不到那份总结，这是两个互不相干的任务节点被一段线性脚本硬凑成先后顺序。

是不是边的判断标准只有一个：下一步真的读上一步的输出吗？不读，就没有边。

很多工作流里，都藏着几条“假边”：看起来有先后关系，实际上后一步根本用不到前一步的结果。

删掉这些连接后，原本排队执行的流程就会展开成并行结构：几个独立任务同时运行，再把结果汇总给下一步。线性流程不是不能跑，但它把所有任务压在一条链上，效率低，也更容易被单点卡住：中间一个节点停住，后面的任务全都要等。

Graph Engineering做的，是重新梳理任务之间真正的依赖关系，让能同时完成的事情不要排队。

三、给节点定契约：schema让Agent输出可被连接

想让多个节点进行协作，第一步是先给每个节点定清楚边界：它接收什么输入，负责什么任务，输出什么结果。

下游节点需要什么信息，必须由上游明确传递，而不是指望Agent从一大段共享上下文里自己寻找。在workflow中，这份约束通常通过schema实现：给agent()定义JSON schema后，subagent返回的结果必须符合指定结构，格式错误时可以自动修正，而不是丢回来一段需要人工解析的自由文本。

这也是“能接进Graph的节点”和“只能给人看的回答”之间的区别。

边同样需要契约，它代表“A会给B提供什么数据”。如果边按照数据结构进行定义，节点就可以在不破坏整体流程的情况下实现替换和调整。

还有一个容易被忽略的点：不是所有步骤都需要Agent。压平、去重、过滤这类确定性操作，本质上只是数据转换，直接用代码完成即可。很多人花token让模型做这些工作，其实只是把一条本该免费的边，变成了一次昂贵的推理。

四、菱形与路由：先拆开跑，再决定往哪走

把节点和边组合起来，最常见的一种结构就是“菱形”：一个节点负责拆任务，多个节点并行执行，再由一个节点汇总结果。它的标准流程可以概括为：派发——归约——合成。

派发阶段，用parallel()同时启动多个subagent，比如让不同Agent分别检索不同信源，最后统一返回结果。

这里有两个关键点：parallel()本质上是一道屏障，会等待所有任务完成后再进入下一步；如果某个节点失败，它不会拖垮整个批次，而是返回空结果，后续通过.filter(Boolean)过滤即可。

汇入阶段，不一定需要Agent。像去重、排序、压平这类确定性操作，用普通代码处理更快、更便宜；真正需要判断的部分，再交给模型完成。

理解这个结构，就不会再纠结如何让Agent多执行几步，而会开始思考：哪些任务应该拆开，哪些结果必须合并。

但Graph不一定总是固定路径。有些任务下一步走向，取决于中间节点产生了什么结果，这时就需要路由。

例如，先让Agent判断一个工单类型，再决定交给哪个处理节点；或者根据代码diff的风险等级，选择快速评审还是完整审计。在workflow中，路由本质上就是一个if或switch：模型负责提供判断，代码负责执行选择。

这种设计把两件事分开了：节点保留Agent的灵活判断能力，边保留程序的确定性控制能力。不会因为一次模型判断，就让整个流程随机偏离预设路径。

五、验证器与隔离：失败必须困在节点里

Graph的价值，不是把更多Agent塞进流程，而是在多个执行单元之间建立确定性。

验证器节点就是其中关键的一环，它只负责质疑答案：在结果进入下一阶段之前，主动寻找错误。经过验证的结果才能继续向下流转，否则就会被拦截。

常见有三种验证方式：

对抗式验证：针对一个问题派出多个独立验证者，多数通过才保留；

多视角验证：不同验证器分别关注正确性、安全性、可复现性等维度，避免同一种检查遗漏题；

评委式验证：生成多个方案，再由多个评审打分，选出最佳结果。

这也是为什么复杂任务里，增加Agent数量并不等于增加可靠性，是否有节点负责质疑和筛选结果非常重要。

但验证只能解决“结果是否可靠”，不能解决“运行过程中如何不互相影响”。在线性Loop中，一个节点失败可能拖垮整条链路；Graph的目标，则是让失败尽量停留在局部。比如某个任务失败，可以只返回空结果，其他节点继续完成，最后在汇入阶段处理缺失信息。

另一类风险来自并行写入，多个Agent同时修改文件，可能会互相覆盖。解决方法是隔离，例如使用git worktree，让每个Agent在独立环境中工作，完成后再合并结果。

不过，隔离不是Graph的默认机制，只在真正存在并发冲突时才开启。

六、循环、模型分层与拓扑：三个控制成本的旋钮

Graph并不是一次性执行完的流程。对于探索型任务，例如漏洞排查、代码审计等，新的发现可能不断产生新的任务，这时需要通过循环边让流程继续探索。

但循环必须有明确的退出条件。否则，一个没有收敛标准的Graph，本质上只是在不断消耗token。

实际设计时，需要设置停止规则，例如连续几轮没有发现新的有效结果就结束；同时去重需要覆盖所有历史发现，而不是只记录最终确认的结果，否则同样的问题会被反复探索。

除了循环，Graph的效率还取决于两个设计选择。第一个是模型分层。不同节点承担的任务不同，并不需要全部调用最强模型。字段提取、分类等规则明确的重复任务，可以交给成本更低的模型；报告合成、结果裁决等需要复杂判断的节点，再使用更强模型。通过单独配置模型，Graph的结构无需改变，也能降低整体成本。

第二个是拓扑选择。不同的连接方式，会直接影响任务延迟。并行执行会等待一批任务全部完成后再进入下一阶段；流水线则允许不同任务独立推进，让完成较快的任务提前进入下一环节。

并不是所有阶段都需要“对齐再出发”。只有后续步骤需要同时看到全部结果时，才值得设置同步等待；对于可以独立推进的任务，让它们继续流转通常更高效。

结语、Graph不是新概念，是Agent工程化的延伸

从工程实现看，Graph并不是突然出现的新方向。

2024年前，LangChain团队推出的LangGraph，就已经将节点、边和共享状态作为Agent编排的核心框架。如今Claude Code等工具重新强调Graph，并不是因为诞生了一套全新的架构，而是随着Agent从单任务执行走向多任务协作，开发者再次需要一种组织复杂执行流程的方法。

变化在于，过去构建Graph需要开发者手动设计节点、状态和流程，如今Claude Code等工具正在降低这一门槛。

但Graph并不是所有Agent的终点。Codez在教程中反复强调克制：只有真正存在独立任务时才需要拆分，只有需要汇总时才设置同步等待，只有存在并行冲突时才引入隔离机制。

从Prompt Engineering到Graph Engineering，Agent的发展过程，是在上一层能力之上继续向工程化深入。

对于简单任务，一个稳定的Loop依然足够；但当任务开始需要多个Agent并行、验证和协作时，Graph就成为下一阶段必须掌握的工程方法了。