想系统看看Agent的Graph Engineering，可以从这篇综述开始｜最新

这两年Agent领域冒出来的Engineering越来越多。

从最早的Prompt Engineering，到Context Engineering，再到最近讨论很多的Harness Engineering、Loop Engineering，现在又开始出现一个新的词：Graph Engineering。

它并不是简单地给Agent套一层图结构。更准确地说，当Agent系统开始涉及多个任务、多个Agent、并行执行、状态共享和失败恢复以后，工程问题本身就发生了变化：以前主要考虑一个模型、一个Agent怎么把事情做好，现在开始需要考虑整个系统怎么组织起来。

这篇最新的Survey，基本就是沿着这条线展开的。研究者把Graph Engineering拆成了三个核心问题：任务怎么组织、Agent怎么协调，以及运行状态怎么管理。

从Harness到Loop，为什么现在要提Graph？

这一节只回答一件事：为什么开始讨论 Graph Engineering。因为工程对象变了。

研究者把这条线画成三步。Model Intelligence（模型智能）：预训练、后训练把能力写进参数，再用 Prompt、Context 在推理时调用出来。Individual Intelligence（个体智能）：套上 Harness、接上 Loop，成为能持续做事的单 Agent。System Intelligence（系统智能）：把各有专长的多个 Agent 组织成整体，追共同目标。对应的工程手段，随之从 Prompt / Context，走到 Harness / Loop，再走到 Graph。

图：从模型智能、个体智能到系统智能的三阶段总览，三个阶段各自对应 Prompt/Context、Harness/Loop 与 Graph Engineering。

关键在第三步，它不等于"再多放几个 Agent"。研究者反复强调：System Intelligence 不是 Agent 数量的增加。一个多 Agent 系统可以有很强的成员，却依然没有清晰的工作组织、责任边界、协调机制和一致的状态管理。

为什么单 Agent 顶不住？因为真实任务的几个要求，正好戳在单 Agent 的结构短板上：异构能力、并行、独立验证、持久状态。单 Agent 的统一上下文和单一控制循环，会把这些要求全压进一条串行轨迹：信息抢上下文容量，依赖被串行化，不同任务的进度混在一个上下文里，无法隔离并行、同步共享结果，也无法独立恢复部分进展。

论文没说 Graph 是唯一或最好的答案。它说的是：当工程对象从模型、单 Agent 转向整个 Agent 系统，"怎么组织"变成第一性问题，图结构是自然的候选载体。"新兴范式"是研究者的主张，不是行业盖章的共识。

Graph Engineering里的“Graph”到底是什么

论文并没有给出一个统一的 G=(V,E,τV,τE,…) 元模型，没有一处把节点类型、边类型一次性定义完整。

它实际把系统里不同种类的关系，分别当作不同用途的图抽象来用。如果您熟悉 typed graph（带类型的图：节点和边都带标签、各有含义），可以这样理解——这篇综述背后躺着好几张语义不同的图，各管一类关系。

研究者把它理成四张。

Task Graph（任务图）：节点是子任务或中间目标，边是先后依赖、数据依赖或逻辑关系。它回答"先做什么、再做什么、哪些可以并行"。

Workflow Graph（工作流图）：节点更具体，是一个个 operator（一次 LLM 调用、一个检索模块、一个工具、一个验证器），边是调度、协调、验证所需要的依赖。Task Graph 讲"要做什么"，Workflow Graph 讲"具体怎么算出来"。

Agent / Team Graph（Agent/团队图）：节点是 Agent、角色或任务，边是分配、委派、监督、验证、汇报关系。它回答"谁来做、谁审查谁、谁向谁汇报"。

Communication Graph（通信图）：节点是 Agent 或人类，被激活的边说明执行到某一步时，谁与谁通信、传什么信息、这个信息又怎么改变后续动作。团队图描述相对稳定的职责，通信图捕捉的是执行时临时发生的信息流。

