智能体互操作与 A2A。
当你的智能体必须与别人造的智能体协作时，你此前默默依赖的每一个假设都会崩塌：你看不到它的提示词，你无法引入它的函数，你也无法让它在你的请求超时之前完成。智能体间协议正是为这一具体情形而生——好用的心智模型是：MCP 递给你的智能体一件工具，而 A2A 把它介绍给一个对等方，那个对等方有自己的目标、自己的延迟，也有自己不在状态的日子。
两种协议，两种关系。
它们是互补而非竞争，区别在于「另一端坐着谁」：
- MCP——智能体对能力。另一端是被动的：一个数据库、一套文件系统、一个 API、一个搜索索引。你的智能体决策、调用、拿到结果。循环由你掌控。
- A2A——智能体对智能体。另一端是一个行动者，有自己的模型、自己的工具、自己的判断。你委派的是一个结果，而它跑自己的循环去达成。你掌控的只有那次请求。
实际后果是：用 MCP 时，你调试的是你自己在别人数据之上的推理；用 A2A 时，你调试的是两个系统之间的对话，而对方的推理你只能从外部观察。这在运维上确实更难，也正是「先确认你真的需要它」的理由。
A2A 由 Google 于 2025 年推出，并在 2025 年 6 月捐赠给 Linux 基金会，这一步把它从厂商协议变成了中立标准。2026 年 4 月满一周年时，该项目宣布已获得 150 多家组织支持，并在各大云平台完成集成。请把这看作「该标准足够持久」的证据——而不是「你需要它」的证据。
任何智能体协议都必须解决的四件事。
剥掉品牌外衣，这个领域里每一种设计回答的都是同样四个问题。值得了解 A2A 的答案，因为生态最终收敛到了它们身上：
- 发现。一个智能体如何得知另一个能做什么？A2A 发布一份 Agent Card——放在约定 URL 上的机器可读文档，声明该智能体的技能、端点与鉴权要求。它相当于一个服务的 OpenAPI 文档，也正是它让「动态委派」取代「硬编码集成」成为可能。
- 任务生命周期。智能体的工作是长时间运行的，塞不进请求／响应模型。A2A 把任务建模为一等对象，带有身份标识与状态机——已提交、执行中、需补充输入、已完成、已失败——使调用方可以轮询或订阅，而不必攥着一个连接等上四分钟。
- 内容协商。两个智能体未必在模态上达成一致。消息由多个部分组成（文本、文件、结构化数据），因此对等方可以直接返回一件产物，而不必被迫用散文来描述它。
- 身份。智能体以自身身份进行鉴权，使用的是普通的 Web 机制而非什么新发明——因为委派方在采纳答案之前，需要知道自己在跟谁说话。参见智能体身份与权限。
协议不会替你解决的事。
团队往往在这里受伤，因为协议解决了传输与发现，然后把最难的部分原样还给了你：
- 没有共享语义。两个智能体可以都讲着合法的 A2A，却对「紧急」意味着什么、客户 ID 长什么样、金额是含税还是不含税各执一词。协议层兼容不等于达成共识。
- 没有信任。远端智能体的输出，对你的智能体而言是不可信输入。你所知道的关于提示词注入的一切都完全适用，而现在攻击载荷是装在你主动索要的响应里送达的——这比一个抓取来的网页更容易让人误以为权威。
- 没有复合可靠性保证。把四个各 95% 可靠的智能体串起来，整体大约只剩 81%。委派会像多智能体系统一样把失败率相乘，而协议对此无能为力。
- 没有成本或延迟上限。你控制不了对等方的模型、步数或账单。请在调用侧设自己的超时与预算，因为另一侧没有任何义务替你设。
- 没有端到端链路追踪，除非你自己建。远端任务默认是不透明的。请传递关联 ID，并记录你发出了什么、收回了什么，否则排查问题会变成考古——参见智能体可观测性。
什么时候它才真的是对的工具。
诚实的判据是组织层面的，而非技术层面的。当另一端确实不属于你时，才该动用智能体间协议：
- 归属不同。另一家公司、另一个业务单元、一个供应商。你无法引入他们的代码，也不该想要他们的凭据。
- 生命周期不同。他们按自己的节奏发布。一条带版本的协议边界，正是让双方能各自独立演进的东西。
- 不透明是硬性要求。他们不能给你看提示词或数据——受监管、涉商业机密，或者干脆不关你的事。
如果这几条都不成立——如果所谓「另一个智能体」其实是你自己仓库里的一个函数——那么引入协议只是拿一次网络跳转、一种序列化格式和一整套分布式系统故障模式，去换取零收益。直接调用那个函数。进程内委派并不更低级，它只是对边界所在诚实而已。
先对外发布 Agent Card，再去消费别人的。把「你的智能体能做什么」连同清晰的任务生命周期与真实鉴权一起公布出来，工作量不大，却会逼你写下自己的能力边界——而团队几乎总会发现，智能体对外宣称的技能和它实际具备的技能并不是同一份清单。至于消费远端智能体，可以等到你真的遇到一个值得承担复合失败风险的对等方再说。