AI Agent 挑战赛优胜架构：四大工程模式

我们刚刚结束了 Google for Startups AI Agents Challenge，成千上万的开发者从世界各地提交了他们的 AI Agent作品，评审团对三个赛道的提交作品进行了评分。

"多智能体系统"可能是提交作品中出现最频繁的描述，但仔细审视后，有些确实是真正复杂的多智能体解决方案，而有些只是单个模型通过一系列带有 Agent 名称的提示词链式运行。

不过，在整个参赛作品中，每个赛道实际排名靠前的作品始终呈现出相同的几个工程决策和模式。以下是其中的四个模式，值得你在自己的项目中借鉴。它们源自真实的代码提交，且描述中不提及团队名称，因为这不是在评价任何特定团队：

• 双向 MCP：一个既是自己工具的客户端、也是其他 Agent 可调用服务的服务器
• 事件驱动并发：Agent 响应共享信号并行运行，而非在调用链中等待
• 同一标准降级：用较小的模型替代过载模型，而不降低质量检查标准
• 分层路由：在模型被调用之前，先运行廉价的确定性检查

模式一：为自己构建的工具也可以服务于其他 Agent

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

这个模式的内部部分本身就很有价值，在你考虑外部部分之前。先看这个 Agent 的朴素版本：会对遥测存储运行 SQL 查询，然后将每一行直接倾倒到模型的上下文中——在真实的生产数据库上，单个请求就是这样耗尽你的 token 配额的。通过 MCP 工具层意味着 Agent 获得了以编程方式检查和过滤数据的工具，可以拉取某个任务的执行计划或特定的堆栈跟踪，而不是整个表，因此上下文能够保持足够小以进行实际推理。通过工具而非原始连接来中介数据库访问，也是外部部分模式得以实现的前提。暴露一个只返回有限、目的明确的答案的工具是安全的，可以交给不受控的调用方，而原始 SQL 连接永远做不到这一点。

这就是改变产品的那个决策。一旦 Agent 自己的推理已经位于工具接口之后，外部暴露只需要在相同工具前搭建一个 MCP 服务器。在这种情况下，这意味着一个在终端或 IDE 中工作的编码 Agent 可以直接调用性能 Agent 并询问特定任务，就像调用任何其他工具一样。人类无需打开仪表板、在聊天框中描述问题，然后再把答案复制回自己的工作流。聊天界面是一个目的地，而 MCP 服务器可以成为其他 Agent 构建的基础设施，无需有人再写第二次集成。

容易遗漏的部分是：一旦你在服务一个不受控的调用方，该服务器需要真正的访问控制。任何能访问它的人现在都可以直接调用你的推理层。只有你自己的 Agent 会调用的工具表面不需要考虑这一点。而外部世界可以调用的工具表面则需要。

今天就可以这样做：如果你的 Agent 已经在内部通过 MCP 与自己的数据通信，检查将这些工具对外暴露需要多少额外工作，而不是去构建另一个做同样事情的、仅限人类的 API。

模式二：让 Agent 并行响应同一事件

一个团队的第一版是一个线性管道：一个传感器监控 Agent 调用合规 Agent，合规 Agent 调用住户消息 Agent，住户消息 Agent 再调用调度 Agent。作为演示，它运行良好。但在真实用例中就崩溃了：从步态变化中捕捉跌倒风险、与活着的药物相互作用数据库交叉比对、在行动窗口关闭之前将消息发送给正确的人。

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

这就是调用链与事件总线的实际区别：在调用链中，总延迟是叠加的，Agent 一的时间加上 Agent 二的时间加上 Agent 三的时间，因为每个都在持有栈等待下一个。在基于主题的总线上，两个不依赖彼此输出的 Agent 同时运行，因为没有一个会阻塞另一个的返回。你希望在你的 Agent 以真正不同节奏运行的任何地方使用这种形态：一个每隔几秒轮询一次，一个进行需要半秒的网络调用，一个只在最后触发一次。把所有这些串成一个调用栈，你最快的 Agent 仍然会被最慢的那个拖累。

今天就可以这样做：检查你的两个 Agent 是否曾经需要响应同一信号。如果你的架构让一个等待另一个来做这件事，那你就是一个戴着多 Agent 标签的单线程系统。

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

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

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

这就是真正防止降级悄悄降低标准的方法：不是记得应用两次相同的标准，而是从结构上使其不可能只应用一次。

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

模式四：在昂贵调用之前的分层路由

推理成本可能是目前 AI 领域争论最多的约束：每个人都想要前沿模型的推理能力，却不想让每个请求都支付前沿模型的价格。这是我们在这个周期中真正看到在生产环境中有效的成本模式之一。

一个团队测量了什么真正在消耗他们的推理预算，发现不是难题，而是简单问题："我的订单在哪"、"取消我的预约"，这些与真正模糊的请求一样经过相同的完整模型调用。他们的修复方案是在 Agent 前面放置一个三层分类器：本地 regex 通过以零 token 捕获导航意图，模糊情况以 10 token 和 temperature 0.1 的廉价 Gemini 调用来分类意图，只有同时通过这两层的内容才会到达完整推理模型。仅第一层就处理了超过 40% 的传入消息，根据他们自己的测量，在真实模型调用发生之前。另一个独立的参赛作品将相同的想法应用到不同的管道：一个快速、廉价的模型对传入案例进行门控和分诊，只将需要深度推理的内容升级到更慢、更贵的模型。不要在你更便宜的模型已经能做出决策的地方花费最贵的模型。

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

回顾本轮挑战，使用 Agent Development Kit (ADK) 构建并通过 Agents CLI 驱动的作品是这些模式出现最频繁的，主要是因为该框架不会在并发、降级或向另一个 Agent 提供工具方面给你添麻烦。

在这四个模式中，没有一个真正需要更大的团队或更新的模型。它们代表的是经常被忽视的可靠工程实践。而且它们可以很好地组合和互补。特别是一个脱颖而出的团队将模式一和模式三结合在了同一个项目中：一个根 Agent 并发地分发出专业 Agent，然后将整个推理层暴露为 MCP 服务器，其他 Agent 可以直接调用它。

这就是我们在下一轮中会寻找的标准：一个遵循这四个模式的系统。但你不需要参加挑战才去使用这些模式。在你的下一个项目中运用这些模式。