4 engineering patterns behind the strongest AI Agents Challenge submissions

最强AI Agents Challenge提交背后的四个工程模式 - Google Developers Blog

Google Tag Manager (noscript)

End Google Tag Manager (noscript)

HTML

最强AI Agents Challenge提交背后的四个工程模式

2026年9月2日

Sergio Villani

Technical Solutions

Google Cloud AI

分享

• Facebook

• Twitter

• LinkedIn

• 邮件

我们刚刚结束了Google for Startups AI Agents Challenge，数千名开发者从全球各地提交了智能体方案，我们的评审团根据三个赛道对提交内容进行了评分。

"多智能体系统"可能是提交中最常见的描述，但深入分析后发现，有些方案确实是真正复杂的多智能体解决方案，而有些则只是单个模型通过提示链运作，附带了智能体名称。

然而在所有提交中，每个赛道排名靠前的方案都展现出相同的工程决策和模式。以下是其中四个值得借鉴的模式，它们均来自真实代码提交，且未使用任何团队名称，因为本文并非针对某个特定团队：

• 双向MCP：一个智能体既是自身工具的客户端，也可以作为其他智能体调用的服务器。
• 事件驱动的并发：智能体通过并行响应共享信号，而非在调用链中等待。
• 同级降级：在不进行质量检查的情况下，用较小模型替代过载模型。
• 分层路由：在模型被调用之前，先运行廉价且确定性的检查。

模式1：你为自己构建的工具也可以服务其他智能体

大多数提交只使用了MCP的一种方向：智能体调用工具服务器获取数据。但有一个团队将MCP扩展为双向模式。他们的智能体通过内部MCP工具层从遥测数据库获取数据，然后将相同的推理能力作为MCP服务器暴露给其他智能体，这样其他智能体可以直接向它提问，无需为人类设计的聊天界面。

这种模式的内部实现本身就很有价值，即使不考虑外部功能。一个简单的实现方式会让智能体直接对遥测存储执行SQL查询，并将所有行直接导入模型上下文，这在真实生产数据库中会导致单次请求消耗大量令牌预算。通过MCP工具层进行处理，智能体可以编程化地检查和过滤数据，获取特定作业的执行计划或具体堆栈跟踪，而非整个表格，从而保持上下文足够小以进行有效推理。通过工具而非原始连接来中介数据库访问，也是实现该模式外部功能的必要条件。将仅返回有限、特定用途答案的工具暴露给不可控的调用者是安全的，而原始SQL连接永远不会具备这种安全性。

这正是改变产品本质的决策。一旦代理自身的推理逻辑已经封装在工具接口后，对外暴露它只需在相同工具前部署一个MCP服务器。在这种情况下，这意味着一个在终端或IDE中工作的编码代理可以直接调用性能代理并询问特定任务，就像调用其他任何工具一样。人类无需打开仪表板、在聊天框中描述问题，再将答案复制回自己的工作流程。聊天界面是终点，而MCP服务器可以成为其他代理构建基础设施的基础，无需为它们编写第二个集成接口。

容易被忽略的关键点：一旦你开始为不受你控制的调用者提供服务，该服务器就需要真正的访问控制。任何能访问它的人都能直接调用你的推理层。一个仅被你自己的代理调用的工具接口无需考虑这个问题。而一个外界可以调用的工具接口则必须考虑。

立即行动：如果你的代理已经在内部通过MCP与自己的数据交互，先检查一下将这些工具对外暴露需要额外付出多少工作量，然后再构建一个仅面向人类的第二套API来做相同的事情。

模式2：让代理并行响应同一事件

一个团队的首个版本是线性流水线：传感器监控代理调用合规性代理，合规性代理调用住户消息代理，住户消息代理再调用调度代理。作为演示它运行良好，但在实际使用场景中却崩溃了——比如通过步态变化检测跌倒风险，同时与实时药物相互作用数据库交叉验证，并在行动窗口关闭前将消息发送给正确的人。

解决方案是基于四个独立asyncio.Queue实例构建的异步事件总线，每个代理一个队列，各自拥有独立的工作者协程从中拉取任务。代理不再通过Agent A调用Agent B并等待返回值，而是通过发布类型化事件到命名主题，并订阅自己关心的主题。当步态速度下降15%或更多时，会发布CLINICAL.ANOMALY_DETECTED事件。合规性代理已经订阅了该主题，因此事件触发的瞬间就能立即获取到，与药物相互作用数据库交叉验证后，会在完成的那一刻立即发布CLINICAL.COMPLIANCE_REPORT_READY事件，而不是等待轮询间隔，也不需要上游显式传递。消息和调度代理在下游也以相同方式工作，每个代理都是由订阅的主题唤醒，而不是等待前一个代理的直接调用。

