Google 从 AI Agents Challenge 参赛作品中总结四个智能体工程模式

2026年9月2日

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

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

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

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

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

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

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

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

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

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

模式 2：让多个 agent 并行响应同一事件

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

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

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

今天就可以做：检查你的两个 agent 是否曾经需要对同一信号做出反应。如果你的架构让其中一个排队等待另一个来完成这件事，那就是一个披着多 agent 标签的单线程系统。

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

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

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

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

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

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

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

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

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

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

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

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

Previous

Next