Graph Engineering是将AI组件组织为可执行图的工程实践,并未取代此前的Loop等范式,只是新增层级解决复杂任务的协调问题,其能否火过8月存疑。 ## **1. Graph Engineering本质是可执行状态机** 将各类AI组件、人工节点设置为图结构的节点,边规定执行逻辑,核心目标仍是实现AI系统稳定工作,是对原有范式的堆叠而非取代。 ## **2. Graph Engineering解决复杂任务的协调问题** 可拆分分工、梳理依赖关系、明确控制逻辑、统一管理共享状态、隔离局部失败、纳入治理规则,适配真实工作的非单一顺序结构。 ## **3. Loop是Graph内部的基础执行单元** Loop解决单个智能体的持续工作问题,适合强顺序任务;Graph解决多主体的组织协调问题,支持并行工作。Google测试显示,并行任务用Graph结构表现可提升80.9%,顺序任务使用Graph反而会下降表现。 ## **4. Graph Engineering面向概率性行动者管理** 本质是将先验结构施加到AI系统,约束LLM的自主判断,核心需要解决节点契约、权限隔离、并发冲突等工程问题,是传统工作流管理针对AI特性的升级。
查了下Graph Engineering的族谱
2026-08-04 16:03

查了下Graph Engineering的族谱

本文来自微信公众号: 碳基智 ,作者:碳基智


碳基智2026年08月04日预计5分钟


AI造词仙人们又闲不住了,这次整的新词叫Graph Engineering,然后网上铺天盖地又是一波Loop Engineering is Dead,Long Live the Graph Engineering的营销。


不对,应该是Short Live,我很怀疑Graph Engineering能不能火过8月。


老读者都知道,我这人最喜欢做些剥皮拆骨的事,那么今天就跟大家一起,聊聊Graph Engineering这玩意儿,本质到底是啥。


1


照惯例还是来个名次解释,看看AI造词仙人们又憋了什么屁。


Graph Engineering是指:把一个或多个智能体、模型调用、确定性代码、工具、验证器和人工审批点,组织成可执行图的工程实践。


其中,节点负责工作,边规定接下来允许发生什么,状态保存系统已经知道和做过的事,运行时负责调度、持久化、重试、暂停与恢复。



LangChain团队在一篇博文中讲得比较清楚:


节点可以是确定性代码、一次模型调用、工具调用,也可以是内部自带循环的完整Agent;边可以固定,也可以依据节点输出、共享状态或外部信号动态决定。它本质上可以被看成状态机。



那用说人话的方式讲,它想干嘛呢?它想实现的,还是让AI系统稳定工作,这也是Prompt、Context、Harness、Loop们一直想实现的结果。


这些所谓的几次范式迭代,都不是后者取代前者的关系,是一层一层往上堆叠,后者解决前者解决不了的问题,带来新的问题,需要更新的所谓范式去解决。


属实是AI圈子里的“面多了加水,水多了加面”了。


2


单次Prompt解决表达,单个Loop解决迭代,Graph解决协调。


用户输入一段Prompt,模型输出一套结果。复杂一点以后,系统给模型接上工具、记忆和环境,这层就是Harness。再往前一步,Agent进入“观察、计划、行动、检查”的循环,直到完成或触发停止条件。


单循环在任务边界清楚时很好用,但现实工作场景往往是串联的,把所有事情塞进同一段对话,状态会变长,职责会混在一起,局部失败也很难局部恢复。Graph Engineering干的事就是把这些隐含关系外置成结构。


它主要处理六类问题:


  1. 分工


    :不同节点只拿完成本职工作所需的上下文和工具。


  2. 依赖


    :哪些任务能并行,哪些必须等待前置结果。


  3. 控制


    :模型在哪些地方可以自由判断,哪些路径由代码强制。


  4. 状态


    :事实、产物、预算和执行进度放进可检查的共享状态,不靠聊天记录硬撑。


  5. 失败隔离


    :某个分支失败,可以重试或回滚该分支,不必让整场任务从头再来。


  6. 治理


    :权限、审批、证据、日志和责任归属进入图结构。


到这里,你有没有发现一个现象:


虽然Graph是造词仙人们整的新活儿,但它背后的一个趋势其实已经呼之欲出:AI Agent已经开始深入到核心工作和组织结构里了,现在的AI工程发展也越来越往组织设计的方向走了。


我在想,下一套Engineering“范式”,没准就是彼得德鲁克那套了。


3


Graph跟它的上一代范式Loop之间的关系是怎样的?


Loop解决“如何让单个智能体持续工作”,Graph解决“如何把多个智能体、工具、人组织成一个可观测、可恢复、可扩展的系统”。


聪明的你肯定想问了,Agent为什么会从Loop走到Graph?



因为Loop天生只有一条主线。一个Agent观察、行动、检查、再行动,特别适合写代码、解题这类强顺序任务。现实工作却经常只有部分步骤需要排队:研究可以分头搜索,代码修改和文档准备可以并行,发布前必须等待测试与审批。把这些工作全塞进一条Loop,系统只能依次处理,所有过程挤进同一份上下文,任何局部失败还可能拖着整条轨迹重跑。


Graph则提供了更贴合这种任务结构的表达。能独立进行的工作从节点处分叉,需要等待的结果在汇合点重聚,验证失败沿环路返回,高风险动作在人工节点暂停。每个节点内部照样可以运行自己的Loop。Loop负责把一件事反复做好,Graph负责安排多件事之间的依赖、交接和权力。


这里是存在明确边界的。


Google Research测试了180种Agent配置后发现,可并行的金融分析任务使用集中式多Agent,表现比单Agent提高80.9%;强顺序规划任务里,多Agent反而下降39%到70%。


只有当任务已经分叉,Graph才能释放并行和隔离价值。任务仍是一条连续推理链时,你用Graph就纯粹是画蛇添足。



说到底,Loop无非是从整套系统里的唯一结构,变成Graph中可以组合、隔离和恢复的基本单元。


4


最后再总结几个核心判断:


Graph是想把自由放进笼子里,让构建者把对系统如何工作的先验结构施加到更受约束的路径上,在需要时减少对LLM自身判断的依赖。


流程图升级成了可执行的组织章程。Graph Engineering要回答:节点输入输出的契约是什么,权限如何隔离,状态由谁更新,并发冲突怎么解决,重试会不会重复消耗,路由错误怎样被发现,版本升级中的任务由谁接管等等……


真正的新东西,是节点变成了概率性解释器。过去的节点执行指令。今天的Agent节点解释意图。确定性工作流管理机器步骤,Agent Graph管理概率性行动者。


学废了吗朋友们?

AI创投日报频道: 前沿科技
本内容来源于网络 原文链接,观点仅代表作者本人,不代表虎嗅立场。
如涉及版权问题请联系 hezuo@huxiu.com,我们将及时核实并处理。
正在改变与想要改变世界的人,都在 虎嗅APP