Agent 系列（十）：什么是 Graph Engineering?

2026 年 7 月 18 日，Peter Steinberger 在 X 上提出 “是否已经从 Loop 转向 Graph”，随后引发了技术社区的大量讨论。

参考前面的几个 X Engineering 的火热程度，再结合 Graph 这个词本身的自带流量，所以很快的就在社区传播开了。Graph 本身就不陌生，它描述的工程对象其实已经存在多年，包括 工作流编排、状态机、数据流图、Actor Model、事件溯源、持久化执行以及多智能体协作。

注：本文中的 Graph 指智能体执行图：节点表示模型、工具、规则、人工审批等执行单元，边表示控制转移、数据传递和依赖关系。它与知识图谱、GraphRAG 属于不同技术层次。

Graph Engineering 可以定义为：

将模型推理、工具调用、确定性程序、验证器、人工决策和子智能体组织为显式执行图，并围绕图状态、节点契约、调度、持久化、并发、恢复、权限和评估建立完整运行时。

其核心目标是把智能体系统中隐式存在的执行过程，转换成可声明、可检查、可恢复、可度量和可治理的程序结构。

一、从 Prompt 到 Graph 的控制范围扩展

Prompt Engineering → 
Context Engineering → 
Harness Engineering → 
Loop Engineering → 
Graph Engineering

这条链路实际上就是控制范围的持续扩展，每个阶段都保留前一阶段的能力，同时解决更外层的工程问题。前面关于从 Prompt 到 Loop 已经有过介绍，这里不再赘述，一句话总结就是： Prompt 管理模型指令，Context 管理模型输入，Harness 管理外部能力，Loop 管理单个过程，Graph 管理多个过程之间的拓扑关系。

二、单一 Agent Loop 无法稳定表达复杂任务

单一 Agent Loop 的控制逻辑主要保存在模型上下文中，模型根据历史消息判断当前任务阶段，并决定下一步执行什么动作，任务规模扩大后，控制流、任务状态和角色职责会同时进入同一段上下文中，系统会逐渐退化为依赖模型来对历史文本进行临时解释。

所以这里就会存在几个问题：

• • 1、控制流隐式： 任务步骤和依赖关系主要依赖提示词约束，顺序、分支、汇合和结束条件缺少明确结构。
• • 2、状态混在消息中： 进度、结果、错误和剩余任务都保存在对话历史里，历史越长，状态识别和一致性维护越困难。
• • 3、职责边界模糊： 规划、执行和验证共享同一上下文，缺少稳定的输入输出约束，阶段之间容易相互干扰。
• • 4、并行与汇合困难： 独立子任务通常被串行处理，即使并发执行，也需要额外判断分支完成情况和结果合并方式。
• • 5、局部恢复能力弱： 中途失败后难以从明确位置继续，重复执行还可能导致文件修改、数据写入和外部通知被再次触发。

这五点本质上指向的是同一个大的问题域：任务流程和任务状态没有成为独立对象。 从这个角度来看，Graph Engineering 解决的就是将流程定义从模型上下文中提取出来，并通过节点和边描述执行关系和通过状态保存已经确认的任务事实的问题。

三、Graph Engineering 的核心抽象

一个执行图由 节点、边、状态和运行时 组成，形式上可以表示为：

其中，(V) 是节点集合，(E) 是边集合，(S) 是当前状态，() 决定状态变化后进入哪些节点，() 负责合并节点产生的状态更新，() 判断任务是否结束。

2

1. Node 表示执行职责

Node 是执行图中的基本计算单元。模型推理、工具调用、规则计算、质量检查、人工确认和子任务都可以被表示为节点。

节点需要具有清晰的输入和输出。

• • 研究节点读取研究主题和任务分工，输出资料和结论；
• • 写作节点读取文章结构和研究结论，输出草稿；
• • 验证节点读取草稿和评价标准，输出问题列表、评分和后续建议。

节点边界会直接影响系统的可理解性和恢复能力；对于需要独立重试、使用不同模型、访问不同工具、拥有不同权限或需要单独评价的逻辑，通常适合拆分为独立节点；连续且确定的数据处理可以保留在同一节点中，避免图结构过度碎片化；节点内部仍然可以存在局部循环，父图只关心节点最终产生的状态结果。

2. Edge 表示依赖和控制转移

Edge 描述节点之间的执行关系。 固定边用于表达确定顺序，条件边根据状态选择后续节点，扇出边启动多个并行任务，汇合边等待多个上游结果，回边形成局部循环，中断边让任务等待人工或外部事件。

