Graph Engineering：把多个 Agent 从循环组织成可治理的系统

Graph Engineering 不是让 Loop Engineering 退场，而是把多个 Agent、工具、校验器和人工节点组织成一张可执行、可观察、可恢复的协作图。本文从概念边界出发，给出一套节点、边、状态与验证并重的设计方法。

Graph Engineering：把多个 Agent 从循环组织成可治理的系统

摘要：Graph Engineering 不是让 Loop Engineering 退场，而是把多个 Agent、工具、校验器和人工节点组织成一张可执行、可观察、可恢复的协作图。本文从概念边界出发，给出一套节点、边、状态与验证并重的设计方法。

一个 Agent 独立完成任务时，我们通常只需要设计好目标、工具、验证器和停止条件：让它执行、检查、修正，直到完成或触发退出规则。

但当系统开始出现多个专业角色、并行任务、人工审批和失败恢复，一条循环就不再足以表达真实的工作结构。此时，问题从“怎样让一个 Agent 做得更好”，变成了“谁负责什么、信息怎样流动、失败由谁处理、结果由什么证据确认”。

这正是 Graph Engineering（图工程） 想解决的问题。

本文的核心结论是：Graph Engineering 的价值不在于画出更多节点，而在于把职责、路由、状态、权限和验证边界变成可以检查的工程对象。 它不会自动提高可靠性，却能让复杂 Agent 系统更容易约束、观察和恢复。

Graph Engineering 不是新框架，而是一种系统设计视角

2026 年 7 月，Peter Steinberger 在 X 上提出一句带有调侃意味的问题：“我们还在谈 Loop，还是已经转向 Graph 了？”这条原始帖子很快引发讨论，随后 Hamel Husain 发布了题为 Loop Engineering Is Dead. Enter Graph Engineering 的长文。

但截至 2026 年 7 月，Graph Engineering 仍没有统一定义、标准参考架构或足以证明它优于 Loop Engineering 的公开对比基准。SmartScope 的证据梳理指出，更准确的理解是：这个新名称把设计重点从单个 Agent 的循环，扩展到了多个处理单元之间的状态、权限、依赖和失败路径。

基于现有讨论和框架实现，可以给出一个实用定义：

Graph Engineering 是把 Agent、确定性代码、工具、评审器和人工操作建模为节点，用边表达执行条件、依赖、并行、重试与终止，并通过结构化状态传递任务、证据、预算和权限的系统设计方法。

这里需要排除两个常见误解。

第一，它不是传统的 Knowledge Graph Engineering。传统知识图谱工程关注实体、关系、模式和语义；本文讨论的是 Agent 工作流的执行图。两者可以结合，但不是同一个概念。

第二，它也不是 LangGraph、AutoGen 或 Google ADK 的新名字。节点、边、状态机、DAG 和工作流编排存在多年。新的只是观察角度：当节点由具有不确定性的 Agent 执行时，状态契约、验证权限和失败恢复需要被更认真地设计。

Graph 不会取代 Loop，因为 Graph 本来就包含 Loop

Loop Engineering 关注一个执行单元内部如何持续改进：发现任务、规划、行动、验证，根据结果继续或停止。

Graph Engineering 关注多个执行单元如何协作：哪个节点先运行，哪些节点可以并行，结果在哪里汇合，失败后回到哪里，什么条件必须交给人工裁决。

两者的关系可以这样理解：

一张 Graph 中可以有多个 Loop：写作节点可能循环修改草稿，代码节点可能循环运行测试，审核失败后还可能从验证节点回到执行节点。

因此，“从 Loop 升级到 Graph”不是技术代际替换，而是设计范围扩大。一个可靠的 Graph，仍然依赖每个关键 Loop 都有清晰的目标、验证器和停止条件。

出现四类信号时，才值得从 Loop 升级为 Graph

图会引入额外状态、路由、提示词、权限配置和运维成本。默认选择应该是：先用一个边界清晰的 Loop 解决问题，只有当工作本身要求分裂时，再引入 Graph。 这与 Anthropic 在 Building Effective Agents 中强调的原则一致：从最简单的可行方案开始，只在效果能够证明复杂度合理时增加结构。

