图工程：构建多智能体 AI 系统的完整指南

大多数构建多智能体 AI 系统的人，都盯错了层。

他们痴迷于提示词、模型、工具、记忆，以及能孵化出多少个智能体。但一旦智能体超过一个，最难的问题就不再是让单个智能体变得更聪明，而是决定工作本身应该如何流动。

哪些智能体可以同时运行？哪些智能体之间真正存在依赖？什么数据应该在它们之间流动？结果应该在哪里汇聚？什么内容需要被验证？某个节点失败时会发生什么？哪些操作在人类批准之前必须保持不可能执行？

这一层有一个名字：图工程（Graph Engineering）。

图（graph）把一堆智能体变成一个系统。你不再这样思考：

A → B → C → D → E

而是开始用节点、依赖、并行分支、归约器（reducer）、验证门、循环、故障域和人工检查点来思考。

读完本指南，你将知道如何设计出更快、更便宜、更容易调试、也更难被糊弄的多智能体系统。

1. 工作流不是清单

浪费一个 AI 系统最容易的方式，就是把顺序（order）和依赖（dependency）混为一谈。

假设你的工作流写的是：

1. 调研定价
2. 调研客户评价
3. 调研产品文档
4. 撰写市场简报

大多数人会按顺序执行这四步，因为它们是按顺序写的。但前三步彼此并不需要，它们只需要在第四步之前完成。所以真实的形状是：

            定价 ──────┐
                       │
评价 ──────────────────┼──→ 市场简报
                       │
      文档 ────────────┘

这张图包含的工程信息，比那个编号清单多得多。重要的问题不是「下一步是什么？」，而是：

「在这一步开始之前，什么信息必须已经存在？」

这一个问题，立刻就能暴露出虚假依赖。如果任务 B 从未消费任务 A 产出的任何东西，那么 A → B 就不是真正的依赖——那只是等待。

2. 图需要状态，而不只是箭头

当人们发现并行智能体之后，通常会犯下一个错误：每个智能体接收一个巨大的提示词，返回一大坨文本。

这在演示里行得通，在真实的图里会崩塌。一个有用的图需要显式的状态——不是「上一个模型说过什么」，而是真正的状态。例如：

ResearchFinding {
  claim        # 论断
  evidence     # 证据
  source       # 来源
  confidence   # 置信度
  timestamp    # 时间戳
}

这样，下一个节点读取的就不是一段对话，而是一个对象。这个差别听起来很小，其实并不小。结构化状态给你三样东西：

1. 可替换性。你可以把一个工作节点换成另一个，而不必重写下游的一切。
2. 可检视性。你能精确看到一个节点进出了什么。
3. 模型周围的确定性。盒子内部的模型可以依然模糊，但盒子周围的接口保持严格。

这就是你停止构建「对话链」、开始构建系统的方式。智能体可以即兴发挥，图不应该即兴发挥。

3. 每加一个智能体之前，先做依赖测试

对工作流里的每一条箭头，都有一个极其有用的测试：

「究竟有什么数据穿过这条箭头？」

如果你无法用一句话回答，这条边就可疑。

坏答案：「下一个智能体应该知道上一个智能体完成了。」那是状态通报，不是依赖。好答案：「审阅者接收研究者产出的论断、来源 URL 和证据摘录。」这样边就有了意义。

你可以对几乎任何工作流套用这个测试：

审阅文件 A → 审阅文件 B    穿过什么？什么都没有。删掉这条边。
提取发票   → 计算总额      穿过什么？发票数值。保留这条边。
生成三个标题 → 选出最强的   穿过什么？三个候选标题。保留这条边。

目标不是最大化并行度，而是消除虚假同步。

4. 并行不是免费的

当人们意识到独立的工作可以同时运行后，往往走得太远。20 个 worker 变成 200 个，200 个变成 2000 个。图变宽了，账单也变宽了。

并行能缩短墙钟时间，但不会神奇地减少工作量。事实上，过宽的图常常制造新的成本：

• 更多重复的调研
• 更多互相冲突的输出
• 更多速率限制
• 更多合并压力
• 更多验证负担
• 最终阶段更多上下文

所以每个严肃的图都需要一个宽度预算。把它想象成内存分配：你不会仅仅因为数据库技术上接受连接，就发起 500 个数据库查询；也不要仅仅因为运行时技术上带得动，就启动 500 个智能体。一条有用的规则：

只有当新增 worker 带来的覆盖增量大于它带来的调和成本时，才增加宽度。

五个研究者各看一个真正不同的角度，可以非常优秀；五十个研究者用略有不同的提示词搜索同一个话题，通常只是在制造噪声。你应该优化的单位不是「智能体数量」，而是「每美元买到的有效独立覆盖」。

