三朵云各建一次智能体：谷歌ADK与AWS Strands、微软Agent Framework差异拆解

三大云厂商如今都推出了自己的智能体框架，而且都支持A2A协议。协议页面会告诉你，互操作性的故事已经讲完了：在智能体由不同框架、不同厂商构建的世界里，A2A提供了智能体互操作的通用语言。

这话在传输层面没错，但传输层并不是全部。一位开发者用同一个任务做了个实验：一个研究智能体、一条指令、一个搜索工具、一个字数预算，分别在谷歌ADK、AWS Strands和微软Agent Framework上各构建一次，托管在各自厂商的运行时上，由一个协调器把同一份任务简报分发给三个智能体，并对返回结果打分。

代码已全部开源在github.com/xbill9/multicloud-a2a-subagent。这次实验不是说A2A有问题——A2A工作正常。要探讨的是A2A正常工作之后，另外九件不同的事，以及两个几乎没人分开的问题：哪些差异来自平台，哪些差异来自模型。

实验设计：只让一个变量变化

这个实验的第一版是个演示：三个智能体、三个SDK、三个绿色勾。它说明不了任何问题。当三列数据在九个方面都不同时，你无法把任何结果归因于其中任何一个因素。

所以规则变成了一句话：除了被测变量之外，其他一切保持一致。右列是文章，左列是让文章成为证据而非轶事的东西。

最受争议的是搜索工具。实验给三朵云用了同一个搜索函数，而不是各家自己的搜索工具——这是作者最坚持的一个决定。只有谷歌提供了现成的搜索工具。微软Agent Framework导出的是SupportsWebSearchTool，那是聊天客户端可以声明的一种协议，不是能直接交给智能体的工具；Foundry自带的grounding需要预先在带外创建Bing资源连接。Strands则什么都不带。

如果都用"原生搜索"，那就意味着Gemini对接谷歌索引、Foundry模型对接Bing、Bedrock对接什么都没有：三种检索产品，比较出来的结果其实是检索产品之间的差距，却被当成模型之间的差距。

仍然保持原生的部分，正是实验想看的——每个框架如何绑定和驱动工具。这部分现在是唯一变化的变量。

三个框架，同一个智能体的三种形态

以下是三朵云上完整的模型侧构建代码，不是节选，是全部。

谷歌ADK：

from google.adk.agents import LlmAgentLlmAgent(    model="gemini-2.5-flash",  # 模型ID字符串    name=..., description=...,    instruction=INSTRUCTION,  # instruction参数    tools=[web_search],  # 普通可调用对象)

AWS Strands：

from strands import Agent, toolfrom strands.models import BedrockModelAgent(    model=BedrockModel(model_id="us.amazon.nova-micro-v1:0"),  # 模型对象    system_prompt=INSTRUCTION,  # system_prompt参数    tools=[tool(web_search)],  # 显式装饰)

Azure Agent Framework：

from agent_framework import Agentfrom agent_framework.foundry import FoundryChatC

三份代码放在一起，差异立刻显现。谷歌把模型当作一个ID字符串传入，指令参数叫instruction，工具就是普通函数。AWS把模型包装成对象，指令参数叫system_prompt，工具需要显式装饰。微软的构造方式又不一样。同一个智能体，在三个框架里长成了三种形状。

这些差异不是表面上的API命名不同，它们反映了每个平台对智能体本质的理解：模型是配置项还是核心对象？指令是提示词还是系统提示？工具是普通函数还是需要特殊标记的实体？这些设计选择会直接影响开发者写代码的方式，以及调试和迁移的难度。

实验的结论很直接：A2A解决了智能体之间的通信问题，但没解决构建体验的一致性问题。协议层之上，每个平台的框架都有自己的世界观。开发者选了一个云厂商，就等于接受了它的一套设计哲学——这套哲学写在每一个参数名和每一个装饰器里。