一句话定义：把 MCP（Model Context Protocol）原本用来暴露「工具」的位置，换成一个活的智能体，让别的 Agent 通过 MCP 调它——这就是 MCP 智能体间通信（Agent-to-Agent over MCP）。
它是怎么被"用歪"的
MCP 的原始设计很像 USB-C：规定应用怎么把外部能力和数据接进来。标准那头连的是数据库、文件系统、日历这类"死"资源，MCP server 对外暴露的是 tools、resources、prompts，client 按需调用。
有人发现：既然 MCP server 能暴露一个 tool，那我在 server 里跑一个智能体不就行了？调用链立刻变成：智能体 A → MCP client → MCP server（里面坐着智能体 B）→ B 再调用它自己的工具。
打个比方：MCP 本来是"我打电话点外卖"，商家出餐，清清楚楚。现在变成"我派一个机器人替我去点外卖，而接电话的那头也是一个机器人"。线路是通的，但对面到底谁在接、它能不能代表那家店、出了问题找谁，协议里压根没写。
它和 A2A 不是一回事
A2A（Agent2Agent）是明确为智能体互相协作设计的协议，两者分工大致如下（具体细节以各自官方页面为准）：
| 维度 | MCP | A2A |
|---|---|---|
| 方向 | 垂直：智能体 → 能力/数据 | 横向：智能体 ↔ 智能体 |
| 形态 | 请求—响应式工具调用，通常较短 | 任务委派、长任务、多轮协商、状态流转 |
| 身份 | 关注"这个客户端能调哪些工具" | 关注"我是谁、能代表谁、会什么" |
| 发现 | 拉取工具清单 | 通过 agent card 一类描述互相认识 |
一句话：MCP 解决"我能用什么"，A2A 解决"我和谁合作、怎么合作"。
为什么风险反而最高
因为它隐形。A2A 名字里就写着"智能体通信"，上线前会有人专门评审；而 MCP 通信看起来只是配置文件里多了一行 server 地址。
更麻烦的是权限与消息模型。MCP 的授权基础是"终端用户同意这个客户端调用某工具"，一旦把智能体挂成 server，授权链就横跨了三个主体：用户 → 智能体 A → 智能体 B。B 执行的调用，究竟以谁的身份、谁的凭证发出，往往含糊；出了事，责任归属同样是空白。加上 MCP 的消息是普通的文本负载，提示注入（prompt injection）可以顺着调用链一路传染给下游智能体。
对从业者的实际意义
- 临时把某个能力"接进来"，用 MCP 是对的；把另一个智能体当工具使，就得补上身份、委托范围、超时与责任约定。
- 如果你的场景是长任务、多轮谈判、需要对方反过来找你，那更像 A2A 的地盘；也可以两者混用——A2A 管协作，MCP 管各自伸手拿工具。
- 无论选哪条路，先问三个问题：对面是谁？它能代表谁？调用失败或越权时谁兜底。
协议是工具，边界得自己画。