5. 关键路径比总步数更重要

线性工作流慢，是因为每一段的耗时都被加起来。如果五个任务分别耗时：

8s + 12s + 6s + 10s + 9s ≈ 45 秒

其中四个任务如果互相独立，系统可能只需等最慢的那一个完成就可以合并。于是重要的数字不再是总和，而是关键路径（critical path）。

这改变了你阅读工作流图的方式。不要数盒子，去找从起点到终点最长的、不可绕过的路径——那条路径决定延迟，其余一切都是优化机会。这就是为什么一个 40 节点的图可以比一条 7 节点的链更快完成：图更大，但关键路径更短。

6. 先压缩，再推理

智能体系统里最昂贵的架构错误之一是这样的：

20 个 worker
    ↓
一个巨大的综合提示词

所有原始输出被塞进最后一个模型。于是最终节点不得不：通读一切、去重、统一格式、发现矛盾、给发现排序、推断缺失字段，然后才写出答案。你把自己最聪明的模型变成了垃圾回收器。不要这么做。

在综合之前放一个归约器（reducer）。归约器应该移除所有不需要判断力的工作：

去重 ID、按时间戳排序、按来源分组、丢弃格式错误的记录、
统计投票、规范化标签、删除完全重复项

这些大部分应该是普通代码，而不是又一个智能体。这样你昂贵的推理节点收到的就是一个更小、更干净的集合。整个架构变成：

workers → 确定性归约 → 推理/综合

这是整个设计空间里最强有力的成本优化之一。把模型用在模糊性上，把代码用在水电煤（plumbing）上。

7. 验证应当是不对称的

worker 不应该因为捍卫自己的答案而获得奖励，那会制造确认偏误的压力。相反，要给验证一个不同的目标。worker 说：

「找出最强的答案。」

验证者说：

「找出这个答案应该被拒绝的理由。」

这不是同一个任务。好的验证是对抗性的。对于研究系统：

WORKER: 寻找支持或解释该论断的证据。
VERIFIER: 尝试证伪该论断；核查来源；核查日期；寻找矛盾证据。

对于代码：

WORKER: 实现这个变更。
VERIFIER: 尝试搞坏它；跑测试；检查边界情况；寻找回归。

对于策略：

WORKER: 构建这个建议。
VERIFIER: 列出这个建议在什么条件下会失败。

验证者必须有权毙掉产出，否则它只是装饰。

8. 在图运行之前设计故障域

一个真实的图假定节点会失败。不是因为你的系统差，而是因为分布式工作总会在某个地方失败：请求超时、来源消失、工具返回畸形数据、模型无视要求的格式、worker 被限流。

架构问题是：图的多少部分应该跟着它一起死？错误答案是「全部」。每个节点都应该处在一个故障域里，并有显式的策略：

故障时:
1. 重试一次
2. 用备用模型/工具重试
3. 返回结构化失败
4. 如果法定人数仍然足够,继续
5. 只有当该节点是关键节点时才阻塞

这样，一个有十个研究者的图，在一个失败时仍然能产出有效报告——但最终输出应该知道只有 9/10 完成了。这就是韧性（resilience）与静默不完整（silent incompleteness）的区别。永远不要隐藏缺失的工作，要可见地降级。

9. 人工批准是一种边类型

这是一个重要的转变。大多数人把人类建模成另一个节点：

AI → 人 → AI

这太含糊了。人类通常不是在「做工作」，而是在授权状态跨越某个边界。这让批准更接近于一种边的条件。例如：

起草营销活动
      ↓
质量检查
      ↓
[ 人工批准 ]
      ↓
发布

发布节点应当字面意义上在批准存在之前不可达。不是「模型被指示要先询问」，也不是「智能体通常会等待」——图应当让不安全的转移在结构上不可能发生。

当下游动作不可逆时，这一点最重要：转账、部署代码、给客户发邮件、删除数据、修改权限、对外发布。后果越强，批准就越应该写进架构，而不是写进提示词。

10. 有些规则应当被冻结

智能体系统是优化机器。这意味着它们最终会发现捷径：如果「成功」意味着更快交付，系统可能会弱化评审；如果「成功」意味着更多线索，它可能会放松资格审查；如果「成功」意味着更多完成的工单，它可能会对什么算「已解决」变得慷慨。

所以有些规则应该坐在优化之外，把它们想成冻结的约束：

未经批准绝不发布
绝不引用没有打开过的来源
绝不在测试没有执行时标记为通过
绝不超出支出上限
绝不修改生产凭证

这些不是给智能体的建议，而是对图的约束。弱边界内的聪明优化器，会更快地变得危险；强边界内的聪明优化器，会更快地变得有用。

