多 Agent + 外挂协同
主 Agent + 子 Agent + 外挂系统，三个角色怎么协同才能不互相打架、不串台、不拖慢。这篇是四种典型编排模式 + 失败传播规则 + 一个完整实战对话模板。
前置条件
- 读完 指挥中枢模式，知道三角色分工
- 读完 带 API 的 Skill 开发，能用对话让龙虾写出 skill
一、什么时候需要多 Agent
新手只用一个龙虾。但当你遇到下面这些场景，单 agent 就不够了：
- 并行任务：同时研究 3 个竞品，串行要 30 分钟，并行只要 10 分钟
- 隔离上下文：派一个子 agent 专门做"长文档总结"，不污染主 agent 的对话记忆
- 专家分工：一个 agent 专门查数据，一个专门写文案，一个专门做校对
- 风险隔离：高权限操作（生产数据库）交给一个受限的子 agent，主 agent 拿不到原始数据
判断标准：如果任务的某一部分会污染主上下文或可以并发，就拆成子 agent。
不要为了多 agent 而多 agent
每个子 agent 都是一次完整的 LLM 调用上下文——token 消耗翻倍、响应时间变长。能用一个 skill 解决的，不要拆成子 agent。子 agent 是编排层的工具，不是所有任务的工具。
二、四种典型编排模式
模式 1：主从（Master / Slave）
最简单。主 agent 拆任务、派活、收结果。
┌──────────┐
│ 主 Agent │
└────┬─────┘
│ 派发任务
┌─────────┼─────────┐
▼ ▼ ▼
┌──────┐ ┌──────┐ ┌──────┐
│子 A │ │子 B │ │子 C │
└──────┘ └──────┘ └──────┘适合：主 agent 能明确把任务拆成 N 个互不依赖的子任务。
对话模板：
帮我做一个竞品调研任务，用主从模式编排：
主任务：对比 3 个竞品（X / Y / Z）的产品定位
拆分：派 3 个独立子 agent，每个负责一个竞品：
- 子 A：抓取竞品 X 的官网和产品页，整理 markdown 摘要
- 子 B：抓取竞品 Y 的官网和产品页，整理 markdown 摘要
- 子 C：抓取竞品 Z 的官网和产品页，整理 markdown 摘要
3 个子 agent 并发跑（不串行），全部完成后主 agent 把 3 份摘要汇总成对比表。
失败策略：单个子 agent 抓取失败重试 2 次，仍失败则跳过、标注"failed"。
最后告诉我：成功几个、失败几个、对比表。模式 2：流水线（Pipeline）
每个 agent 处理一个阶段，输出给下一个。
┌──────┐ ┌──────┐ ┌──────┐ ┌──────┐
│ 抓取 │ ──> │ 翻译 │ ──> │ 摘要 │ ──> │ 排版 │
└──────┘ └──────┘ └──────┘ └──────┘适合：任务有清晰的"上下游"阶段，每阶段需要的 prompt 完全不同。
对话模板：
帮我做一个内容处理流水线，处理这篇文章：〈URL〉
按流水线 4 阶段编排：
1. 子 agent A（抓取）：调 fetch_skill 抓原文
2. A 完成后，结果传给子 agent B（翻译）：译成中文
3. B 完成后，传给子 agent C（摘要）：做 200 字摘要
4. C 完成后，主 agent 排版推送给我
失败策略：任一阶段失败则停止整条流水线，告诉我失败位置和原因。模式 3：并行 + 汇总（Fan-out / Fan-in）
N 个子 agent 并发跑，主 agent 等齐后汇总。
┌──────────┐
│ 主 Agent │
└────┬─────┘
│ fan-out
┌─────────┼─────────┐
▼ ▼ ▼
┌──────┐ ┌──────┐ ┌──────┐
│子 A │ │子 B │ │子 C │
└──┬───┘ └──┬───┘ └──┬───┘
└─────────┼─────────┘
│ fan-in
▼
┌──────────┐
│ 主 Agent │ ← 汇总
└──────────┘跟主从的区别：主从每个子 agent 任务可能不同，fan-out/in 的子 agent 任务模板相同，只是参数不同。
适合：批量同质任务（处理 10 个文件、查 50 个 URL）。
对话模板：
帮我做一个批量处理任务，用 fan-out/in 模式：
任务：对下面 10 个 URL，每个派一个子 agent 做"抓取+摘要"
URL 列表：
〈URL_1〉
〈URL_2〉
...
〈URL_10〉
每个子 agent 任务模板相同，只是 URL 不同：
- 抓取 URL
- 返回 200 字摘要
10 个子 agent 并发跑。所有完成后，主 agent 把 10 份摘要合并成总报告。
失败策略：失败的子 agent 跳过，最后报告标注哪些 URL 失败。模式 4：协商（Negotiation）
多个子 agent 各自给出方案，主 agent 或另一个评审 agent 选最优。
┌─────────────┐
│ 主 Agent │
└──────┬──────┘
│ 分派同一个问题
┌───┴───┐
▼ ▼
┌──────┐ ┌──────┐
│专家 A │ │专家 B │ ← 各自独立给方案
└──┬───┘ └──┬───┘
└───┬────┘
▼
┌─────────────┐
│ 评审 Agent │ ← 选最优 / 合并
└─────────────┘适合：开放性问题（设计、写作、决策），单一思路容易跑偏。
对话模板：
帮我做一个设计决策任务，用协商模式：
目标：给我们团队的周报定一个模板
派两个独立子 agent 当"专家"，各自给方案：
- 专家 A：偏向"数据驱动"风格，重点是 KPI 表格，理由是清晰可量化
- 专家 B：偏向"叙事"风格，重点是进展故事，理由是好读有温度
两个方案都给我后，对比优劣：
- 数据驱动的优劣
- 叙事的优劣
然后根据我们团队的风格（〈描述团队特点〉），选一个或合并，给出最终方案。三、子 Agent 和外挂的配合
子 agent 是"龙虾的分身"，外挂是"龙虾的同事"。两者经常配合：
| 场景 | 子 Agent 干什么 | 外挂干什么 |
|---|---|---|
| 批量数据处理 | 决定处理哪些数据、用什么策略 | 实际跑 SQL / 调 API |
| 多源信息汇总 | 决定查哪些源、怎么合并 | 抓取单个源 |
| 多步骤业务 | 编排步骤、应对异常 | 执行每一步的具体动作 |
铁律：子 agent 永远不直接碰外挂的敏感数据。子 agent 调用 skill，skill 调外挂，外挂返回脱敏结果给子 agent，子 agent 处理后给主 agent。
主 agent
│ 调用
▼
子 agent
│ 调用 skill
▼
Skill（脱敏层）
│ 调用
▼
外挂（执行层）四、失败传播和降级
多 agent 编排最容易翻车的地方：一个子 agent 失败了，整条链怎么办。
三种策略
| 策略 | 含义 | 适合 |
|---|---|---|
| Fail Fast | 任一子 agent 失败，立刻终止整个任务 | 强一致场景（金融、交易） |
| Fail Safe | 失败的子 agent 返回默认值/空值，继续 | 信息聚合场景（少一两个数据源不影响整体） |
| Retry & Skip | 失败重试 N 次，仍失败则跳过、记录 | 网络不稳定场景 |
在对话里明确选哪个：
任务失败策略（写进每个子 agent 的 prompt）：
- 网络错误：自动重试 3 次，间隔 5 秒
- 仍失败：跳过这个子 agent，标注"failed"
- 主 agent 汇总时，失败的子 agent 不计入总数
- 如果失败超过 50%，整个任务判定为"失败"，不发汇总报告不要让龙虾自动重试不可逆操作
重试只适用于幂等操作
如果子 agent 调的外挂是"扣款"、"发邮件"、"删数据"，绝不要自动重试——失败可能意味着"已经成功了一半"，重试会扣两次钱、发两封邮件。
非幂等操作失败 → 直接 fail，让人判断怎么处理。
五、实战：市场调研任务
把前面的拼起来。任务：给 3 个竞品做调研，输出一份对比报告。
错误做法（一个龙虾从头干到尾）
让龙虾顺序抓取 3 个网站、各自总结、对比、排版。问题：① 耗时长（串行）；② 上下文被塞满，对比时细节已丢失；③ 抓取失败时整个任务崩。
正确做法（多 agent + 外挂）
架构：
主 agent
│ 1. fan-out: 派 3 个调研子 agent
▼
[子 agent X / Y / Z] ← 各自调 fetch_skill + summarize_skill
│ 2. fan-in: 3 份调研报告汇总
▼
主 agent
│ 3. 派 1 个对比子 agent（专家角色）
▼
对比子 agent
│ 4. 产出对比表 + 结论
▼
主 agent → 推送到飞书完整对话模板：
帮我做一个市场调研任务，按下面步骤编排：
阶段 1 - 并发调研（fan-out）：
派 3 个独立子 agent，分别负责竞品 X / Y / Z。
每个子 agent 的任务：调 fetch_skill 抓官网、用 summarize_skill 生成 markdown 调研报告。
失败策略：单个子 agent 抓取失败，重试 2 次；仍失败则跳过、标注。
阶段 2 - 汇总（fan-in）：
3 个子 agent 都返回（或失败）后，主 agent 把成功的报告合并。
阶段 3 - 对比分析：
派一个"对比分析"子 agent，输入是合并后的报告，输出是对比表格（功能 / 价格 / 优劣）+ 结论。
如果阶段 1 失败超过 1 个，对比子 agent 不发起，直接报告"数据不足"。
阶段 4 - 推送：
对比报告生成后，通过飞书推送给我。
执行过程中：
- 每个阶段开始和结束时告诉我进度
- 失败的子 agent 不要重试超过 2 次
- 整个任务如果超过 30 分钟，主动停下来告诉我卡在哪关键点：
- fan-out 阶段，每个子 agent 上下文隔离——抓竞品 X 的子 agent 不知道竞品 Y 的存在
- fan-in 在主 agent 做，避免子 agent 互相串台
- 失败策略显式写——单个失败不阻断、超过 50% 失败则中止
- 每个子 agent 调 skill，不直接抓 URL——抓取失败时 skill 层处理重试
六、调试技巧
1. 先单 agent 跑通，再加 agent
不要一上来就 3 agent 并发。先用 1 个 agent 把完整流程跑通（哪怕是串行的），然后逐个阶段拆成子 agent。每拆一个就测一次。
我有一个多 agent 任务想调试。先帮我用单 agent 模式跑一遍完整流程（即使串行也行），跑通后我们再逐个阶段拆成子 agent。每拆一个就测一次。2. 让子 agent 输出过程日志
每个子 agent 在完成时，除了返回结果，还要返回：
- 用了哪个 skill
- skill 返回了多少数据
- 哪一步花了最长时间
- 是否触发了重试
主 agent 收齐后，先输出一份"执行摘要"，再输出最终结果。3. 调试时关掉并发
调试模式：所有子 agent 串行执行，每个完成后打印"子 agent X 完成"，再启动下一个。
确认逻辑正确后再切回并发模式。七、下一步
- 把这一切稳定跑在生产环境：生产部署实战
- 多 agent 涉及大量 API 调用，注意成本控制（参考 生产部署 · 成本监控）