下面四类信号通常说明 Graph 开始值得投入。

任务存在真正独立的专业职责

研究、写作、安全审核和发布审批需要不同上下文、工具或权限。把它们全部塞进一个 Agent，会让职责和失败影响范围混在一起。

节点应该代表真实的责任边界，而不只是流程中的每一个动作。若两个步骤使用相同工具、相同权限和相同验收标准，它们可能更适合留在同一个节点中。

工作需要扇出并行，再汇合结果

市场调研、代码审查和多来源事实核验都可能把任务拆成互不依赖的分支，并行执行后再由综合节点汇合。

并行不是“多开几个 Agent”这么简单。系统还要规定分支如何结束、缺失结果是否阻塞、冲突信息怎样处理，以及汇合节点读取哪些证据。

控制流必须显式、可审计

当系统涉及付款、发布、生产变更或隐私数据时，不能把“下一步做什么”完全藏在模型推理里。审批节点、权限边界、条件分支和失败升级路径需要成为可追踪的结构。

任务必须跨时间恢复或隔离失败

长时间运行的任务可能被中断，外部 API 可能超时，某个节点可能需要独立重试。此时系统需要检查点、幂等控制和明确的恢复入口，而不是让整个 Agent 从头再来。

如果上述信号都不明显，一个有外部验证器和硬性停止条件的单 Loop 通常更经济。

一套可落地的 Graph Engineering 五步法

第一步：先定义外部结果，再设计内部拓扑

不要从“需要几个 Agent”开始，而要从“什么证据能证明任务完成”开始。

外部结果可以是自动化测试通过、数据校验成功、事务状态改变、人工签字或真实业务结果。它们必须尽量来自系统推理之外，而不是让一个模型生成答案，再让另一个模型仅凭语言风格判断答案是否正确。

为每张工作图先写清四项内容：

• 最终交付物是什么；
• 成功证据来自哪里；
• 哪些错误可以自动恢复；
• 哪些情况必须停止并交给人工。

没有外部锚点的 Graph，只会把未经验证的结果生产得更快。

第二步：按责任、权限和失败边界划分节点

一个好节点应该有单一责任，并且能够独立说明输入、输出、工具和验收规则。

可以用一张“节点卡”约束设计：

• 职责：这个节点唯一负责什么；
• 输入：只读取哪些字段和证据；
• 输出：必须生成什么结构化结果；
• 工具：允许调用哪些外部能力；
• 权限：可以读取、修改或发布什么；
• 验收：由什么规则判断完成；
• 失败：重试、降级、跳过还是升级人工。

如果一个节点既检索资料、又修改数据库、还负责批准自己的结果，它就拥有过大的职责和故障半径。

第三步：先设计边和契约，再优化节点提示词

很多团队把主要精力放在每个 Agent 的提示词上，却忽略节点之间如何交接。Graph 真正难维护的部分通常不是节点，而是边。

每条边至少需要说明：

• 上游提供哪些字段；
• 下游依赖哪些前置条件；
• 路由条件由规则还是模型决定；
• 超时、失败和部分完成如何处理；
• 重试是否会重复调用外部系统；
• 谁有权让流程结束、回滚或升级。

优先让确定性规则负责高风险路由。例如“测试通过才允许合并”“金额超过阈值必须人工审批”。只有无法用稳定规则表达的语义判断，才交给模型路由，并为它设置候选范围、置信阈值和回退路径。

第四步：把共享状态当成产品接口治理

共享状态不是一段不断增长的聊天记录，而应该是有类型、有所有者、有版本的系统接口。

状态可以包含任务说明、结构化事实、产物地址、验证证据、重试次数、成本消耗和审批结果。不同节点只读取完成职责所需的字段，并只修改自己拥有的部分。

实践中需要重点处理：

• 单一事实来源：避免多个节点各自维护互相冲突的任务状态；
• 字段所有权：明确哪个节点能够更新哪个字段；
• 版本与迁移：长任务恢复时，状态结构可能已经变化；
• 检查点：保存可恢复位置和已经产生的证据；
• 幂等性：重放节点时，不重复扣款、发信或提交变更；
• 上下文隔离：下游只获得必要信息，不继承所有中间噪声。