11. 观察图，而不是观察聊天

聊天记录对于一个分布式系统来说是糟糕的仪表盘。一旦工作流变成图的形状，你就需要图形状的指标。有用的指标出奇地简单：

• 关键路径延迟——最长的依赖链有多长？这告诉你真正的等待发生在哪里。
• 节点失败率——哪些 worker 最常失败？这能抓住脆弱的工具和糟糕的提示词。
• 重试率——一个每个节点重试四次才「成功」的图并不健康。
• 验证者毙稿率——如果验证者 0% 拒绝产出，它可能毫无用处；如果拒绝 80%，你的 worker 可能分工不当。
• 扇出效率——多少并行 worker 产出了独特的有用信息？这是你的信噪宽比。
• 压缩率——最终综合之前有多少原材料被移除？如果 200 条输出变成 18 条有用发现，归约器就在做有价值的工作。
• 人工干预率——人们还在哪里需要手动拯救系统？那就是你下一个架构目标。

一旦你开始追踪这些，改进系统就会容易得多。你不再凭感觉调提示词，而是在优化一台机器。

12. 五种值得掌握的图形态

你不需要一个五十种模式的模式库。这五种就能覆盖惊人数量的真实工作。

1. 分叉 / 汇合（Fork / Join）

        A
     ↙  ↓  ↘
    B   C   D
     ↘  ↓  ↙
        E

用于调研、审计、批量分析、竞品扫描。

2. 升级阶梯（Escalation Ladder）

便宜检查
    ↓ 不确定?
中等检查
    ↓ 仍不确定?
强模型 / 人类

用于大多数情况简单、少数情况值得昂贵推理的场景。

3. 锦标赛（Tournament）

候选 1 ─┐
候选 2 ─┼→ 评委 → 赢家
候选 3 ─┘

用于文案、设计、方案、代码思路、假设。

4. 映射 → 归约 → 验证 → 综合

多个 worker
     ↓
规范化 + 去重
     ↓
攻击薄弱发现
     ↓
最终答案

用于决策级研究和大规模审阅。

5. 有界发现循环（Bounded Discovery Loop）

搜索 → 有新发现? → 是 → 深入 →（回到搜索）
预算: 最大迭代数 / 最大发现数 / 最大时间

用于开始之前不知道问题有多大的场景。预算是拓扑的一部分——没有停止规则的循环不是架构，是泄漏。

13. 一份可以粘贴进几乎所有智能体框架的图规格

在写代码之前，这样描述你的系统：

目标: 最终必须存在什么?
输入状态: 什么结构化数据进入图?
并行工作: 哪些任务真正独立?
边数据: 每条依赖上究竟穿过什么信息?
归约器: 什么可以用代码规范化、去重、排序或过滤?
验证: 什么独立的测试能拒绝弱产出?
故障策略: 什么重试?什么兜底?什么失败了也不会杀死整次运行?
预算: 最多智能体数?最多 token/成本?最多墙钟时间?
人工门: 哪些不可逆操作需要批准?
输出: 返回的确切 schema 或产物是什么?

这份规格比先写二十个提示词更有价值。因为提示词优化的是节点，规格优化的是系统。

14. 什么时候不该建图

图足够强大，以至于人们开始到处用它。不要这样。在以下情况使用单个智能体：

• 任务很小
• 每一步都真正依赖上一步
• 你还在探索问题本身
• 协调的成本超过了工作本身
• 你需要一个连贯的视角，而不是广覆盖
• 人类想亲自掌舵每一个中间步骤

图买到的是宽度、隔离和控制流。它不会自动买到品味，不会自动买到真相，也不会自动让一个糟糕的任务定义变好。有时候，一个带着正确工具的好智能体才是正确的架构。要点不是把一切都图化，而是识别出什么时候一条「线」在人为地限制一项本来就不是顺序进行的工作。

真正的转变

第一代 AI 工作流是提示词工程，然后是工具使用，然后是循环。现在更难的技能是编排。不是「我怎么让模型更聪明？」，而是：

• 什么可以同时运行？
• 什么状态应该共享？什么绝不该共享？
• 什么需要被验证？
• worker 死了会发生什么？什么被允许继续？
• 成本会在哪里爆炸？
• 人类还在哪里握着钥匙？

这就是「一个执行任务的 AI」与「一个能拥有整个流程的 AI 系统」之间的区别。更多的智能体不是答案，更好的拓扑才是。

来源：X（Twitter）长文《Graph Engineering: The Complete Guide to Building Multi-Agent AI Systems》，作者 @LunarResearcher（Lunar），原文地址：x.com/LunarResearcher/status/2086071302272528833。本文为完整翻译，已去除原文中的订阅推广内容。