最强 AI Agents 挑战赛作品背后的 4 个工程模式

• Facebook

• Twitter

• LinkedIn

• 邮件

我们刚刚结束了 Google for Startups AI Agents 挑战赛，来自世界各地的数千名开发者提交了他们的 agent 作品，我们的评审团在三个赛道中进行了评分。

“多智能体系统”可能是提交作品中最常见的说法，但仔细一看，有些确实是真正复杂的多智能体解决方案，而另一些则只是一个模型通过一串提示词（prompt）在运行，只是给这些步骤贴上了 agent 的名字而已。

不过，在这些作品中，真正在每个赛道排名靠前的参赛作品 反复展示了同样的几个工程决策和模式。以下是其中四个，值得你在自己的项目中借鉴。它们来自真实的代码提交，描述时不提具体团队名字，因为这不是关于某一个团队的：

• 双向 MCP：一个 agent 既是自己工具（tool）的客户端，又是其他 agent 可以调用的服务器。
• 事件驱动并发：agent 并行响应同一个信号，而不是在调用链中排队等待。
• 同标准降级：当主模型过载时，用一个小模型顶上，但不会降低质量检查的标准。
• 分层路由：在模型被调用之前，先运行便宜、确定性的检查。

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

大多数提交作品只在一个方向上使用了 MCP：agent 调用工具服务器来获取数据。但有一个团队把它扩展成了双向的。他们的 agent 通过自己的 MCP 工具层内部消费一个遥测数据库（telemetry database，用于记录系统运行数据的数据库），然后把同样的推理能力以 MCP 服务器的形式暴露出来，让其他 agent 可以直接调用。这样，另一个 agent 可以直接向它提问，不需要为人类专门构建聊天界面。

内部这一半本身就很重要，甚至在你考虑外部那一半之前。这个 agent 的一个简单版本可能会对遥测数据库运行 SQL 查询，然后把每一行数据直接塞进模型的上下文里。在真实的生产数据库上，这就是单个请求如何烧光你的 token 预算的方式。通过 MCP 工具层，agent 获得的是以编程方式检查和过滤数据的工具，拉回来的是一个任务的执行计划或一个具体的堆栈跟踪（stack trace，程序出错时的调用记录），而不是整张表。这样上下文保持足够小，模型才能真正进行推理。通过工具来中介数据库访问，而不是直接连接，这也是让模式的外部一半成为可能的原因。暴露一个只返回有界、有目的答案的工具，对于你无法控制的调用方来说是安全的，而原始的 SQL 连接则永远不可能安全。

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

容易忽略的部分是：一旦你开始服务一个你无法控制的调用方，那个服务器就需要真正的访问控制。任何能访问到它的人现在都可以直接调用你的推理层。一个只有你自己的 agent 会调用的工具表面不需要考虑这个问题。但一个外部世界可以调用的工具表面就必须考虑。

今天就试试：如果你的 agent 已经在内部通过 MCP 与自己的数据对话，检查一下把这些同样的工具对外暴露需要多少额外工作——在你去构建第二个只给人类用的 API 之前。

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

一个团队的第一版是一个线性流水线：传感器监控 agent 调用合规 agent，合规 agent 调用住户通知 agent，住户通知 agent 再调用调度 agent。作为演示它运行得很好，但在真实场景中就崩溃了：从步态变化中捕捉跌倒风险、与实时药物相互作用数据库交叉比对、在行动窗口关闭之前把消息送到正确的人手中。

解决方案是构建在一个异步事件总线（event bus，一种让不同组件通过发布和订阅消息来通信的机制）上，由四个独立的 asyncio.Queue 实例组成，每个 agent 一个，每个都有自己的工作协程（coroutine，一种可以暂停和恢复的函数）从中拉取消息。不再是 Agent A 调用 Agent B 然后等待返回值，而是 agent 向命名主题发布类型化事件，并订阅它们关心的主题。步态速度下降 15% 或更多时，会发布一个 CLINICAL.ANOMALY_DETECTED 事件。合规 agent 已经停靠在该主题上，所以它会在事件触发的瞬间拾取它，与药物相互作用数据库交叉比对，完成后立即发布自己的 CLINICAL.COMPLIANCE_REPORT_READY 事件——不是按轮询间隔，也不是等待上游任何东西显式地交接给它。消息和调度 agent 在下游以同样的方式工作，每个都由它们订阅的主题唤醒，而不是由前一个运行者的直接调用来触发。

