Loop Engineering 让单个 Agent 的行为变得可编程；Graph Engineering 进一步把多个 Agent 的组织方式变成可编程对象。真正值得关注的不是「把流程画成图」，而是把职责、依赖、状态、权限与失败恢复从对话记录中提取出来，形成可执行、可观察、可改写的系统结构。

2026 年 7 月，Peter Steinberger 在社交媒体上抛出一个问题：还在讨论 Loop，还是已经转向 Graph？一个月前，Loop Engineering 刚把开发者的注意力从「如何逐条 Prompt Agent」推向「如何设计一个持续驱动 Agent 的循环」；现在，新的瓶颈又出现了。这轮讨论及其后续观点可见 Yash Thakker 在 2026 年 7 月 18 日发布的讨论汇总。

一个循环很适合描述单个 Agent 如何反复执行：

观察 → 规划 → 行动 → 验证 → 重试或结束
  ↑                         │
  └─────────────────────────┘

但真实任务很少永远保持单线程。一次线上故障可能同时需要查日志、核对数据库、回滚版本和通知业务；一次大型重构可能横跨 API、数据、前端、安全与测试。任务会分叉、汇合、暂停，也会因为新证据而改变方向。此时，问题已经不只是「循环如何继续」，而是：

• 哪些 Agent 应该长期存在，各自负责什么？
• 当前任务应该拆成哪些工作，先后关系是什么？
• 哪些工作可以并行，哪些结果必须汇合后才能继续？
• 新证据出现后，谁有权增加、取消或重新路由任务？
• 一个节点失败后，应该重试节点、回滚副作用，还是让整张图失败？

这就是 Graph Engineering 开始受到关注的原因。

需要先说明：截至 2026 年 7 月 21 日，Graph Engineering 仍是一个刚形成的行业术语，不是已经稳定的学术分类，也不是某个框架发明的新算法。更准确地说，它是一次「命名事件」：工作流 DAG、状态机、Actor、分布式调度和多 Agent 编排已经存在多年，现在这些实践被放进了同一个工程概念中。Josh C. Simmons 在 2026 年 7 月 4 日的文章中已经给出「节点、类型化边、检查点状态」这一组较完整的工程定义。

一、Graph Engineering 到底是什么

Graph Engineering 是把 Agent 系统表示为一张可执行图，并把图本身当作需要设计、版本管理和运行治理的软件制品。

可以用一个简化表达式描述：

G = (V, E, S, P)

V：节点，可能是 Agent、确定性函数、工具、路由器或人工审批者
E：边，定义依赖、数据传递和允许发生的状态转换
S：状态，记录任务、证据、预算、产物与检查点
P：策略，约束谁可以创建节点、调用工具、修改图或产生副作用

这里有两个容易混淆的概念。

第一，Graph Engineering 不是知识图谱工程。知识图谱组织的是「系统知道什么」，例如实体、属性和关系；这里的 Graph 组织的是「系统由谁组成、工作如何流动」。两者可以同时存在，但回答的问题不同。

第二，Graph 也不等于把现有 Prompt 流程画成流程图。只有当节点可独立执行，边携带明确状态，运行过程可以检查、暂停、恢复和追踪时，这张图才是系统结构，而不只是展示材料。

二、Loop 没有消失，它进入了节点内部

Loop 与 Graph 不是替代关系。一个实用的理解方式是：

Loop 规定一个节点内部如何工作；Graph 规定多个节点之间如何协作。

工程层级	主要对象	关键问题	典型状态载体
Prompt Engineering	一条指令	这句话如何写清楚？	Prompt 文本
Context Engineering	一次模型调用	当前步骤应该看到什么？	上下文窗口
Harness Engineering	一次 Agent 运行	模型拥有哪些工具、记忆和护栏？	Agent Runtime
Loop Engineering	一个 Agent 的连续行为	如何反复执行，何时停止？	会话与进度记录
Graph Engineering	多个执行单元的组织结构	谁负责什么，工作如何路由与恢复？	结构化图状态与检查点

