Appearance
🐣 小a的过劳危机
小a在 pi 工坊越干越顺,能读文件、能改代码、能跑测试。老z开始给它堆活儿:"这个项目的 bug 你修着,那个新功能你也写,顺便把文档补一下。"
小a没长八只手,三个任务来回切换,顾此失彼。它修 bug 修到一半,想起还有功能没写;写功能写到一半,又记起文档没动。
"我忙不过来了!"小a崩溃,"能不能多招几个兄弟?"
老z放下茶杯:"你算是问到 Agent 世界的一个大命题了——一只 agent 够不够?要不要养一群? 这事儿,江湖上分两派。"
12.1 单兵派 vs 群殴派
先看清楚,Agent 世界对"一个还是多个"有两种哲学。
🧙 两派之争:
单兵派 群殴派 主张 一个强 agent + 好工具,搞定一切 多个专长不同的 agent 协作 比喻 一个全能的超级英雄 一个分工明确的团队 优点 简单、好控、省资源 并行、专业、能扛复杂任务 缺点 复杂任务容易顾此失彼 协调难、成本高、易混乱 代表 pi(本书主角) 各种多 Agent 框架 关键认知:pi 是坚定的单兵派。 它的整个设计都围绕"一个 agent 把活干好"。但了解群殴派,你才知道为什么 pi 这么选、什么时候你该选另一条路。
12.2 子代理:让主 agent 当"项目经理"
群殴派最基础的玩法,是子代理(sub-agent)。
🧙 子代理是什么?
子代理是主 agent 派出去的"分身"。主 agent 当项目经理,把子任务甩给子代理跑,自己不亲自下场,等子代理干完汇报结果。
老z打比方:老板(主 agent)接到一个大任务,不自己从头干,而是:
- 拆成几个子任务
- 派给不同的专员(子代理)
- 各自干完,汇报回来
- 老板汇总,给最终答案
一个具体场景
假设主 agent 收到任务:"调研竞品 A 和竞品 B,写一份对比报告。"
单 agent 做法(串行):
主 agent:查竞品 A 的资料 → 分析 A → 查竞品 B 的资料 → 分析 B → 写报告
(一步步来,慢)用子代理做法(并行):
主 agent(项目经理):
├─ 派子代理甲:"去调研竞品 A,给我结论"
├─ 派子代理乙:"去调研竞品 B,给我结论"
│ (甲乙同时干活,并行)
└─ 等甲乙都回来 → 汇总 → 写报告
(并行,快)🐣 小a眼睛亮:"所以子代理 = 把任务拆开并行干?"
🧙 "对,但有个前提——子任务得是『可独立完成』的。 如果甲乙的活儿互相依赖(甲的结果乙要用),那就并行不了,还是得串行。子代理适合『可并行、低耦合』的任务。"
12.3 Agent Teams:长期协作的"团队"
子代理是"临时雇佣",用完就散。还有种更重的玩法——Agent Teams(多 Agent 团队),像组建一个长期团队。
🧙 Agent Teams 是什么?
多个 agent 各有固定专长,长期协作完成一类任务。每个 agent 是团队里的一个"角色"。
老z打比方:不像子代理那样"临时派活",Teams 像一个常设的项目组——有固定的产品经理、前端、后端、测试,各司其职,长期配合。
一个软件开发的 Team 例子
用户提需求:"做个登录页"
↓
┌─────── Team 协作 ───────┐
│ 产品经理 agent │
│ "拆需求、定方案" │
│ ↓ ↕ ↓ ↕ │
│ 前端 agent 后端 agent │
│ "写页面代码" "写登录接口"│
│ ↓ ↓ │
│ 测试 agent(写测试用例) │
│ ↓(互相沟通、协作) │
└──────────┬──────────────┘
↓
交付完整的登录功能每个 agent 专注自己擅长的,通过某种方式沟通(传消息、共享文档等)。
🐣 小a问:"这听起来很美好,但……谁来指挥谁?消息传错了怎么办?"
🧙 "你问到点子上了——这就是 Teams 最大的难点。"
Teams 的地狱:
- 谁说了算?——多个 agent 意见冲突时,谁拍板?
- 消息怎么传?——agent A 给 B 传信息,B 没收到/理解错了怎么办?
- 状态怎么同步?——A 改了代码,B 还在用旧的,冲突了
- 成本爆炸——N 个 agent 同时跑,N 倍的 token 消耗
- 调试地狱——出错了,是哪个 agent 的锅?链路怎么追?
Teams 听起来酷,工程上极难做好。 这正是 pi 坚决不碰它的原因。
12.4 它们怎么沟通:三种协议
多个 agent 要协作,就得"说话"。江湖上有三种协议,各自管不同的事。
🧙 先记住一个区分:
- MCP:agent 跟工具/资源说话(第 10 章讲过)
- ACP:agent 跟 agent 说话
- A2A:agent 之间互相发现并协作
协议一:MCP —— 调工具(已讲)
第 10 章详细讲过。MCP 是"agent 调用工具/资源"的标准——它解决的是 agent ↔ 工具 的沟通,不是 agent ↔ agent。
Agent ←─MCP─→ 工具/资源(文件、数据库、API)协议二:ACP —— Agent 之间对话
🧙 ACP(Agent Communication Protocol)是什么?
ACP 是 agent 跟 agent 对话的协议。它定义了"一个 agent 怎么向另一个 agent 发消息、怎么收回复"。
老z打比方:MCP 是"你跟工具说话"(下单调工具),ACP 是"你跟同事说话"(商量事情)。
Agent A ←─ACP─→ Agent B
"嘿,帮我查下 X" → "好的,结果是……"协议三:A2A —— Agent 互相发现并协作
🧙 A2A(Agent-to-Agent)是什么?
A2A 比 ACP 更进一步——它不仅让 agent 能对话,还让它们能互相发现、自动建立协作关系。
老z打比方:
- MCP = 你知道有把螺丝刀,拿起来用
- ACP = 你认识老王,直接打电话跟他商量
- A2A = 你不认识老王,但有个"Agent 黄页",你能查到"谁擅长修水管",然后自动联系他协作
Agent A Agent B(陌生人)
│ │
└─── A2A 发现 ──────────┘
"哦,你擅长修水管,我正好需要"
↓
自动建立协作三种协议一句话区分
| 协议 | 沟通对象 | 一句话 |
|---|---|---|
| MCP | 工具/资源 | agent 调工具 |
| ACP | 另一个 agent | agent 跟 agent 对话 |
| A2A | 陌生的 agent | agent 互相发现并协作 |
🐣 小a总结:"所以大部分时候,我只需要 MCP——调工具就够了。ACP/A2A 是要搞『agent 团队』时才用的高级玩法?"
🧙 "完全正确。 99% 的场景,MCP 够用。ACP/A2A 是要构建大规模多 Agent 系统时才碰的。"
12.5 pi 的选择:单兵作战,一个都不上
讲了这么多多 Agent 的玩法,老z必须对小a说实话:
🧙 pi 的选择:这些,它一个都没用。
- ❌ 不用子代理
- ❌ 不用 Agent Teams
- ❌ 不用 ACP
- ❌ 不用 A2A
- ✅ 只用 MCP(而且支持有限,见第 10 章)
pi 是纯粹的单兵作战。 一个 agent,一套好工具,把活干好。
为什么 pi 这么选?
老z给小a分析了三条理由:
🧙 理由一:简单优先
单 agent 的认知负担最低——一个循环、一套工具、一个状态。多 agent 引入协调、消息传递、状态同步,复杂度指数级上升。pi 的哲学是"能用简单解决,就别上复杂"(这本书反复的主题)。
🧙 理由二:编码场景不需要
pi 干的是"帮人写代码"。写代码虽然复杂,但通常是一个上下文里串行推进的(读→改→测),不太需要多个 agent 并行。强行上多 agent,反而协调成本大于收益。
🧙 理由三:成本与可控
多 agent = N 倍的 token、N 倍的不确定性。一个 agent 出错好排查,N 个 agent 互相影响,调试是地狱。pi 选了可控性。
🐣 小a恍然:"所以『多 agent』不是更高级,而是另一种取舍?"
🧙 "对。 多 agent 解决的是『并行 + 专业分工』,代价是『复杂 + 贵 + 难控』。pi 选了相反的路:一个强 agent,把单兵战斗力练到极致。"
12.6 什么时候你该考虑多 Agent?
既然 pi 不用,那什么时候轮到你自己造 agent 时,该考虑多 Agent?老z给了一个判断框架:
🧙 四个信号——中了任意一个,才考虑多 Agent:
- 任务能清晰拆成独立子任务 —— 比如同时调研 5 个竞品(互不依赖,可并行)
- 需要不同专长 —— 比如一个 agent 专精代码、一个专精设计、一个专精文案,且这种分工是长期的
- 单 agent 上下文塞不下 —— 任务太大,一个 agent 的窗口装不下所有信息,得分给多个 agent 各扛一块
- 真有并行收益 —— 多 agent 能同时干活,省时间,且协调成本可接受
反之——如果单 agent + 好工具就能搞定,别上多 Agent。 这正是 pi 的智慧。后续在实现篇,我们造的也是单 agent——先在"单兵"上做深,多 Agent 的协调复杂度留给你在理解这些原则后自行探索。
12.7 多 Agent 怎么编排:三种模式与"黑盒/白盒"
"假设你决定上多 Agent,"老z说,"还有个问题:一群 agent 怎么组织? 江湖上常见三种编排模式。"
🧙 三种编排模式:
模式 结构 适合 例子 层级式(hierarchical) 主 agent 指挥,子代理各自干活汇报 任务可拆、需要统一调度 项目经理 + 专员 流水线式(pipeline) 上一个 agent 的输出,是下一个的输入 流程固定、有先后顺序 分析 → 生成 → 评审 共享式(shared context) 多个 agent 共用一个工作区/文档,协作完成 需要共同修改同一产物 多人共编一份设计稿
- 层级式最接近 12.2 的子代理——主 agent 是老板,子代理是下属
- 流水线式像工厂流水线——每站干一段,交棒给下一站
- 共享式像一张共享文档——大家同时改,最终拼成完整成果
黑盒 vs 白盒:子代理的"过程"要不要给人看?
🧙 多 Agent 里一个绕不开的设计抉择:
- 黑盒(black box):主 agent 只收子代理的最终结论,过程不看 → 简洁,但没法审计——子代理干了啥、踩了什么坑,没人知道
- 白盒(white box):子代理的中间过程(工具调用、思考)都透传给用户 → 透明、可审计,但信息爆炸——几个子代理同时吐过程,用户看不过来
老z类比:"黑盒是'外包'——你只验收结果;白盒是'驻场'——每一步你都看得见。信任度高,敢黑盒;要监管,得白盒。"
🐣 小a:"所以多 Agent 不只是『多几个模型』,还要想清楚『怎么组织』『透不透明』?"
🧙 "对。 这就是为什么说多 Agent 复杂——模型多一倍,组织、沟通、审计的问题多一倍。这三个问题(怎么编排、怎么同步、怎么审计),任何一个没想清楚,多 Agent 就是灾难。 这也是 pi 宁可选单兵的深层原因之一。"
本章小结
🐣 小a的第十二课
┌──────── 多 Agent 的江湖 ────────┐ │ │ │ • 两派:单兵派 vs 群殴派 │ │ pi = 坚定的单兵派 │ │ │ │ • 子代理 = 主 agent 派分身 │ │ → 适合可并行的独立子任务 │ │ │ │ • Agent Teams = 长期协作团队 │ │ → 各有专长,但协调极难 │ │ │ │ • 三种协议: │ │ MCP = 调工具 │ │ ACP = agent 对 agent 对话 │ │ A2A = agent 互相发现协作 │ │ → 99% 场景 MCP 够用 │ │ │ │ • pi 一个都不用(除有限 MCP) │ │ → 简单优先 + 编码不需要 + │ │ 成本可控 │ │ │ │ • 编排三种:层级/流水线/共享 │ │ • 黑盒(只收结论)vs 白盒(全程 │ │ 可见)→ 信任与审计的权衡 │ └─────────────────────────────────┘
关键认知:多 Agent 不是"更高级",是另一种取舍——用复杂度和成本换并行与专业分工。它还带来组织(编排模式)、沟通、审计(黑盒/白盒)三重新问题。pi 选了单兵,不代表单兵永远对,而是 pi 的场景适合单兵。
课后实验
- 判断场景:想三个你想用 AI 解决的任务,分别判断它们该用单 agent 还是多 agent,说出理由(参考 12.6 的四个信号)。
- 体会协调难度:找一个你熟悉的团队协作场景(如公司项目),列出"多人协作时会出的问题"(沟通错漏、状态不同步、责任不清)。感受多 Agent 同样会面对这些。
- 画协议关系图:画一张图,标出 MCP/ACP/A2A 各自连接的是什么(agent↔工具?agent↔agent?),加深记忆。
- 选编排模式:给你设计的"多 agent 调研系统"选一种编排(层级/流水线/共享),说明理由;再决定子代理用黑盒还是白盒,说清信任依据。
下一章:除了"一个还是多个 agent",小a还发现另一个问题——它"记得"的事有一半是编的。老z说:"你这是在闭卷考试。先查资料再答。" → 第 13 章 · RAG