Google 复盘 AI Agents Challenge：最强参赛作品背后的 4 种工程模式

2026年9月2日

我们刚刚结束了Google for Startups AI Agents Challenge，来自世界各地的数千名构建者提交了智能体，我们的评审小组对三个赛道的提交作品进行了评分。

“多智能体系统”可能是所有提交作品中最常见的说法，但仔细审视后发现，有些确实是真正复杂的多智能体解决方案，而另一些则不过是一个模型在一条提示链上运行，只是给每个环节贴上了智能体的名字。

不过，纵观整个范围，真正在每个赛道中排名靠前的参赛作品都反复展现出同样几个工程决策和模式。以下是其中四个，值得你在自己的构建中借鉴。它们取自真实的代码提交，描述时不提及名称，因为这与任何单个团队无关：

• 双向 MCP：一个智能体既是自身工具的客户端，又是其他智能体可以调用的服务器。
• 事件驱动并发：智能体并行响应共享信号，而不是在调用链中等待。
• 同栏回退：用较小的模型顶替过载的模型，而不降低质量检查标准。
• 分层路由：在触及模型之前先运行廉价、确定性的检查。

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

大多数提交作品只单向使用 MCP：智能体调用工具服务器获取数据。然而，有一个团队将其扩展到了双向。他们的智能体在内部通过自己的 MCP 工具层消费遥测数据库，然后将同样的推理能力作为 MCP 服务器暴露出来，供其他智能体调用，这样另一个智能体就可以直接向它提问，无需为人类构建聊天界面。

即使还没到外部那一半，内部的这一半本身就已经很重要。这个智能体的朴素版本会对遥测存储运行 SQL 查询，并将每一行直接倾倒进模型的上下文中，而在真实的生产数据库上，这正是单个请求耗尽你 token 预算的方式。通过 MCP 工具层意味着智能体获得工具，以编程方式检查和过滤数据，只取回某个作业的执行计划或特定的堆栈跟踪，而不是整张表，从而使上下文保持足够小，以便真正进行推理。通过工具而非原始连接来中介数据库访问，也正是这个模式外部那一半得以实现的原因。暴露一个只返回有界、专用答案的工具，可以安全地交给你不控制的调用方，而原始 SQL 连接则永远不行。

正是这个决策改变了产品的本质。一旦智能体自身的推理已经位于工具接口之后，将其对外暴露就只是在同一批工具前面架起一个 MCP 服务器。在这个案例中，这意味着在终端或 IDE 中工作的编码智能体可以直接调用性能智能体，询问某个特定作业的情况，就像调用任何其他工具一样。人类不必打开仪表盘、在聊天框中描述问题，再把答案复制回自己的工作流中。聊天界面是一个目的地，而 MCP 服务器可以成为其他智能体赖以构建的基础设施，无需任何人为它们编写第二套集成。

容易被忽略的一点：一旦你开始为不受你控制的调用方提供服务，那台服务器就需要真正的访问控制。任何能访问到它的人，现在都能直接调用你的推理层。一个只有你自己的智能体才会调用的工具接口不需要考虑这一点。一个外部世界可以调用的工具接口则需要。

今天就可以做的事：如果你的智能体已经在内部通过 MCP 与自己的数据通信，那就先评估一下把这些同样的工具对外暴露需要多少额外工作，然后再去构建一个功能相同、仅供人类使用的第二套 API。

模式 2：让智能体并行响应同一个事件

某个团队的第一版是一条线性流水线：一个传感器监控智能体调用一个合规智能体，后者调用一个居民消息智能体，后者再调用一个调度智能体。作为演示它运行良好。但在真实用例中它崩溃了：从步态变化中捕捉跌倒风险，将其与实时药物相互作用数据库交叉比对，并在行动窗口关闭之前把消息送达正确的人。

修复方案是基于四个独立的 asyncio.Queue 实例构建的异步事件总线，每个智能体一个，各自有专属的 worker 协程从中拉取。智能体 A 不再调用智能体 B 并等待返回值，而是向命名主题发布类型化事件，并订阅自己关心的那些主题。步态速度下降 15% 或更多会发布一个 CLINICAL.ANOMALY_DETECTED 事件。合规智能体已经驻留在该主题上，因此事件一触发它就会立即拾取，将其与药物相互作用数据库交叉比对，并在完成的那一刻发布自己的 CLINICAL.COMPLIANCE_REPORT_READY 事件——不是按轮询间隔，也不是等待上游任何东西显式移交。消息和调度智能体在下游以同样的方式工作，每一个都是被自己订阅的主题唤醒，而不是被前一个运行的智能体直接调用。

