本文是「Agent 开发实践与思考」系列第 19 篇。系列目录：
- 2024
- 2025
- 01-28 长任务不失忆：上下文压缩、交接文档与子任务隔离
- 02-25 MCP 用了三个月：工具标准化之后 Agent 设计变了什么
- 03-25 拆解 Coding Agent：为什么”写代码 + 文件系统”是通用 Agent 的内核
- 05-13 Agent 如何用代码完成推理、校验、适配与展示
- 06-03 能看会说的 Agent：语音交互与 Computer Use 这半年
- 06-24 从同步问答到事件驱动：异步 Agent 的架构改造笔记
- 07-08 没有评估就没有迭代：我的 Agent 评估落地记
- 09-09 后训练扫盲：SFT 记知识、RL 学长处，和 Agent 有什么关系
- 10-01 AI Coding 的上下文摘要：几家产品到底在压缩什么
- 10-14 让 Agent 从经验里长本事：失败复盘、经验库与提示词自动优化
- 11-04 能力按需加载：从动态提示词到 Agent Skills
- 11-25 多 Agent 协作的真实收益与代价（本篇）
什么时候真的值
第一种，上下文隔离。调研类子任务会产生几万 token 的中间产物，网页全文、搜索结果、试错记录，主对话并不需要这些，只需要结论。有人会说压缩也能解决，但压缩是有损的，压掉的东西后面想找就找不回来；隔离是另一种思路，中间产物完整留在子 Agent 的上下文和文件里，只是不进主对话。我在长任务那篇写的子任务隔离，其实就是多 Agent 的雏形：把子任务派给隔离上下文的 Agent 跑，只把结论带回来。主对话的上下文是稀缺资源，这是拆 Agent 最硬的动机。
第二种，专长不同。写代码的和审代码的用不同的提示词和模型，生成和评审分开还有一个额外收益：评审方的上下文里没有生成过程的思维惯性，更容易看出问题。这也解释了为什么让一个 Agent 自己检查自己的产出，效果总是差一截，它被自己的推理路径说服过了。
第三种，并行执行。三个互相独立的调研同时跑，可以减少墙钟时间。我算过一次具体的账：三个技术方案调研，各自跑完要八分钟左右，串行是二十四分钟，并行加上合流整理不到十分钟。前提是任务之间确实独立。如果第二个任务依赖第一个任务的结论，强行并行可能得到基于猜测的中间结果，合流时还要返工。
三种组织模式，按踩坑顺序
管理者模式：一个 lead 派活收活，最常用，也是我现在的默认。结构清楚，问责清楚，出问题知道找谁。瓶颈在 lead 自己的上下文：所有子任务的结论都回流到它那里，任务一多 lead 先被塞满，开始丢约束、忘记交代过的事。我遇到过一次，lead 管着四个子任务跑到后半程，把最早交代给第一个子任务的边界条件丢了，收上来的结果格式五花八门，还得返工重派。对策是 lead 只收结论和文件路径，不收过程，过程让子 Agent 自己落盘；lead 的上下文里只留任务清单和状态，不堆细节。
对等模式：没有 lead，几个 Agent 互相交付。灵活，但我印象最深的一次事故就出在这里。让两个 Agent 协作处理一个工单流，A 负责分类，B 负责写回复草稿，边界情况（分类置信度低的时候怎么办）我以为在提示词里说清楚了。结果 A 假设 B 会兜底，B 假设 A 会升级，那批工单两边都没处理，日志里各自写着”对方负责”。人类组织里这叫三不管地带，Agent 里一模一样，只是 Agent 不会觉得尴尬，也就没人主动把活捡起来。教训：对等模式下每个任务必须有且只有一个 owner，写在消息结构里，不靠默契。
流水线模式：同一个上下文依次换角色提示词，先当产品经理写需求，再当工程师实现，再当测试挑错。最省，不用真的起多个进程。问题是角色之间互相干扰：后面的角色能看到前面角色的全部思考过程，“测试”容易被”工程师”的思路说服，挑错的力度明显下降。我的用法是，角色之间确实需要共享大量背景时用流水线，需要对抗性评审时拆开，理由和上一条生成评审分离是一样的。
通信的硬问题
Agent 之间传什么，我在这类项目里的偏好是优先传文件路径，不把大段内容直接塞进消息。文件系统可以作为共享产物存储，这点在拆解 Coding Agent 那篇写过，多 Agent 场景下它更好用。子 Agent 把中间产物落盘，交接时传路径和摘要。消息短，上下文就省；产物留在盘上，出问题能回去翻原始版本；多个下游读同一份文件，也不用在消息里复制。对于很短、需要立即确认的状态，直接传结构化内容更合适，具体取舍取决于运行时和一致性要求。
反过来，把大段内容塞进消息会增加上下文和版本管理成本。消息历史通常不会随着文件更新自动同步，下游如果继续使用消息里的副本，就可能拿到过期版本，因此需要通过版本号、校验和或重新读取文件来确认状态。
第二件事，消息要结构化。自由文本交接会丢约束，上游写了三段话，下游模型抓住的往往只是最后一句。我现在的交接消息固定几个字段：任务 ID、输入文件、产出文件、状态、置信度、给下游的注意事项。这里面最关键的是置信度，它决定了下游敢不敢直接用这份产出，这个下一节细说。多几个字段的代价很小，省掉的是”上游说了一半”这一类事故。
两种典型死法
并发冲突。两个 Agent 改同一个文件时，如果没有锁、版本检查或合并策略，后写入的结果可能覆盖先写入的结果，另一个 Agent 也可能继续基于过期状态工作。单 Agent 通常较少遇到这种并发写入问题，多 Agent 则更容易暴露它。对策可以是文件级分工，也可以使用锁、版本检查或明确的合并策略，不要只依赖运行时自行协调。
错误级联。A 的判断错了，被 B 当事实继承，B 的结论再传给 C，多个环节之后可能逐步偏离，而且每个环节的输出看起来都有依据。这不是多 Agent 独有的问题，但多次交接会增加错误被复制和放大的机会。对策是跨 Agent 传递的结论尽量带置信度、出处或验证状态，并在关键节点重新校验。“这个接口支持分页（我读过分页的实现）“和”这个接口应该支持分页”是两句话，下游对它们的用法完全不同，前者可以直接依赖，后者必须先验证。没有出处的结论，下游有权也有义务重新验一遍。
A2A 一瞥
Google 在 2025 年 4 月发布了 A2A（Agent2Agent）协议，目标是让不同厂商、不同框架的 Agent 能互相发现并协作。其设计包含 Agent Card、任务生命周期和 artifact 等概念，传输层使用 HTTP 与 JSON-RPC。它和 MCP 的常见分工是：MCP 主要描述 Host、模型与工具或资源之间的连接，A2A 主要描述 Agent 之间的任务委派、状态同步和产物交付。实际边界还取决于协议版本和具体实现。MCP 我在二月那篇写过，它解决互操作问题，不负责替模型选对工具；A2A 也主要解决互联互通，不保证协作质量。
我的判断是现在还早。A2A 假设的前提是”你的 Agent 要和别人家的 Agent 协作”，这个场景在企业内部还不普遍，大多数团队的现状是自己内部的几个 Agent 都还没编排明白。协议本身值得关注，但不必现在上车。
斯坦福小镇是模拟，不是协作
聊多 Agent 绕不开 2023 年那个斯坦福小镇实验：25 个 Agent 在模拟小镇里生活，自己组织起了一场情人节派对。演示效果好，也成了很多”多 Agent 涌现”叙事的源头。
冷静看，那是模拟，不是面向生产交付的协作任务。小镇的观察重点是行为是否像人，派对是实验中的行为结果，不是预先定义的交付物；它也没有生产系统通常要求的截止时间、验收标准和责任归属。生产力场景的评价标准不同。这个实验可以用于观察多 Agent 的社会行为，但不能单独证明这种组织形态适合生产任务。
收尾
多 Agent 的一个重要问题是组织设计：分工、接口和责任边界。换成 Agent 后，这些要求仍然存在。具体系统是否会主动汇报进度、发现缺少 owner 或质疑含糊的交接口径，取决于提示词、编排逻辑和运行时能力，不能假定它一定会补位。设计不清时，Agent 可能更快地执行错误流程。
所以我的优先级一直没变：先把单 Agent 的上下文、工具和评估做扎实，碰到开头那三个条件里的一个，再拆。拆的时候按人类组织的常识来，任务有 owner，交接口径结构化，结论带出处。这套东西不新，只是以前在管人，现在在管 Agent。
