OceanBase 聊聊Graph Engineering ——别让一个Agent 既当运动员又

OceanBase数据库官方博客

350人浏览 · 2026-08-07 10:36:16

OceanBase数据库官方博客 · 2026-08-07 10:36:16 发布

如果生产结果、检查结果和判断方向都由同一个 Loop 完成，它很容易同时成为运动员、裁判和记分员。
Graph Engineering 要设计的，就是多个 Loop 之间，如何分工、交接、纠偏和停手。

最近几天，突然到处都在聊 Graph Engineering。有人把它说成多 Agent 工作流，有人强调运行时生成任务，也有人讨论“让 Loop 检查 Loop”。

这个词虽然暂时还没有公认的定义，但有一点可以先确定：Loop 没有被 Graph 取代。当一个 Loop 装不下执行、检查和方向判断时，工程问题才会从 Loop 内部移到多个 Loop 之间。

Graph Engineering 是怎么被聊起来的？

起点是一句很短的话。7 月 18 日，OpenClaw 作者 Peter Steinberger 问：“我们还在谈 Loop，还是已经转向 Graph 了？”

这条只有九个英文单词的推文[1]，已经获得了近 300 万次浏览。

几个小时后，Hamel Husain 搞了个标题党：《Loop Engineering Is Dead. Enter Graph Engineering.》[2]。内容只有一张动图。

他后来在回复里直接说：“Nobody knows what it is.”[3]

一个还没有公认定义的词，先拥有了流量、阵营、架构图和教程。看来 AI Coding 圈现在和娱乐圈也大差不差……

A 赛场分权方形版 v2

欢迎大家关注 OceanBase 社区公众号 “老纪的技术唠嗑局”。在这里，我们会持续为大家更新与 #AI 和 #Data 相关的技术内容~

开篇先聊两句 Loop Engineering

为什么之前不单独在公众号上写篇文章去聊 Loop Engineering？

首先，因为在 Loop Engineering 这个概念突然爆火之前，我们已经聊过 Harness 了（详见：《深度“解剖”AI Agent Harness》）。

在上面这篇文章里，LangChain 讲得也很直接：Agent = 模型 + Harness，“既然模型不是你造的，那你做的就都是 Harness”。

因此，Harness 工程就已经包含了：

提示词工程（Prompt Engineering）：单参数函数。研究的是如何写一个高质量的提示词，让模型输出更好的结果。
上下文工程（Context Engineering）：多参数函数。研究的是给模型看到哪些上下文信息，让模型输出更好的结果。
循环工程（Loop Engineering）：带状态反馈的循环程序。研究的是如何让模型能够自动地长时间持续运行，且更好地完成任务。
（还有很多其他的组件，这里不再一一列举了）

其次，Loop 一直都是 Agent 的基础，根本不是新鲜的概念。AI Agent 的运行模式是：感知 → 推理 → 行动 → 观察 → 继续推理（也就是 ReAct 模式，Reasoning + Acting）。换言之，Agent 和 ChatBot 最大的区别，就是 Agent 是一个具有循环（Loop）能力的系统，它的运行模式就是一个循环迭代的过程，而非传统 AI 对话的单次响应模式。

如果非要掰扯一下 Loop Engineering 和 ReAct 有什么不同，那我的理解是：Loop Engineering 无非是在 ReAct 的外面再多套一层 Loop，也就是父循环套子循环，减少人工干预，让 Agent 自己感知环境变化，持续执行，直到完成目标。其实，不去严格区分 Loop Engineering 和 ReAct，问题也不大。

前一阵儿大家讨论的更多的，还是说不同的 Loop 形式分别适合怎样的场景，例如：回合制（turn-based）、目标制（goal-based）、定时制（time-based）、主动制（proactive）。不过这些不是这篇文章的重点，也不再继续深入去聊，只推荐一篇 Akshay Pachaar 的文章：《The four types of agent loops》[4]。

AI 社区正在讨论的 Graph Engineering 是什么？

先说说我自己的理解

按照上面的规律，如果把 Loop Engineering 类比成：带状态反馈的循环程序。那我会把 Graph Engineering 理解成：多个程序节点组成的分布式程序。

实际场景中可能需要多个 Agent 并行在跑，而且互相之间有所依赖，并非 while 循环的结构这么简单，对应计算机里面的概念就是图，Graph。

这个 Graph 是个有向图（Directed Graph），某个 Agent 跑完可能结果就要给到另一个 Agent 继续处理，因此需要有向。

注意：这不是 DAG（有向无环图），因为实际场景可能是有环的，某个节点处理完了可能会回到原来某个过去的节点继续。
其实，这更像是 FSM（有限状态机），它也是一种图，让模型在一个图中的各种状态间切换，持续执行，直到到达目标。

最近工作中有个大任务，思来想去其实就是构建一个 FSM，前面的 Agent 处理完成给到后面的 Agent，但是后面处理完发现有问题可能又回到前面的 Agent。

