技术 · 深入
图工程真正的代价：先算上下文和成本
图首先是上下文管理技术，其次才是并行技术
上一版讲了「图 vs 循环」和四步上手，漏掉的是最容易翻车的那半：多 Agent 图是拿 token 换质量。Anthropic 自己实测——多 Agent 配置比单 Agent 基线好 90.2%，但烧掉约 15 倍 token（单 Agent 本身已是普通对话的约 4 倍），而且在 BrowseComp 上约 80% 的性能方差由 token 用量单独解释，他们自己写下的最诚实一句是「多 Agent 之所以有效，主要是因为它帮你花了足够多的 token」。所以这份补强只做三件事：先算成本账，再判断这活拆不拆，最后选一个能说出「什么时候用」的拓扑。
方法 · 一图看懂
1
先算成本账 — 别信「多 Agent 更强」，先知道它烧多少：多 Agent 图约 15× token，而单 Agent 本身已约 4×
2
判断这活拆不拆 — 只有 breadth-first（有多条独立方向可探）才值；每个节点都要同一份共享上下文、或子任务互相依赖 ⇒ 不拆
3
选一个拓扑 — 从九种常见形状里挑：链 / 路由 / 并行 / 编排器-工作者 / 生成-评审 / 扇出-汇总 / 对抗验证 / 锦标赛 / 直到跑干
4
把节点做窄 — 一个节点一件事、只给它需要的工具：评审员不给写权限、写手不给联网；「不能指望模型执行的边」写成 hook 而不是礼貌指令
5
用边做压缩 — 每条边都是一次压缩点：worker 只把 1000-2000 token 的摘要交回，探索过程的细节留在它自己的上下文里
6
验证靠独立节点 — 对抗验证专治「agent 给自己批作业」：换新上下文、无立场、被明确要求去拆
15 倍 token 的账，怎么读
这组数字要连着读才有意义：单 Agent 已经比普通对话贵约 4 倍，多 Agent 再叠到约 15 倍；而 Anthropic 在 BrowseComp 上做归因时发现，token 用量一项就解释了约 80% 的性能方差。换句话说，多 Agent 图不是魔法，它是一台「比一个上下文窗口能装下的多得多的 token 花法」——对某些任务是质变，对另一些就是纯粹浪费。所以第一步不是画图，是问这张图省下的时间值不值这 15 倍。
九种拓扑，各配一句「什么时候用」
链（直线，每步喂下一步）——任务能拆成固定顺序步骤；路由（一个分类器扇出到专门分支）——输入天然分几类且各有专门处理；并行——子任务互相独立，或想让多个节点对同一问题投票。编排器-工作者（星形，主 Agent 现生成子任务再汇总）——子任务事先列不出来、要模型自己决定；生成-评审（两节点成环）——结果质量可判、且迭代确实能变好；扇出-汇总（多个找 → 一个合）——广度型发现（调研、审计、迁移）；对抗验证（发现 → 独立质疑者 → 裁决）——防自偏爱偏差，作者不当裁判；锦标赛（N 次尝试 → 两两评审 → 胜出）——解空间大、单次尝试探不够；直到跑干（循环重生直到找不到新的）——工作量事先未知（查 bug、扫边界）。最该先内化的是对抗验证：它攻的正是一个循环在结构上修不了的那个坏毛病——agent 给自己批作业。
什么活不该上图（Anthropic 点名了编码）
判断标准只有一条：这活是不是真的能拆成互不依赖的部分。图上表现好的，是 breadth-first 型工作——多个独立方向可探、任务超出单个上下文窗口、且价值高到撑得起成本。图上表现差的，是每个节点都需要同一份共享上下文、或子任务彼此依赖的工作——Anthropic 原文直接点名编码：「多数编码任务真正可并行的部分比研究少」。所以那句自查要放在拆图之前：如果单个 Agent 配一个明确的验证器就已经做完了，把三个接起来只是又贵又慢。图里每个节点本身都得是一个能独立交付的循环——弱节点搭出来的图，只是并行生产的垃圾。
版图之外：把共享状态换成知识图谱
同一条思路还有一个更重的版本 —— Anthropic 的图工程 playbook 把节点间的共享状态从「编排器的上下文」换成一张共享知识图谱，用四阶段 Claude API 流水线搭起来：抽取（Haiku · schema 约束 · 「每写一条关系，两端必须都是抽取出来的实体」）→ 实体消解（Sonnet · 靠抽取阶段那句一句描述来消歧，24 个表层形式压成 22 个规范实体）→ 汇总（Sonnet · 只对高度数节点跑）→ 多跳查询（Sonnet · 把 k 跳邻域序列化成三元组再推理）。它有两个已知失效模式要防：漏配（谁都归不进簇的名字会从图上消失 ⇒ 生产系统要回落成单点簇）与过度合并（把「Gemini 12」并进「Project Gemini」⇒ 精度丢失）。验收看图的健康指标：节点与边之比、连通分量数、枢纽节点度数。
让编排器别乱撒子任务
编排器最常见的两个毛病，Anthropic 都写下来了：该停不停（已经有足够结果了还在继续搜）和任务描述太糊——早期版本里，一句「研究半导体短缺」让一个子 Agent 去查 2021 年汽车芯片危机、另两个重复查 2025 年供应链，分工完全失效。修法是给每个子任务写清四样：明确目标 · 期望输出格式 · 该用哪些工具与来源 · 明确的边界。另一条是把投入量按复杂度分级写进提示词：简单事实查找 = 1 个 Agent 3-10 次工具调用；直接对比 = 2-4 个子 Agent 各 10-15 次；复杂研究 = 10+ 个子 Agent 分摊。不写这条，早版会对简单问题投入过多。
原理 · 为什么有效
图之所以有效，不是因为「多个模型一起想更聪明」，而是因为它把上下文按节点切开了。Anthropic 的文档把机制写得很直白：每个子 Agent 在自己的新会话里跑，中间的工具调用与结果留在子 Agent 内部，只有最终消息回到父级；研究中它们回来的摘要通常只有 1000-2000 token，而详细的搜索上下文被隔离在子 Agent 里。所以图首先是一种上下文管理技术，其次才是并行技术——每条边都是一次压缩点，编排器拿到的是蒸馏过的结论，而不是继承每个工作者的探索残渣。这也解释了那 15 倍 token 去了哪：它买的是把「一个窗口装不下」的工作，切成多个各自干净的窗口。反过来，当每个节点都需要同一份共享上下文时，切开就没有收益，只是多付协调成本。
适用场景
适用：广度优先的调研（一条问题有多个独立方向要探）；单个上下文窗口装不下的任务；价值高到撑得起约 15 倍 token 的题目；以及「产出 + 独立检查」天然分离的流程（起草-评审 / 研究-写作 / 构建-测试）——最后这类是最适合练手的第一张图。不适用：① 每个节点都要看到同一份共享上下文的活 —— 切开之后每个节点都得再灌一遍，成本翻倍而质量不涨；② 子任务彼此依赖、必须串行推进的活（Anthropic 原文点名编码：多数编码任务真正可并行的部分比研究少）；③ 单个 Agent 配一个明确验证器就已经做完的活 —— 接成图只是更贵更慢；④ 还在调单个循环的阶段 —— 节点先各自可靠，再接图。
自测 · 5 问
这件事真有多条互不依赖的方向可探吗，还是我先把「多个 Agent」当成答案了？
我算过这张图大概要花多少 token 吗，省下来的时间值这个数吗？
图里每个节点是不是「只做一件事 + 只拿它需要的工具」，还是我给了它们同一套权限？
节点之间过的是蒸馏过的摘要，还是我把上游的原始探索过程原样传给了下游？
我的验证节点跟产出节点是分开的吗，还是同一个节点在给自己批作业？
怎么上手 · 验证步骤
别从最复杂的那张图开始。第一张图挑「产出 + 独立检查」的活：拿一个你每周都要做的短任务（比如「整理一份来源清单」或「把一份初稿改成终稿」），按五步搭：① 先跑基线——同一个任务先让单 Agent 做一遍，把耗时、token 与结果都记下来（这就是那张 15 倍的参照系）；② 切两个节点——一个只负责产出、一个只负责挑错，两个节点各自的系统提示要窄到一句话能说完；③ 只放一条边——产出节点的输出交给评审节点，评审不通过就退回产出节点重做（这条回路必须是明确的边，不是一句「你觉得不好就再说一遍」）；④ 把「不能指望模型执行」的那条边写成 hook——比如「移交前必须先跑完测试」，做成代码而不是提示词；⑤ 跑第二遍对比基线：看节点输出有没有被正确接收、路由有没有真的触发、有没有节点在做无用功。
做完回看三件事：① token 账——这张图比基线多花了多少倍？如果质量提升感知不明显而成本涨了一大截，说明这个活本来不该拆；② 边是否真的在压——把每个节点交回给上游的那段内容单独拿出来看，它是 1000-2000 token 的蒸馏结论，还是把整个探索过程搬了过去（后者说明上下文隔离没生效，图白搭）；③ 验证是否独立——把评审节点的上下文清掉重跑一次同一份产出，结论应该一致；若不一致，说明它是在顺着产出节点的说法点头，而不是真在判。三件事都过，才算把「多 Agent」从数量变成了结构。