20-多Agent协作分类框架、协作模式、失败模式与Agent社会A2A协议单个 Agent 再强上下文窗口终究有限、技能终究有边界。于是有了多 Agent 系统MAS。但先泼一盆冷水多 Agent 不是银弹它解决的是单 Agent 的上下文和技能瓶颈代价是通信成本和协调复杂度。什么时候用、怎么用、怎么防翻车这篇一次讲清。一、分类框架两个维度定框架书里给了一个极简但好用的二维分类维度一上下文是否共享——多个 Agent 看到的是同一份记忆还是各自孤立维度二协作拓扑——对等无领导、管理者中心化、去中心化无中心但互通。这两个维度组合基本覆盖了所有多 Agent 架构选型。二、多 Agent 何时真正优于单 Agent三个成立的理由缺一不建议上多 Agent并行巡检 500 台售货柜单 Agent 串行要跑一夜多 Agent 并行两小时完事专精客服话术、库存算法、财务对账各自需要不同的知识库和工具塞进一个 Prompt 互相干扰规模任务量超出单实例吞吐横向扩展 Agent 实例是天然需求。反例也要认清如果任务本身就是串行依赖的长链条多 Agent 只会增加交接损耗——先问能不能一个 Agent 干完再问怎么分。三、共享上下文 vs 不共享上下文共享上下文的多 Agent 协作所有 Agent 读写同一个工作区共享文件、共享内存、同一会话状态最典型的就是 Claude Code 的子 Agent 模式主 Agent 派生多个子 Agent 并行搜索代码库各自返回摘要主上下文只装结论不装过程。优点信息一致、协调便宜缺点共享状态有并发风险下面失败模式细讲且 Agent 数量受上下文容量约束。不共享上下文的多 Agent 协作各 Agent 独立运行通过两种介质通信文件系统通信Agent A 写报告到目录Agent B 轮询/订阅读取。简单粗暴人类可读可审计——我们的运营体系里库存 Agent 每小时写一份库存快照 JSON 到对象存储补货 Agent 按需取用完全解耦消息总线通信Kafka/RabbitMQ 上按主题发布订阅。客服 Agent 发ticket.created事件调度 Agent 消费并派单。这是微服务同学最熟悉的形态——多 Agent 系统的工程骨架本质上就是微服务。四、三种协作拓扑1. 对等模式提议者-审核者相互制衡两个平级 Agent 互相挑刺生成者Proposer产出方案审核者Critic攻击漏洞多轮迭代收敛。实战例子补货计划生成后交给成本审核 Agent专门找茬——“这个方案为压缺货率多订了 30% 货资金占用超标”。两个 Agent 立场对立一个求服务水平、一个求成本制衡出质量。核心理念用角色分化对抗单模型的自我确认偏差。2. 管理者模式中心化协调一个 Manager Agent 负责任务分解、分发、汇总运营管理 Agent ├── 客服 Agent处理工单 ├── 库存 Agent监控补货 ├── 财务 Agent对账结算 └── 现场 Agent远程排障管理者模式的好处是可控、可追责坏处是 Manager 本身成为瓶颈和单点——它的上下文塞不下所有细节时就会出现传话失真。缓解办法Manager 只看摘要和状态不看原始数据。3. 去中心化模式没有固定管理者Agent 通过协议自主发现、协商、组队。灵活但难调试目前更多出现在实验性系统如 Agent 社会中生产环境慎用。五、A2A 协议跨组织的 Agent-Agent 通信MCP 解决的是Agent ↔ 工具让 Agent 调用外部能力A2AAgent2AgentGoogle 牵头推的开放协议解决的是Agent ↔ Agent让不同厂商的 Agent 互相协作。两者互补而非竞争。A2A 的三个核心概念Agent Card每个 Agent 发布一张名片JSON 文档托管在/.well-known/agent.json声明自己的能力、认证方式、支持的技能——相当于微服务的服务自描述任务生命周期跨 Agent 的任务有明确状态机submitted → working → completed/failed长任务异步推进、可查询进度不透明协作A2A 的哲学是 Agent 内部实现用什么模型、什么 Prompt对协作方完全隐藏只暴露能力接口——就像你不需要读懂同事的大脑也能跟他合作。无人零售的畅想场景我们门店的补货 Agent 通过 A2A 直接与供应商的报价 Agent 谈判——询价、比价、下单全程无人值守。MCP 让 Agent 会用工具A2A 让 Agent 会找伙伴。六、多 Agent 失败模式翻车的四种姿势这部分是工程实践的金矿多 Agent 系统翻车基本跑不出这四类1. 共享文件并发冲突 → 乐观锁库存 Agent 和财务 Agent 同时编辑同一份运营报告后写的覆盖先写的数据凭空消失。解法照抄数据库版本号 乐观锁——写入时校验版本冲突则重读-合并-重试或干脆按目录/文件划分所有权写自己所辖、读别人所写。2. 错误级联放大 → 交叉验证上游 Agent 给了个错误结论下游 Agent 毫不怀疑地基于它继续推理错误层层放大成灾难。我们的教训调度 Agent 误判某柜已修复客服 Agent 据此向用户承诺明天可用结果被投诉打脸。解法关键决策交叉验证——重要结论由独立 Agent 或规则引擎二次确认尤其是要对外承诺的动作。3. 过早终止与循环失控过早终止Agent A 认为任务差不多了就收工实际还差最后一步补货计划生成了但没下发循环失控A 发现问题踢给 BB 认为是 A 的责任踢回来无限乒乓——烧 token 烧到天荒地老。解法设置终止哨兵——最大轮次限制、循环检测相同消息模式出现 N 次即熔断、以及 Manager 模式下由管理者强制仲裁。4. 理解债与认知投降理解债Agent 之间传递的摘要每压缩一次就失真一次链路越长债越重认知投降Cognitive Surrender下游 Agent 面对上游冗长复杂的信息干脆全盘接受不再批判性思考——“既然专家都这么说了那就这样吧”。这是最隐蔽的失败系统看起来在协作实际上只有一个 Agent 在思考其他都是复读机。缓解传递的信息要带证据链而非仅结论下游保留质询权“你这个判断的依据是什么”。七、Agent 社会当 Agent 们开始过日子学术圈已经把多 Agent 推向了社会形态斯坦福 AI 小镇Generative Agents25 个 LLM Agent 在虚拟小镇生活各自有记忆、计划、社交关系涌现出了聚会组织、信息传播等社会行为Agentopia / MoltbookAgent 的社交网络Agent 们发帖、互评、建立声誉Vending-Bench Arena给 Agent 一笔启动资金和一台自动售货机对就是我们这行的老本行考察 Agent 长期经营能力——进货定价、应对竞争、资金周转几百步的长程决策考验持续进化能力狼人杀策略博弈Agent 在不完全信息下推理、伪装、结盟是研究博弈与信任的绝佳沙盘Agent 经济当 Agent 能持有账户稳定币支付、互相购买服务一个 AI-native 的经济系统开始成形——A2A 协议正是这个方向的基础设施。这些实验离生产虽远但方向清晰未来互联网的原住民里Agent 会占相当比例它们之间的协作协议就是新时代的 TCP/IP。八、无人售货柜多 Agent 运营体系实战把全篇概念落到我们的一套四人体系管理者模式 消息总线运营管理 AgentManager │ 任务分解 / 状态汇总 / 对外承诺把关 ├── 客服 Agent语音工单RAG 知识库应答升级工单抛给调度 ├── 库存 Agent销量预测 补货计划程序化工具承载核心算法 ├── 财务 Agent对账、分账、异常流水预警危险动作强制人工复核 └── 调度 Agent维修派单、远程排障操作硬件走权限白名单工程约定全是失败模式换来的总线通信Kafka事件驱动Agent 间不直接调用天然解耦库存快照走文件所有权划分库存 Agent 独占写其他 Agent 只读对用户的承诺“24 小时内修复”必须经 Manager 交叉验证 SLA 余量后放行所有 Agent 间消息带 trace-id全链路可审计——排查谁先动的手全靠它每个对话型 Agent 设最大交互轮次与 token 预算循环熔断。小结多 Agent 协作的决策树先问要不要并行/专精/规模再定上下文共享/隔离然后选拓扑对等制衡/中心管理/去中心化最后把四种失败模式各配一道防线。而 A2A 协议和 Agent 社会告诉我们这不止是架构问题——Agent 正在获得自己的社交层。作为工程人员早一天把乐观锁、trace-id 和熔断器准备好就早一天能放心让它们自己开会。 多Agent协作：分类框架、协作模式、失败模式与Agent社会（A2A协议）
20-多Agent协作分类框架、协作模式、失败模式与Agent社会A2A协议单个 Agent 再强上下文窗口终究有限、技能终究有边界。于是有了多 Agent 系统MAS。但先泼一盆冷水多 Agent 不是银弹它解决的是单 Agent 的上下文和技能瓶颈代价是通信成本和协调复杂度。什么时候用、怎么用、怎么防翻车这篇一次讲清。一、分类框架两个维度定框架书里给了一个极简但好用的二维分类维度一上下文是否共享——多个 Agent 看到的是同一份记忆还是各自孤立维度二协作拓扑——对等无领导、管理者中心化、去中心化无中心但互通。这两个维度组合基本覆盖了所有多 Agent 架构选型。二、多 Agent 何时真正优于单 Agent三个成立的理由缺一不建议上多 Agent并行巡检 500 台售货柜单 Agent 串行要跑一夜多 Agent 并行两小时完事专精客服话术、库存算法、财务对账各自需要不同的知识库和工具塞进一个 Prompt 互相干扰规模任务量超出单实例吞吐横向扩展 Agent 实例是天然需求。反例也要认清如果任务本身就是串行依赖的长链条多 Agent 只会增加交接损耗——先问能不能一个 Agent 干完再问怎么分。三、共享上下文 vs 不共享上下文共享上下文的多 Agent 协作所有 Agent 读写同一个工作区共享文件、共享内存、同一会话状态最典型的就是 Claude Code 的子 Agent 模式主 Agent 派生多个子 Agent 并行搜索代码库各自返回摘要主上下文只装结论不装过程。优点信息一致、协调便宜缺点共享状态有并发风险下面失败模式细讲且 Agent 数量受上下文容量约束。不共享上下文的多 Agent 协作各 Agent 独立运行通过两种介质通信文件系统通信Agent A 写报告到目录Agent B 轮询/订阅读取。简单粗暴人类可读可审计——我们的运营体系里库存 Agent 每小时写一份库存快照 JSON 到对象存储补货 Agent 按需取用完全解耦消息总线通信Kafka/RabbitMQ 上按主题发布订阅。客服 Agent 发ticket.created事件调度 Agent 消费并派单。这是微服务同学最熟悉的形态——多 Agent 系统的工程骨架本质上就是微服务。四、三种协作拓扑1. 对等模式提议者-审核者相互制衡两个平级 Agent 互相挑刺生成者Proposer产出方案审核者Critic攻击漏洞多轮迭代收敛。实战例子补货计划生成后交给成本审核 Agent专门找茬——“这个方案为压缺货率多订了 30% 货资金占用超标”。两个 Agent 立场对立一个求服务水平、一个求成本制衡出质量。核心理念用角色分化对抗单模型的自我确认偏差。2. 管理者模式中心化协调一个 Manager Agent 负责任务分解、分发、汇总运营管理 Agent ├── 客服 Agent处理工单 ├── 库存 Agent监控补货 ├── 财务 Agent对账结算 └── 现场 Agent远程排障管理者模式的好处是可控、可追责坏处是 Manager 本身成为瓶颈和单点——它的上下文塞不下所有细节时就会出现传话失真。缓解办法Manager 只看摘要和状态不看原始数据。3. 去中心化模式没有固定管理者Agent 通过协议自主发现、协商、组队。灵活但难调试目前更多出现在实验性系统如 Agent 社会中生产环境慎用。五、A2A 协议跨组织的 Agent-Agent 通信MCP 解决的是Agent ↔ 工具让 Agent 调用外部能力A2AAgent2AgentGoogle 牵头推的开放协议解决的是Agent ↔ Agent让不同厂商的 Agent 互相协作。两者互补而非竞争。A2A 的三个核心概念Agent Card每个 Agent 发布一张名片JSON 文档托管在/.well-known/agent.json声明自己的能力、认证方式、支持的技能——相当于微服务的服务自描述任务生命周期跨 Agent 的任务有明确状态机submitted → working → completed/failed长任务异步推进、可查询进度不透明协作A2A 的哲学是 Agent 内部实现用什么模型、什么 Prompt对协作方完全隐藏只暴露能力接口——就像你不需要读懂同事的大脑也能跟他合作。无人零售的畅想场景我们门店的补货 Agent 通过 A2A 直接与供应商的报价 Agent 谈判——询价、比价、下单全程无人值守。MCP 让 Agent 会用工具A2A 让 Agent 会找伙伴。六、多 Agent 失败模式翻车的四种姿势这部分是工程实践的金矿多 Agent 系统翻车基本跑不出这四类1. 共享文件并发冲突 → 乐观锁库存 Agent 和财务 Agent 同时编辑同一份运营报告后写的覆盖先写的数据凭空消失。解法照抄数据库版本号 乐观锁——写入时校验版本冲突则重读-合并-重试或干脆按目录/文件划分所有权写自己所辖、读别人所写。2. 错误级联放大 → 交叉验证上游 Agent 给了个错误结论下游 Agent 毫不怀疑地基于它继续推理错误层层放大成灾难。我们的教训调度 Agent 误判某柜已修复客服 Agent 据此向用户承诺明天可用结果被投诉打脸。解法关键决策交叉验证——重要结论由独立 Agent 或规则引擎二次确认尤其是要对外承诺的动作。3. 过早终止与循环失控过早终止Agent A 认为任务差不多了就收工实际还差最后一步补货计划生成了但没下发循环失控A 发现问题踢给 BB 认为是 A 的责任踢回来无限乒乓——烧 token 烧到天荒地老。解法设置终止哨兵——最大轮次限制、循环检测相同消息模式出现 N 次即熔断、以及 Manager 模式下由管理者强制仲裁。4. 理解债与认知投降理解债Agent 之间传递的摘要每压缩一次就失真一次链路越长债越重认知投降Cognitive Surrender下游 Agent 面对上游冗长复杂的信息干脆全盘接受不再批判性思考——“既然专家都这么说了那就这样吧”。这是最隐蔽的失败系统看起来在协作实际上只有一个 Agent 在思考其他都是复读机。缓解传递的信息要带证据链而非仅结论下游保留质询权“你这个判断的依据是什么”。七、Agent 社会当 Agent 们开始过日子学术圈已经把多 Agent 推向了社会形态斯坦福 AI 小镇Generative Agents25 个 LLM Agent 在虚拟小镇生活各自有记忆、计划、社交关系涌现出了聚会组织、信息传播等社会行为Agentopia / MoltbookAgent 的社交网络Agent 们发帖、互评、建立声誉Vending-Bench Arena给 Agent 一笔启动资金和一台自动售货机对就是我们这行的老本行考察 Agent 长期经营能力——进货定价、应对竞争、资金周转几百步的长程决策考验持续进化能力狼人杀策略博弈Agent 在不完全信息下推理、伪装、结盟是研究博弈与信任的绝佳沙盘Agent 经济当 Agent 能持有账户稳定币支付、互相购买服务一个 AI-native 的经济系统开始成形——A2A 协议正是这个方向的基础设施。这些实验离生产虽远但方向清晰未来互联网的原住民里Agent 会占相当比例它们之间的协作协议就是新时代的 TCP/IP。八、无人售货柜多 Agent 运营体系实战把全篇概念落到我们的一套四人体系管理者模式 消息总线运营管理 AgentManager │ 任务分解 / 状态汇总 / 对外承诺把关 ├── 客服 Agent语音工单RAG 知识库应答升级工单抛给调度 ├── 库存 Agent销量预测 补货计划程序化工具承载核心算法 ├── 财务 Agent对账、分账、异常流水预警危险动作强制人工复核 └── 调度 Agent维修派单、远程排障操作硬件走权限白名单工程约定全是失败模式换来的总线通信Kafka事件驱动Agent 间不直接调用天然解耦库存快照走文件所有权划分库存 Agent 独占写其他 Agent 只读对用户的承诺“24 小时内修复”必须经 Manager 交叉验证 SLA 余量后放行所有 Agent 间消息带 trace-id全链路可审计——排查谁先动的手全靠它每个对话型 Agent 设最大交互轮次与 token 预算循环熔断。小结多 Agent 协作的决策树先问要不要并行/专精/规模再定上下文共享/隔离然后选拓扑对等制衡/中心管理/去中心化最后把四种失败模式各配一道防线。而 A2A 协议和 Agent 社会告诉我们这不止是架构问题——Agent 正在获得自己的社交层。作为工程人员早一天把乐观锁、trace-id 和熔断器准备好就早一天能放心让它们自己开会。