所以，Graph Engineering 和 Loop Engineering 一样，也不算是全新概念，只是目前大家的工程化阶段纷纷走到这里了，需要用图来描述和解决真实场景里面的问题。

主流观点是怎样的？

如果把高互动讨论放在一起看，大致有这些共识：

Loop 仍然存在。 一个 Agent 依然需要根据结果继续行动、验证和修正。这始终都是 Agent 的基础。
Graph 组织多个执行单元。 它描述谁先做、谁能并行、检查失败后退回哪里，以及什么时候需要人介入。
节点不一定都是 Agent。 它也可以是工具、确定性程序、验证器或人；每个 Agent 节点内部仍可能运行自己的 Loop。
检查关口和失败路径比方框数量更重要。 如果所有箭头都只指向“继续”，那只是一条画得更复杂的流水线。

Graph Engineering 社区讨论中的主要共识

LangGraph、AutoGen 以及传统工作流系统早就在处理节点、状态、分支和重试。这轮讨论的变化来自 Agent 节点越来越自主，也越来越不确定：它可能临时改变计划、调用工具修改真实环境，甚至在运行过程中继续拆任务。

不过有些问题依然没有结论

社区目前围绕几组问题继续分化：

其中最值得继续追问的是第三行。

如果 Graph 只是“研究 Agent 做完交给写作 Agent”，它很像传统 Workflow 换成了更聪明的节点。但讨论里已经出现另一条路线：一个 Agent 实现，一个独立 Agent 评审，另一个主动寻找反例，还有一个重新检查最初的目标是否已经偏了。它们不只是接力，还会相互检查、挑战，必要时阻断彼此。“You need loops watching loops”[5] 说的正是这一层。

多个 Loop 的编排已经有大量框架和实践，让一个 Loop 检查、校准甚至叫停另一个 Loop，还没有统一做法。后者决定了 Graph 最后只是一张协作图，还是一套能够纠偏的系统。

如何理解 Graph Engineering？

还是要先聊 Loop：执行者怎么根据反馈来运行

Loop 不只是代码里的 while。一个执行者看到结果后，会决定下一步、采取行动、验证，再带着新信息继续调整，这就是 Loop。

它解决的是一个很具体的问题：一个执行者怎样持续把事情往前推。 目标、上下文、工具、验证方法、退出条件和人工确认，都是这个循环的一部分。

单个 Loop 简单、灵活、反应快。问题也来自这里：如果生产结果、检查结果和判断方向都由同一个 Loop 完成，它很容易同时成为运动员、裁判和记分员。

执行、检查、定方向，不能都塞进一个 Loop

当一个 Loop 已经装不下所有责任时，就需要拆开：有人负责把事做出来，有人独立检查，还有人隔一段时间重新判断方向。

做事循环 关心怎么把眼前工作往前推，例如搜索、写代码、生成内容和修复问题。
检查循环 不继续替前者做事，而是用测试、约束和反例判断有没有做对。
方向循环 看得更慢、更远：相同问题为什么反复出现？成本是否值得？用户是否真的接受？最初的目标是否还合理？

这三种循环不一定对应三个 Agent，也不必每一步都同时运行。它们强调的是三种责任：前进、纠错、重新定向。

这里可以把 Loop 看成能够根据反馈继续调整的工作单元，把 Graph 看成这些工作单元之间的分工、交接、检查和控制关系。

多个 Loop 如何配合：交接清楚、检查有效、必要时停手

如果把一个 Loop 看成一个会自己找路的执行者，Graph 关心的就不是“工位怎么排”，而是谁把什么交给谁，谁来验收，发现不对能不能退回，方向错了又由谁喊停。

设计失败路径时，还要把退回给谁、允许重试几次、什么时候升级给人、已经消耗多少预算写清楚。节点一旦能调用工具或修改真实环境，权限也要跟着角色和阶段收紧，不能让“负责检查”的节点顺手改掉自己正在检查的结果。

例如，实现 Loop 交出代码和测试证据；检查 Loop 不看它如何解释自己，而是直接运行测试、核对约束、寻找反例。检查失败后，工作真的被退回；如果发现最初目标就有问题，则交给方向 Loop 或人重新判断。只有检查能够改变后续路径，它才不是普通的下一步。

传统工作流主要决定下一步运行哪个步骤；Graph Engineering 面对的节点可能会自己找路、改计划、调用工具甚至修改真实环境，因此还必须决定谁有权作判断、交接什么证据、谁能否决，以及什么时候回到人。

Graph 可以怎样变化：外层先定边界，内部按需调整

社区里既有提前画好的固定路线，也有 Agent 在运行时临时拆出的任务图，还有根据任务难度增删角色的设想。现实里更可能这样：权限、验收和几个必须停下来的位置先定好；至于这次到底拆出几个任务、走哪条支路，可以边做边调。

权限、验收、预算和人工闸口构成相对稳定的外层；本次任务怎样拆、是否并行、何时增加检查，可以在边界内按需调整。