Josh C. Simmons 对这层关系的概括很准确：Loop 被「降级」为节点内部的执行机制，而不是被淘汰。一个研究 Agent 节点仍然可以运行「搜索—阅读—验证—补充搜索」循环；Graph 负责决定何时调用它、给它什么输入、结果交给谁，以及失败后如何处理。

这也是图相对循环的核心变化：控制流不再全部藏在模型的上下文里，而是被提升为外部、显式、可检查的结构。2026 年 4 月的立场论文 From Agent Loops to Structured Graphs（arXiv:2604.11378）从调度器视角给出了相似判断：普通 Agent Loop 同一时刻只有一个可执行单元，而显式图把依赖和恢复策略从上下文中提取出来。该论文提出的是理论框架与实验方案，不是已经完成实证验证的生产实现。

三、生产系统里其实有两张图

单独说「Agent Graph」仍然过于含混。据 2026 年 7 月 18 日的讨论记录，Shubham Saboo 将它拆成了两个层次：长期存在的 Org Graph 与随任务变化的 Work Graph；Preston Holmes 进一步强调，两张图都重要，但运行在不同的时间尺度上。

1. Org Graph：谁负责什么

Org Graph 可以译为「组织图」。它描述系统中相对稳定的成员与责任：

• Agent 的身份与角色；
• 每个 Agent 负责的领域；
• 可以读取的上下文与长期记忆；
• 可以使用的模型、工具和凭据；
• 可以与哪些 Agent 通信；
• 哪些操作需要人工批准；
• 预算、速率和权限上限。

例如，一个软件研发 Agent 组织可能包含以下长期角色：

                       [工程负责人 Agent]
                       /        |        \
                      /         |         \
          [安全 Agent]     [数据 Agent]     [发布 Agent]
                |               |               |
          auth / audit     schema / SQL     CI / rollout

这里的「长期」不一定意味着进程永不退出，而是身份、职责和记忆可以跨任务保留。安全 Agent 即使当前没有运行，它的权限边界、审查规则和领域记忆仍然存在。下一项任务到来时，系统可以重新实例化同一个角色。

Org Graph 更像公司的组织架构。它通常由开发者预先设计、测试和部署，不应该因为某次任务中的一句模型输出就永久改变。

2. Work Graph：现在要做什么

Work Graph 可以译为「工作图」。它描述某一项任务在当前时刻的执行结构：

• 有哪些工作节点；
• 节点之间有哪些依赖；
• 哪些节点正在运行、等待、阻塞或完成；
• 哪些分支可以并行；
• 哪些结果需要汇合；
• 新证据是否要求增加、取消或重新排序节点。

它更像一份实时生成的项目计划，生命周期通常只覆盖一次任务或一次运行。

用户目标
   │
   ▼
[问题分诊]
   ├──────────┬──────────┐
   ▼          ▼          ▼
[查日志]   [核对账本]   [检查幂等逻辑]
   │          │          │
   └──────┬───┴──────────┘
          ▼
      [根因判断]
       /      \
      ▼        ▼
 [生成修复]  [生成回滚方案]
      \        /
       ▼      ▼
      [独立验证]
          │
          ▼
      [人工审批]

图中的「查日志」由可观测性 Agent 执行，「核对账本」由数据 Agent 执行，「生成修复」由支付领域 Agent 执行。Org Graph 提供可用的角色与权限，Work Graph 将当前工作分配给这些角色。

这一区分解决了一个常见的建模错误：Agent 与任务不是同一种节点。一个 Agent 可以连续处理多个任务，同一个任务也可能经过多个 Agent。把两者硬塞进一张图，往往会把「谁能做」和「现在做什么」混在一起。

3. 两张图的差异

维度	Org Graph	Work Graph
回答的问题	谁负责什么？	当前要做什么？
节点	长期角色、能力与权限主体	临时任务、检查点与产物
生命周期	跨任务存在	随单项任务创建和销毁
变化频率	低，通常随部署变化	高，可在运行时变化
状态	领域记忆、工具权限、策略	进度、依赖、证据、预算、结果
主要风险	越权、职责重叠、上下文污染	重复执行、死锁、失败传播、状态不一致