这就是调用链与事件总线的真正区别：在调用链中，总延迟是累加的——智能体一的时间加上智能体二的时间再加上智能体三的时间，因为每一个都保持着调用栈打开、等待下一个。在基于主题的总线上，两个不依赖彼此输出的智能体会在同一时刻运行，因为谁都不阻塞在对方的返回值上。只要你的智能体以真正不同的节奏运行，你就需要这种形态：一个每隔几秒轮询一次，一个进行耗时半秒的网络调用，一个只在最后触发一次。把这一切串进单个调用栈，你最快的智能体仍然会被耗时最长的那个拖成瓶颈。

今天就可以做的事：检查你的两个智能体是否曾经需要对同一个信号做出反应。如果你的架构让其中一个必须排在另一个后面才能做到，那就是一个披着多智能体外衣的单线程系统。

模式 3：回退模型仍然必须达到你的标准

另一个团队的临床推理智能体运行在 Gemini 3.1 Pro 上。在真实负载下，Pro 开始返回 503。大多数其他方案会针对同一个模型加一个重试循环然后了事。而这个团队构建了到 Gemini 3.6 Flash 的回退并带有退避，并且在接受之前，把来自任一模型的响应都送进完全相同的验证函数：一项引用检查，确认答案确实引用了一条真实的临床指南，而不只是听起来像那么回事的医学术语。

这里值得借鉴的细节不是回退机制的存在，而是验证逻辑所在的位置。它没有被复制成两份——一份给主路径、一份给回退路径——那样很容易更新了一份却忘了另一份。这里只有一个 validate_clinical_response() 函数，Pro 路径和 Flash 路径在结果离开 agent 之前都被强制调用它。一旦响应进入这个函数，无论它是由哪个模型生成的，两者都没有捷径可走，也都不能因为请求到来时恰好是它可用就发出一个未通过检查的答案。

这才是真正防止回退机制悄悄降低你标准的方法：不是记得把同一标准应用两次，而是让只应用一次在结构上变得不可能。

今天就可以做：去找出回退触发后运行的那段代码路径。如果它跳过了主路径拥有的某个验证步骤，那你就是在发布两个不同的产品，却只测试了其中一个。

模式 4：在昂贵调用之前进行分层路由

推理成本大概是当下 AI 领域争论最多的约束：每个人都想要前沿模型的推理能力，却不想为每个请求都付出前沿模型的价格。这是我们在本轮中实际看到在生产环境里奏效的成本模式之一。

有一个团队测量了究竟是什么在吞噬他们的推理预算，结果发现不是那些难题，而是那些简单问题：“我的订单在哪”、“取消我的预约”，它们和真正含义模糊的请求一样走完了整个完整模型调用。他们的解决方案是在 agent 前面加一个三层分类器：本地正则匹配以零 token 捕获导航类意图，模糊的情况用一次廉价的 Gemini 调用、仅十个 token、温度 0.1 来分类意图，只有通过这两层的才会到达完整的推理模型。据他们自己测量，仅第一层就处理了超过 40% 的传入消息，而且是在真正调用模型之前。另一个参赛作品把同样的思路应用到了不同的流水线上：用一个快速、廉价的模型对传入的案例进行把关和分诊，只把需要深度推理的部分升级给更慢、更贵的模型。不要用你最贵的模型去做一个更便宜的模型就能做出的决定。

今天就可以做：在假设你需要一个更大的模型之前，先看看你自己的流量分布。一个更便宜的第一层通常能让你走得更远。

回顾这一轮 Challenge，那些基于 Agent Development Kit (ADK) 构建、并通过 Agents CLI 驱动的参赛作品，是这些模式出现得最频繁的，主要是因为该框架不会在并发、回退或把工具交给另一个 agent 这些事情上跟你作对。

在这四个模式中，没有一个真正需要更大的团队或更新的模型。它们代表的是经常被忽视的扎实工程实践。而且它们能很好地组合并相互补充。有一个特别突出的团队在同一个构建中把模式一和模式三结合了起来：一个根 agent 并发地把专家 agent 分发出去，然后把整个推理层暴露为一个 MCP server，供其他 agent 直接调用。

这就是我们在下一轮中要寻找的标准：一个遵循这四个模式的系统。但你并不需要去完成一个 challenge。在你下一次构建中使用这些模式吧。

Previous

Next