你的agent团队互相踩脚，因为没人画过那张图

五个agent上线三天。研究员和写手在干同一件事，检查员在等一条没人发的消息，经理花掉一半额度挨个问进度。于是你加了第六个agent来协调前五个。

问题从来不在agent身上，在于没人把工作画出来。

这是distort在X上写的一篇文章的核心观点。他管这叫Graph Engineering：先把工作当成步骤和交接画在纸上，再决定到底需要几个agent。

一张图上有四样东西

节点：每个节点只做一件事，比如“找10个来源”“写初稿”“核对数字”。

边：上一步传给下一步什么，以什么格式传。

状态：工作唯一存放的地方，每个步骤都读它、写它。

条件：下一步走哪条边，比如“如果检查没过，退回初稿”。

LangGraph让你用代码写这些东西，但用一张纸也能画。

为什么agent最后才设计

多数人按职位设计agent：研究员、策略师、经理。职位描述的是人，不是工作。两个职位很容易落到同一个步骤上，而步骤之间的空白没人认领。

先画步骤，agent会从图里自己掉出来：一组需要相同上下文的步骤，对应一个agent。大多数图需要的agent比想象中少，有些步骤根本不需要agent。

五种形状

Anthropic在《Building effective agents》里列过几种反复出现的模式，distort把它们整理成五种：

链：一步接一步，顺序固定，每步依赖上一步。中间可以加一道门，检查通过才放行。

路由器：一个入口，多条路径。第一步读输入，把它送到该去的那条路。退款问题走一边，bug报告走另一边。

扇出：同一种活，并行做。读20个来源、查5个竞品，各自独立，最后合并。

经理与工人：经理看任务，现场决定分几块、分给谁、怎么收回来。Anthropic的研究系统就是这个形状。

循环：一个步骤做，另一个步骤按明确标准查，不过关就退回去，直到通过。一定要设轮次上限。

能跑的系统，大多是其中两三种拼起来。跑不动的系统，大多是一个经理在跟所有人聊所有事。

Anthropic说拆，Cognition说别拆，谁对

2025年6月，Anthropic公开了他们的研究系统：一个主agent带一组子agent，在他们内部的研究评测上比单agent高90.2%。代价是多agent跑了大约15倍的token，而在浏览评测里，token用量本身就能解释约80%的性能差异。

同一周，做Devin的Cognition发了一篇《Don't Build Multi-Agents》。他们的例子很具体：让两个子agent分别做Flappy Bird克隆，一个画了超级马里奥风格的背景，另一个画了完全不搭的鸟，合并的人得替两个从没沟通过的决策擦屁股。他们的规则是：共享完整上下文，做不到就别拆。

两边都对，因为他们画的是不同的工作。Anthropic自己在文章里也说了，多数编程任务真正能并行的部分远比研究少。研究是许多独立的阅读，图是宽的；造一个东西是一串互相依赖的决策，图是窄的。

distort给的规则是：扇出阅读，绝不扇出决策。

今晚就能画

不需要框架，一张纸就够。

用一句话写结果：这件事做完时，什么东西存在了。
把每个步骤写成动词加名词："拉上周数据""写摘要"。
每一步写清楚它需要什么、给出什么。
某一步的输出是另一步的输入，就画一条边。
圈出互不依赖的步骤，这些可以扇出。
标出每个判断（"如果X，走这里"）和每个检查（"没过就退回"）。
在不可逆的动作前面加审批：发送、付款、删除、发布。
这时候才分配agent：需要相同上下文的步骤归一组，一个agent管一组；不需要判断的步骤变成工具或脚本。

一个例子：周报团队

原来的版本：5个agent，经理、研究员、分析师、写手、编辑。经理转发一切，研究员和分析师读同样的页面，写手等两个人，编辑重写写手，没有任何人核对一个数字。

按图重画之后：

规划检查项 → 5个竞品并行检查 → 合并写初稿 → 核对每个数字 → 你审批 → 发布

agent从图里掉出来，变成3个角色：

主笔：规划5项检查、合并、写初稿，同一份上下文，一个agent。

侦察员×5：一个提示词，各盯一个竞品，同时跑，返回固定格式。

检查员：打开每个数字背后的来源，默认答案是不通过，把失败的行退回去。

发布不是agent，是一个等你点头才运行的工具。

3个角色代替5个，每一步只有一个主人，唯一扇出的地方是真独立的工作。

把图画下来：GRAPH.md

每个agent开始前先读这个文件，知道自己从哪来、往哪去。distort给的模板是这样的：

OUTCOME: 一份关于5个竞品的报告，每个数字都链到来源
STATE: report.md，所有步骤唯一读写的文件
NODES: plan (Lead) → scout x5 (Scout, parallel) → merge + draft (Lead) → check (Checker) → approve (me) → publish (tool)
EDGES: 每个scout返回company / what changed / link / date，别的不要
CONDITIONS: 检查失败→退回初稿并附失败行，最多3轮，然后问我
NEVER: 没有我的approve，任何东西不发布

图坏在哪，症状会告诉你

两个agent干同样的活：一个步骤有两个主人。

输出互相矛盾：一个决策被扇出了。

工作停了没人发现：一条边没有触发条件，有人在等没人发的消息。

没人知道什么算完了：没有共享状态，工作散在5个聊天窗口里。

所有事都等一个agent：一个经理坐在每条边的中间。

用量烧掉了、结果没变好：扇出用在了不独立的工作上。

六种症状对应图的六个部位，没有一个是靠再加一个agent能修的。

回复区里有个不同的声音

Darren T.在回复里贴了自己的经历。他花几年时间在大公司内部待过，自认为懂组织怎么运转，于是照人司架构给agent搭了一套操作系统：一棵角色树，每个角色有章程、有一个人管、有一个agent干活。指令从根往下流，每个角色翻译成自己的目标和任务，做不了的往上抛，报告用固定字段往上交，每条声明必须引用下级的报告。

建完之后他意识到一个问题：人类组织架构本身就是对人脑处理能力有限的一种妥协。人记不住太多上下文，所以规定谁跟谁说话、谁决定什么、信息怎么流，本质上是个二维结构。agent没有同样的限制，一条信息每次该走的路径可能都不一样。画死这棵树，等于把agent的能力上限锁在自己能想象的范围内。

他暂停了这个项目，把它开源了。GitHub上的zeenly-os目前是早期状态，内核和第一次运行能端到端跑通。

两种思路的差别很清楚：distort说先把工作画成图再分配agent，Darren说图本身也可能是个限制，应该让agent动态决定信息怎么流。前者适合结构相对稳定的工作，后者把赌注押在agent自己找路的能力上。

不管站哪边，有一件事是两篇文章都同意的：agent不是起点。