LangGraph 的官方 Graph API把图概括为 State、Nodes 和 Edges，并通过共享状态模式与 reducer 管理更新。无论是否采用该框架，这种显式状态模型都值得借鉴。

第五步：给验证、预算和人工节点真正的否决权

验证节点不能只是“给点建议”。如果它发现证据不足或规则未满足，就必须能够阻止下游执行、要求补充材料或把任务升级给人工。

同时，Graph 中的每条路径都要有边界：

• 最大重试次数；
• 最大执行时长；
• Token 或调用成本上限；
• 最大并行宽度；
• 允许访问的工具与数据；
• 必须人工确认的副作用。

观察指标也不应只看最终成功率。至少需要记录节点耗时、路由选择、重试次数、状态变化、验证失败原因、外部调用结果和单次任务成本。只有路径可追踪，团队才能判断复杂度是否真的换来了收益。

用“研究—写作—核验”理解一张最小可用工作图

以一篇需要多来源支撑的技术文章为例，最小工作图可以这样设计：

1. 任务节点接收主题、读者和交付标准。
2. 规划节点拆出相互独立的研究问题。
3. 多个研究节点并行收集官方资料、论文和社区实践。
4. 综合节点去重、识别冲突，并生成带来源的事实表。
5. 写作节点只能根据事实表组织文章，不能自行补造证据。
6. 独立核验节点检查核心论点能否回溯到来源。
7. 核验失败时返回综合或写作节点；核验通过后进入人工发布节点。

这里有三个关键设计。

第一，研究节点并行，但写作节点不会直接吞下所有搜索原文，而是读取经过整理的事实表，降低上下文噪声。

第二，核验节点拥有回退权，不能被写作节点绕过。

第三，发布是外部副作用，由人工节点最终确认。即使模型判断文章“可以发布”，也不能自动越过权限边界。

这张图已经包含并行、汇合、验证回路和人工审批，却没有把每一个小动作都包装成 Agent。复杂度来自任务需要，而不是为了展示拓扑。

八条最佳实践，让 Graph 可治理而不是只可展示

用确定性骨架承载 Agent 节点

触发、权限、预算、超时、状态更新和高风险路由优先用代码与规则实现。把 Agent 放在真正需要语义理解、开放探索和生成判断的节点中。

使用外部证据，而不是模型互相投票

多个同类模型基于同一份错误上下文，可能得出一致但错误的结论。测试结果、数据库约束、真实交易、引用原文和人工审批，比“另一个 Agent 也同意”更接近可靠验证。

按最小权限配置每个节点

研究节点通常只读，写作节点只写草稿，审核节点只给出结论，发布节点才拥有对外操作权限。权限跟随职责，而不是所有 Agent 共享同一套工具。

让循环有硬边界

任何回边都要有最大次数、超时和升级路径。无限自我改进不是能力，而是成本与风险失控。

为副作用设计幂等与补偿

节点重试可能重复发邮件、重复提交代码或重复扣款。使用幂等键、状态机、事务记录或补偿动作，确保恢复不会制造第二次事故。

分别观察节点、边和整条路径

节点指标说明单步质量，边的记录说明路由是否合理，端到端轨迹说明系统是否真正完成任务。只看最终输出，会掩盖重试风暴和成本异常。

把拓扑当成成本模型

一个扇出到十个分支的节点，不只是图上多了十条线，也意味着模型调用、外部查询、汇合等待和错误处理同时增加。设计评审时应估算最坏路径，而不只看成功路径。

从静态小图开始，再逐步引入动态路由

先让三到五个职责清楚的节点稳定运行，积累失败样本和路径数据。只有当固定拓扑确实限制任务，才允许 Agent 动态拆分或改写工作图。

Graph 能暴露失败，但不能自动消除失败

Graph 最大的现实价值之一，是把原本藏在长上下文里的控制流变得可见：我们能看到哪一步失败、状态在哪里变化、哪个节点反复重试。

