13 多 Agent

第一部分 速记页

第二部分 易混对照

第三部分 面试口述稿

3.1 “你怎么看多 Agent？”

我觉得要看任务能不能拆成互不依赖的部分。

多 Agent 真正的好处有三个：上下文隔离，每个子 Agent 只看自己那部分资料，不会被无关内容干扰；并行，几个方向同时做，总时间短；专业化，不同子 Agent 可以用不同的提示词和工具。

代价也很明显：token 用量大，Anthropic 公开的研究系统里，多 Agent 的 token 大约是普通对话的 15 倍；子 Agent 各自做决定，决定之间可能冲突；子 Agent 把结果压成摘要交回来，摘要里没写的信息主 Agent 就拿不到；出了问题要在好几条轨迹里找原因。

所以像调研这种可以按方向拆开、广度优先的任务，多 Agent 效果好，Anthropic 的系统比单 Agent 在他们的内部评测上高了 90%；而像写代码这种步骤之间强依赖、需要一致决定的任务，Anthropic 自己也说不适合，Cognition 2025 年的文章更是直接建议用单线程 Agent。不过到 2026 年，Cognition 自己也改了说法：写操作仍然只让一个 Agent 做，但可以加一个上下文干净的评审 Agent，或者让管理 Agent 给多个子 Agent 分派互不重叠的范围。所以现在比较稳妥的说法是”动手的只有一个，出主意、做检查的可以有多个”。

我项目是交叉编译，依赖链是串行的，所有步骤操作同一个工作目录，所以我用的是单 Agent。

3.2 “多 Agent 有哪几种常见模式？”

常见的有四种。

主管-工人：一个编排 Agent 把任务拆开，派给多个子 Agent，收回结果再汇总。Anthropic 的研究系统就是这种，主 Agent 规划方向，子 Agent 并行搜索，最后还有一个专门处理引用的 Agent。

流水线：几个 Agent 按固定顺序处理，前一个的输出是后一个的输入，比如先抽取、再分析、再写报告。其实这更接近工作流。

评审：一个 Agent 生成，另一个 Agent 检查并给意见，循环几轮。能检查的东西最好用程序检查，比如跑测试，模型评审作为补充。

交接：一个入口 Agent 判断用户意图，把对话转给专门处理退款、技术问题的 Agent，由它接着和用户对话。OpenAI Agents SDK 里叫 handoff。

另外还有一种很实用的轻量用法：主 Agent 把一个边界清楚的调查任务交给子 Agent，子 Agent 在自己的上下文里读一大堆文件，只把结论交回来，主 Agent 的上下文就不会被塞满。

3.3 “多 Agent 为什么会出问题？怎么缓解？”

我觉得最核心的问题是 Cognition 那篇文章讲的：每个行动背后都有隐含的决定，子 Agent 各自看到的上下文不同，做出的决定就可能冲突，最后拼不起来。它举的例子是做 Flappy Bird 游戏，一个子 Agent 做背景做成了超级马里奥风格，另一个做鸟的动作也不像这个游戏，汇总的 Agent 没法把两个不一致的结果合起来。

放到我项目的场景：如果一个子 Agent 编 zlib，另一个编 libpng，编 zlib 的决定编静态库还是共享库、装在哪、开不开 PIC，编 libpng 的如果不知道这些决定，大概率接不上。我评测里真实出现过”静态依赖没开 PIC 链不进共享库”这类报错，后来整理进了知识库。

缓解办法：一是事先由主 Agent 把关键决定定好，写清楚发给每个子 Agent，不要让它们各自猜；二是任务描述要详细，Anthropic 的经验是任务描述太简单，子 Agent 会重复劳动或者漏掉东西；三是子 Agent 返回结构化的结果，而不只是一段自由文本；四是最后有程序化的验收，而不是只靠汇总 Agent 判断。

如果这些做起来很别扭，往往说明任务本身不适合拆。

3.4 “多 Agent 的成本怎么看？”

要分开看时间和 token。

并行主要省时间。Anthropic 的文章里说并行调用工具能让复杂查询的研究时间最多缩短 90%。