这就是调用链和事件总线之间的真正区别：在调用链中，总延迟是累加的——agent 一的时间加上 agent 二的时间加上 agent 三的时间——因为每个都在保持调用栈打开，等待下一个完成。在基于主题的总线上，两个不依赖彼此输出的 agent 在同一时刻运行，因为没有一个在阻塞等待另一个的返回。只要你的 agent 运行在真正不同的节奏上，你就需要这种结构：一个每几秒轮询一次，一个做网络调用需要半秒，一个只在最后触发一次。把所有这些串成一个单一的调用栈，你最快的 agent 仍然会被最慢的那个拖住。

今天就试试：检查你的两个 agent 是否需要对同一个信号做出反应。如果你的架构让一个必须等另一个完成后才能行动，那这就是一个穿着多智能体外衣的单线程系统。

模式 3：降级模型仍然必须达到你的标准

另一个团队的临床推理 agent 运行在 Gemini 3.1 Pro 上。在真实负载下，Pro 开始返回 503 错误（服务不可用）。大多数其他参赛作品会加上一个针对同一模型的重试循环然后继续。但这个团队构建了一个带退避策略（backoff，失败后逐渐增加等待时间的重试策略）的 Gemini 3.6 Flash 降级方案，并且无论哪个模型产生的响应，在接收之前都要经过完全相同的验证函数：一个引用检查，确认答案确实提到了真实的临床指南，而不仅仅是听起来像医学的语言。

这里值得借鉴的细节不是降级方案的存在，而是验证逻辑所在的位置。它不是为主路径和降级路径各复制一份——那样很容易更新一份而忘记另一份。这里有一个单一的 validate_clinical_response() 函数，Pro 路径和 Flash 路径在结果离开 agent 之前都必须调用它。一旦响应进入这个函数，是哪个模型产生的就不重要了——两者都没有捷径，任何一个都不能因为恰好是请求到达时可用的那个模型而通过一个未通过检查的答案。

这才是真正防止降级悄悄降低你标准的做法：不是记住要两次应用相同的标准，而是从结构上让只应用一次变得不可能。

今天就试试：找到降级触发后运行的代码路径。如果它跳过了主路径有的验证步骤，那你就是在发布两个不同的产品，却只测试了一个。

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

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

一个团队测量了到底是什么在消耗他们的推理预算，发现不是难题，而是简单问题：“我的订单在哪里”、“取消我的预约”——这些和真正模糊的请求走的是同一个完整模型调用。他们的解决方案是在 agent 前面加一个三层分类器：第一层是本地正则表达式（regex，一种文本匹配规则）检查，以零 token 成本捕捉导航类意图；模糊的情况会得到一个便宜的 Gemini 调用，只用 10 个 token、温度设为 0.1，仅用于分类意图；只有通过这两层的才会到达完整的推理模型。根据他们自己的测量，仅第一层就在真正调用模型之前处理了超过 40% 的传入消息。另一个参赛作品把同样的想法应用到了不同的流水线上：一个快速、便宜的模型对传入案例进行门控和分流，只把需要深度推理的升级给一个更慢、更贵的模型。不要把你最贵的模型花在一个更便宜的模型已经能做的决定上。

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

回顾这一轮挑战赛，基于 Agent Development Kit (ADK) 构建并通过 Agents CLI 驱动的作品，是这些模式出现最多的地方，主要是因为该框架不会在并发、降级或把工具交给另一个 agent 这些方面跟你对着干。

这四个模式都不需要更大的团队或更新的模型。它们代表的是经常被忽视的扎实工程实践。而且它们能很好地组合在一起，互相补充。特别值得一提的是，有一个团队在同一构建中结合了模式一和模式三：一个根 agent 并发地派出多个专家 agent，然后把整个推理层暴露为一个 MCP 服务器，让其他 agent 可以直接调用。

这就是我们下一轮会寻找的标准：一个遵循这四个模式的系统。但你不需要参加挑战赛才能用上它们。在你下一个构建中使用这些模式吧。

• AI

• Cloud

• 案例研究

• 最佳实践

• 学习