总结成一句话：Graph Engineering 不是给 Agent 加一张图，而是把原本藏在 Prompt、上下文和代码里的系统关系，变成显式、可查询、可调度、可修改的结构。

任务、团队、状态：论文关心的三张图

上一节是"图"的通用读法。论文真正花力气组织的，是三个工程问题。记住这三个词就够：Task Organization（任务组织）、Agent Coordination（Agent 协调）、Runtime State Management（运行状态管理）。研究者用 What、Who、How 来对应。

图：Graph Engineering 总览——任务组织、Agent 协调、运行状态管理三张图耦合，共同支撑任务完成。

What：要做什么？Task Organization

复杂目标不会自己变成可执行步骤。What 这一层做的，是把大目标拆成子目标，把子目标间的依赖显式化，决定哪些能并行、哪些必须等前面完成。拆完还只是"描述性"的，下一步是 workflow 优化：把语义上的子目标编译成具体的可执行操作，LLM 调用、检索、工具、验证器，再把这条可执行结构当作优化对象去搜索、重组、评估，找到更省、更稳、更可靠的那张工作流图。这层真正的收益在于：并行、依赖、调度从"模型心里默算"变成"图上看得见的约束"，可以查、可以改、可以优化。

更重要的是，任务图不是执行前画一次就封死的。中间结果出来后，可以反过来修订剩下的任务图和子目标。这种"中间结果驱动任务图修订"，是 What 这一层正在发生的转变。

Who：谁来做？Agent Coordination

目标拆开了，下一步是匹配人和活。Who 这一层有三件事：能力建模（每个 Agent 会什么、能碰哪些资源、适合什么活）、团队组织（把选中的 Agent 排成某种分工结构：谁做、谁审查、谁监督、出问题找谁）、通信（执行时谁和谁交换信息、反馈怎么传回去）。

用一个大家都熟的组合贯穿讲：Planner、Coder、Reviewer、Tester。团队图可以是一条链，Planner 的产出喂给 Coder，Coder 的产出交给 Reviewer 和 Tester；也可以是带分支的结构，同一段需求派给多个 Coder 并行出方案，再汇聚比较。这条链、这组分支、谁监督谁、谁验证谁，就是团队图的边。评审不是走过场：写的人和验的人被显式分开，就是为了让"独立验证"成为结构，而不是同一个 Agent 既当运动员又当裁判。另外：团队拓扑不是只能预先固定，任务条件或 Agent 表现变化时，系统也可以在运行时重组角色、调整连接。不过这是"这次怎么走"的运行时重组，与第四节讲的、把经验沉淀为跨次执行持久结构的演化不是一回事。

图：Agent Coordination 的三个子问题：能力映射、团队结构（链式与扇出/扇入）、通信流；团队结构示例为 Planner 派给多个 Coder、再汇聚给 Reviewer。

How：现在发生了什么？Runtime State Management

What 和 Who 规划的是"该发生什么"，但系统真正跑起来之后，还要回答"现在到底什么状态"。这就是 How，也是论文里最容易被忽略、其实最硬核的一块：Runtime State Management。

它要回答一连串很具体的问题：哪些任务完成了？哪些结果可信？谁在什么时候改过某个状态？错误最早从哪个点冒出来？出错后哪些结果还能保留、哪些要作废？怎么从 checkpoint 恢复而不必整个重跑？论文把这三件事对应为 State Recording（状态记录）、Fault Localization（故障定位）、Failure Recovery（失败恢复）。

它比听起来难得多。分布式执行里，不同 Agent 各自看到一部分、各自更新一部分，没有人拥有全貌。没有一份一致、可追溯、带来源和版本的运行记录，系统就无法可靠回答"现在到哪了"，错误定位不到，有效进度也找不回来。所以论文强调的状态管理，不是"存个变量"：要把提议、验证、提交分开（有些修改要先过 schema、权限、不变量的校验才能正式生效）；要按身份和时间控制共享状态的可见范围；要把提交历史做成可回放、可分叉的记录。

