Google 总结 AI Agents Challenge 中最强提交背后的 4 个工程模式

我们刚刚结束了 Google for Startups AI Agents 挑战赛：https://cloud.google.com/blog/topics/startups/startups-are-building-the-agentic-future-with-google-cloud?e=48754805，全球数千名开发者提交了各类智能代理产品，我们的评审小组对三个赛道的作品进行了评分。

“多代理系统”可能是提交中最常见的宣称，但仔细观察会发现，有些确实是复杂的多代理解决方案，而另一些实际上只是单个模型通过一连串带有代理名称的提示进行工作的方案。

在这个范围中，每个赛道实际排名靠前的作品：https://lnkd.in/p/eVKZNj77 不断显示出相同的几个工程决策和模式。这里列出四个，非常值得在你自己的构建中借鉴。它们摘自真实代码提交，并未指明具体团队，因为重点不是某一个团队：

大多数提交只使用 MCP 的单向功能：代理调用工具服务器获取数据。然而，有一个团队将其扩展为双向。他们的代理通过自己的 MCP 工具层内部访问遥测数据库，然后将相同的推理作为 MCP 服务器公开，其他代理可以直接调用，因此另一个代理可以直接向它提问，无需为人类构建聊天界面。

其中的内部部分本身就很重要，在你还没涉及外部部分之前。如果是一个简单的代理版本，它会对遥测存储运行 SQL 查询并将每一行直接导入模型上下文，而在真正的生产数据库上，这正是一次请求就把你的 token 预算消耗殆尽的方式。通过 MCP 工具层，代理能够使用工具以编程方式检查和过滤数据，提取作业执行计划或特定的堆栈跟踪，而不是整个表，从而保持上下文足够小以供实际推理。通过工具而非直接连接数据库访问，也是使外部模式可行的原因。公开一个始终返回有限、专门构建的答案的工具，是安全的，而原始 SQL 连接永远不能交给你无法控制的调用者。

这是改变产品本质的决策。一旦代理自身的推理已经在工具接口背后，就对外暴露它只是意味着在相同工具前端架设一个MCP服务器。在这种情况下，这意味着一个在终端或IDE中工作的编码代理可以直接调用性能代理并询问特定任务，就像调用任何其他工具一样。人类不必打开仪表板，在聊天框中描述问题，然后将答案复制回自己的工作流程。聊天接口是一个终点，而MCP服务器可以是其他代理构建的基础设施，而无需任何人为它们编写第二个集成接口。

容易被忽略的部分是：一旦你为你无法控制的调用者提供服务，该服务器就需要真正的访问控制。任何能访问它的人现在都可以直接调用你的推理层。一个只有你自己的代理会调用的工具表面不需要考虑这个问题。而一个外部世界可以调用的工具表面则需要考虑。

今天可以这样做：如果你的代理已经在内部通过MCP与自己的数据进行通信，检查在对外暴露这些相同工具需要多少额外工作，然后再去构建第二个仅供人类使用的API来完成同样的工作。

一个团队的第一个版本是线性管道：传感器监控代理调用合规代理，合规代理调用常驻消息代理，常驻消息代理调用调度代理。作为演示效果很好。在真实用例中却崩溃了：捕捉步态变化带来的跌倒风险，将其与实时药物交互数据库交叉核对，并在操作窗口关闭前将信息传达给正确的人。

这就是调用链与事件总线的实际区别：在调用链中，总延迟是累加的，即代理一的时间加上代理二的时间再加上代理三的时间，因为每个代理都在等待下一个代理时保持堆栈开启。在基于主题的总线上，两个不依赖彼此输出的代理可以同时运行，因为彼此都不阻塞对方的返回。无论你的代理运行在真正不同的节奏上，你都希望这种形态：一个每几秒轮询一次，一个进行耗时半秒的网络调用，一个只在最后触发一次。把所有这些链成一个调用栈，你最快的代理仍会被耗时最长的代理阻塞。