token 不一定省。每个子 Agent 都要带自己的系统提示词和任务说明，而且因为并行便宜了时间，系统往往会查得更多、更广。他们的数据是多 Agent 系统的 token 大约是普通对话的 15 倍，单 Agent 大约是 4 倍。他们还发现在 BrowseComp 这个评测上，token 用量一项就解释了 80% 的效果差异，也就是说多 Agent 效果好，很大程度上是因为花了更多 token。

我自己做过一个简单的估算：同样读 12 份资料，单 Agent 不压缩时每一步都重发全部历史，输入合计最大；拆成三个子 Agent 各读 4 份，输入合计降到一半左右，和单 Agent 定期压缩历史差不多。但如果子 Agent 因为并行而各自多查一倍，总量就反过来超过单 Agent 了。所以多 Agent 适合任务价值高、值得多花钱换效果和时间的场景。

3.5 “你的项目如果要改成多 Agent，你会怎么设计？”

首先我会说目前不建议改，因为依赖链是串行的，所有步骤共用一个工作目录，拆开得到的并行收益很小。

如果真的要拆，我会选一个边界最清楚的地方：依赖编译。评测里困难项目的轨迹显示，编 libpng 之前要先完成一整个”编 zlib”的子任务，编 re2 之前要先编 abseil，这部分会在主 Agent 的上下文里留下几十步的试错记录。

设计上，主 Agent 发现缺依赖时，先把关键决定定下来：库类型、安装位置、要不要 PIC、用哪个 toolchain，然后派一个子 Agent，只给它依赖的源码目录和这些决定。子 Agent 在自己的上下文里编完，程序先验收产物确实存在、架构正确，然后只返回安装路径和一段摘要。主 Agent 拿到后继续配置主项目。

这样主 Agent 的上下文里不会有编依赖时的几十条报错，但主 Agent 也看不到子 Agent 踩过的坑。如果主项目后面遇到的问题和依赖的编译选项有关，就得靠摘要里写得够不够全。这个取舍要用评测去验证，而不是想当然。

第四部分 逐个详解

4.1 几种协作模式

先说多 Agent 这个说法是怎么来的。 “多智能体系统”在人工智能研究里是个老题目，比大模型早几十年。那时的”智能体”是按规则写好的程序，研究的是一堆程序怎么分工、怎么谈判。1980 年 Reid G. Smith 在 IEEE Transactions on Computers 上发表的合同网协议（论文）就很像今天的主管-工人：管理者把任务公开出来，各个节点报价，管理者选一个签”合同”。

大模型出来以后，这个词换了一种意思：每个”智能体”是一个带着自己提示词的模型实例。2023 年是集中出现的一年，3 月的 CAMEL（论文）让两个模型分别扮演用户和助手角色对话完成任务；8 月微软等机构发布 AutoGen（论文），做成了一个让多个 Agent 互相对话来完成任务的框架。这类做法很快流行起来，实际用下来的代价也逐渐暴露：token 成倍增长，各个 Agent 各做各的决定、互相接不上。到 2025 年就有了本篇开头提到的 Anthropic 和 Cognition 两篇观点相反的文章，后面几节的数据大多来自它们。

多 Agent 系统（multi-agent system）：由多个模型实例组成，每个实例有自己的提示词、工具和上下文，分工完成一个任务。05 篇讲过的”编排者-工人”工作流是它的一种形态，区别在于分派多少、分派什么由模型动态决定。

主管-工人（orchestrator-workers）

flowchart TD
    U[用户问题] --> O[主管 Agent<br/>规划、拆分、汇总]
    O -->|子任务 1<br/>详细说明| W1[子 Agent 1<br/>自己的上下文]
    O -->|子任务 2| W2[子 Agent 2]
    O -->|子任务 3| W3[子 Agent 3]
    W1 -->|摘要| O
    W2 -->|摘要| O
    W3 -->|摘要| O
    O --> R[最终结果]

适合：能拆成互不依赖的方向，比如”调研某行业的五家主要公司”。

流水线（pipeline）

flowchart LR
    A[抽取 Agent] --> B[分析 Agent] --> C[写作 Agent] --> D[校对 Agent]