调用链与事件总线的本质区别在于：在调用链中，总延迟是累加的，代理1的时间加上代理2的时间再加上代理3的时间，因为每个代理都在等待下一个代理的响应。而在基于主题的总线中，两个不依赖彼此输出的代理可以同时运行，因为彼此之间不会阻塞。当你需要让代理在真正不同的节奏上运行时（比如一个每几秒轮询一次，一个进行需要0.5秒的网络调用，一个只在最后时刻触发），将它们全部串入单个调用栈会导致最快的代理仍被最慢的代理所限制。

立即行动：检查你的两个代理是否需要对同一信号做出响应。如果架构迫使其中一个必须等待另一个完成才能执行，那这就是一个披着多代理外衣的单线程系统。

模式 3：后备模型仍需通过你的标准

另一个团队的临床推理代理运行在 Gemini 3.1 Pro 上。在真实负载下，Pro 开始返回 503 错误。大多数其他系统会直接在相同模型上重试并继续处理。而这个团队则构建了回退机制，将请求转至 Gemini 3.6 Flash 并采用指数退避策略，且无论哪个模型返回结果，都必须经过完全相同的验证函数：通过引用检查确认答案确实引用了真实临床指南，而非仅仅是听起来合理的医学语言。

值得借鉴的关键点并非后备机制本身，而是验证逻辑的位置。验证函数没有分别在主流程和后备流程中重复实现，这会导致更新一处而遗忘另一处。而是存在一个统一的 validate_clinical_response() 函数，主流程和后备流程都必须在结果离开代理前强制调用该函数。一旦响应进入该函数，无论来自哪个模型，都无法获得任何捷径，任何未通过验证的响应都无法被接受，即使它恰好是当前可用的模型。

正是这种设计真正防止了后备机制悄悄降低标准：不是因为忘记重复应用标准，而是通过架构设计使只应用一次标准变得不可能。

立即行动：找到你的后备机制触发后的代码路径。如果它跳过了主流程中存在的验证步骤，那么你实际上在同时交付两个不同产品，却只测试了其中一个。

模式 4：昂贵调用前的分级路由

推理成本可能是当前 AI 领域最受争议的约束条件：每个人都希望获得前沿模型的推理能力，但又不想为每个请求支付前沿模型的费用。这正是我们在本轮生产环境中实际看到的降本方案之一。

某团队测量了实际消耗推理预算的来源，发现并非那些复杂问题，而是大量简单查询："我的订单在哪"、"取消预约"等请求，与真正需要推理的模糊请求使用了相同的完整模型调用。他们的解决方案是在代理前增加三层分类器：本地正则表达式匹配在零 token 成本下捕获导航意图；模糊案例通过廉价的 Gemini 调用（10 token，温度 0.1）进行意图分类；只有同时通过这两层的请求才会进入完整推理模型。根据他们的测量，仅第一层分类器就处理了超过 40% 的入站消息，无需任何真实模型调用。另一个案例将该思路应用于不同流程：快速廉价模型对入站案例进行初步筛选和分级，仅将需要深度推理的案例转交给更慢更贵的模型。不要用最昂贵的模型处理廉价模型已经能完成的决策。

立即行动：在假设需要更大模型之前，先分析你的流量分布。通常，一个廉价的预处理步骤能走得更远。

回顾本轮挑战赛，那些基于代理开发工具包（ADK）并通过代理 CLI 驱动的参赛作品最常展现出这些模式，主要因为该框架不会对并发处理、后备机制或跨代理工具调用设置障碍。

在所有这四种模式中，没有一种真正需要更大的团队或更新的模型。它们体现了经常被忽视的优秀工程实践。此外，它们可以很好地组合在一起并相互补充。有一个团队特别突出，他们在同一构建中结合了第一种模式和第三种模式：一个根代理并发地派发专业代理，然后将整个推理层作为其他代理可以直接调用的MCP服务器公开。

这就是我们在下一轮要寻找的标准：一个遵循这四种模式的系统。但你不需要完成挑战任务。在你的下一个构建中使用这些模式。

发布于：

• AI

• 云服务

• 案例研究

• 最佳实践

• 学习

上一篇

下一篇

相关文章

列表

AI

案例研究

社区

使用深度学习和Keras解码宇宙信号

2026年8月27日

云服务

学习

HeyGen x Google Cloud：将Avatar IV带入TPUs

2026年8月13日

操作指南

公告

推动开发者卓越：项目冲刺内部解析

2026年9月4日

导航点