很多人第一次看到 A2A，会下意识把它当成 MCP 的竞品：都是协议，都是 Agent 相关，好像只是换了一套调用格式。这个理解很容易把方向搞反。MCP 关注的是“一个 Agent 怎么接工具和数据源”，A2A 关注的是“多个 Agent 之间怎么互相协作”。一个向下连工具，一个向外连 Agent，解决的是两类问题。

把它放到真实项目里就很好理解：你要做一份竞品分析报告，可能需要市场 Agent 查行业趋势，技术 Agent 对比架构，财务 Agent 分析商业模式，写作 Agent 最后汇总成文。A2A 就是让这些 Agent 能互相发现、委派任务、跟踪状态、交换结果的一套通信协议。

1. A2A 解决的不是“调用工具”，而是“协作分工”

Function Calling 更像“模型写了一张调用单”，告诉宿主程序应该调用哪个函数、参数是什么。MCP 更像“统一工具接口”，让数据库、文件系统、浏览器、GitHub 等能力可以被 Agent 标准化接入。A2A 则更进一步，它不是让 Agent 调一个工具，而是让 Agent 把一段工作交给另一个 Agent。

这就是 A2A 的关键点：接收方不是一个死板函数，而是一个有自己模型、工具、记忆、权限和执行流程的远程 Agent。调用方只需要知道它能做什么、怎么发任务、怎么拿结果，不需要知道它内部怎么推理、用了哪些工具。

2. Agent Card：让 Agent 先发一张“名片”

多 Agent 协作的第一步，不是直接发任务，而是先发现对方的能力。A2A 里有一个非常重要的设计：Agent Card。它是一份 JSON 元数据，描述远程 Agent 的名称、服务地址、能力、认证方式、输入输出类型，以及最重要的 Skill 列表。

通俗点说，Agent Card 就是 Agent 的“能力说明书”。调度 Agent 看到这张名片，才知道对方能不能做竞品分析、能不能流式返回、需不需要 Bearer Token、结果支持文本还是文件。这样就不用在代码里写死“某个 Agent 能做什么”。

下面是一个简化版 Agent Card 示例，实际字段会随规范版本和业务场景调整：

{
    "name": "market-research-agent",
    "description": "负责行业趋势、竞品信息和商业模式分析",
    "url": "https://agent.example.com/a2a",
    "capabilities": {
        "streaming": true,
        "pushNotifications": true
    },
    "security": [
        {
            "BearerAuth": [

            ]
        }
    ],
    "skills": [
        {
            "id": "competitor_research",
            "name": "竞品分析",
            "description": "根据产品名称生成竞品分析摘要",
            "inputModes": [
                "text/plain"
            ],
            "outputModes": [
                "text/markdown",
                "application/json"
            ]
        }
    ]
}

3. Message、Part、Task、Artifact：A2A 的四件套

看懂 A2A，最重要的是看懂四个对象：Message、Part、Task、Artifact。Message 是一次通信内容，里面有 role 和 parts；Part 是更小的内容块，可以是文本、文件或结构化数据；Task 是可追踪的一项工作；Artifact 是任务最终产出的结果。

为什么要设计 Task？因为 Agent 协作经常不是毫秒级函数调用，而是长时间任务。比如“生成一份 20 页调研报告”，对方可能要搜索、清洗、分析、写作、校验，整个过程持续几分钟甚至更久。Task 可以承载状态、进度、补充输入、取消和最终结果。

4. 一次 A2A 请求长什么样？

A2A 可以用 JSON-RPC，也可以通过 HTTP+JSON/REST 等绑定方式表达。对业务开发者来说，重点不是背字段，而是理解结构：客户端给远程 Agent 发送一条 Message，远程 Agent 要么直接返回 Message，要么创建一个 Task 来跟踪工作。

POST /message:send

Content-Type: application/a2a+json

Authorization: Bearer <token>

{
    "message": {
        "messageId": "msg-001",
        "role": "ROLE_USER",
        "parts": [
            {
                "text": "请分析 Cursor、Claude Code、CodeBuddy 的产品差异"
            }
        ]
    },
    "configuration": {
        "acceptedOutputModes": [
            "text/markdown",
            "application/json"
        ]
    }
}

如果任务很简单，远程 Agent 可以直接返回一个 Message；如果任务复杂，就返回一个 Task，后续通过轮询、SSE 流式更新或 Push Notification 告诉调用方进度和最终结果。

5. Task 生命周期：A2A 为什么适合长任务

Function Calling 通常强调“一次函数调用”。A2A 更强调“一段可跟踪的工作”。Task 可以经历 submitted、working、input-required、completed、failed、canceled 等状态。比如订机票时信息不全，远程 Agent 可以进入 input-required，要求补充出发地、时间和预算；生成报告时可以不断推送中间片段，最后返回完整 Artifact。

