多 Agent 不是多起几个名字：Google 竞赛里真正拉开差距的结构

多 Agent 不是多起几个名字：Google 竞赛里真正拉开差距的结构

Google 9 月 2 日复盘 AI Agents Challenge 时提到一个很常见的现象：参赛项目频繁自称“多 Agent”，拆开后却只是同一个模型依次执行几段提示词，每段换了一个角色名。角色数量增加了，调用关系仍是一条同步链，延迟、失败恢复和权限边界都没有发生结构变化。

排名靠前的项目更像传统分布式系统。它们让多个执行单元围绕事件并发工作，用 MCP 暴露边界明确的能力，在主模型不可用时切换到备用模型，但输出仍经过同一套检查；简单请求则在进入昂贵模型前被筛掉。模型当然重要，系统能否在高峰、超时和脏数据下保持行为一致，更接近生产验收的核心。

从调用链改成事件流，Agent 才真正可以并行

Google 举的一个案例最初把监测、合规、通知和调度串成调用链。上游必须等下游返回，整条链的耗时由各段相加。团队后来为不同 Agent 设置独立队列，并让它们订阅有类型的事件；两个不依赖彼此结果的任务可以同时运行，慢接口也不再占住整条调用栈。队列数量只是实现细节，依赖关系是否被明确表达才决定并发能否成立。

另一类项目把 MCP 用成双向边界。Agent 内部通过工具查询遥测数据库，只取执行计划或某段堆栈，避免把整张表塞进上下文；同一组受限工具随后又作为 MCP Server 暴露给其他 Agent。这样，IDE 中的编码助手可以直接询问某个任务的性能问题，不必先打开人类仪表盘再复制答案。对外暴露后必须补身份认证、调用范围和结果上限，原始数据库连接不应跟着暴露出去。

这两个模式都能用工程指标验证。事件化之后要测端到端延迟、队列积压、重复消费和幂等；MCP 化之后要测工具返回大小、越权请求和不可用时的行为。如果系统只展示一条成功演示，却没有这些失败路径，多 Agent 的标签并没有带来更强的可靠性。

备用模型与便宜模型都不能绕过验收

竞赛案例里有团队在主模型遇到 503 时切换到更快的备用模型，但两个模型的回答都必须通过同一个引用校验函数。校验放在汇合点，而不是在两条路径里各写一份，能避免备用链路悄悄降低标准。模型网关做故障切换时也应沿用这个原则：切换策略可以按可用性和成本变化，业务验收门不能跟着供应商变化。

分层路由解决的是另一笔账。某个项目先用本地正则处理明确意图，再用一个低成本模型判断模糊请求，只有剩余任务进入完整推理模型。官方文章称，参赛团队自己的测量中，第一层拦下了超过 40% 的消息。这个比例属于单一项目数据，不能直接套到别的业务；可复用的是先统计真实流量，再决定哪些请求根本不需要大模型。

落地时可以从一张任务表开始：哪些步骤彼此依赖，哪些可并行，哪些结果需要确定性校验，哪些错误允许换模型，哪些操作必须人工批准。随后用统一模型接口记录每条路径的 Token、延迟、错误码和完成率。比较多模型时，最好再让独立模型或人工样本复核关键结果，防止路由优化只把账单压低，却把错误转移到业务末端。

AnyAIS 可用于统一调用不同模型并观察路由后的消耗；MCP 工具权限、事件幂等与业务验收仍需由应用层负责。把这些责任拆清楚，比在架构图里增加几个圆形 Agent 图标更有用。

来源：[Google Developers Blog：4 engineering patterns behind the strongest AI Agents Challenge submissions](https://developers.googleblog.com/4-engineering-patterns-behind-the-strongest-ai-agents-challenge-submissions/)。