适合：步骤固定、每步职责清楚。但如果顺序是固定的，用普通工作流（每步一次模型调用）通常就够了，不一定需要每步都是一个会循环调工具的 Agent。

评审（generator-critic）

flowchart LR
    G[生成 Agent] -->|草稿| C[评审 Agent]
    C -->|意见| G
    C -->|通过| OUT[输出]

05 篇讲过的”评估-优化循环”。关键提醒：能用程序检查的，不要用模型评审。我项目的验收是程序重新构建并检查 ELF 架构，比模型判断”看起来编译成功了”可靠得多。

交接（handoff）

sequenceDiagram
    participant U as 用户
    participant T as 分诊 Agent
    participant R as 退款 Agent
    U->>T: 我上周买的耳机坏了想退
    T->>R: 交接（带上对话历史）
    Note over T,R: 控制权转移
    R->>U: 请提供订单号
    U->>R: 12345
    R->>U: 已为您提交退款

适合：客服这类有明确分类、每类处理方式不同的场景。OpenAI Agents SDK 把它作为核心概念之一（12 篇）。

子 Agent 当工具（最常见的轻量用法）

主 Agent 把一个边界清楚的问题交给子 Agent，比如”在这个代码库里找出所有调用了 find_package(ZLIB) 的地方”。子 Agent 在自己的上下文里读几十个文件，只返回结论。控制权始终在主 Agent，子 Agent 做完就结束。Cognition 的文章也认为这种”回答边界清楚的问题”的子 Agent 是可以的。

4.2 好处从哪来

1. 上下文隔离。 06 篇讲过上下文越长越不可靠（Context Rot），而且每一步都要重发全部历史。子 Agent 在自己的上下文里读大量资料，交回来的只是几百字的摘要。主 Agent 的上下文保持干净，每个子 Agent 的上下文也只装自己那一份。

2. 并行。 几个子 Agent 同时工作，总耗时接近最慢的那个，而不是所有人加起来。

3. 专业化。 不同子 Agent 可以用不同的系统提示词、不同的工具集，甚至不同的模型（简单的用便宜模型）。

Anthropic 的多 Agent 研究系统（How we built our multi-agent research system，2025-06-13）是目前公开数据最多的一个例子：

“token 用量解释了 80% 的效果差异”这句话很关键。 它的意思是：多 Agent 系统效果好，很大程度上是因为它能花更多 token 去查更多东西，而单个上下文窗口装不下这么多。多 Agent 是一种”把更多 token 有效地用起来”的方式，不是免费的智力提升。

4.3 代价从哪来

Cognition 的 Don’t Build Multi-Agents（Walden Yan，2025-06-12）提出了两条原则：

1. 共享上下文，而且要共享完整的 Agent 轨迹，不只是单条消息
2. 行动里带着隐含的决定，决定互相冲突就会产生坏结果

文章里的例子：让系统做一个 Flappy Bird 游戏，拆成两个子任务并行。一个子 Agent 把背景做成了超级马里奥的风格，另一个做的鸟也不像这个游戏里的样子，最后汇总的 Agent 面对的是两份互相不搭的结果。

问题出在哪？ 每个子 Agent 只看到分给自己的那句任务描述，“做背景”这句话里没写风格，子 Agent 就自己做了决定。两个子 Agent 做的决定彼此看不见，也就没法保持一致。

Cognition 的建议：

• 大多数情况下用单线程的线性 Agent，上下文连续
• 任务特别长、上下文装不下时，用一个模型把历史压缩成关键细节、决定和事件
• 子 Agent 用来回答边界清楚的问题是可以的，但要避免让多个子 Agent 并行地做需要彼此配合的工作

两篇文章不矛盾。 Anthropic 的研究任务天然可以按方向拆开，子 Agent 之间几乎不需要协调，查到什么交回来就行；Cognition 做的是编码 Agent，改代码的每一步都依赖前面的决定。Anthropic 的文章自己也写了编码任务不太适合。

2026 年的进展：从”要不要”变成”哪种能用”。 上面两篇都是 2025 年 6 月的。之后一年里，编程 Agent 普遍用上了子 Agent，几家也公开了新的经验：