两张图共同运行，但不应共同随意变化。Org Graph 是可用能力与治理边界，Work Graph 是这些能力在当前任务上的一次编排。

四、工作图为什么必须动态变化

传统工作流通常假设流程在执行前已经确定。Agent 任务的不同之处在于：计划所依赖的信息，常常只能在执行中获得。

仍以「支付重复扣款」为例。初始计划可能要求同时检查前端重试、API 幂等键和账本记录。运行后出现新证据：前端没有重复请求，但数据库迁移导致幂等索引失效。此时合理的 Work Graph 应该发生以下变化：

T0：分诊 → {前端检查, API 检查, 账本检查} → 汇总

T1：取消前端深挖
    新增「检查迁移历史」
    新增「评估重复扣款影响范围」

T2：{索引修复, 补偿脚本, 回归测试} 并行执行
    三者完成后进入安全审查与人工审批

这不是普通的失败重试，而是运行时拓扑变化。常见的图改写操作包括：

• split：把一个工作拆成多个并行分支；
• join：等待多个分支汇合；
• spawn：发现新问题后创建工作节点；
• cancel：证据表明某个分支已无必要；
• reroute：原执行者不适合时重新分配；
• retry：在相同职责下更换参数、模型或执行实例；
• escalate：超出权限、预算或置信度阈值时交给人工节点。

工作图的价值并不只是并行，而是允许计划根据证据更新，同时保留每次更新的原因和历史。

五、动态 Agent 组织：图开始改写自身

Graph Engineering 再向前一步，就是 Dynamic Agent Org：系统在任务执行中修改图的结构。

不过，「动态」至少分为三个等级：

等级 1：只改写 Work Graph

系统可以拆分、合并、取消和重排任务，但只能把工作交给 Org Graph 中已经存在的角色。这是最容易治理、也最适合先投入生产的形式。

等级 2：创建受约束的临时 Agent

系统可以从已批准模板中生成临时专家。例如，发现一次性的数据兼容问题后，创建一个只读、限时、限预算的 PostgreSQL 诊断 Agent。任务结束后，Agent 与临时凭据一并销毁。

等级 3：修改长期 Org Graph

系统根据长期运行数据新增角色、合并职责、调整通信关系，甚至修改工具权限。这已经接近组织自我演化，风险远高于动态任务编排。任何持久修改都应该经过离线评估、策略检查、版本发布和人工审批。

因此，生产级「自改写图」不应理解为 Agent 可以随意重组自身。更准确的设计是：

Work Graph 可以在策略允许的范围内快速变化；Org Graph 的持久变化必须走慢速、可审计的发布流程。

这正是两张图需要不同时间尺度的原因。快图负责适应任务，慢图负责保持责任与治理稳定。

六、真正困难的不是画图，而是维护图的不变量

当图能够动态变化时，系统必须始终守住一组不变量。例如：

1. 每个运行中的任务必须有唯一负责人。
2. 未通过安全检查的产物不能进入发布节点。
3. 被取消节点产生的外部副作用必须已撤销或明确登记。
4. 临时 Agent 不能继承创建者的全部权限。
5. 任意时刻的累计花费不能超过本次运行预算。
6. 图的每次结构变化必须记录触发证据和决策者。

围绕这些不变量，生产系统至少需要补齐七类工程能力。

1. 结构化状态

不能再把聊天记录当作唯一状态。任务输入、前置依赖、产物、证据、预算和审批结果都应进入带 Schema 的状态对象。每次跨边时保存检查点，进程崩溃后才能从节点恢复，而不是重新播放整段对话。

2. 类型化交接

Agent 之间不应只传一段自然语言总结。边需要明确输入输出契约，例如 Finding[]、Patch、TestReport 和 ApprovalDecision。自然语言可以是字段之一，但不能代替协议。

3. 幂等、重试与补偿

