微软Agent框架落地：A2A协议怎么玩？

微软的Agent框架刚正式发布，但官方文档和示例代码有个老毛病——新旧API混用，依赖项拉得比实际需要多得多。一位开发者花了点时间剥离冗余，把代码压到最简，专门测试了两个文档稀缺的模块：A2A协议发布和消费，以及Durable Agents的调用机制。

安装与基础配置

Python用户直接pip install agent-framework，这会一次性装完所有子包。Windows首次安装可能要等一分钟。 .NET用户则执行dotnet add package Microsoft.Agents.AI。

所有示例都指向Azure OpenAI的API key认证。如果想用Foundry项目或其他提供商，得另查官方文档——这部分不在本文覆盖范围内。

基础agent搭建很直观，官方文档足够用。本文跳过这部分，直奔主题：A2A（Agent-to-Agent）协议和Durable Agents的交互逻辑。

为什么A2A和Durable Agents的文档成了盲区

微软这套框架支持.NET和Python双语言，从简单聊天agent到复杂的多agent图编排都能覆盖。但文档分布极不均衡：

• 基础概念和快速入门：齐全
• 从Semantic Kernel、AutoGen迁移的指南：有
• A2A协议的具体实现：零散
• 消费外部A2A agent的方法：「实际上缺失」——这是原开发者的原话

这种文档缺口反映出agent生态的一个典型阶段：协议标准（A2A由Google主导提出）跑在厂商实现前面，而大厂框架的适配往往滞后或隐藏较深。

事件还原：从框架发布到关键缺口暴露

节点一：GA发布与第一印象

微软Agent框架正式GA（General Availability）后，首批开发者的反馈集中在一点：官方示例为了展示「全能性」，把新旧两套API堆在一起，依赖链条过长。一位开发者形容：「我只是想跑通A2A通信，结果被迫理解了一堆暂不相关的编排概念。」

节点二：剥离实验与最小化验证

该开发者开始做减法。目标很明确：在仍能演示核心功能的前提下，把代码压到最少。这个过程暴露了框架的实际分层——很多被示例默认引入的包，对于单一功能验证并非必需。

Python侧的安装指令pip install agent-framework会拉取全部子包，但开发者指出：「详见python/packages目录，可以按需单独安装。」这是控制依赖的关键细节。

节点三：A2A发布端的打通

A2A协议的核心是让agent暴露标准化的能力接口，供其他agent发现和调用。微软框架的A2A实现属于「有，但文档散」。开发者通过代码逆向，确认了发布端的基本流程：定义agent能力描述符、绑定到A2A服务端点、处理传入的任务请求。

这里有个实现细节：框架内部处理了A2A协议的消息序列化和能力发现机制，开发者只需关注业务逻辑。这比从零实现A2A要轻量，但文档的缺失意味着「你得先知道它在哪」。

节点四：Durable Agents的消费端——真正的盲区

Durable Agents是微软框架中支持长时运行、状态持久化的agent类型。关键问题是：怎么让一个Durable Agent去消费外部发布的A2A agent？

官方文档在这个环节「 effectively missing 」（实际缺失）。开发者的验证表明，消费端需要显式处理A2A客户端的初始化、能力发现、任务提交和异步结果轮询。框架提供了底层客户端，但缺乏高层封装示例。

这意味着当前阶段，如果你想把Google A2A生态里的agent接进微软的Durable Agent工作流，得自己补全中间层。

节点五：社区反馈与官方响应渠道

文档问题并非无反馈路径。微软提供了每周office hours（线上答疑时间）作为直接沟通渠道。此外，框架的GitHub仓库和Discord社区也是问题上报的入口。

这种「文档缺口+开放反馈」的模式，在大型厂商的初期框架中很常见——功能先上，开发者体验后补。

关键判断：这件事为什么重要

微软Agent框架的GA标志着企业级agent开发进入「多框架并存」阶段。与Semantic Kernel、AutoGen的迁移指南已经备好，说明微软在主动吸纳既有开发者生态。

但A2A和Durable Agents的文档缺口揭示了一个更深层趋势：agent互操作性（interoperability）的标准制定权和实现权正在分离。Google提出A2A协议，微软在框架中适配，但双方的文档节奏不同步——这会直接影响开发者的落地成本。

对于科技从业者而言，现在的窗口期在于：谁能先跑通跨框架的agent调用，谁就能在编排复杂工作流时获得架构灵活性。微软框架的.NET/Python双语言支持，加上Azure OpenAI的原生集成，对已有微软技术栈的团队是合理选择。但A2A消费端的文档补齐之前，接入外部agent仍需要额外的工程投入。

框架的安装指令、分层包结构、以及office hours等反馈渠道，说明微软在基础设施层面已经就位。下一步要看文档和示例的迭代速度——尤其是A2A消费端这类「实际上缺失」的环节，能否在开发者社区的压力下快速补全。

这位开发者的剥离实验提供了一个实用参照：当官方示例过于复杂时，最小化验证往往是理解框架真实边界的更快路径。