今天要做的事情：检查你的两个代理是否曾经需要对同一个信号做出反应。如果你的架构让一个代理必须在另一个之后才能进行响应，那么这就是一个打着多代理标签的单线程系统。

另一个团队的临床推理代理运行在 Gemini 3.1 Pro 上。在实际负载下，Pro 开始返回 503 错误。大多数其他实现会在相同模型上添加重试循环然后继续。相反，这个团队构建了一个到 Gemini 3.6 Flash 的回退方案，并且对任意一个模型的响应都运行同样的验证函数再接受它：一个引用检查，确认答案确实引用了真实的临床指南，而不仅仅是听起来合理的医学语言。

值得借鉴的细节不是回退方案的存在，而是验证函数的位置。它不会在主路径和回退路径各自复制一次，这样容易更新了一个副本而忘记更新另一个。这里有一个单一的 validate_clinical_response() 函数，Pro 路径和 Flash 路径都必须调用它，才能让任何结果离开代理。一旦响应进入该函数，无论哪个模型生成的，都无所谓，没有捷径，也不能因为它是请求到来时唯一可用的模型就提交未通过检查的答案。

这正是防止回退悄悄降低标准的关键：不是忘记在两处应用相同标准，而是结构上不可能只应用一次。

今天要做的事情：找到回退触发后的代码路径。如果它跳过了主路径的验证步骤，你就是在交付两个不同的产品，但只测试了其中一个。

推理成本可能是当前 AI 最争论的约束条件：每个人都希望获得前沿模型的推理能力，但又不想在每次请求上支付前沿模型的价格。这就是我们在本周期生产实践中实际看到的成本模式之一。

有一个团队测量了实际上消耗他们推理预算的是什么，发现并不是难题，而是简单的问题：“我的订单在哪里”，“取消我的预约”，这些都要经过与真正模糊请求相同的完整模型调用。他们的解决方法是在代理前设置三层分类器：本地正则表达式（regex）直接捕获导航意图，不耗费任何令牌；模糊情况调用便宜的Gemini模型，只用十个令牌和温度0.1来分类意图；只有同时通过这两个步骤的请求才会进入完整推理模型。他们自己测量显示，仅第一步就处理了40%以上的来信，在实际模型调用之前。另一个参赛项目将同样的思路应用于不同的流程：快速、便宜的模型用来筛选和分流进入的案例，只将需要深度推理的情况升级到慢而昂贵的模型。不要用最贵的模型来做廉价模型已经能做的决定。

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

回顾本轮Challenge，使用Agent Development Kit (ADK)：https://adk.dev/ 并通过Agents CLI：https://github.com/google/agents-cli 驱动的作品是这些模式最常出现的地方，这主要是因为该框架在并发、回退或者将工具交给其他代理方面不会阻碍你。

在这四种模式中，没有一种真正需要更大的团队或更新的模型。它们代表了经常被忽略的良好工程实践。此外，它们组合得很好，并且相互补充。有一个特别突出的团队，将模式一和模式三结合在同一个构建中：一个根代理并行分发专业代理，然后将整个推理层作为一个MCP服务器暴露，其他代理可以直接调用。

这就是我们下一轮要看的标准：遵循这四种模式的系统。但你不需要完成挑战，在下一次构建中就可以使用这些模式。

面向企业级的TPU云长上下文多模态嵌入推理精度

用深度学习和Keras解码宇宙信号

HeyGen x 谷歌云：将 Avatar IV 带到 TPU

We just wrapped the Google for Startups AI Agents Challenge：https://cloud.google.com/blog/topics/startups/startups-are-building-the-agentic-future-with-google-cloud?e=48754805 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：https://lnkd.in/p/eVKZNj77 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:

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.

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.

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.

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.

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)：https://adk.dev/ and driven through the Agents CLI：https://github.com/google/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.

Enterprise-Grade Precision for Long-Context Multimodal Embedding Inference on Cloud TPU

Decoding cosmic signals with deep learning and Keras

HeyGen x Google Cloud: Bringing Avatar IV to TPUs