读取日志可以安全重试，执行退款却不能简单再跑一次。每个节点都应声明其副作用类型、幂等键、重试策略与补偿动作。取消节点也不等于取消已经发生的外部影响。

4. 身份与最小权限

Org Graph 中的每个 Agent 都应拥有可解析的身份。权限根据职责授予，而不是所有节点共享同一组凭据。临时 Agent 只能继承完成当前任务所需的最小能力，并设置过期时间。

5. 调度、预算与背压

图可以瞬间分出几十个节点，但并行数不应等于模型允许创建的最大数量。调度器需要控制并发、Token、费用、速率限制与人工审核队列。下游处理不过来时，上游必须减速，而不是继续派生工作。

6. 图级可观测性

单个 Agent 的日志不足以解释全局故障。每次模型调用和工具调用至少应关联 graph_id、run_id、node_id 与 attempt_id。系统还要保存实际运行过的 Work Graph，而不只是设计时的模板。

7. 轨迹评估

只评估最终答案，会漏掉重复搜索、无效分叉、错误路由和异常成本。Graph 系统需要同时评估结果与轨迹：是否选择了合理节点、是否传递了必要证据、是否在合适的位置请求人工批准，以及是否以合理成本完成任务。

七、一个最小可用的双图架构

不依赖具体框架，一个最小实现通常包含六个部分：

┌──────────────────────────────────────────────┐
│ Org Registry：角色、能力、权限、长期记忆版本 │
└──────────────────────┬───────────────────────┘
                       │ 可分配能力
                       ▼
┌──────────────────────────────────────────────┐
│ Planner / Router：生成并改写 Work Graph      │
└──────────────────────┬───────────────────────┘
                       │ 调度命令
                       ▼
┌──────────────────────────────────────────────┐
│ Scheduler：依赖、并发、重试、超时与背压       │
└───────────────┬──────────────────┬───────────┘
                ▼                  ▼
         [Agent Runtime]     [Function / Human]
                │                  │
                └────────┬─────────┘
                         ▼
┌──────────────────────────────────────────────┐
│ State Store + Event Log：检查点、产物、改图历史│
└──────────────────────┬───────────────────────┘
                       ▼
             Policy + Observability

其中，Planner 可以使用 LLM 提出图修改建议，但 Policy Engine 决定建议是否允许执行。Scheduler 只执行合法的状态转换。Event Log 保存事实历史，便于恢复、审计和重放。

这种分工非常重要：模型可以参与规划，但不能同时成为规则制定者、执行者和审计者。

这些组件并非停留在概念阶段。Anthropic 在 2025 年公开的多 Agent 研究系统使用主 Agent 动态创建并行研究子 Agent；LangGraph 的子图与持久化机制提供了隔离状态、检查点和暂停恢复；Google 的 A2A处理 Agent 发现与通信；Preston Holmes 参与创建的实验性项目 Scion则提供容器、工作区和凭据隔离。这些项目分别覆盖图运行所需的部分原语，但还不存在一套公认的「双图标准」。

八、什么时候该从 Loop 升级到 Graph

Graph 的复杂度很高，默认方案仍然应该是 Loop。出现以下信号时，再考虑升级：

信号	Loop 的典型问题	Graph 提供的能力
任务可拆成多个独立分支	单线程执行过慢	Fan-out / Fan-in
不同步骤需要不同权限	单 Agent 权限过大	角色隔离与最小权限
任务需要跨天暂停和恢复	上下文难以长期保存	检查点与持久状态
某一步失败不应推倒重来	只能重启整个循环	节点级重试与补偿
过程包含多人审批	人工介入被当成异常	将人建模为正式节点
新证据会改变任务结构	原计划只能在 Prompt 中隐式调整	可记录的运行时图改写
需要解释费用与失败来源	只有一条长对话记录	节点级成本与轨迹观测

如果任务只有一个领域、一个 Agent、一个明确停止条件，把它改造成多 Agent Graph 往往只会增加延迟、成本和调试难度。多个 Agent 也不自动等于 Graph Engineering；没有状态契约、故障边界和治理策略的 Agent 群，只是一组并发运行的循环。

