Graph Engineering

图源：The AI Operator，Eugeniu Ghelbur。

这两周的 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 解决很多角色、工具和人工审批之间，事情该怎样交接、验证、暂停和恢复。

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

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

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

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

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

• 研究阶段搜到的一堆材料，为什么要原封不动塞给部署阶段？
• 测试失败时，应该回到代码修改，还是升级给人？
• 谁有权触发真正的生产部署？
• 如果网络超时，重跑会不会把同一封邮件、同一笔操作执行两次？

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

图源：Anthropic · Building Effective AI Agents。

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 公司”，而是让系统的控制权重新可见。

什么时候该用Graph，什么时候用 Loop

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

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

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

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

如何开始

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

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

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

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

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

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

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

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

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