这套机制的价值很工程化：调用方不需要一直阻塞等待，也不需要知道远程 Agent 内部跑到哪一步。它只看 Task 状态和 Artifact 结果，就像后端系统看异步任务队列一样。

6. A2A 的完整协作链路

把上面的概念串起来，一次 A2A 协作通常分成六步：先发现 Agent Card，再匹配 Skill，再发送 Message 或创建 Task，再由远程 Agent 执行，执行过程中返回状态更新，最后把 Artifact 交给调用方。

注意，这里的“远程 Agent”可以是完全黑盒的。它内部可能用 MCP 查数据库，用 Function Calling 调接口，用 Skill 执行固定流程，也可能用自己的 Agent 框架。A2A 不要求调用方知道这些实现细节，只要求对外通信遵守协议。

7. A2A 和 MCP 的区别：一纵一横

MCP 和 A2A 经常一起出现，但它们不是替代关系。MCP 更像“工具插座”，让 Agent 能标准化访问数据库、浏览器、文件系统、搜索引擎、内部 API。A2A 更像“协作流程”，让一个 Agent 能把任务交给另一个专业 Agent，并拿回状态和结果。

项目里经常是两者同时存在：调度 Agent 用 A2A 把任务交给财务 Agent；财务 Agent 内部再用 MCP 查数据库、读表格、调用风控接口。这样既能做到分工协作，又能保持每个 Agent 内部工具接入的标准化。

8. 代码侧怎么落地：先发现，再委派，再取结果

下面是一段简化版伪代码，重点展示开发时的思路。真实项目里还要补充鉴权、超时、重试、日志、幂等、权限校验和异常处理。

import requests

AGENT_CARD_URL = "https://agent.example.com/.well-known/agent-card.json"

# 1. 读取远程 Agent 的能力名片
agent_card = requests.get(AGENT_CARD_URL, timeout=5).json()

# 2. 根据 skills 判断是否能承接任务
skill_ids = [skill["id"] for skill in agent_card["skills"]]
if "competitor_research" not in skill_ids:
raise RuntimeError("没有找到合适的竞品分析 Agent")

# 3. 把任务作为 Message 发给远程 Agent
payload = {
"message": {
"messageId": "msg-001",
"role": "ROLE_USER",
"parts": [
{"text": "请输出 AI 编程工具竞品分析摘要"}
]
}
}

resp = requests.post(
agent_card["url"] + "/message:send",
json=payload,
headers={"Authorization": "Bearer <token>"},
timeout=30
)

result = resp.json()
print(result)

这段代码表达的不是完整 SDK，而是工程思路：先看对方会不会做，再把任务发过去，然后根据返回的是 Message 还是 Task 走不同处理路径。简单任务直接读 Message；复杂任务拿到 Task ID 后继续轮询、订阅流式更新或等待回调。

9. 落地 A2A 时最容易踩的坑

第一，不要把 Agent Card 写成广告文案。Skill 描述越虚，调度 Agent 越难做路由。每个 Skill 最好写清楚输入范围、输出格式、限制条件和示例任务。

第二，不要把所有内部细节都暴露出去。A2A 的一个重要价值是保持 Agent 的黑盒性：调用方只需要知道能力、接口、认证和结果，不需要知道内部工具链、提示词、私有知识库和执行策略。

第三，异步任务必须设计幂等。网络抖动、调用方重试、服务重启都可能导致重复提交。生产环境要利用 messageId、taskId、contextId 做去重和追踪，避免重复下单、重复发邮件、重复扣费。

第四，权限边界要提前定。能发现一个 Agent，不代表能调用它的所有能力。公开 Agent Card 可以只放基础能力；更敏感的 Skill、配额、内部参数可以通过认证后的扩展信息返回。

10. 面试回答可以这样说

A2A 是 Agent-to-Agent 协议，解决的是多个 AI Agent 之间如何发现能力、委派任务、跟踪状态和交换结果的问题。它不是 MCP 的替代品，因为 MCP 主要解决 Agent 如何连接工具和数据源，A2A 主要解决 Agent 如何和另一个 Agent 协作。

A2A 的核心机制包括 Agent Card、Skill、Message、Task、Artifact。Agent Card 负责能力发现，Task 负责长任务状态管理，Artifact 负责交付结果。它特别适合跨团队、跨系统、跨框架的多 Agent 协作，比如调度 Agent 把市场分析、技术调研、财务分析分别交给不同专业 Agent。

在复杂系统里，A2A、MCP、Function Calling、Skill 可以同时存在：Function Calling 负责模型输出工具调用意图，MCP 负责工具接入标准化，Skill 负责封装可复用流程，A2A 负责多个 Agent 之间的横向协作。