从"子 agent 是啥"到亲手开盲盒
半夜用 AI 编程工具写东西，看到它时不时冒出一句“正在运行智能体”，就随口问了一句：子 agent 是啥？
结果一路问下去，从“能不能让几个子 agent 吵架”问到“那我写代码到底该不该用”，又去搜了正反两方的文章，最后自己开了两个实验。这篇把整个过程整理一下，包括我当时的疑问和得到的答案。
子 agent 是什么
一句话：子 agent 是主 agent 派出去干活的临时帮手。
平时跟你对话的那个是主 agent。碰到某个比较独立、或者要翻很多文件的任务，主 agent 可以再开一个新的 agent，给它一段任务说明，让它自己去跑。跑完以后，子 agent 只交回一份结论，主 agent 拿着结论继续往下做。
打个比方：我是组长，跟组员说“去把这个仓库里跟网络同步有关的代码都找出来，告诉我结构是怎样的”。组员自己去翻几十个文件，回来只跟我说三句话。我不用亲自看那几十个文件，脑子也就不会被塞满。
好处：
- 省上下文：大量搜索、读文件的过程都在子 agent 那边，主对话只留下结论，长任务不容易“忘事”。
- 能并行：几件互不相关的事可以同时派给几个子 agent。
- 专人专事：可以定义不同类型的子 agent，给它们不同的工具权限和提示词，写成配置文件放在项目里，以后按名字调用。
代价：
- 子 agent 是从零开始的，看不到你和主 agent 之前聊过什么，任务说明必须写清楚。
- 交回来的只是总结，细节可能丢掉。
- 每个子 agent 都要额外消耗 token。
我的第一个想法：让它们吵架
知道这个以后，我第一反应是：能不能出几个方案，让几个子 agent 吵架，谁吵赢了就听谁的？
答案是可以，这种玩法叫多 agent 辩论（multi-agent debate）：每个方案派一个子 agent 当“辩护律师”，为自己的方案找论据、挑别人的毛病，最后交给一个裁判打分。
但“谁吵赢听谁的”有几个坑：
- 吵赢不等于正确。 子 agent 都是同一个模型，谁话说得漂亮、谁更会抓对方小毛病，谁就容易“赢”。所以一定要给裁判明确的评判标准，别让它凭感觉判。
- 它们会附和。 模型天生有点爱认同别人，吵两轮就变成“你说得也有道理”。要明确要求“必须坚持立场，只能指出对方的具体问题”。
- 背景要给全。 子 agent 看不到你之前的对话，你的约束条件得写进任务说明，不然它们会在真空里瞎吵。
后来我觉得更有用的版本是互相找茬：每个子 agent 只负责挑别人方案的致命问题，最后看哪个方案被挑出的硬伤最少、最好修。得到的信息比“谁赢了”有用得多。
再进一步：主 agent 当主持人
接着我又想：能不能让一个主 agent 来判断几个子 agent 之间的沟通？
在我用的工具里，本来就只能这么做。子 agent 之间不能直接说话，所有消息都要经过主 agent 转交。所以结构天然就是“主持人 + 几个辩手”。如果想要多轮有来有回，就让主 agent 把 A 说的话转给 B 和 C，让它们针对性回应，再把回应转回去。
三轮里最有价值的是第 3 轮：一个方案的问题，连它自己的“辩护律师”都承认了，那基本就是真问题。
几个注意点：
- 主持人可能偏心，转话时悄悄概括、改变语气。所以要求它“只转原文，不加自己的倾向”。
- 轮数不是越多越好，3 轮已经够多，再往后基本只是重复和互相客气。
不只是吵架：子 agent 还能干什么
出点子
我又问：能不能让几个子 agent 出点子，让游戏变得更好玩？
可以，但思路跟辩论正好相反。辩论是收敛，从几个方案里挑一个；出点子是发散，先尽量多想、想得不一样，最后再筛。
最大的问题是几个子 agent 想出来的东西容易雷同，毕竟是同一个模型。解决办法是给每个子 agent 不同的视角或限制：
- 按玩家类型分：爱社交起哄的、爱精打细算的、爱搞破坏坑人的、第一次玩的新手
- 按切入点分：只想玩家互动的、只想节奏的、只想惊喜和笑点的
- 加奇怪的限制：比如“不准加新道具卡”“必须让落后的人有翻盘机会”
流程是：各想各的（互相看不到，避免被带偏）→ 互相接力（只能在别人点子上加东西，不能否定）→ 再筛选。
不过 AI 想的“好玩”是纸面上的好玩，真好不好玩，还是得拉朋友玩一局才知道。
其他用途
- 多角度代码审查：一个只看安全，一个只看性能，一个只看“一年后自己还看不看得懂”。
- 各持一种猜测抓 bug：联机偶尔不同步，一个怀疑网络时序，一个怀疑状态没重置，一个怀疑客户端逻辑，看谁找到的证据最硬。
- 一个写、一个攻：一个写服务端代码，另一个专门想办法把它搞崩。
- 模拟玩家：几个子 agent 扮演不同的朋友读游戏规则，说出哪里看不懂、哪里无聊。
- 事前验尸：假设项目半年后失败了，让几个子 agent 各写一个失败原因。
- 出题、答题、批改：复习的时候一个出题、一个批改，我自己来答。
- 模拟面试小组：技术面试官、HR、挑刺的主管各问一轮。
判断方法很简单：如果你会想“问问几个不同的人怎么看”，那就适合开几个子 agent。 有明确答案的事，比如某个函数怎么写、某个报错怎么修，一个 agent 就够了。
外面的人怎么说
我顺便搜了一下相关的文章，正反两方都有。
支持派：Anthropic《How we built our multi-agent research system》。 他们的深度研究（Research）功能就是多 agent 做的：一个主 agent 统筹，把任务分给几个并行的子 agent。他们内部评测里，多 agent 版本比单个 agent 高出 90.2%。但文章也讲了坑：一开始主 agent 给子 agent 的指令太简短，子 agent 经常理解错，或者重复做一模一样的搜索。
反对派：Cognition（Devin 团队）《Don’t Build Multi-Agents》。 他们举了个很形象的例子：让一个 agent 做 Flappy Bird 的背景、另一个做小鸟，两边不共享上下文，最后可能一个是马里奥风格的世界，一个是写实风的鸟。他们建议用更简单的线性结构，一个主 agent 掌握全部上下文。不过大约 10 个月后，他们也表示形势变了，在 Devin 里实现了几种特定的多 agent 流程。
两派其实没那么对立。 有篇分析总结得很好：Cognition 处理的是需要共享状态的任务，隔离会把事情搞坏；Anthropic 处理的是互相独立的任务，隔离恰恰是重点。任务决定架构。
UC Berkeley《Why Do Multi-Agent LLM Systems Fail?》 发现多 agent 系统在常见基准上的提升往往很小，总结出 14 种失败模式，比如无视其他 agent 的输入、该问清楚的时候不问、跑着跑着偏离目标。
专门讲辩论的：
- MIT 的开山论文说辩论有用：算术题准确率从 67.0% 提到 81.8%。
- 但后续几篇研究泼了冷水：如果总调用次数一样，辩论往往比不过“多生成几次，然后投票”；而且辩论的好处几乎都来自第一次交换答案。还有一个“多数暴政”效应：大多数 agent 给了同一个答案，不管对错，少数派都倾向于随大流。
对我的启发是：
- 辩论一两轮就够，后面主要是在烧 token。
- 有标准答案的问题，让几个 agent 独立作答再投票，可能更有效也更省。辩论更适合用来暴露问题，而不是直接产出结论。
- 写代码别让多个子 agent 同时改同一块东西，不然就是 Flappy Bird 那种翻车。
我写代码时到底该不该用
结论是：要了解，但不用刻意去用。
首先，我用的编程工具本来就会自己派子 agent。比如问“这个项目的联机逻辑在哪”，它常常会自动开一个只读的探索型子 agent 去翻文件。所以不用每次都想着“要不要开”，需要知道的是在哪些场合主动点名让它用，以及什么时候拦住它。
适合用的：摸清代码结构、改完之后审查、查资料、几件互不相关的事并行、原因不明的 bug 各查一个方向。
不适合用的：多个子 agent 同时改代码、改按钮修报错这种小任务、需要前面讨论上下文的任务。
“审”等于“判断”吗？
不完全等于。
- 审：找问题、摆证据、评估风险。“这里有个空指针。”
- 判断：在审的基础上做决定。“所以不上这个方案。”
有客观标准、能验证的判断，比如有没有 bug、符不符合接口文档，交给子 agent 没问题。但需要权衡取舍的判断，比如这个风险值不值得冒、先求快还是先求稳，最好留给自己。原因有三个：它缺我的背景，它有偏见（容易偏向写得长、写得自信的答案），而且它不承担后果。
这其实挺像我想当的技术组长：组员负责发现问题，组长负责做取舍。
几个让我想通的类比
角色提示词和子 agent 有什么区别？
以前常见的写法是“你是一位 XX 面试官，我现在正在接受你的面试”。子 agent 是不是就是把这个包装成了专业名词？
有一部分是。子 agent 配置文件的正文，确实就是一段角色提示词。但区别在于：角色扮演是让同一个人换顶帽子说话，子 agent 是真的派了另一个人出去。
| 角色扮演提示词 | 子 agent | |
|---|---|---|
| 记忆 | 和主对话共用 | 独立的上下文，从零开始 |
| 工具 | 跟主对话一样 | 可以单独限制，比如只读 |
| 模型 | 跟主对话一样 | 可以单独指定 |
| 怎么工作 | 跟你一来一回地对话 | 自己去干活，干完交报告 |
| 跟谁说话 | 跟你 | 只跟主 agent |
有个容易误会的地方：正因为子 agent 不直接跟你对话，“你当面试官我来面试”这种需要一来一回的场景，反而不适合做成子 agent，直接在对话里用角色提示词就行。
另外，“你是一位资深 XX”这类说法主要改变的是关注点和语气，并不会让模型突然多懂一些知识。真正让子 agent 好用的，是把任务、约束、要交回什么写清楚。
像美国的陪审团吗？
我又问：是不是像陪审团那样，不展示讨论过程，只展示讨论结果？
抓住了一个点：主 agent 只拿到结果，拿不到过程。 但有几处对不上：陪审团是一屋子人互相争论，子 agent 之间根本看不见彼此；陪审团的裁决有约束力，子 agent 交的只是一份报告，采不采纳由主 agent 和我决定。
所以更像的比喻是专家证人：各自去查，各自交报告，最后由法官定夺。也正因为主 agent 只看报告，报告的格式很关键，最好要求它交回结论、证据、把握有多大，别只回一句“没问题”。
完整工作流程
其中最关键的是第 ③ 步。子 agent 从零开始，任务说明就是它知道的全部，写得含糊，它就会理解错或者做重复的事。这跟 Anthropic 那篇文章踩的坑一模一样。
几种常见玩法汇总：
| 玩法 | 结构 | 适合 |
|---|---|---|
| 分头调研 | 几个子 agent 各查一块，主 agent 汇总 | 摸代码结构、查资料 |
| 审查 | 写完，子 agent 挑刺，主 agent 修 | 改完代码之后 |
| 辩论 | 各护一个方案，主 agent 传话、当裁判 | 技术选型（一两轮就够） |
| 头脑风暴 | 不同视角各自发散，互相接力，再筛选 | 游戏玩法、起名 |
| 多猜测排查 | 各持一种猜测去找证据 | 原因不明的 bug |
实验：开了两个盲盒
光说不练没意思，我开了两个会话，同时跑辩论。
实验一（桌面工具选型）
用的是单轮版：三个辩手各说各的，裁判一次判完。
一开始没加任何限制，跑了半个多小时还没出结果。后来加了一句“子 agent 不要联网搜索，只根据给定背景论证，每份陈述控制在 500 字以内”，再把推理强度从最高档调成中等，重跑几分钟就出了结论。
裁判做得好的地方：
- 抓出了“打错靶子”。 有辩手攻击某个方案会“直接改数据库文件”，但那个方案根本没这么做，裁判判了夸大。
- 用我的背景反驳夸大。 有辩手说某门语言我“看不懂”，裁判用我修过相关课程这一点驳回了。
- 找到了最致命的一条，还额外列出了开工前要确认的前提。
但它也漏了东西：有一个方案被判“做不到某件事”，其实换个调用系统自带工具的思路就能做到。可是三个辩手都没提，裁判也就没判。辩手只会在给定的方案里攻防，裁判也只判已经提出的论点，没人提出的选项就会被漏掉。 所以最后拍板还得靠自己。
实验二（大富翁联机）
用的是三轮版：开场、交叉质询、回应。
这个会话我没来得及发那句限制。跑了 38 分钟，三个辩手还停在第 1 轮开场陈述。我让主 agent 停掉子 agent，把已经交回的内容贴出来，它的回答是：
三个子 agent 都已停止。它们在停止前都没有交回开场陈述，所以没有可贴的原文。
38 分钟，一个字都没拿到，哈哈。
这两个实验让我亲眼验证了几件事：
- 主 agent 确实只能拿到最终报告，半成品会全部丢失。
- 不加限制的子 agent 可以一直跑下去，不知道在忙什么，大概率是在不停地查资料。
- 至少在我用的界面里，运行中的子 agent 点不开，跑的过程中我和主 agent 都看不到里面在干什么。
- 多 agent 的代价是实实在在的时间和额度，研究里说它费 token，这回算是亲眼看到了。
怎么让盲盒变透明
这种“盲盒感”在一定程度上是子 agent 的设计本身决定的：它存在的意义，就是把过程挡在主对话外面。所以没有完美的解法，只能按需要打开盒子：
- 限制子 agent 的活：不联网、限字数，把每一轮变成一个很快就能交回的小任务。盒子小了，开出来是什么马上就能看到。
- 要求原文转发：每一轮先把子 agent 交回的原文完整贴出来，不要压缩，再写总结。实验一的结果里，三方立论那一节标着”（压缩）“，说明我看到的已经是转述过的版本。
- 判定时引用原话：每条判定都附上被判定的那句原话，方便检查有没有断章取义。
- 把全过程写进文件：对话里只放结论，完整过程放进一个“辩论记录”文档。
- 每轮停下来等我：每一轮结束先停，我说“继续”再进入下一轮。这样我变成真正的主持人，可以中途补背景、追问，也可以直接叫停。
| 场合 | 透明程度 |
|---|---|
| 随便练手、小决定 | 只看结论 |
| 正经的技术选型 | 原文 + 带引用的裁判 |
| 很重要、不好回头的决定 | 每轮停下来等我 |
连 Anthropic 都说他们专门做了一套工具去追踪 agent 之间的交互，可见这个问题谁都会遇到。越重要的决定，越要把盒子打开。
我的结论
子 agent 是被派出去的专人：说明要写清，干完交报告；读、查、审交给它，写交给主 agent，大判断留给自己。
这跟我想当的技术组长其实是一回事：会派活、会验收、会拍板，而不是什么都自己干，也不是什么都甩给别人。
附录：辩论提示词模板
这是我在实验一里用的结构，加上了后来总结的限制和透明度要求，把背景和方案换成你自己的就能用：
我要做的事：（一句话描述）
背景约束：
- （人手、时间）
- （你熟悉和不熟悉的技术）
- （硬性限制）
- （必须满足的功能）
候选方案：
A. ……
B. ……
C. ……
请这样做：
1. 开 3 个子 agent，每个负责一个方案，任务说明里包含上面全部背景约束。
子 agent 不要联网搜索、不调用工具，只根据给定背景论证，每份控制在 500 字以内。
每个子 agent 要：
- 论证自己的方案为什么最合适（最多 5 点）
- 指出另外两个方案在这个场景下的具体硬伤（每个最多 3 点，必须具体）
- 坚持立场，不要说"其他方案也不错"
2. 结果交回后，先把三份原文完整贴出来，不要压缩。
3. 然后你当裁判，逐条判断每个硬伤是真问题、可以规避，还是夸大，并引用被判定的原话。
4. 按这些标准给每个方案打 1-5 分：（你自己的标准）
5. 给出推荐，并说明选它最需要提前注意的 1-2 个风险。
先别写代码，只要这份分析。