深色模式
15 · 该不该上多 Agent
先泼一盆冷水
📚 系列导航：这是《Agent 开发进阶》的第 15 篇（共 24 篇）。上一篇你用 MCP 接入了工具生态，单体能力基本到位；这一篇先泼盆冷水——动手拆多 agent 前，把收益代价这笔账算清。下一篇：16 · 编排者-工人模式。
刷技术文章时，你大概率见过十几个框框连线的多 agent 架构图，看着就"高级"。我也心动过，照着搭了一套五 agent 系统，联调两周，效果不如单 agent 改一天 prompt。这不是我笨——多数人根本没碰到单 agent 的天花板，就先给自己上了分布式的复杂度。多 agent 不是更高级的 agent，是一笔要精打细算的买卖。这一篇只干一件事：给你一套判据，让你在动手之前就得出"拆还是不拆"的结论。
看完这一篇，你会拿到：
- 单 agent 三堵墙对照表，逐条自测
- 三真收益 vs 三真代价的算账清单
- 五问判据清单，套用出拆/不拆结论
- 反例解剖：系统怎么被拆碎拆笨
01 单 agent 的天花板到底在哪
多数人抱怨"单 agent 不行"，真实问题往往是 prompt 糙、工具描述含混、上下文没管理——第 05、06 篇的作业没做完，不是架构问题。真正的天花板只有三堵墙：上下文塞不下（所需信息远超窗口，压缩也救不回）；任务域冲突（一个 agent 又当运动员又当裁判，立场打架）；必须并行（子任务独立，串行等不起）。
我的判断很直接：三堵墙一堵没撞上，就回去把单 agent 做扎实。Anthropic 在《Building Effective Agents》里的口径也一样——能用简单方案解决的，别加编排层。
💡 一句话总结：先确认撞的是墙而不是地基——多数"天花板"其实是没写好的 prompt。
02 三真收益 vs 三真代价
该不该拆，本质是一笔账。打个比方，这就像一个人单干和开公司招人：招人确实能分担活（收益），但从此你要开会、对齐、发工资（代价）。
真收益三条：上下文隔离——每个 agent 只装自己那摊事，注意力不被稀释；并行——独立子任务同时跑，总耗时大降；专业化——每个角色的 prompt 和工具都能精调。真代价也三条：通信损耗——agent 间传话必丢信息；调试地狱——出错先花半天定位是哪个 agent 的锅；成本翻倍——每个 agent 各烧各的 token，账单按份数涨。
💡 一句话总结：收益和代价都是真的——账要摆到桌面上算，不能只看架构图好看。
03 判据清单：五个信号说明该拆
把下面五问过一遍，答"是"记一分：
- 上下文是否稳定超窗，压缩后仍丢关键信息？
- 是否存在天然独立、可并行的子任务？
- 是否需要立场独立的角色（如评审）制衡产出？
- 不同子任务是否需要截然不同的工具集或规则集？
- 单 agent 是否已按 05/06 篇优化到位仍不达标？
0–1 分别拆；2–3 分从"编排者+一个工人"的最小拆分试起；4–5 分值得上。第 5 问一票否决——单 agent 没优化到位，前四问都是伪信号。
💡 一句话总结：判据清单是护栏——分不够就不拆，别让"想拆"污染了"该拆"。
04 反例解剖：拆错刀口，系统变笨
我见过最惨的拆法是按技术层拆："模型调度""工具执行""记忆管理"各一个 agent。听着像微服务，实际每个 agent 都残缺——干活的没上下文，有上下文的不干活，一个请求在三个 agent 间倒手三次，上下文传丢一半。正确的刀口是按任务域拆：调研、写作、审查，每个 agent 拿到一件完整的事，配齐全部工具和上下文。检验一句话：任何 agent 单拎出来能否独立干完自己那份活？不能就是拆错了。
💡 一句话总结：按任务域拆出完整的手艺人，按技术层拆出一堆半成品。
05 动手：给自己的场景出一份拆/不拆结论
任务：拿你手头真实的 agent 场景，走一遍 03 的五问判据，逐问写下答案和依据，落成一页 ADR（架构决策记录）：结论（拆/不拆/最小拆分）+ 三条理由 + 重新评估的触发条件（如"压缩后成功率跌破 80%"）。
验收标准：一页纸 ADR，别人不问也能看懂为什么这么定，理由能对应判据编号。
两种结果都正常：结论是"不拆"——恭喜，你省下了两周联调，把精力投回工具与上下文优化；结论是"拆"——带着判据依据进下一篇，从最实用的架构起步。
06 小结
你现在应该能：说清单 agent 的三堵墙、算清三收益三代价的账、用五问判据给自己的场景产出一页 ADR。
下一篇 16 · 编排者-工人模式：如果你的结论是"拆"，这是覆盖 80% 场景的第一选择。
📎 实战案例
一个团队模仿大厂架构图起手五个 agent，联调两周，效果不如单 agent 调优一天。按五问判据重评（上下文没超窗、无并行需求、无立场制衡需求，得 0 分），砍回单 agent 后一周上线——复杂度是要挣来的，不是送的。
踩坑
- 我照大厂架构图起手五个 agent，联调两周不如单 agent 改一天 prompt——复杂度自负盈亏。
- 我按技术层拆过一版，用户请求在三个 agent 间倒手，上下文传丢一半，成功率掉了 20 个点——任务域才是正确的刀口。
- 我上多 agent 后没盯账单，三个 agent 各带全量历史，成本是单 agent 的 3 倍、效果持平——拆之前先给成本设上限。