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 就成为下一阶段必须掌握的工程方法了。