在过去的两年里，AI 工程遵循着一个简单的剧本。给智能体（agent）一个提示词、一些工具和一个记忆层。看着它安排会议、总结合同或调试脚本。当时的目标是让单个智能体能够独立发挥作用。

那个目标已经改变了。

我们现在正目睹行业从单兵作战的智能体向智能体团队（agent teams）转变。一个客服分流机器人识别出退款请求，并将案例路由给支付智能体。一个抓取网页数据的研究智能体遇到了细分领域的空白，于是将任务委派给一个拥有专有数据库的专家智能体。一个规划货运的物流智能体需要实时的运费报价，因此它向定价智能体询问一个数值。

这在理论上听起来很简单，但在实践中却非常脆弱。

新的挑战在于互操作性（interoperability）。团队使用不同的框架构建智能体。不同的供应商交付具有不同接口的智能体。当一家公司需要与其他公司协作时，差距就会拉大。我们现在面对的是一个充满了能干的“工人”但缺乏共同语言的局面。智能体无法在目录中查找另一个智能体，无法阅读同事的工作描述，也无法在不承担数据泄露、上下文丢失或重复执行风险的情况下移交敏感任务。

这正是 A2A 旨在解决的问题。它为智能体提供了一种用于发现、委派和安全协作的通用协议。

从单体智能体到智能体孤岛

第一波智能体框架将系统的边界视为智能体的边界。你构建一个推理循环，给它配上工具包，并希望它能通过思考来完成工作流。当智能体停留在同一个代码库、同一个云账户或同一个供应商平台内时，这种方式效果还不错。

真实的业务并不在单体架构（monoliths）中运行。一个退款请求可能始于 CRM，流转到用 Python 编写的内部支付服务，最后结束于第三方托管的欺诈检查。当你将这些服务中的每一个都建模为一个智能体时，你会很快发现，基于不同技术栈构建的智能体无法原生地理解彼此。基于专有框架构建的企业级智能体不会向外界广播它们的能力。

如果没有标准，每一次集成都会变成一个定制项目。工程师们不得不编写一次性的胶水代码（glue code）。上下文在转换过程中会丢失。安全策略也会变得不一致，因为每一次移交都是量身定制的。

Agent Cards：一份公开的简历

A2A 引入了 Agent Cards，作为智能体宣布身份及其能力的手段。

可以将 Agent Card 想象成一份机器可读的简历。智能体发布一张卡片，描述其领域、所需的输入、预期的输出以及对所接受工作的任何约束。一个支付智能体可能会声明：在提供订单 ID 和原因代码的情况下，它可以处理一定金额以下的退款请求，并返回确认号或错误信息。一个数据专家可能会说明：它接受特定大小以内的结构化文件，并在可预测的时间窗口内返回清洗后的时间序列数据。

在委派工作之前，请求方智能体会阅读该卡片。它会了解目标智能体是否具备处理该任务的能力，了解负载（payload）需要什么格式，并知道应该期待同步响应还是稍后完成的异步任务。

这消除了猜测。智能体不再需要针对每个可能的合作伙伴编写硬编码的集成逻辑，而是可以浏览可用的能力，并动态地选择合适的队友。

Tasks：结构化工作，而非仅仅是 API 调用

智能体不需要像人类一样聊天。它们需要干净利落地移交工作。A2A 将这种交换建模为一个 Task。

一个 Task 不仅仅是