Cognition：Multi-Agents: What’s Actually Working（Walden Yan，2026-04-22）。同一个作者回头修正了自己的结论，核心一句是：多 Agent 系统目前在”写操作保持单线程、其他 Agent 只贡献判断而不动手”时效果最好。

这和 4.3 节的两条原则是一致的：评审 Agent 和”聪明朋友”都不做写操作，就不会产生互相冲突的隐含决定。

Anthropic：Building a C compiler with a team of parallel Claudes（2026-02-05）。这是”并行改同一个代码库”做成了的例子，但条件很苛刻：

所以”并行改代码”不是不能做，而是要同时满足：任务能拆到文件级、有自动化测试兜底、能承受很高的成本。

Anthropic：Harness design for long-running application development（2026-03-24）用的是规划、生成、评估三个 Agent。单独设评估 Agent 的原因是模型评价自己的作品时偏宽松，会自信地夸一个平庸的结果；评估 Agent 用 Playwright 真去点页面、按标准打分，把问题反馈给生成 Agent。代价同样明显：做一个复古游戏编辑器，单 Agent 20 分钟花 9 美元，完整的三 Agent 流程 6 小时花 200 美元，贵了 22 倍，但做出来的东西真能用。

代价汇总：

4.4 动手实验 1：上下文隔离到底省了什么

用字符数粗略代表 token，模拟”读 12 份资料”的调研任务，比较四种做法的单次最大输入和输入合计。保存为 context_cost.py。

SYSTEM = 1200
DOC = 3000
SUMMARY = 300
TOPICS = 3
CALL = 60


