我们刚刚结束了 Google for Startups AI Agents Challenge，来自世界各地的数千名开发者提交了智能体作品，我们的评审团对三个赛道的参赛作品进行了评分。
“多智能体系统”可能是参赛作品中最常见的表述，但仔细审视后发现，有些确实是真正复杂的多智能体解决方案，而另一些则只是通过一串提示词运行的单一模型，只不过给各个步骤贴上了智能体的名字。
不过，在这些形形色色的作品中，真正在每个赛道名列前茅的参赛作品，始终展现出同样的一小撮工程决策和模式。以下是其中四个，值得你在自己的开发中借鉴。它们取自真实的代码提交，描述时不提具体团队名称，因为重点不在于某个团队：
- 双向 MCP：一个智能体既是自身工具集的客户端，又是可供其他智能体调用的服务器。
- 事件驱动并发：智能体并行响应共享信号，而不是在调用链中排队等待。
- 同级回退：用较小的模型顶替过载的模型，且不经过低质量检查。
- 分层路由：在模型被调用之前，先运行廉价、确定性的检查。
模式一：你为自己构建的工具，也可以为其他智能体所用
大多数参赛作品只单向使用 MCP：智能体向外调用工具服务器获取数据。不过，有一个团队把它做成了双向的。他们的智能体在内部通过自己的 MCP 工具层消费遥测数据库，然后把同样的推理过程暴露成一个可供其他智能体调用的 MCP 服务器，这样另一个智能体就能直接向它提问，完全不需要为人类构建聊天界面。
即便先不谈外部那一半，光是内部这一半本身就很有价值。这个智能体的一个朴素版本会直接对遥测存储执行 SQL 查询，把每一行数据都塞进模型的上下文里——在真实的生产数据库上，这正是单个请求就能烧穿你 token 预算的做法。而通过 MCP 工具层来处理，意味着智能体获得的是以编程方式检查、过滤数据的工具，取回的是某个任务的执行计划或某条具体的堆栈跟踪，而不是整张表，这样上下文才能保持足够小，真正可以进行推理。通过工具而非原始连接来中介数据库访问，也正是让这个模式的外部那一半成为可能的原因。暴露一个只返回有界、专用答案的工具，交给不受你控制的调用方是安全的，而原始 SQL 连接则永远做不到这一点。
正是这个决定改变了产品的本质。一旦智能体自身的推理已经位于工具接口之后，将其对外暴露就只是在同一批工具前架设一个 MCP 服务器而已。在这种情况下，这意味着在终端或 IDE 中工作的编码智能体可以直接调用性能智能体，询问某个具体任务的情况，就像调用任何其他工具一样。人类无需打开仪表盘、在聊天框中描述问题，再把答案复制回自己的工作流程。聊天界面是一个终点，而 MCP 服务器可以成为其他智能体构建于其上的基础设施，无需任何人为它们编写第二套集成。
容易被忽略的部分：一旦你服务的调用方不受你控制，该服务器就需要真正的访问控制。任何能触达它的人现在都可以直接调用你的推理层。一个只有你自己的智能体会调用的工具表面无需考虑这一点。而外部世界可以调用的工具表面则必须考虑。
今天就做这件事：如果你的智能体已经在内部通过 MCP 与自己的数据对话，那么在构建第二个仅面向人类的、功能重复的 API 之前，先检查一下将同样的工具对外暴露需要多少额外工作。
模式 2：让智能体并行响应同一事件
某个团队的第一版是线性流水线：传感器监控智能体调用合规智能体，合规智能体调用住户消息智能体，住户消息智能体再调用调度智能体。作为演示它运行良好。但在真实用例中却崩溃了：从步态变化中捕捉跌倒风险、与实时药物相互作用数据库交叉比对、并在行动窗口关闭前将消息送达正确的人。
解决方案是构建一个基于四个独立 asyncio.Queue 实例的异步事件总线，每个智能体对应一个队列，每个队列都有各自的工作协程从中拉取事件。智能体 A 不再直接调用智能体 B 并等待返回值，而是将类型化事件发布到命名主题，并订阅自己关心的主题。步态速度下降 15% 或更多时，会发布一个 CLINICAL.ANOMALY_DETECTED 事件。合规智能体早已在该主题上待命，因此事件一触发它就能立刻拾取，与药物相互作用数据库进行交叉比对，并在处理完成后立即发布自己的 CLINICAL.COMPLIANCE_REPORT_READY 事件——不是按轮询间隔，也不是等待上游任何环节显式交接。消息智能体和调度智能体在下游也以同样的方式工作，各自被自己订阅的主题唤醒，而不是被前一个执行者直接调用。
这就是调用链与事件总线之间的真正区别：在调用链中，总延迟是累加的，智能体一的时间加上智能体二的时间再加上智能体三的时间，因为每个智能体都在保持调用栈打开、等待下一个返回。而在基于主题的总线上，两个不依赖彼此输出的智能体可以在同一时刻运行，因为两者都不会阻塞在对方的返回值上。只要你的智能体运行在真正不同的节奏上，你就需要这种形态：一个每隔几秒轮询一次，一个发起需要半秒的网络调用，还有一个只在最后触发一次。把所有这一切串成单一调用栈，那么即使是最快的智能体，也仍然会被耗时最长的那个卡住瓶颈。
今天就做这件事：检查你的两个智能体是否需要对同一个信号做出反应。如果你的架构让其中一个必须等另一个完成后才能响应，那这就是一个披着多智能体外衣的单线程系统。
模式三：备用模型同样必须达到你的标准
另一个团队的临床推理智能体运行在 Gemini 3.1 Pro 上。在真实负载下，Pro 开始返回 503 错误。大多数其他团队的做法是给同一个模型加上重试循环然后继续。而这个团队的做法是：构建了一个带退避机制的 Gemini 3.6 Flash 备用方案，并且无论响应来自哪个模型，在采纳之前都必须通过完全相同的验证函数——即引用检查，确认答案确实引用了真实的临床指南，而不是仅仅听起来像那么回事的医学语言。
这里值得借鉴的细节不是备用方案本身的存在，而是验证逻辑所处的位置。它并没有为主路径和备用路径各复制一份——那样很容易更新了一份却忘了另一份。而是只有一个 validate_clinical_response() 函数，Pro 路径和 Flash 路径在结果离开智能体之前都必须强制调用它。一旦响应进入该函数，它是由哪个模型生成的就不重要了，两者都没有捷径可走，任何一个都不能仅仅因为它是请求到来时恰好可用的那个模型，就带着未通过检查的答案被放行。
这才是真正防止备用方案悄悄拉低你标准的做法：不是记得把同一标准应用两次，而是从结构上让只应用一次变得不可能。
今天就做这件事：去找到备用方案触发后所运行的代码路径。如果它跳过了主路径所具备的某个验证步骤，那你实际上是在交付两种不同的产品，却只测试了其中一种。
模式四：在昂贵调用之前进行分层路由
推理成本可能是当前 AI 领域争论最多的制约因素：每个人都希望在每个请求上获得前沿模型的推理能力，却不想承担前沿模型的价格。这是我们在本周期中实际看到在生产环境中行之有效的成本模式之一。
有一个团队测量了究竟是什么在消耗他们的推理预算，结果发现消耗预算的并不是难题，而是简单问题：“我的订单到哪了”、“取消我的预约”——这些简单请求与真正模糊不清的请求一样，都要走一遍完整的模型调用。他们的解决方案是在智能体前面加一个三层分类器：第一层用本地正则表达式匹配，以零 token 成本识别导航类意图；遇到模糊情况时，调用一次廉价的 Gemini 模型，仅用十个 token、温度设为 0.1 来分类意图；只有通过前两层的请求才会进入完整的推理模型。据他们自己的测量，仅第一层就在真正调用模型之前处理了超过 40% 的传入消息。另一个参赛作品将同样的思路应用到了不同的流水线上：一个快速、廉价的模型对传入案例进行把关和分诊，只把需要深度推理的案例升级给更慢、更贵的模型。不要把最贵的模型花在一个更便宜的模型就能做出的决策上。
今天就行动起来：在假设自己需要更大模型之前，先看看你的流量分布。一个更便宜的初筛层通常能让你走得更远。
回顾这一轮挑战赛，基于 Agent Development Kit（ADK）构建并通过 Agents CLI 驱动的参赛作品，是这些模式出现频率最高的，主要是因为该框架不会在并发、回退或将工具移交给另一个智能体这些方面给你制造障碍。
在这四种模式中，没有一种真正需要更大的团队或更新的模型。它们代表的是经常被忽视的扎实工程实践。此外，它们之间组合良好、相互补充。其中有一个团队尤为突出，他们在同一次构建中把模式一和模式三结合了起来：一个根智能体并发地调度多个专家智能体，然后将整个推理层暴露为一个 MCP 服务器，供其他智能体直接调用。
这就是我们在下一轮中要寻找的标准：一个遵循这四种模式的系统。但你并不需要去完成某个挑战。在你下一次构建中运用这些模式即可。
- AI
- 云
- 案例研究
- 最佳实践
- 学习
We just wrapped the Google for Startups AI Agents Challenge with thousands of builders shipping agents from around the world, and our panel scored submissions across three tracks.
The “multi-agent-system” was probably the most frequent claim across the submissions, and on closer inspection, some actually were truly sophisticated multi-agent solutions while some others turned out to be a single model working through a chain of prompts with agent names attached.
Across this spectrum though the entries that actually ranked at the top of each track kept showing the same handful of engineering decisions and patterns. Here are four of them, worth stealing for your own build. They're pulled from real code submissions and described without names, because this isn't about any one team:
- Bidirectional MCP: an agent that's both a client of its own tools and a server other agents can call.
- Event-driven concurrency: agents reacting to a shared signal in parallel instead of waiting in a call chain.
- Same-bar fallback: a smaller model standing in for an overloaded one without a lower quality check.
- Tiered routing: cheap, deterministic checks running before the model gets touched at all.
Pattern 1: The tools you built for yourself can serve other agents too
Most submissions used MCP one direction: the agent calls out to a tool server for data. However, one team extended it both ways. Their agent consumed a telemetry database through its own MCP tool layer internally, then exposed that same reasoning as an MCP server other agents could call, so another agent could ask it a question directly, no chat UI built for humans required.
The internal half of this matters on its own, before you even get to the external half. A naive version of this agent would run a SQL query against the telemetry store and dump every row straight into the model's context, and that on a real production database is exactly how a single request blows through your token budget. Going through an MCP tool layer means the agent gets tools to inspect and filter the data programmatically, pulling back a job's execution plan or a specific stack trace rather than an entire table, so the context stays small enough to actually reason over. Mediating database access through tools rather than a raw connection is also what makes the external half of the pattern possible at all. Exposing a tool that only ever returns a bounded, purpose-built answer is safe to hand to a caller you don't control while a raw SQL connection never would be.
That's the decision that changes what the product is. Once the agent's own reasoning already sits behind a tool interface, exposing it externally just means standing up an MCP server in front of the same tools. In this case, that meant a coding agent working in a terminal or an IDE could call the performance agent directly and ask about a specific job, the same way it calls any other tool. A human doesn't have to open a dashboard, describe the problem in a chat box, and copy the answer back into their own workflow. A chat interface is a destination while an MCP server can be infrastructure other agents build on, without anyone writing a second integration for them.
The part that's easy to skip: once you're serving a caller you don't control, that server needs real access control. Anyone who can reach it can now call your reasoning layer directly. A tool surface only your own agent ever calls doesn't need to think about that. A tool surface the outside world can call does.
Do this today: if your agent already talks to its own data over MCP internally, check how much extra work it'd take to expose those same tools externally, before you build a second, human-only API that does the same job.
Pattern 2: Let agents react to the same event in parallel
One team's first version was a linear pipeline: a sensor-monitoring agent called a compliance agent, which called a resident-messaging agent, which called a dispatch agent. It worked fine as a demo. It fell apart on the real use case: catching a fall risk from a change in gait, cross-referencing it against a live drug-interaction database, and getting a message to the right person before the window to act closed.
The fix was an async event bus built on four separate asyncio.Queue instances, one per agent, each with its own worker coroutine pulling from it. Instead of Agent A calling Agent B and waiting for a return value, agents publish typed events to named topics and subscribe to whichever ones they care about. A gait-velocity drop of 15 percent or more publishes a CLINICAL.ANOMALY_DETECTED event. The compliance agent is already parked on that topic, so it picks the event up the instant it fires, cross-references it against the drug-interaction database, and publishes its own CLINICAL.COMPLIANCE_REPORT_READY event the moment it's done, not on a polling interval, not waiting for anything upstream to explicitly hand it off. The messaging and dispatch agents work the same way downstream, each one woken by the topic it subscribes to rather than a direct call from whoever ran before it.
That's the actual difference in a call chain versus an event bus: in a call chain, total latency is additive, agent one's time plus agent two's plus agent three's, because each one is holding the stack open waiting on the next. On a topic-based bus, two agents that don't depend on each other's output run at the same moment, because neither one is blocking on the other's return. You want this shape wherever your agents run on genuinely different tempos: one polling every few seconds, one making a network call that takes half a second, one that only fires once at the very end. Chain all of that into a single call stack and your fastest agent is still bottlenecked behind whichever one takes longest.
Do this today: check whether two of your agents ever need to react to the same signal. If your architecture makes one wait behind the other to do it, that's a single-threaded system wearing a multi-agent label.
Pattern 3: A fallback model still has to clear your bar
A different team's clinical-reasoning agent ran on Gemini 3.1 Pro. Under real load, Pro started returning 503s. Most other entries would bolt on a retry loop against the same model and move on. Instead, this team built a fallback to Gemini 3.6 Flash with backoff, and ran the response from either model through the exact same validation function before accepting it: a citation check confirming the answer actually named a real clinical guideline, not just plausible-sounding medical language.
The detail worth stealing here isn't the existence of a fallback, it's where the validation lives. It isn't duplicated once for the primary path and once for the fallback path, where it's easy to update one copy and forget the other. There's a single validate_clinical_response() function that both the Pro path and the Flash path are forced to call before either result can leave the agent. Once a response hits that function, it doesn't matter which model produced it, neither one gets a shortcut, and neither can ship an answer that fails the check just because it happened to be the one available when the request came in.
That's what actually prevents a fallback from quietly lowering your bar: not remembering to apply the same standard twice, but making it structurally impossible to apply it only once.
Do this today: go find the code path that runs after your fallback fires. If it skips a validation step the primary path has, you're shipping two different products while only testing one.
Pattern 4: Tiered routing before the expensive call
Inference cost is probably the most argued-about constraint in AI right now: everyone wants frontier-model reasoning without frontier-model prices on every request. This is one of the cost patterns we actually saw working in production this cycle.
One team measured what was actually eating their inference budget and found it wasn't the hard questions, it was the easy ones: "where's my order," "cancel my appointment," going through the same full model call as genuinely ambiguous requests. Their fix was a three-layer classifier in front of the agent: a local regex pass catches navigational intent at zero tokens, an ambiguous case gets a cheap Gemini call at ten tokens and temperature 0.1 just to classify intent, and only what survives both reaches the full reasoning model. That first pass alone handled more than 40 percent of incoming messages, by their own measurement, before a real model call ever happened. A separate entry applied the same idea to a different pipeline: a fast, cheap model gates and triages an incoming case, escalating only what needs deep reasoning to a slower, pricier model. Don't spend your most expensive model on a decision a cheaper one can already make.
Do this today: look at your own traffic distribution before assuming you need a bigger model. A cheaper first pass usually gets you further.
Looking back at this round of the Challenge, the entries built on Agent Development Kit (ADK) and driven through the Agents CLI were the ones where these patterns showed up most often, mostly because the framework doesn't fight you on concurrency, fallback, or handing a tool to another agent.
Across all these four patterns none of them truly require bigger teams or newer models. They represent sound engineering practices that are frequently overlooked. Also, they compose nicely and complement each other. One team in particular that stood out combined pattern one and pattern three together in the same build: a root agent fanning specialist agents out concurrently, then exposing that whole reasoning layer as an MCP server other agents could call directly.
That's the bar we'll be looking for in the next round: a system that follows these four patterns. But you don’t need to be completing a challenge. Use these patterns in your next build.