Graph Engineering 火了：Agent 的难题变成了“协作”

这两周的Agent圈，有一种很熟悉的速度。

上个月大家还在讨论Loop Engineering：别再把Agent当成一次性的对话，得让它能触发、执行、验证、重试，最后还知道什么时候停下来。

没过多久，OpenClaw创始人Peter Steinberger在X上丢下一句调侃：“Are we still talking loops or did we shift to graphs yet?”——我们还在聊loop，还是已经切到graph了？随后，Hamel Husain把文章标题写成了“Loop Engineering Is Dead.Enter Graph Engineering.”

新词又来了。但这一次，热词背后其实藏着一个很具体的工程问题：当一个Agent已经能自己闭环干活，多个Agent到底怎么不互相添乱？

我不太愿意把Graph Engineering当成“Loop的下一代”。它不是替代关系。更准确的说法是：Loop解决一个角色如何反复把事情做完；Graph解决很多角色、工具和人工审批之间，事情该怎样交接、验证、暂停和恢复。

从“它会做事”，到“它们能协作”

图源：The AI Operator，Eugeniu Ghelbur。

一个单独的Agent loop很好理解。

它接到任务，调用工具，看到结果，判断是否继续；失败了重试，完成了结束。写代码、处理固定类型的工单、每天巡检日志，这些都可以从一个小loop开始。

问题会在任务变复杂时出现。

比如，一个“帮我上线这个改动”的请求，背后可能同时有需求理解、代码修改、测试、风险检查、部署权限和人工确认。你当然可以让同一个Agent一口气做完。但很快就会遇到一些很不舒服的问题：

•研究阶段搜到的一堆材料，为什么要原封不动塞给部署阶段？

•测试失败时，应该回到代码修改，还是升级给人？

•谁有权触发真正的生产部署？

•如果网络超时，重跑会不会把同一封邮件、同一笔操作执行两次？

这些已经不是“提示词写得够不够好”的问题了。它们是协作关系的问题。

Graph Engineering讨论的，正是把这些隐含关系摆到台面上。

它关心的不是“画出一张更复杂的流程图”，而是把系统中的责任做成可执行的约定：某个节点能做什么、需要读什么、会留下什么证据；什么结果可以进入下一步；什么情况必须停止；什么动作必须经过人。

在这个意义上，Graph更像一张组织图，而不是一条流水线。节点不必都是Agent：它可以是模型调用、确定性的校验脚本、数据库写入、路由器，也可以是人工审批点。Loop也可以藏在某个节点里，专门负责一类工作。

说到这里，你可能会觉得：这不就是一张早就存在的任务图吗？确实如此。要理解Graph Engineering到底新在哪里，得先认识它背后那个更老、也更基础的概念：DAG。