故障定位还有一层隐蔽的难：一个早期的小错误，可能被下游一路传播，直到很晚才在别处爆出来，可见故障和真正原因往往隔着好几步。研究者特别提醒，定位不等于证明因果，时间先后和结构连接都不是因果，系统要把"原因"当成假设，拿保留的证据逐个检验，而不是顺着依赖链一路把责任推下去。

讲到这，三张图的中轴就出来了：任务图解决"做什么"，Agent 图解决"谁来做"，状态图解决"现在发生了什么"。三张图是耦合的——任务结构一变，能力需求就变；谁来做一变，通信和权限就变；运行中发现的证据，又会反过来触发对前两张图的修订。

图怎么演化

三张图如果只是画好放着，就是静态配置。真正值得注意的，是论文把"图结构本身"当优化对象——System Evolution（系统演化）。

演化的动作包括：修改任务图（拆法不好就换拆法）、修改团队拓扑（角色不合适就换人、换汇报线）、修改通信边（低价值的边删掉、该加的边加上）、把成败经验写回结构，以及配套的 version（版本）、rollback（回滚）、replay（重放）——结构改动要能记录、能验证、能撤销。

这里有一条论文划得很清楚的边界：动态路由不等于系统演化。

运行时决定下一步走哪条路——条件边、临时派工、失败后换个分支——改变的是"这一次执行"的轨迹，没有改变"下一次执行"的组织结构。系统演化要求的是：把执行证据转化成持久的、可复用的结构改动，跨次执行依然成立。这是两个层级。论文的判断是：前者已经很常见，后者仍然很少见。所以别把运行时 replanning 混写成跨运行持久演化——前者是"这次绕路"，后者是"把地图改了"。

Graph之后是Ontology

图把关系显式化了，但显式不等于大家都懂。一个尖锐的问题：图里写着 Reviewer -- verifies --> Result（Reviewer 验证 Result），可"验证"这条边到底意味着什么？Reviewer 是什么？什么叫"验证完成"？什么证据算有效？谁有权改 Result？verify（验证）和 approve（批准）是不是一回事？

这些疑问背后是同一个洞：有结构，不等于各组件对结构含义的理解一致。两个 Agent 可以对"任务完成""证据充分""状态有效"各执一词，同一张图在它们眼里是不同的东西。

Ontology Engineering 补的就是这个洞。Ontology 提供共享的、机器可解释的实体、关系、约束定义——哪些实体存在、关系是什么意思、哪些约束必须成立、能推出什么结论。它不往图里塞更多节点，而是给图的每个元素一个全系统一致的解释。

两者的区别可以自然地说成：Graph 回答"谁和谁有什么关系"，Ontology 进一步回答"这些东西到底是什么，这种关系究竟意味着什么"。论文把 Ontology 定位成 Graph Engineering 通往更完整 System Intelligence 的语义基础，而不是"Graph 的尽头就是 Ontology"那种确定论——后者是我想替您避开的过度解读。论文的措辞是：Ontology 主要补共享语义，也顺带为目标、角色、状态、证据、约束提供一致定义，但不是系统级问题的一揽子解。

写在最后

如果只是做一个简单Agent，Graph Engineering可能并没有那么必要。一个模型、几个工具、一条比较固定的Loop，很多关系直接写在代码里就够了。真正到了多个Agent并行、任务不断拆分、状态长期保存、失败以后需要局部恢复的时候，结构才开始从“实现细节”变成“系统能力的一部分”。Graph不是因为看起来更高级才重要，而是因为系统复杂到一定程度以后，隐式关系开始变得难以管理。到了这个阶段，任务依赖、职责分配、通信路径、运行状态甚至系统演化本身，都可能需要成为可以单独观察、修改和优化的对象。Graph Engineering至少给这批问题起了一个可以继续讨论的名字。

文章来自于"AI修猫Prompt"，作者 "AI修猫Prompt"。