边承担的是控制契约，它需要说明当前节点完成后是否可以继续、后续节点依赖哪些条件，以及需要传递哪些状态；模型可以参与路由判断，例如判断报告需要继续补充资料还是进入写作阶段。从模型输出角度，仍然需要映射到有限路径集合，这样才能使运行时能够校验路由结果，另外语义判断可以由模型来完成，执行范围由图结构限定。

3. State 保存执行事实

State 保存系统当前已经确认的事实，包括 任务目标、执行计划、中间结果、节点进度、错误信息、评价结果和终止原因。

聊天历史记录模型和工具交换过哪些内容，图状态记录后续执行应该依据哪些事实。两者可以同时存在，但图运行不应依赖模型从完整对话中反复提取任务进度。节点每次执行只返回局部状态变化，运行时将其合并到全局状态中：

不同字段需要采用不同的合并语义，怎么理解呢，一般情况下任务阶段可以直接覆盖，并行节点同时更新状态时，合并规则需要保证执行顺序变化不会导致结果失控。状态结构的主要作用就是保证任务进度从自然语言描述转化为系统能够直接计算的数据，也让节点之间形成明确的数据接口。

4. Runtime 推动图持续运行

图定义描述节点和关系，Runtime 负责计算当前哪些节点可以执行，包括调度节点运行和保存运行进度，并根据边条件激活后续节点。现在主流的能够支撑 graph 的框架或者组件，一般都有自己的私有的 DAG 的描述文件协议，当然也包括对应的解析引擎和执行引擎。我们在实践的过程中，可以通过对协议文件的转换来实现不同 graph 的适配。

四、执行图如何运行

执行图的运行过程可以概括为五个步骤： 找到当前可以执行的节点，执行这些节点，合并节点结果，根据条件选择下一条路径，判断任务是否结束。任务从入口节点开始。运行时先检查节点依赖是否满足，再决定哪些节点可以执行。前后存在依赖的节点按顺序运行，相互独立的节点可以并行运行。多个分支完成后，由汇合节点统一整理结果，再进入下一阶段。节点只返回自己产生的结果和状态变化。例如研究节点追加研究结论，验证节点更新评分和问题，工具节点记录调用结果。

运行时负责把这些局部变化合并到全局状态中：

其中，(S_t) 是当前状态，() 是节点产生的状态变化，() 是合并规则。

节点完成后，图根据当前状态选择后续路径。结果满足要求时进入下一阶段，结果不足时返回前面的节点继续修改，出现不可恢复错误时结束任务。分支和循环因此成为图结构的一部分，不需要模型从长对话中临时判断整个流程。为了支持长时间运行，系统会在关键节点完成后保存检查点。进程中断后，可以从最近的检查点继续执行。人工审批和外部回调也可以作为中断节点，任务暂停时保存状态，收到输入后恢复运行。

Graph Engineering 的这些能力主要来自状态机、工作流、数据流图和事件溯源。状态机提供状态转移，工作流提供长任务和中断恢复，数据流图提供并行和汇合，事件溯源保存执行历史。语言模型负责节点中的语义判断，图运行时负责控制执行顺序和状态变化。

五、总结

从 Prompt、Context、Harness 到 Loop，控制对象逐步从模型指令扩展到推理输入、外部能力和连续执行过程；Graph 继续扩展这一范围，用于描述多个执行过程之间的关系；Graph Engineering 关注的是智能体系统的控制面，模型节点负责概率性的语义推理，工具节点连接外部环境，确定性节点处理规则和计算，验证节点判断执行结果，图状态保存已经发生的事实，边控制后续路径，运行时推动整个过程持续演化。它们之间的关系可以表示为：

多个节点通过状态和边连接：

因此，Prompt、Context、Harness 和 Loop 可以看作节点内部的能力组成，Graph 负责组织节点之间的系统关系。

从底层技术关系看：

状态机提供状态和转移语义，工作流编排提供顺序、分支和中断，数据流模型提供并行和汇合，智能体运行时提供模型和工具调用，持久化执行提供检查点和恢复。

总的来说，Graph Engineering 最终解决的是复杂智能体程序的结构表达问题。它把模型上下文中的隐式计划展开成节点，把模型临时决定的执行顺序展开成边，把对话历史中的任务进度转换成状态，把一次性运行过程转换成可以暂停、恢复和局部重算的执行图。

当智能体只包含一个简单循环时，Graph 的价值是有限的；当系统开始包含多个角色、多个循环、并行任务、验证反馈和长期状态时，Graph 会成为描述和控制这类系统的基础表达形态。