九、Graph Engineering 最常见的七个误区

1. 把所有节点都做成 Agent。 确定性校验、格式转换和权限判断更适合普通代码。
2. 把所有边都交给模型决定。 能用规则表达的转换应优先使用确定性逻辑。
3. 让所有 Agent 共享完整上下文。 这会放大成本、隐私风险和错误传播；边只应传递下游必需的信息。
4. 只设计成功路径。 超时、重复执行、部分成功、节点取消和人工拒绝才是生产故障的主要来源。
5. 把 Work Graph 当成 Org Graph。 每次任务都重新发明角色，会丢失领域记忆，也会让权限无法治理。
6. 允许动态创建 Agent，却没有继承规则。 新节点继承什么模型、记忆、预算和凭据，必须由策略明确规定。
7. 只看最终输出，不看执行轨迹。 结果偶然正确，不代表图的结构可靠。

十、从 Prompt 到 Graph，开发者的能力重心发生了什么变化

Prompt Engineering 的核心是表达；Context Engineering 的核心是信息选择；Harness Engineering 的核心是运行环境；Loop Engineering 的核心是持续控制；Graph Engineering 的核心则是系统组织。

能力重心因此从「如何与一个 Agent 对话」继续上移到以下问题：

• 如何划分职责与故障域；
• 如何定义稳定的状态与交接协议；
• 如何处理并发、重试、幂等和背压；
• 如何让权限、预算和人工审批成为图的一部分；
• 如何允许系统适应新证据，同时保持关键不变量不被破坏。

这些问题并不新，很多都来自分布式系统、工作流引擎和组织设计。新变化在于：节点内部不再只是确定性函数，而可能是能够规划、调用工具并运行自己 Loop 的 Agent；图的部分结构也可能由 Agent 在运行时提出修改。

因此，Graph Engineering 真正带来的不是一张更复杂的流程图，而是一种新的控制边界：

Prompt 编程一次回答，Loop 编程一个 Agent 的行为，Graph 编程一组 Agent 的组织方式。

再往前一步，动态 Agent 组织让这套结构具备有限的自我改写能力。但生产系统的关键始终不是「能否改图」，而是「谁可以在什么证据下改哪一部分图，以及系统如何证明改完仍然安全」。

这可能才是从 Loop 走向 Graph 后，最值得工程师投入的部分。

---

参考资料

• Yash Thakker, Graph Engineering: After Loops, This Is How You Wire Multi-Agent Orgs, 2026-07-18。用于追溯 2026 年 7 月讨论、Org Graph / Work Graph 二分及 Preston Holmes 的时间尺度观点。
• Josh C. Simmons, We Are Entering the Graph Engineering Phase, 2026-07-04。提出节点、类型化边、检查点状态及「Loop 进入节点内部」的工程解释。
• Hu Wei, From Agent Loops to Structured Graphs: A Scheduler-Theoretic Framework for LLM Agent Execution, arXiv:2604.11378, 2026-04-13。该论文是立场论文与设计提案，不包含生产实现或实证结果。
• Anthropic, How we built our multi-agent research system, 2025-06-13。介绍 Orchestrator-Worker、并行子 Agent 与动态研究计划的生产经验。
• LangChain, LangGraph Subgraphs 与 Persistence。介绍多 Agent 子图、检查点、暂停恢复与持久状态。
• Google Developers Blog, Developer’s Guide to AI Agent Protocols, 2026-03-18。介绍 A2A 在 Agent 发现与通信中的作用。
• GoogleCloudPlatform, Scion。Preston Holmes 参与创建的实验性多 Agent 编排项目，支持隔离容器、独立工作区、凭据与并行执行；项目明确标注为早期实验阶段。

注：Graph Engineering、Org Graph 与 Work Graph 的术语仍在快速演化。本文采用的是截至 2026 年 7 月 21 日的行业讨论口径，不代表已经形成统一标准。