直到7月18日，OpenClaw的作者Peter Steinberger在X上抛出一个问题：大家还在讨论Loop，还是已经转向Graph了？
两天后，Codez就发布了一篇长篇教程，列出了从零开始学习Graph Engineering的14步路线图。
很多人的反应大概都一样：Loop还没搞明白，怎么又开始画图了？
先简单解释一下Loop是什么。它其实是让单个Agent反复自我检查、自我修正，直到结果达标为止的机制——写完一遍、检查一遍，不行就重来，做到合格才放手。下文会反复拿它来对比。
图源：Codez 原文
所以这篇文章不打算按那14个名词逐一讲解——那14步里出现的Node、Edge、Schema、Router、Fan-out/Fan-in，后面都会用大白话覆盖到。换成一种普通人更容易理解的说法：
Graph Engineering，就是给一群Agent分工，规定工作怎么交接、哪里检查、什么时候停。
先把Agent想成一个新员工
假设你招了一个新员工，让他每天给你写一份AI新闻简报。
最简单的做法，就是把所有事情都交给他一个人：找新闻、读原文、核对真假、挑重点、写文章、改错字。
这就是大家熟悉的单Agent模式。
Prompt相当于你给他的工作要求。Loop相当于他写完检查，发现不对再重做，一直做到合格为止。
简单任务这么做没问题，但事情一多，这位员工就开始忙不过来了。他需要一边翻资料，一边记数字，还要考虑文章结构，能记住的上下文越来越满，前面看过的东西也忘得越来越快。
Graph Engineering做的事情，大家其实都能想到：别让一个人干这么多事儿了，组个团队吧。
有人找资料，有人核对事实，有人写稿，还有人负责挑错。分工明确，最终促成一篇成稿落地。
顺带澄清一个容易混淆的概念：图里出现的Graph Reasoning，和本文讲的Graph Engineering不是一回事。Graph Reasoning偏向模型内部的推理结构，Graph Engineering偏向工程层面的多Agent编排。这篇文章讲的是后者。
这张图看起来可能很复杂。其实下面那些小圆点、小方框，大多都可以理解成不同员工和不同的工作。
Node是员工，Edge是交接单
Graph里最重要的两个概念是Node和Edge。
Node，也就是节点。你可以把它理解成一个岗位：资料员、翻译、事实核对员、作者、审稿人。
Edge，也就是边缘。它表示工作从谁手里交到谁手里，以及交过去什么东西。
这里有个特别容易踩的坑：做事有先后顺序，但不代表它们存在依赖关系。
比如，让Agent总结这份文件，然后查一下北京天气。天气查询根本不需要等总结结束后才能执行，这两个任务完全可以同时开始。
很多Agent慢就慢在这里。所有工作被写成A → B → C → D，前一个任务结束不了，后一个任务绝不开始。
再举个更直观的例子：B和C都只需要A提供的资料，C并不需要B的结果。那么A完成后，就可以同时启动B和C，没必要让C排在B后面干等。
所以，Graph Engineering最基础的能力，是看清任务之间真正的依赖关系：哪些任务需要等待，哪些任务可以同时开工。
任务可以并行以后，问题就从谁等谁，变成了结果怎么交给下一个Agent。
比如，资料员Agent查完资料，只交回来一大段文字。负责写作的Agent既找不到原文链接，也分不清哪些是事实、哪些是结论，只能自己再猜测一遍。
解决方法，是给每次交接规定一个固定格式。比如资料员必须返回三项内容：标题、原文链接、重要程度。少一项，这次交接就不合格；全部齐全之后，写作Agent才继续工作。
技术上，这份格式规则叫作Schema。你可以把它理解成一张统一的交接单。
现在再看Node和Edge就容易理解了：Node规定这个Agent负责什么，Edge规定它要把哪些数据交给谁。交接格式越清楚，下一个Agent就越容易理解。
所以，多Agent真正难的是提前写清楚每一步的交付物、如何检查、出错后怎么办。
如果这些规则没定好，那么Agent数量越多，造成的返工反而越多。
最常用的图，其实就是一颗菱形
最常见的Graph形状并不复杂。
先把任务拆分，让几个人同时做；做完之后再把结果收回来，去重、筛选；最后交给一个人统一出结果。
就拿写这篇文章来举例。
一个Agent读X原文，一个Agent查Anthropic官方文档，另一个Agent看最近大家怎么讨论Graph Engineering。三边可以同时开始。
资料回来后，先去掉重复内容，再交给最终的拟稿人和审核人。所以，你不需要背着十几个网页工作，只需要拿到整理好的结果就行了。
这就是Fan-out和Fan-in。
Fan-out是把工作分出去，Fan-in是把结果收回来。两个动作连在一起，就构成了下面这颗菱形形态。
放到写文章这件事里就很好理解了：先让几个Agent同时查资料，再让程序自动去重、分类，最后把整理好的材料交给一个Agent，由它形成最终结论。
前面几个Agent已经同时找完资料，程序也完成了去重和分类。但这些材料还不能直接拿来写文章，因为它们可能引用了过期消息，也可能把别人的转述当成官方结论。
所以，最后一个Agent拿到材料后，需要先做一轮验收判断：链接能不能打开，数字和日期能不能对上，不同来源有没有互相矛盾，判断之后才能开始写。
技术上，这个负责挑错的角色叫Reviewer或Verifier。它的工作不是再写一份答案，而是检查前面的答案能不能相信。
但“检查”这件事并不是一个固定的动作，力度也得看事情轻重。
一个普通的观点，让一个Agent快速核对就够了；涉及重要数据、安全问题或产品结论时，就要安排几个Agent从不同角度交叉检查。决定“这件事该走哪条检查流程”的角色，叫Router。它像一个分诊台，根据重要程度把任务引向不同的边。
如果负责查资料的Agent说官方已经确认，验证Agent就要找到官方原文；如果只能找到媒体转述，这条结论就要降级，甚至退回去重新查。只有经得住检查的内容，才会进入到文章中。
如果Agent执行的不是查资料，而是修改代码，还要多做一步隔离：给每个Agent一份独立的工作区。否则两个人同时改同一个文件，后面保存的人可能直接盖掉前一个人的成果。
如果检查发现问题后，需要退回前面的Agent补资料，然后再检查一次。这样就形成了一个循环。
但是循环必须规定什么时候结束。比如连续两轮没有发现新问题就停止，否则就像老板一直喊“再查一遍”，Agent会不停工作，token也会一直烧。
整套流程说白了就是：有人找资料，有人整理资料，还有人专门检查资料。检查不通过就退回重做，通过之后才下最终结论。
前面一直在说把任务分给多个Agent，但有件事不能忽略：每启动一个Agent，它都要单独读取材料、思考并输出答案，这些操作都会消耗token。
比如为了写一篇文章，同时叫来十个最强模型查资料，确实可能比一个模型查得更全面，但也相当于花了十倍价钱请了十位专家。并行能节省等待时间，却不会让这十个人免费工作。
省钱的办法，是别让所有工作都交给最贵的模型。提取标题、整理格式、简单分类，可以让便宜的模型完成；判断消息真假、处理冲突、形成最终结论，再交给能力更强的模型。
这就像一个编辑部：整理资料不必总编辑亲自上，真正需要拍板时再找他。
除了选什么模型，任务怎么排也会影响速度。
比如十份资料要放在一起去重，那就必须等十个Agent全部回来后再开始，像开会一样，人到齐了才能进入下一步。
但如果每份资料可以单独处理，就不用等所有人。第一份回来就先检查第一份，第二份回来再处理第二份，像流水线一样。
所以，设计一张Agent Graph，本质上还要算清三笔账：启动多少个Agent、每个Agent使用什么模型、哪些步骤必须互相等待。
Graph设计得好，是用更少的钱更快地完成任务；设计得不好，只是让更多模型一起更快地烧token。
讲到这里，你可能已经发现了一个问题：Graph确实能让多个Agent一起工作，但这张图本身还是要有人设计。
谁去查资料，谁负责验证，哪些任务可以同时开始，哪一步必须等待，最后由谁下结论——以前，这些规则通常要开发者提前写好。
Claude Code的Dynamic Workflows想做的，就是把这部分工作也交给Claude。
你只需要告诉它最终目标。Claude会先分析任务，再生成一段Ja vaScript编排脚本。
还是以写文章为例，它可以安排几个Agent分头查找原文、官方文档和外部讨论；等资料回来后，让程序去重；再叫验证Agent检查来源，最后交给写作Agent输出文章。
在Claude Code里，你可以直接要求它使用Workflow，也可以运行/deep-research。打开ultracode后，Claude还会先判断当前任务够不够复杂，是否真的值得启动一组Agent。
图源：Anthropic Dynamic Workflows 官方介绍
这里有个很容易误解的说法：编排脚本可以做到零模型token。
它真正的意思是，分发任务、等待结果和合并数据这些管理动作由普通Ja vaScript完成，不需要再调用一次模型。但真正出去干活的每个Agent，仍然会正常消耗token。
说白了，排班表不拿工资，不代表排班表里的员工也不用拿工资。
截至2026年7月，Claude官方文档给出的上限是同时运行16个Agent，单次Workflow最多启动1,000个Agent（见Claude Code Docs）。这代表系统能承载多大的任务，并不代表普通任务也应该把人数拉满。
下面这张图，就是原文最后组装出来的一套完整流程。
第一眼看上去密密麻麻，拆开后仍然是前面讲过的几件事：先确定任务范围，再分头查资料；用固定格式交接，用程序整理；安排Agent验证，最后形成结论；整个过程还要控制停止条件和成本。
Claude现在可以自动生成这套流程，但仍然要检查三个问题：任务拆得是否合理，该验证的地方有没有验证，启动这么多Agent是否值得。也就是说，不一定要亲手画出每个节点，但仍然要判断Claude安排的这套分工能不能真正完成任务。
看到这里，小白不需要马上安装一个Graph框架，更不用给每个任务都安排十几个Agent。
如果只是总结一份PDF、修改一个标题，交给一个Agent从头做到尾，通常更快也更便宜。为了显得高级硬拆成一张图，只会增加等待、交接和出错的机会。
当任务开始出现下面这些情况时，Graph才真正有用：有几块工作可以同时进行；一个Agent已经看不过来；结果必须经过独立检查；整个过程会反复执行很多次。
真要动手，也可以从最简单的一步开始。先让一个Agent完成整个任务，找到最慢或者最容易出错的环节；再拆出一个可以并行的分支；确实担心答案不可靠时，再加一个验证Agent。等流程稳定之后，最后才考虑框架和自动编排。
说到底，Loop解决的是一个Agent如何反复工作，直到把事情做完；Graph解决的是多个Agent如何分工、交接、检查，以及如何避免把token白白烧掉。
Graph不是重点，Graph里每一条箭头为什么存在，才是Graph Engineering真正要解决的问题。
参考资料
Codez：Graph Engineering with Claude，14步原文
Anthropic：Introducing dynamic workflows in Claude Code
Claude Code Docs：Dynamic Workflows
LangGraph 官方文档：Graph API overview