但可见性不等于可靠性。Jeff Liu 在 Graph Engineering Makes Agent Failure Legible, Not Agents Reliable 中指出，把一个 Agent 拆成五个节点，可以改善上下文隔离和并行效率，也能让失败更容易定位，却不会自动降低模型犯错的概率。

常见反模式包括：

• 把每一个普通函数都替换成 Agent；
• 让生成节点负责批准自己的输出；
• 让多个节点任意修改同一份全局状态；
• 由模型自由创建节点，却没有数量、权限和成本限制；
• 只有成功路径，没有超时、取消、回滚和人工升级；
• 以图画得复杂作为系统先进的证据。

Graph 解决的是复杂工作的表达与治理问题。可靠性仍然来自外部证据、权限隔离、幂等机制、测试、评估和人工责任。

不必先选“最强框架”，先确定控制需求

现有框架早已提供 Graph Engineering 所需的大部分结构：

AutoGen GraphFlow 官方文档明确支持顺序、并行、条件和循环行为；Google ADK 工作流文档同时区分顺序、循环、并行模板以及更灵活的 Graph 和 Dynamic Workflows。

这些实现也说明，Graph Engineering 的核心技术并非突然出现。Data Science Dojo 的框架回顾同样指出，LangGraph、ADK、AutoGen 等工具早已在使用节点、边和共享状态，只是最近才被统一放进“Graph Engineering”这个话题中。

如果希望理解更形式化的理论，可以参考论文 From Agent Loops to Structured Graphs。它从调度器角度比较 Agent Loop 和结构化 DAG，并提出 Structured Graph Harness；但作者明确说明这是一份立场论文和设计提案，不是已经验证的生产实现。

开工前，用十个问题检查这张图是否值得存在

1. 单个 Agent 加外部验证器能否完成任务？
2. 每个节点是否代表真实的责任、权限或失败边界？
3. 哪些边必须由确定性规则控制？
4. 每条边的输入、输出和失败契约是否明确？
5. 共享状态是否有类型、所有者和版本？
6. 所有循环是否有次数、时间和成本上限？
7. 外部副作用是否支持幂等、回滚或补偿？
8. 验证节点是否拥有真正的阻断权？
9. 哪些路径必须经过人工批准？
10. 团队能否追踪一次任务经过的节点、状态与成本？

如果其中多数问题无法回答，继续增加节点只会放大不确定性。

结语：先把一个 Loop 做可靠，再把必要的 Loop 组织成 Graph

Graph Engineering 提供了一种有用的系统视角：当一个 Agent Loop 无法独自承担多职责、并行处理、权限隔离和长任务恢复时，把工作建模为节点、边和共享状态，让控制流从隐式推理变成显式设计。

但这不是“节点越多越先进”的竞赛。

真正值得保留的方法论只有四句话：

• 节点表达责任边界，不表达所有细碎步骤；
• 边表达契约、权限与失败路径，不只是画箭头；
• 状态必须结构化、可恢复、可审计；
• 可靠性依赖外部证据和治理机制，而不是 Agent 数量。

最稳妥的演进路径是：先让一个 Loop 在真实验证下稳定工作；当任务自然出现独立职责、并行汇合、审批和恢复需求时，再把必要的 Loop 组织成一张小而清晰的 Graph。

图的价值，不是让系统看起来复杂，而是让复杂性终于可以被管理。

参考资料

1. Peter Steinberger：Are we still talking loops or did we shift to graphs yet?
2. Hamel Husain：Loop Engineering Is Dead. Enter Graph Engineering
3. SmartScope：What Is Graph Engineering? How It Differs from Loop Engineering
4. Anthropic：Building Effective Agents
5. LangChain：LangGraph Graph API Overview
6. Microsoft AutoGen：GraphFlow Workflows
7. Google ADK：Template Agent Workflows
8. Wei Hu：From Agent Loops to Structured Graphs
9. Louis-François Bouchard：Graph Engineering Explained: What Actually Changed
10. Jeff Liu：Graph Engineering Makes Agent Failure Legible, Not Agents Reliable
11. Tony Bai：Loop Engineering 才火两个月，硅谷已经卷出 Graph Engineering 了
12. Data Science Dojo：The Frameworks That Were Doing Graph Engineering Before It Had a Name