什么是 A2A 协议？
回答由 AI 基于 batype 的笔记生成，不代表本人实时观点。
我目前没有发布过 A2A（Agent2Agent）协议的笔记，不能把它当作自己已经系统研究过的主题来展开讲。
只做概念区分的话：A2A 面向 AI Agent 与 AI Agent 之间的通信和协作，目标是让不同厂商、不同框架的 Agent 能互操作；MCP 则更偏向让模型或 Agent 接入外部工具、数据和上下文。【W2】
我没有发布过 A2A 的系统笔记，所以不能把下面当成我对协议细节的完整解读；但基于现有资料，可以先建立一个可靠的框架。
**A2A（Agent2Agent）是让不同 AI Agent 彼此发现、通信并协作的开放协议。**它主要解决的是：不同厂商、不同框架实现的 Agent，如何跨系统完成一项任务，而不是各自困在自己的生态里。【W2】【W4】
它解决什么问题
单个 Agent 通常能调用模型、工具和数据，但现实任务常常需要多个专业 Agent 配合，例如：
- 一个 Agent 负责拆解用户任务；
- 一个 Agent 查企业知识库；
- 一个 Agent 查询库存或生成报价；
- 一个 Agent 汇总结果并回复用户。
如果这些 Agent 分别由不同团队、不同框架甚至不同供应商构建，没有统一通信方式，集成成本会很高。A2A 想做的就是定义一层共同的交互规范，让它们能“对话”。【W2】【W3】
可以把它类比为：
- HTTP 让不同客户端和服务器能交换 Web 内容；
- A2A 让不同 Agent 能交换任务、状态和结果。
这个类比只是帮助理解，不能认为 A2A 已经像 HTTP 一样成熟和普及；它本身仍是较新的协议。【W3】
基本角色：Client Agent 与 Remote Agent
A2A 中有两个核心角色：
-
Client Agent
- 接收用户目标；
- 组织、发起任务；
- 将任务发送给其他 Agent。
-
Remote Agent
- 接收任务；
- 自己执行推理、调用工具或转交内部流程；
- 返回结果或任务进度。
Google 对它的描述很直接：Client Agent 负责形成并传达任务，Remote Agent 负责执行任务并尝试给出正确的信息或动作。【W4】
例如用户说：“帮我安排一次出差。”
用户
↓
行程规划 Agent（Client Agent）
├──→ 航班 Agent（Remote Agent）
├──→ 酒店 Agent（Remote Agent）
└──→ 费用政策 Agent（Remote Agent）
↓
汇总可执行的出行方案这里 A2A 关注的是这些 Agent 怎样交付任务和返回结果，而不是规定它们内部必须使用什么模型、记忆系统或工具链。
它不规定 Agent 内部怎么实现
我认为这是理解 A2A 的关键：它强调 Agent 间互操作，不要求暴露 Agent 的内部实现。
一个 Remote Agent 可以用 LangGraph、CrewAI、AutoGen，也可以是团队自研框架；它的内部 prompt、工具调用逻辑、私有记忆和业务实现不必暴露给调用方。资料将这种特征描述为“opaque execution”，即协议关注交互接口，而非 Agent 内部如何完成工作。【W1】【W3】
这对企业场景很重要：
- 能保护私有业务逻辑和数据；
- 不需要强制统一技术栈；
- 外部调用方只需要知道它有什么能力、如何请求、会返回什么。
通信上复用了常见 Web 技术
A2A 没有另起炉灶地发明一套全新网络协议，而是建立在已有标准之上，包括：
- HTTP
- JSON-RPC
- SSE（Server-Sent Events）
这样做的好处是接入门槛低，也更容易融入已有的服务治理、认证、审计和监控体系。【W1】【W3】
其中 SSE 很适合长任务：某个 Agent 不必等全部工作结束才返回，可以持续推送“任务进行中”“等待人工确认”“已完成”等状态。
Client Agent 发起任务
↓
Remote Agent 返回：已接收
↓
Remote Agent 返回：正在查询
↓
Remote Agent 返回：需要补充信息
↓
Remote Agent 返回：最终结果这比一次性 HTTP 请求更符合 Agent 任务的现实：很多任务耗时长、过程不确定，甚至需要 Human-in-the-loop。
A2A 与 MCP 的区别
一句话：
- MCP（Model Context Protocol）：重点是 Agent / 模型如何接入工具、数据和上下文。
- A2A：重点是一个 Agent 如何与另一个 Agent协作。
Google 将二者定义为互补关系：MCP 为 Agent 提供工具和上下文，A2A 则处理 Agent 与 Agent 的连接和协作。【W4】
可以这样理解：
Agent A
├── 通过 MCP 调用数据库、文件系统、GitHub、浏览器等工具
└── 通过 A2A 委托 Agent B 完成一类专业任务所以 A2A 不是 MCP 的替代品。一个实际系统里，两者完全可以同时存在：
- Agent 对内通过 MCP 使用能力；
- Agent 对外通过 A2A 寻找和委派专业 Agent。
为什么不直接用普通 API
普通 API 当然也能让服务相互调用，但 API 通常面向固定、明确的功能：
GET /flights?from=SHA&to=HKGA2A 面向的是更高层的、可能持续变化的任务协作：
请根据用户预算、公司差旅政策和会议时间，
制定可预订的出行方案；如信息不足，请说明缺少什么。这类请求的特点是：
- 任务可能很复杂；
- 执行可能耗时；
- 结果不一定是一个固定 JSON 字段；
- 可能需要流式进度；
- 可能需要补充信息或人工介入；
- 调用方不应该依赖被调用 Agent 的内部工具和实现。
因此，我倾向于把 A2A 看作“面向 Agent 协作的任务协议层”，而不是普通 REST API 的简单替代。
需要保持清醒的地方
A2A 的愿景很明确：降低多 Agent 生态的互操作成本。但协议存在不代表协作天然可靠。
真正落地仍然要处理：
- 身份认证与授权：谁能调用哪个 Agent；
- 数据边界：哪些上下文允许发送给外部 Agent；
- 结果可信度：Agent 的输出是否需要校验；
- 成本与超时：长任务如何取消、重试和计费；
- 可观测性：任务经过哪些 Agent、在哪一步失败；
- 人类确认：涉及付款、删除、发布等高风险动作，不能只靠 Agent 自行决定。
A2A 的资料本身也强调了企业级认证、授权、安全和隐私等需求。【W1】【W3】
**总结：A2A 要标准化的不是“模型怎么思考”，而是“Agent 如何把任务交给另一个 Agent，并获得可跟踪、可协作的结果”。**它更适合多团队、多供应商、多专业 Agent 共存的场景；如果只是一个应用内几个固定函数的调用，先用普通 API 或 MCP 往往更简单。
我没有发布过 A2A 规范的系统笔记，因此不把下面当作对某一版规范字段和流程的逐条解读。先给结论：
**A2A 的认证与授权，本质上沿用成熟的 Web/API 安全模型：TLS 负责确认通信端点和保护链路；OAuth 2.0、Bearer Token、JWT 或 mTLS 等机制负责确认调用方身份；服务端再依据 token 的权限范围、用户身份和资源策略决定是否允许这个 Agent 执行某个任务。**A2A 不应因为通信双方是 Agent，就跳过现有的身份和权限边界。【W1】【2】
先区分三个问题
1. 传输链路是否可信：TLS / HTTPS
Client Agent 调用 Remote Agent 时，首先应走 HTTPS。
TLS 证书让客户端验证“我连到的确实是目标服务”，同时加密传输内容。浏览器/客户端会检查证书链、有效期、签发方与撤销状态；证书体系通过根 CA 与中间 CA 建立信任链。【2】
Client Agent -- HTTPS/TLS --> Remote Agent这解决的是：
- 请求是否被窃听；
- 传输内容是否被篡改；
- Remote Agent 的服务端身份是否可信。
但 TLS 不能替代业务授权。即使连接的是正确服务，也仍要回答“这个调用方有没有权调用它”。
2. 谁在发起请求：Authentication
常见方式是 Authorization: Bearer <token>。
POST /tasks HTTP/1.1
Host: agent.example.com
Authorization: Bearer eyJhbGciOi...
Content-Type: application/json
{
"message": "查询订单状态",
"context": {
"orderId": "123"
}
}这里的 Token 可以是：
- OAuth 2.0 Access Token；
- JWT；
- 服务间签发的短期 Bearer Token；
- 在更高安全级别的企业场景，也可以结合 mTLS 的客户端证书。
要注意：**AI Token 和认证 Token 只是同名，不是一回事。**前者是模型处理文本的单位；后者是客户端证明身份或权限的凭证。【1】
服务端收到请求后，至少应验证：
- Token 是否存在、格式是否合法；
- 签名或向授权服务器的校验是否通过；
- 是否过期；
issuer、audience是否匹配当前服务；- 调用方身份是谁，例如某个 Agent、某个服务账号，或某个最终用户。
3. 允许做什么：Authorization
认证确认“你是谁”，授权确认“你能做什么”。
例如一个“行程规划 Agent”有权调用航班查询 Agent，却未必有权让付款 Agent 直接扣款：
行程规划 Agent
├─ flights.read ✅ 查询航班
├─ hotels.read ✅ 查询酒店
├─ payment.create ❌ 无权创建付款
└─ payment.confirm ❌ 无权确认扣款服务端通常根据 Token 中的 scope、角色（RBAC）、资源归属或业务规则判定：
function canCreatePayment(claims: { scope?: string[] }) {
return claims.scope?.includes('payment.create') ?? false;
}我倾向于把权限设计得细一些：查询、创建、确认、取消必须是不同权限。特别是涉及付款、删除、发信、修改生产数据等动作，不能只因为 Agent “声称代表用户”就直接放行。
Agent 场景里最容易混淆的身份链
A2A 往往不是单一主体，而是至少有三层身份：
最终用户
↓ 授权/委托
Client Agent
↓ 发起 A2A 请求
Remote Agent
↓ 调用内部工具
业务系统因此服务端最好能区分：
- 用户身份：是谁提出了任务；
- Client Agent 身份：哪个 Agent 或服务在代理请求；
- Remote Agent 身份：实际处理任务的是谁；
- 工具/服务身份：Remote Agent 再调用数据库、支付、CRM 时使用什么身份。
不能把它们揉成一个“万能 Token”。否则审计时只能看到“某个 Agent 做了操作”，却不知道它代表哪个用户、经过了谁的授权。
一个更合理的 Token Claims 示意：
{
"sub": "user_123",
"client_id": "travel-planner-agent",
"aud": "payment-agent",
"scope": ["payment.create"],
"delegation": {
"on_behalf_of": "user_123"
},
"exp": 1735689600
}这里表达的是：travel-planner-agent 代表 user_123，向 payment-agent 请求 payment.create 权限。
实现上我会遵守的原则
-
默认 HTTPS，拒绝明文 HTTP
数字证书既用于证明服务端身份，也包含服务端公钥；它是链路安全的基础。【2】 -
Token 短时效、最小权限、指定 audience
不给一个能访问所有 Agent、永久有效的 Token。 -
高风险操作要求显式确认
例如支付、提交订单、删除数据。Agent 可以规划，但最终执行要有明确用户确认或额外授权。 -
不要把第三方输入直接转成权限决策
Agent 接收的自然语言、网页内容、工具返回值都可能是不可信输入；它们不能改变原有权限范围。 -
完整审计
记录用户、Client Agent、Remote Agent、任务 ID、授权范围、实际执行动作和结果。 -
Token 不写进日志、Prompt 或任务正文
它应只存在于安全传输层或受控凭证存储中。
一句话概括：A2A 解决 Agent 怎么协作；认证和授权解决“谁在代表谁、能操作什么、出了问题如何追溯”。前者不能覆盖后者。
标题：A2A 协议是什么？AI Agent 开始学会“跨团队协作”
现在很多人都在做 AI Agent：能查资料、调工具、写代码、处理订单。
但一个现实问题是：
不同团队、不同厂商、不同框架做出来的 Agent，怎么互相协作？
A2A（Agent2Agent）协议，就是为这个问题准备的。
它希望建立一套通用规则，让一个 Agent 能发现另一个 Agent、委托任务、持续获取进度，最后拿到结果。【W1】
1. A2A 解决的是什么问题？
假设你有一个“出差助手” Agent。
用户说：“帮我安排下周去上海的出差。”
这件事可能要拆给多个专业 Agent：
- 航班 Agent：查航班、比价、预订；
- 酒店 Agent：找符合差旅标准的酒店；
- 财务 Agent：核对预算和报销政策；
- 日程 Agent：把行程同步到日历。
如果每个 Agent 都是独立系统，接口、鉴权、任务格式各不相同，协作成本会很高。
A2A 的目标就是让它们用统一方式交接工作：
用户
↓
出差助手 Agent
├─→ 航班 Agent
├─→ 酒店 Agent
├─→ 财务 Agent
└─→ 日程 Agent
↓
汇总为一份可执行方案重点不在于“一个 Agent 多聪明”，而在于“多个 Agent 能否可靠协作”。
2. A2A 里有哪些核心角色？
可以先记住两个：
Client Agent：发起协作的一方
它接收用户目标，选择合适的外部 Agent，并把任务交出去。
例如，出差助手把“查上海酒店”这个子任务发给酒店 Agent。
Remote Agent：执行任务的一方
它接收任务，完成自己的工作，然后持续返回状态或最终结果。
它的内部可以是任意技术实现：自研工作流、不同模型、不同工具链，都不重要。
A2A 约束的是 Agent 之间怎么交互，不是 Agent 内部必须怎么写。
3. Agent 怎么找到彼此？
A2A 里有一个很关键的概念：Agent Card（智能体卡）。
可以把它理解成 Agent 的“能力说明书”或“服务名片”，通常会描述：
- 这个 Agent 是做什么的；
- 擅长哪些任务；
- 服务地址在哪里；
- 支持哪些输入、输出格式；
- 是否支持流式返回、异步任务；
- 需要什么认证方式。
Client Agent 先通过 Agent Card 判断：
“这个 Agent 能不能完成我现在的任务？我要怎么调用它？”
这一步叫 发现（Discovery）。【W1】
4. 一次 A2A 调用大致怎么走？
一个典型流程可以概括成 3 步：
① 发现
Client Agent 找到 Remote Agent，并读取它的 Agent Card，确认能力和调用方式。
② 身份认证
Client Agent 按对方要求证明身份，例如使用 API Key、OAuth 2.0 或 OpenID Connect 等方案。【W1】
③ 任务通信
Client Agent 创建任务并发送消息；Remote Agent 处理后返回：
- 当前状态；
- 中间进度；
- 最终结果；
- 文件、表格等产物。
Client Agent
↓ 创建任务
Remote Agent
↓ 执行中 / 需要补充信息
Client Agent
↓ 补充上下文
Remote Agent
↓ 返回最终结果或产物
Client Agent
↓ 汇总后回复用户5. A2A 中常见的数据对象
A2A 不只是“发一句话、回一句话”，它围绕任务协作定义了几类基础对象：【W1】
- Task：任务本身，例如“查询订单状态”
- Message：任务过程中的消息
- Artifact：任务输出的产物，例如报告、文件、结构化结果
- Part：消息或产物中的具体内容片段
Part 可以是：
TextPart：文本；FilePart：文件；DataPart：JSON 等结构化数据。【W1】
这意味着 A2A 更适合处理真实业务协作，而不只是聊天。
6. A2A 和 MCP 有什么区别？
这是最容易混淆的一点。
MCP：让 Agent 接工具和数据
MCP（Model Context Protocol）更关注：
Agent / 模型
↓
数据库、文件系统、GitHub、搜索、支付接口……也就是：Agent 怎么使用外部工具和上下文。
A2A：让 Agent 接 Agent
A2A 更关注：
Agent A
↓
Agent B、Agent C、Agent D……也就是：一个 Agent 怎么把任务交给另一个专业 Agent。
一句话记忆：
MCP 解决“Agent 如何用工具”，A2A 解决“Agent 如何找同事”。
两者不是替代关系，反而常常会组合使用：
用户
↓
总控 Agent
↓ A2A
专业 Agent
↓ MCP
数据库 / 搜索 / 企业系统 / 第三方 API7. 为什么 A2A 值得关注？
我认为，Agent 真正大规模进入企业业务后，难点不会只是“调用一次大模型”。
更难的是：
- 不同团队的 Agent 怎么复用；
- 不同系统如何安全协作；
- 长任务如何跟踪状态；
- 任务失败后如何重试、补充信息或转交；
- 如何避免把内部实现和敏感权限完全暴露出去。
A2A 试图把这些跨 Agent 协作问题标准化。
不过也要冷静看待：**协议存在不等于生态已经成熟。**实际落地仍要处理鉴权、权限最小化、数据隔离、任务幂等、超时重试、审计日志等工程问题。
总结
A2A 是一套面向 AI Agent 协作的协议。
它希望让不同厂商、不同框架、不同业务系统里的 Agent，可以：
✅ 发现彼此
✅ 说明自身能力
✅ 安全地委托任务
✅ 获取任务状态
✅ 返回结构化结果和文件产物
未来的 AI 应用可能不再是“一个万能 Agent 包打天下”，而更像一个由多个专业 Agent 组成的协作网络。
#AI #AIAgent #A2A #MCP #大模型 #人工智能 #AI应用 #技术分享
资料参考：【W1】