def run_agent(steps, compress_every=None):
    context, calls = SYSTEM, []
    for i, step in enumerate(steps, 1):
        calls.append(context)
        context += CALL + step
        if compress_every and i % compress_every == 0:
            calls.append(context)
            context = SYSTEM + SUMMARY * (i // compress_every)
    calls.append(context)
    return calls


def scenario(name, agents):
    all_calls = [c for calls in agents.values() for c in calls]
    total = sum(all_calls)
    detail = "，".join(f"{who} {len(c)} 次" for who, c in agents.items())
    print(f"{name:<14} 调用 {len(all_calls):>2} 次  单次最大 {max(all_calls):>6,}  合计 {total:>8,}  ({detail})")
    return total


docs = 4
base = scenario("A 单 Agent", {"主": run_agent([DOC] * TOPICS * docs)})
scenario("B 单 Agent+压缩", {"主": run_agent([DOC] * TOPICS * docs, compress_every=docs)})
multi = {f"子{t + 1}": run_agent([DOC] * docs) for t in range(TOPICS)}
multi["主管"] = run_agent([SUMMARY] * TOPICS)
scenario("C 多 Agent", multi)
wide = {f"子{t + 1}": run_agent([DOC] * docs * 2) for t in range(TOPICS)}
wide["主管"] = run_agent([SUMMARY] * TOPICS)
wide_total = scenario("D 多 Agent 查两倍", wide)
print(f"D / A = {wide_total / base:.2f}")

实际输出（Python 3.14，只用标准库）：

A 单 Agent      调用 13 次  单次最大 37,920  合计  254,280  (主 13 次)
B 单 Agent+压缩   调用 16 次  单次最大 14,040  合计  116,400  (主 16 次)
C 多 Agent      调用 19 次  单次最大 13,440  合计  116,760  (子1 5 次，子2 5 次，子3 5 次，主管 4 次)
D 多 Agent 查两倍  调用 31 次  单次最大 25,680  合计  369,840  (子1 9 次，子2 9 次，子3 9 次，主管 4 次)
D / A = 1.45

逐段讲。

常量。 系统提示词 1200 字、每份资料 3000 字、摘要 300 字、3 个调研方向、每次工具调用本身 60 字。这些数都是假设的，只用来看趋势。

run_agent(steps, compress_every=None)：模拟一个 Agent 的循环。

• steps 是一个列表，每一项是”这一步工具返回的内容长度”
• calls 记录每次调模型时的输入长度。Agent 每一步都要把当前全部上下文发给模型，所以输入长度就是当时的 context
• for i, step in enumerate(steps, 1)：enumerate 同时给出序号和元素，第二个参数 1 表示序号从 1 开始
• context += CALL + step：模型发起一次工具调用，结果放回上下文，上下文变长
• if compress_every and i % compress_every == 0：% 是取余数。每读完 compress_every 份资料就压缩一次：先多一次调模型（让模型写摘要），然后上下文重置为”系统提示词 + 到目前为止的所有摘要”
• 循环结束后再 append 一次，代表最后那次调模型给出结论
• 默认参数 compress_every=None，None 在 if 里当作假，不压缩

scenario：打印一种做法的统计。

• agents 是字典，键是 Agent 名字，值是它的 calls 列表
• [c for calls in agents.values() for c in calls]：把所有 Agent 的调用摊平成一个列表
• "，".join(...)：用中文逗号把各 Agent 的调用次数连起来

四种做法。

• A：一个 Agent 依次读完 12 份，从不压缩
• B：一个 Agent，每读 4 份压缩一次
• C：3 个子 Agent 各读 4 份，主管读 3 份摘要
• D：和 C 一样，但每个子 Agent 各读 8 份，模拟”因为并行不费时间，就查得更广”
• {f"子{t + 1}": ... for t in range(TOPICS)}：字典推导式，和列表推导式类似，用花括号，冒号左边是键、右边是值

看结果。

1. A 最贵的原因是每一步重发全部历史。输入长度一直在涨，合计近似于平方增长。06 篇讲过这一点，我项目 288 次运行输入是输出的 41.6 倍，就是这个原因
2. C 和 B 几乎一样（116,760 对 116,400）。上下文隔离省下的 token，单 Agent 定期压缩也能省下来。多 Agent 相对压缩真正多出来的，是并行省时间和每个子 Agent 能带不同的提示词和工具
3. D 比 A 还贵 45%。当并行让系统做更多的事，总 token 会反过来超过单 Agent。这和 Anthropic 数据里多 Agent 系统用 token 多得多是一致的：它的效果提升本来就是靠查更多东西换来的
4. C 的单次最大输入只有 A 的约三分之一，对长上下文下模型变得不可靠这个问题，隔离和压缩都有效

这个模型的局限：没算子 Agent 的任务说明、没算摘要丢失信息导致的返工、没算缓存命中（前缀相同的部分实际很便宜），也没算主管规划和汇总本身的难度。数字不能直接套到真实系统，只用来看”钱花在哪、省在哪”。

自己改一改：

1. 把 SUMMARY 改成 1500（摘要写得更详细），看 B 和 C 的变化
2. 给 C 的每个子 Agent 的系统提示词加上 800 字的任务说明（提示：给 run_agent 加一个起始上下文参数）
3. 算一下时间：假设每次调模型 2 秒、子 Agent 完全并行，A 和 C 各要多少秒

4.5 动手实验 2：隐含决定为什么会拼不起来

用我项目的场景模拟 Cognition 说的”决定冲突”：一个子 Agent 编依赖 zlib，主 Agent 编 libpng，两边都要对 zlib 做三个决定。比较”各自决定”和”事先定好共享决定”。保存为 decisions.py。

import random

OPTIONS = {
    "zlib 库类型": ["静态库 .a", "共享库 .so"],
    "zlib 安装位置": ["deps/zlib", "_install"],
    "位置无关代码 PIC": ["开", "关"],
}


def worker(decided, rng):
    choices = {}
    for key, values in OPTIONS.items():
        choices[key] = decided.get(key) or rng.choice(values)
    return choices


def check(dep, main):
    problems = [k for k in OPTIONS if dep[k] != main[k]]
    if main["zlib 库类型"] == "静态库 .a" and main["位置无关代码 PIC"] == "关":
        problems.append("libpng 要编共享库，静态 zlib 必须开 PIC")
    return problems


for mode in ("各自决定", "先定好共享决定"):
    failures = 0
    for seed in range(1000):
        rng = random.Random(seed)
        decided = {}
        if mode == "先定好共享决定":
            decided = {"zlib 库类型": "静态库 .a", "zlib 安装位置": "deps/zlib", "位置无关代码 PIC": "开"}
        dep = worker(decided, rng)
        main = worker(decided, rng)
        failures += bool(check(dep, main))
    print(f"{mode}: 1000 次里 {failures} 次拼不起来")

rng = random.Random(7)
dep, main = worker({}, rng), worker({}, rng)
print("例子 seed=7:", check(dep, main))

实际输出（Python 3.14，只用标准库）：

各自决定: 1000 次里 918 次拼不起来
先定好共享决定: 1000 次里 0 次拼不起来
例子 seed=7: ['zlib 库类型', '位置无关代码 PIC']

逐段讲。

• OPTIONS：三个需要做的决定，每个有两个合理的选项。每个选项单独看都没错，这正是隐含决定的麻烦之处：子 Agent 不会觉得自己做错了什么
• worker(decided, rng)：模拟一个子 Agent。decided.get(key) 查有没有事先定好的决定，dict.get 在键不存在时返回 None；None or rng.choice(values) 在左边为空时取右边，也就是没人定就自己随机选一个
• random.Random(seed)：创建一个带种子的随机数生成器。种子相同，产生的随机序列就相同，保证实验可复现。两个子 Agent 共用这个生成器，但各自调用时拿到的是序列里不同位置的数，所以选择是独立的
• check(dep, main)：列表推导式找出两边不一致的决定；另外加一条真实的约束：libpng 要编共享库，静态的 zlib 必须开 PIC 才能链进去。这条来自我项目知识库的 k012，是从 run 140、160 的真实报错里提炼的
• failures += bool(check(...))：bool(列表) 在列表非空时为 True，加到整数上当作 1

看结果。

1. 各自决定时，1000 次里 918 次拼不起来。算一下：三个二选一全部碰巧一致的概率是 1/8；一致之后还要避开”静态库 + 不开 PIC”这个组合（占四分之一），成功率约 1/8 × 3/4 ≈ 9.4%，失败率约 90.6%，和实验的 91.8% 接近
2. 事先定好之后，0 次失败
3. seed=7 的例子里，两边库类型不一致，PIC 也不一致

这个实验简化得很厉害：真实的子 Agent 不是随机选，它会根据看到的信息推理，多数时候会选常见的做法。但只要子任务描述里没写，它就是在猜，而猜错一个就可能全盘接不上。决定越多，全部碰巧一致的概率下降得越快。

缓解的办法就是实验里的第二种：主 Agent 事先把关键决定定下来发给子 Agent。 难点在于，你得事先知道哪些是”关键决定”。zlib 的 PIC 这一条，是评测跑出报错之后才知道的。

自己改一改：

1. 在 OPTIONS 里加一个决定 "C 标准": ["c99", "c11"]，看各自决定的失败次数变成多少
2. 只事先定好”库类型”和”安装位置”，不定 PIC，看失败次数。想一想：漏掉一个关键决定会怎样
3. 让 main 在 dep 做完之后，直接复制 dep 的全部选择（模拟”共享完整轨迹”），和”事先定好”对比

4.6 什么时候值得用多 Agent

flowchart TD
    Q1{任务能拆成<br/>彼此不依赖的部分吗} -->|不能| S[单 Agent<br/>长任务加历史压缩]
    Q1 -->|能| Q2{各部分需要<br/>共享同一份可变状态吗<br/>比如同一个代码库}
    Q2 -->|需要| S
    Q2 -->|不需要| Q3{单个上下文装得下吗<br/>串行时间能接受吗}
    Q3 -->|都可以| S2[单 Agent 或普通工作流<br/>先别拆]
    Q3 -->|装不下或太慢| Q4{任务价值<br/>能承担数倍 token 吗}
    Q4 -->|不能| S3[缩小范围<br/>或子 Agent 只做调查]
    Q4 -->|能| M[主管-工人多 Agent<br/>事先定好共享决定<br/>结构化返回 程序验收]

适合的典型任务：

不适合的典型任务：

4.7 真要做的话，设计要点

1. 任务描述要写全。 Anthropic 的经验是，每个子任务要给子 Agent 写清楚：目标、输出格式、该用哪些工具和信息源、任务边界。只给一句”调研 X”，子 Agent 会重复别人的工作、漏掉该做的、或者做过头。

一个子任务描述的模板：

目标：交叉编译 zlib 1.3.1 到 aarch64-linux-musl，供 libpng 链接使用
已定好的决定：
  - 编成静态库，开启 PIC（libpng 要编共享库）
  - 安装到工作目录下 deps/zlib
  - 使用环境变量 CMAKE_TOOLCHAIN_FILE 指定的 toolchain，不要改
边界：只在 deps/zlib-src 和 deps/zlib 内操作，不要修改主项目
输出：JSON，包含 install_prefix、生成的库文件列表、遇到的问题摘要（不超过 200 字）
完成标准：install_prefix/lib 下存在 aarch64 架构的 libz.a

2. 按任务复杂度决定投入。 Anthropic 在提示词里写了规则，让主 Agent 根据问题复杂度决定派几个子 Agent、每个做多少次工具调用，简单问题不要派一堆子 Agent。

3. 返回结构化结果。 子 Agent 交回的不应该是一大段自由文本，而是有固定字段的结构，主 Agent 和程序都能直接读。关键的中间产物（比如编好的库、下载的文件）写到共享存储里，只把路径交回来。

4. 程序化验收每个子任务。 子 Agent 说”完成了”不算数。上面模板里的”完成标准”应该由程序检查，和我项目的 verify 一个思路。

5. 链路追踪串起所有 Agent。 主管和每个子 Agent 都是同一个 trace 下的 span（10 篇的 invoke_agent span 可以嵌套），出问题时能看到是哪个子 Agent 在哪一步出的错。

6. 考虑失败和重试。 一个子 Agent 失败了，是重试它、换个方式、还是整体失败？子 Agent 执行了一半有副作用怎么办？这些和 07 篇的幂等、恢复是同样的问题，只是多了几份。

4.8 我项目为什么没用，如果要用怎么拆

为什么没用：

如果要拆，最合理的切分点是依赖编译。

09 篇讲过第一版评测的发现：困难项目本质上是嵌套任务，编 libpng 之前要先完成一整个”编 zlib”的子任务。在单 Agent 里，编依赖时的试错记录会一直留在上下文里。

sequenceDiagram
    participant M as 主 Agent（libpng）
    participant C as 程序
    participant D as 依赖子 Agent（zlib）
    M->>M: configure 报错：找不到 ZLIB
    M->>C: 请求编译依赖 zlib
    C->>C: 定好共享决定<br/>静态库 开 PIC 装到 deps/zlib
    C->>D: 任务描述 + 共享决定<br/>只能访问 deps/
    loop 子 Agent 自己的上下文
        D->>D: 下载 配置 编译 安装
    end
    D-->>C: install_prefix、库列表、摘要
    C->>C: 验收：deps/zlib/lib/libz.a 存在且是 aarch64
    C-->>M: 验收通过，ZLIB_ROOT=deps/zlib，摘要
    M->>M: 带 -DZLIB_ROOT 重新 configure

这样拆的好处和风险：

要诚实说的是：这个设计没有实现，也没有评测数据。面试时应该说”如果要做我会这样设计，并用评测验证”，而不是说”这样会更好”。

第五部分 对照项目

对照开源实现：pi

pi（05 篇第五部分介绍过）的核心不做子 Agent，README 的理由是”做法太多，各人需求不同”，建议用 tmux 开几个 pi，或者用扩展自己做。仓库里给了一个示例扩展 examples/extensions/subagent，一千多行，正好是本篇”子 Agent 当工具”模式的一个具体实现。源码以 commit 7b4cfd6 为准。

怎么实现的。 主 Agent 多了一个 subagent 工具。调用它时，程序另起一个 pi 子进程，参数是 --mode json -p --no-session：以 JSON 事件流输出、跑完一个任务就退出、不保存会话（index.ts L300）。子进程有自己全新的上下文，主 Agent 只拿回最终输出。

每种子 Agent 用一个 Markdown 文件定义，开头写名字、可用工具、用哪个模型，正文是它的系统提示词：

三种调用方式：单个任务；并行，最多 8 个任务、同时跑 4 个；链式，上一步的输出通过 {previous} 占位符填进下一步的任务描述。还预置了几条流程，比如 /implement 是”侦察 → 规划 → 执行”。每个任务交回主 Agent 的输出最多 50KB。

和本篇内容的对应：

值得讲的点：

1. 编程 Agent 的主流做法，和本篇结论一致。 本篇引用 Anthropic 的说法，大部分编码任务不适合多 Agent；子 Agent 适合”回答边界清楚的问题、做调查”。pi 的核心不内置子 Agent，示例里并行的也都是只读调查，真正改代码的始终只有一个。

2. 用独立进程做隔离，简单直接。 不需要任何多 Agent 框架：子 Agent 就是同一个程序换了参数再跑一次，上下文天然隔离，主进程按 Ctrl+C 还能把子进程一起结束。代价是每个子 Agent 都要重新加载系统提示词和工具定义，拿不到主 Agent 已经缓存的前缀。

3. 对我项目”依赖编译子 Agent”设计的启发。 本篇 4.8 节设想过这个子 Agent。pi 的示例给了两个可以直接借的做法：一是像 scout 那样在子 Agent 的提示词里写明”输出给谁看、对方没看过什么”，并固定输出格式（我项目里就是产物路径、库类型、编译选项）；二是像 planner 那样按角色收紧工具，依赖编译子 Agent 只该在自己的依赖目录里写文件。但示例没有解决隐含决定的问题，库类型、PIC 这些共享决定仍然要按 4.8 节的设计，由程序在派任务之前定好。

第六部分 追问清单

第七部分 闭卷自测

1. 多 Agent 的三个主要好处和四个主要代价是什么？

2. Anthropic 多 Agent 研究系统的几个关键数字是什么？“token 用量解释 80% 效果差异”说明了什么？

3. Cognition 提出的两条原则是什么？Flappy Bird 的例子说明了什么？

4. Anthropic 和 Cognition 的观点矛盾吗？

5. 实验 1 里，为什么 C（多 Agent）和 B（单 Agent + 压缩）的输入合计几乎一样？D 为什么比 A 还贵？

6. 实验 2 里各自决定时失败率约 90%，怎么粗略算出来？怎么缓解？

7. 交接（handoff）和子 Agent 当工具有什么区别？各适合什么场景？

8. 给子 Agent 写任务描述时，Anthropic 建议至少写清哪几项？

9. 列出至少三类适合多 Agent 和三类不适合的任务。

10. 我项目为什么没有用多 Agent？

11. 如果给我项目加一个依赖编译子 Agent，流程是怎样的？有哪些风险？怎么证明它有用？

12. pi 的子 Agent 示例是怎么做到上下文隔离的？它针对”汇总时信息丢失”做了什么，没解决什么？

延伸阅读

1. Anthropic：How we built our multi-agent research system（2025-06-13）— 架构、token 数据、提示词经验、评测和上线挑战
2. Cognition：Don’t Build Multi-Agents（2025-06-12）— 共享上下文和隐含决定两条原则
3. Anthropic：Building effective agents（2024-12）— 编排者-工人等工作流模式
4. Anthropic：Effective context engineering for AI agents（2025-09）— 子 Agent 作为上下文管理手段
5. OpenAI Agents SDK — 交接等多 Agent 概念的实现
6. pi：subagent 示例扩展（commit 7b4cfd6）— 用独立进程实现子 Agent，含侦察、规划、评审、执行四种角色定义和链式、并行两种调用方式
7. Cognition：Multi-Agents: What’s Actually Working（2026-04-22）— 同一作者一年后的修正：写操作单线程，其他 Agent 只贡献判断
8. Anthropic：Building a C compiler with a team of parallel Claudes（2026-02-05）— 16 个 Agent 无主管并行开发，测试和锁文件怎么起作用
9. Anthropic：Harness design for long-running application development（2026-03-24）— 规划、生成、评估三 Agent，为什么评估要单独拆出来

下一篇：14 AI 应用后端——Agent 要给用户用，得有一个能流式推送、能处理长任务、能控制并发的后端。