有些人把运行中临时形成的任务和依赖叫作 Work Graph。这个词可以帮助理解，但目前不是统一术语，更不是已经得到验证的结论；Asana 也早已把 Work Graph® 用于另一套工作数据模型。

换成程序结构看，可以借状态机帮助理解

换个程序员更熟悉的角度，这几个概念可以串成一条线：Prompt Engineering 像只接收提示词的单参数函数，Context Engineering 像拿到多组上下文参数的函数，Harness Engineering 再把工具、权限和运行环境接进来；Loop Engineering 让程序读取状态和反馈，持续调整。

到了 Graph Engineering，多个带状态的执行节点被连成一张图，任务可以分支、汇合、回退，也可以在必要时停下来。

如果检查失败后会退回、重新规划，或者再次进入已经跑过的节点，路径里就可能出现环。此时可以借有限状态机（FSM）来理解：系统根据结果在不同状态之间切换，直到满足退出条件。

这只是理解程序控制关系的一种类比，不能拿来给 Graph Engineering 下技术定义。图论和状态机都不是新东西，变化来自 Agent 节点本身：它们开始自己拆任务、改计划、调用工具，还会修改真实环境。过去用在工作流和分布式系统里的控制方法，现在得重新拿出来处理这些更自主、也更不确定的节点。

什么时候值得用 Graph：先看任务是否真的需要

Graph 也不是 Agent 越多越好。它更适合这样的任务：可以拆成相对独立的部分，不同部分需要不同信息、工具或权限，中间结果能够单独检查，失败后也希望只重做局部。

如果任务很小、每一步严格依赖上一步，所有 Agent 又频繁修改同一份内容，一个清楚的 Loop 往往更好。Anthropic 的多 Agent Research 系统[6] 适合广泛搜索和并行探索，但其官方工程文章也指出，多 Agent 系统的 token 使用量约为普通聊天的 15 倍；Google Research、Google DeepMind 与 MIT 的实验[7] 则发现，多 Agent 在可并行任务上可能提升，在严格顺序任务上反而可能下降。

再看到一张 Graph，可以先问三个问题：

它比一个 Loop 多解决了什么关系？
检查结果能不能真的退回、换路或叫停？
增加的协调成本，是否小于它带来的独立判断和局部恢复能力？

从一个清楚的 Loop 开始。只有任务能够拆开、中间结果能够单独验收，而且确实需要不同信息、工具或权限时，Graph 才更可能带来净收益。

小结：Loop 没死

Graph Engineering 还没有公认定义，也不必急着给它划边界。

Loop 继续负责让局部工作前进；当执行、检查和方向判断需要拆开时，Graph 才开始变的有意义。

真正需要设计的是关系能否生效：交接是否带着成果和证据，检查能否改变后续路径，方向错误时谁来重新判断。

做不到这些，Graph 只是一张更复杂、更昂贵的流程图；做得到，工程问题就从“一个 Agent 怎样反复做事”变成了“多个 Loop 怎样协作，又怎样避免一起走偏”。

参考资料[1]

推文: https://x.com/steipete/status/2078277297791189132

[2]

《Loop Engineering Is Dead. Enter Graph Engineering.》: https://x.com/HamelHusain/status/2078346425621237935

[3]

“Nobody knows what it is.”: https://x.com/HamelHusain/status/2079224401267224677

[4]

《The four types of agent loops》: https://x.com/akshay_pachaar/status/2076748259377516782

[5]

“You need loops watching loops”: https://x.com/VaibhavSisinty/status/2078646016568606961

[6]

Anthropic 的多 Agent Research 系统: https://www.anthropic.com/engineering/multi-agent-research-system

[7]

Google Research、Google DeepMind 与 MIT 的实验: https://research.google/blog/towards-a-science-of-scaling-agent-systems-when-and-why-agent-systems-work/

近期社区活动推荐

了解更多

添加社区小助手，加入微信交流群~

立即试用 OceanBase 企业版，体验国产数据库能力180 天免费试用，零门槛开通

加入 OceanBase 分布式数据库社区

了解最新的技术洞察和前沿趋势，参与 OceanBase 定期举办的线下活动，与行业开发者互动交流

更多推荐

济南地铁票务系统重构：基于OceanBase解决高并发与零中断实战

OceanBase数据库社区

信也科技 × OceanBase ：从风控核心到AI 数据底座的探索（技术解析

信也许多业务最初使用MySQL分库分表方案支撑，在该方案中，以下四个痛点对DBA而言应该并不陌生。**第一，研发效能黑洞，跨库查询与分表治理问题。**我们内部有一套面向研发的自动化平台，但当分表数量较多时，排查问题需要做跨分片聚合查询，往往需要DBA协助，流程比较繁琐。而且，大部分业务代码被迫适配中间件逻辑，严重拖累敏捷迭代的交付节奏。**第二，扩容如履薄冰，极高运维风险。**一方面随着业务持续增