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。

先把DAG讲清楚：它不是Agent时代才有的东西

DAG的全称是Directed Acyclic Graph，中文常译为“有向无环图”。Directed（有向）指箭头有方向：A完成后才能做B；Acyclic（无环）指顺着箭头走，不会又绕回起点。

把它放进工程里，它就是一张任务接力表。上游任务完成，下游任务才能开始；彼此没有依赖的任务可以并行。比如先取数，再清洗、训练，最后出报表——谁依赖谁，一目了然。

DAG来自图论，不是为LLM发明的。它后来长期被用在构建依赖、数据管道和任务调度里。Apache Airflow这类数据调度系统的核心就是DAG：任务、依赖、重试、超时和运行频率都围绕它组织。

DAG的好处是可预测。调度器不必理解每个任务的业务细节，只要知道依赖关系，就能判断谁该先跑、谁可以并行、失败后该怎样按规则重试。它擅长处理边界清楚、路径相对固定的工作。

Graph比DAG多了什么？不是“更高级”，而是少了约束

DAG本身是Graph的一种特殊情况：它规定整张图不能有环。Graph则更宽，它可以包含DAG，也可以允许循环、反馈、条件分支和多次交接。

这不是说Graph天生更先进。固定的数据管道，用DAG往往最清楚；非要加循环，只会把系统做复杂。真正的区别在于：当任务会根据中间结果改道、需要反复验证，或需要把人也放进审批链路时，DAG的“只往前走”开始不够用了。

Agent把这个差别放大了。过去，DAG里的节点多半是确定性的程序；现在，节点可能是会读模糊任务、选择工具、临场判断下一步的LLM。它们不只需要依赖顺序，还需要明确状态、权限、预算、证据和停止条件。

所以我更愿意把它理解为：DAG解决任务怎么排队；Graph Engineering解决一组会自主行动的角色，怎样有边界地协作。一个Agent的loop可以在某个节点内部反复执行；Graph则负责这些loop之间怎样交接、何时分支、何时暂停。

为什么偏偏现在火了？

不是因为图论突然有了新发现，也不是某个全新框架在那两天横空出世。更像是大家先把单个Agent跑起来，才发现瓶颈从“它会不会做事”移到了“它们怎么协作”。

一条loop能让一个角色观察、执行、验证、重试；但十条各自能跑的loop放在一起，谁分任务、谁合并结果、失败回到哪里、谁有最终授权，仍然要有人设计。Peter Steinberger的那句调侃之所以会传开，正好点中了这个集体经验。

真正新增的，不是“图”，而是控制权

LangGraph这类框架早就用三样东西描述这种系统：State是任务账本，记录现在发生了什么；Nodes是各个干活的环节；Edges则规定一项结果接下来能交给谁。

新鲜的部分在于，今天许多节点里坐着的是LLM。节点越有自主性，系统越不能把关键边界交给“它应该会懂”。

于是，Graph Engineering真正需要被设计的，通常是下面五件事：

第一，状态。哪些信息是整个任务的事实记录，哪些只属于某个节点的临时上下文？一份越滚越长的聊天记录，不等于一个可恢复的任务状态。

第二，路由。当模型说“我做完了”，谁来决定下一步？是交给测试、交给另一个专家、返回补充信息，还是直接结束？这条边越影响成本、权限或风险，越不该模糊。

第三，验证。让另一个模型夸一句“看起来不错”，可以有帮助，但不该是最终证据。测试结果、数据库回执、支付状态、用户确认，才是真正来自系统外部的反馈。

第四，重放。一个节点超时后再次执行很正常；重复发出一封外部邮件、重复扣一笔钱就不正常了。带副作用的动作要有“幂等保护”——同一个请求跑两遍，结果仍只生效一次。

第五，授权。什么时候让Agent自己决定，什么时候停下来问人？删除数据、改变生产配置、付款、对外发信，这些动作不应该靠“模型足够聪明”来兜底。

如果这些没有被写清楚，所谓“多Agent协作”很容易变成一群模型拿着同一份上下文互相转发，然后一起自信地错下去。

社区为什么一边兴奋，一边翻白眼

Reddit上已经有人按这个思路做实验。原帖作者把一类工作拆成一张DAG：研究、实现、测试、审批各占一个节点，由这张图决定结果往哪里交接。

每个节点里，仍然可以有自己的loop，也可以有工具接口、当下必需的上下文、长期记录和可复用的操作规范。用人话说：研究的人能查资料，测试的人只跑测试，部署的人只有在条件满足时才拿到部署权限。

这里容易混淆的一点是：DAG说的是这些角色之间怎样交接；节点内部要不要重试、要不要循环，是另一回事。Graph Engineering不一定都要画成DAG，但DAG是最容易看清责任边界的一种形式。

随后有评论一句话戳破气泡：“这不就是DAG吗？”这个质疑没有错。编排、状态机和任务图都是成熟的软件工程概念，Graph Engineering并没有突然发明它们。

它仍然有价值，是因为以前很多边界由确定性代码天然给出；现在把LLM放到中间，边界会变软。模型可能把相同输入理解成不同任务，也可能在信息不足时自作主张。要么把约束写进系统，要么继续让人盯着每一次运行。

所以，Graph Engineering最有价值的地方，不是让系统“看起来像一个AI公司”，而是让系统的控制权重新可见。

什么时候该用它，什么时候就老老实实用一个Loop

不是Agent多了就需要一张图。

如果任务就是固定的三步，失败后也是固定地重试，所有动作都在同一个风险等级里，一个清楚的loop或几段普通代码往往更可靠。Anthropic在工程实践中也反复强调：先用最简单能解决问题的方案，只有复杂度真的改善结果时，才往上加。

真正值得显式建图的时刻，往往是这些时刻：任务需要并行分工、结果要在某处汇合；不同分支有不同权限；失败后有多种处理方式；状态需要跨步骤保存与回放；或者你需要能回答“这次任务为什么走到了这里”。

如果画完以后，仍然说不清谁对哪一个结果负责、哪一个结果能越过验证关口、哪个人能终止运行，那它就只是张好看的图，不是工程设计。

如何开始

如果明天要把一个成熟的Agent任务往Graph的方向改，我不会先搭多Agent框架，而会先做三件事。

先把失败路径写出来。成功路径人人都能想出来；真正消耗人力的，是超时、空结果、冲突结果和越权动作。

再把任务状态写成结构化记录：任务ID、输入摘要、当前阶段、外部证据、重试次数、预算、审批状态。这样无论重启、转人工还是回放，都有据可查。

最后，把验证和副作用分开。能由代码、测试、回执确认的，就不要让模型自评；有不可逆后果的，就给它幂等键、预算上限和人工门槛。

这听上去不炫，但这是让Agent从演示走向真实系统的部分。

结尾：别急着换一个新名词

从Prompt到Context、Harness、Loop，再到Graph，变化的其实不是“工程师又多背了一个概念”。变化是我们在给Agent更大的行动范围后，终于不得不认真设计它的边界。

Loop让一个角色有机会把事情做完；Graph要求多个角色在不确定性里仍能有秩序地协作。

如果这波热度最终让大家少讨论一点“再加一个Agent”，多讨论一点状态、验证、权限、恢复和人类授权，那这个词就没有白火。