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 RuntimeLoop Engineering一个 Agent 的连续行为如何反复执行何时停止会话与进度记录Graph Engineering多个执行单元的组织结构谁负责什么工作如何路由与恢复结构化图状态与检查点Josh C. Simmons 对这层关系的概括很准确Loop 被「降级」为节点内部的执行机制而不是被淘汰。一个研究 Agent 节点仍然可以运行「搜索—阅读—验证—补充搜索」循环Graph 负责决定何时调用它、给它什么输入、结果交给谁以及失败后如何处理。这也是图相对循环的核心变化控制流不再全部藏在模型的上下文里而是被提升为外部、显式、可检查的结构。2026 年 4 月的立场论文 From Agent Loops to Structured GraphsarXiv:2604.11378从调度器视角给出了相似判断普通 Agent Loop 同一时刻只有一个可执行单元而显式图把依赖和恢复策略从上下文中提取出来。该论文提出的是理论框架与实验方案不是已经完成实证验证的生产实现。三、生产系统里其实有两张图单独说「Agent Graph」仍然过于含混。据 2026 年 7 月 18 日的讨论记录Shubham Saboo 将它拆成了两个层次长期存在的 Org Graph 与随任务变化的 Work GraphPreston 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 GraphWork 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 动态创建并行研究子 AgentLangGraph 的子图与持久化机制提供了隔离状态、检查点和暂停恢复Google 的 A2A处理 Agent 发现与通信Preston Holmes 参与创建的实验性项目 Scion则提供容器、工作区和凭据隔离。这些项目分别覆盖图运行所需的部分原语但还不存在一套公认的「双图标准」。八、什么时候该从 Loop 升级到 GraphGraph 的复杂度很高默认方案仍然应该是 Loop。出现以下信号时再考虑升级信号Loop 的典型问题Graph 提供的能力任务可拆成多个独立分支单线程执行过慢Fan-out / Fan-in不同步骤需要不同权限单 Agent 权限过大角色隔离与最小权限任务需要跨天暂停和恢复上下文难以长期保存检查点与持久状态某一步失败不应推倒重来只能重启整个循环节点级重试与补偿过程包含多人审批人工介入被当成异常将人建模为正式节点新证据会改变任务结构原计划只能在 Prompt 中隐式调整可记录的运行时图改写需要解释费用与失败来源只有一条长对话记录节点级成本与轨迹观测如果任务只有一个领域、一个 Agent、一个明确停止条件把它改造成多 Agent Graph 往往只会增加延迟、成本和调试难度。多个 Agent 也不自动等于 Graph Engineering没有状态契约、故障边界和治理策略的 Agent 群只是一组并发运行的循环。九、Graph Engineering 最常见的七个误区把所有节点都做成 Agent。确定性校验、格式转换和权限判断更适合普通代码。把所有边都交给模型决定。能用规则表达的转换应优先使用确定性逻辑。让所有 Agent 共享完整上下文。这会放大成本、隐私风险和错误传播边只应传递下游必需的信息。只设计成功路径。超时、重复执行、部分成功、节点取消和人工拒绝才是生产故障的主要来源。把 Work Graph 当成 Org Graph。每次任务都重新发明角色会丢失领域记忆也会让权限无法治理。允许动态创建 Agent却没有继承规则。新节点继承什么模型、记忆、预算和凭据必须由策略明确规定。只看最终输出不看执行轨迹。结果偶然正确不代表图的结构可靠。十、从 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 日的行业讨论口径不代表已经形成统一标准。
从 Loop 到 Graph：生产级多 Agent 系统为什么要同时运行两张图
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 RuntimeLoop Engineering一个 Agent 的连续行为如何反复执行何时停止会话与进度记录Graph Engineering多个执行单元的组织结构谁负责什么工作如何路由与恢复结构化图状态与检查点Josh C. Simmons 对这层关系的概括很准确Loop 被「降级」为节点内部的执行机制而不是被淘汰。一个研究 Agent 节点仍然可以运行「搜索—阅读—验证—补充搜索」循环Graph 负责决定何时调用它、给它什么输入、结果交给谁以及失败后如何处理。这也是图相对循环的核心变化控制流不再全部藏在模型的上下文里而是被提升为外部、显式、可检查的结构。2026 年 4 月的立场论文 From Agent Loops to Structured GraphsarXiv:2604.11378从调度器视角给出了相似判断普通 Agent Loop 同一时刻只有一个可执行单元而显式图把依赖和恢复策略从上下文中提取出来。该论文提出的是理论框架与实验方案不是已经完成实证验证的生产实现。三、生产系统里其实有两张图单独说「Agent Graph」仍然过于含混。据 2026 年 7 月 18 日的讨论记录Shubham Saboo 将它拆成了两个层次长期存在的 Org Graph 与随任务变化的 Work GraphPreston 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 GraphWork 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 动态创建并行研究子 AgentLangGraph 的子图与持久化机制提供了隔离状态、检查点和暂停恢复Google 的 A2A处理 Agent 发现与通信Preston Holmes 参与创建的实验性项目 Scion则提供容器、工作区和凭据隔离。这些项目分别覆盖图运行所需的部分原语但还不存在一套公认的「双图标准」。八、什么时候该从 Loop 升级到 GraphGraph 的复杂度很高默认方案仍然应该是 Loop。出现以下信号时再考虑升级信号Loop 的典型问题Graph 提供的能力任务可拆成多个独立分支单线程执行过慢Fan-out / Fan-in不同步骤需要不同权限单 Agent 权限过大角色隔离与最小权限任务需要跨天暂停和恢复上下文难以长期保存检查点与持久状态某一步失败不应推倒重来只能重启整个循环节点级重试与补偿过程包含多人审批人工介入被当成异常将人建模为正式节点新证据会改变任务结构原计划只能在 Prompt 中隐式调整可记录的运行时图改写需要解释费用与失败来源只有一条长对话记录节点级成本与轨迹观测如果任务只有一个领域、一个 Agent、一个明确停止条件把它改造成多 Agent Graph 往往只会增加延迟、成本和调试难度。多个 Agent 也不自动等于 Graph Engineering没有状态契约、故障边界和治理策略的 Agent 群只是一组并发运行的循环。九、Graph Engineering 最常见的七个误区把所有节点都做成 Agent。确定性校验、格式转换和权限判断更适合普通代码。把所有边都交给模型决定。能用规则表达的转换应优先使用确定性逻辑。让所有 Agent 共享完整上下文。这会放大成本、隐私风险和错误传播边只应传递下游必需的信息。只设计成功路径。超时、重复执行、部分成功、节点取消和人工拒绝才是生产故障的主要来源。把 Work Graph 当成 Org Graph。每次任务都重新发明角色会丢失领域记忆也会让权限无法治理。允许动态创建 Agent却没有继承规则。新节点继承什么模型、记忆、预算和凭据必须由策略明确规定。只看最终输出不看执行轨迹。结果偶然正确不代表图的结构可靠。十、从 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 日的行业讨论口径不代表已经形成统一标准。
