客服团队要给 Agent 加两个能力：查公司 MySQL 里的订单状态，遇到物流延误时联系承运商的 Agent 改派。第一个能力三天跑通，第二个卡了两周——两边没约定怎么描述自己能干什么、任务状态怎么同步、取消订单时谁说了算。接口约定不齐，模型再强也接不上。
这是 2026 年做 Agent 集成时反复出现的场景。MCP 和 A2A 分别在解决其中一半问题。
MCP 规定了什么：宿主、Server 和三类原语
MCP（Model Context Protocol）由 Anthropic 在 2024 年 11 月开源，规范与 SDK 公开在 GitHub，规范版本按日期命名，常见的有 2024-11-05、2025-03-26、2025-06-18、2025-11-25 几个修订版。
它的角色分三层：Host 是用户直接用的应用（Claude Desktop、Claude Code、VS Code 里的 Copilot、Cursor、JetBrains 插件等），Client 是 Host 内部连接到某个 Server 的连接器，Server 对外暴露能力。协议用 JSON-RPC 2.0 传递消息，本地进程走 stdio，远端走 Streamable HTTP——2025-03-26 那版把早期的 HTTP+SSE 换成了 Streamable HTTP，如果你的实现还在用旧传输，升级时要留意兼容性。
Server 能提供三类原语：
- tools：模型可以调用的动作，带 JSON Schema 参数定义。查订单、建工单、发消息都属于这类。
- resources：只读数据，比如一份文档、一张表的结构。模型读它但不改它。
- prompts：预置的提示模板，通常由用户主动触发。
鉴权方面，远端 MCP Server 按 OAuth 2.1 的资源服务器来做，配合 Resource Indicators 把 token 的受众限定住。规范里有一条硬规定：MCP Server 不得接受不是专门签发给它的 token，也不得把收到的 token 转发给上游 API。这条专门用来堵住混淆代理（confused deputy）问题——Server 拿着用户的 token 去调第三方接口，第三方看到合法 token 就放行，实际是用户没授权过的操作。
A2A 规定了什么：Agent Card 和任务状态机
A2A（Agent2Agent）由 Google 在 2025 年 4 月提出，同年 6 月捐给 Linux Foundation 的 A2A 项目，参与方包括多家云厂商与企业软件公司。它要解决的是：一个 Agent 怎么发现另一个 Agent、怎么把活派过去、怎么知道干到哪一步了。
入口是 Agent Card。调用方按约定路径请求对方的名片，默认路径在 0.3 系列改成了 /.well-known/agent-card.json（更早的版本用 agent.json）。名片里写清楚：这个 Agent 叫什么、有什么技能、接受什么输入模态、输出什么、支持不支持流式、支持哪些认证方案。
任务模型是这套协议和简单函数调用最大的区别。调用方发一个 Task，Task 有状态：submitted、working、input-required、completed、canceled、failed 等（具体枚举以规范仓库对应版本为准）。input-required 这个状态尤其关键——对方 Agent 缺信息时会挂起任务等你补，而不是直接失败。长任务还能通过 SSE 流式推送进度，或用 webhook 推送到你指定的地址。产出用 Artifact 承载，和过程消息分开。
A2A 明确了一件事：Agent 之间不交换内部思考过程，只交换完成任务必需的信息。这条在跨公司场景里是底线，别为了“效果更好”把上游 Agent 的完整上下文甩给对方。
工具调用、多智能体协作、权限模型，差异在哪
工具调用是一次请求一次响应。模型输出结构化参数，Server 执行，返回结果。MCP 的 tools 就是这个模型。风险点在参数由模型生成：模型可能把 project=OPS 填成 project=ALL，也可能被工具返回内容里的指令带偏。所以参数的合法性必须在 Server 侧校验，不能指望模型自觉。
多智能体协作是长任务、可中断、有中间状态。A2A 的 Task 状态机就是为此设计。链变长之后有两个新问题：谁对最终结果负责（通常是发起方），以及级联取消能不能传下去——上游取消了，被调用的 Agent 还在跑，白烧 token。
权限模型两边的出发点不同。MCP 偏“用户委托”：某个具体用户授权 Agent 代表他去读某个资源，scope 按资源划。A2A 偏“企业身份”：Agent 代表某个组织身份去调用另一个 Agent，认证走标准 HTTP 方案（API key、OAuth2、OIDC、mTLS），Agent Card 里只声明用了哪种方案，不放凭据。mTLS 在跨企业内部网络调用时比 API key 更常见，因为能顺带解决双向身份确认。
四类协议横向对比
除 MCP 和 A2A，还有几个协议在特定圈子里有采用。截至 2026 年初的状态大致如下，细节以各项目仓库为准。
| 维度 | MCP | A2A | ACP | ANP |
|---|---|---|---|---|
| 解决的问题 | Agent 到工具、数据 | Agent 到 Agent | Agent 到 Agent，REST 风格 | 开放网络里的 Agent 发现与身份 |
| 消息格式 | JSON-RPC 2.0 | JSON-RPC 2.0 over HTTP | HTTP + JSON（REST） | 基于 W3C DID 与 JSON-LD |
| 发现机制 | 宿主配置或私有注册表 | Agent Card（well-known 路径） | Agent Manifest | DID 文档加元协议 |
| 传输方式 | stdio、Streamable HTTP | HTTP、SSE、webhook | HTTP | HTTPS |
| 权限模型 | OAuth 2.1、scope、用户同意 | 企业身份，OAuth2/OIDC/mTLS/API key | 依赖 HTTP 层认证 | DID 可验证凭证 |
| 治理归属 | 开源规范加社区 SDK | Linux Foundation | Linux Foundation（BeeAI 项目） | 社区开源 |
| 典型用法 | 接数据库、文件、SaaS API | 跨团队、跨厂商任务编排 | 企业内部 Agent 服务化 | 跨组织开放互操作 |
企业选型：先看协作边界在哪
判断方法很简单，问三个问题。
边界在系统内还是 Agent 间？ 只有一个 Agent 去读数据库、调 API、写工单，MCP 够用，不需要引入 A2A。只有当“另一个 Agent”本身也由别人维护、有自己的生命周期和负责人时，A2A 的价值才显现。
调用方和被调方是不是同一个团队？ 同团队时，一个内部函数调用往往比 A2A 的 Task 状态机更省事。跨团队、跨公司时，你需要的恰恰是那份契约：名片、状态、产物、认证声明。
任务跑多久？ 秒级的问答用不上状态机。分钟到小时级的任务（供应链查询、批量审核、跨系统对账）才有 input-required 和流式进度的用武之地。
常见组合是：内部用 MCP 接工具和数据，对外用 A2A 暴露能力。一个售后 Agent 内部通过 MCP 查订单库、读知识库，对外通过 A2A 联系承运商 Agent 改派。两层各管各的，不互相替代。
分阶段落地路线图
每个阶段给退出条件，不达标就别急着进下一阶。
阶段 0：盘点（1–2 周） 列出要接的系统、数据分级、系统负责人、当前接入方式。产出一张清单，标注哪些是只读、哪些有写操作、哪些涉及个人数据。退出条件：每个拟接入系统都有明确 owner 签字。
阶段 1：只读 MCP Server（2–4 周） 挑一到两个只读系统先跑通，比如 Jira 查询、Confluence 搜索、数据库只读视图。工具数量控制在 3 个以内——工具一多，模型选错的概率明显上升。退出条件：连续一周真实使用，记录工具选错次数，错选率能解释清楚。
阶段 2：写操作与人工审批（1–2 个月） 加 OAuth 授权，高风险动作（退款、删除、对外发消息）走人工确认。日志必须记全：哪个用户、哪个 Agent、哪个工具、什么参数、返回结果摘要、trace id。退出条件：一次完整审计能靠日志还原操作链路。
阶段 3：A2A 试点（2–3 个月）
选两个团队，一方暴露 Agent Card，另一方做调用方，跑一条真实链路，比如售后 Agent 调供应链 Agent 查库存并预留。先跑通 input-required 和取消两条路径。退出条件：跨团队任务能端到端追踪，取消能级联到下游。
阶段 4：治理 建 Agent 注册表、统一网关、策略引擎、成本与配额。到这一步重点不再是接多少系统，而是谁批准上线、怎么下线、出问题找谁。
安全与审计要点
- 工具返回内容当作不可信输入处理。提示注入最常见的入口就是工具输出，不是用户输入。
- 第三方 MCP Server 做代码审计、锁定版本。生产环境别用
-y拉最新版本，供应链一变你就被动。 - 禁止 token 透传。MCP Server 不能把客户端给它的 token 转给上游 API。
- 按用户维度授权，不用共享服务账号。用服务账号接数据库，审计日志里只会留下一行“agent-service 干的”。
- 写操作带幂等键。Agent 重试是常态，没有幂等键就会重复退款、重复建单。
- 审计 Agent Card 里泄露了什么。description 和 skills 写太细，等于把内部系统名和接口路径公开了。
- 检查级联取消。A2A 任务取消要能传到被调用方，否则下游一直在跑。
- 设速率与成本上限。多 Agent 链路会放大 token 消耗，一条链路几百次调用不罕见。
两个可复制的最小示例
MCP 客户端配置（以文件系统参考 Server 为例，配置结构在各宿主里基本一致）：
{
"mcpServers": {
"fs-project": {
"command": "npx",
"args": ["-y", "@modelcontextprotocol/server-filesystem", "/path/to/your/docs"]
}
}
}@modelcontextprotocol/server-filesystem 是官方参考实现之一。2026 年部分参考服务器已移入归档目录，用之前先看仓库当前状态，别照抄旧博客里的包名。
A2A Agent Card 示例（字段为示意，具体以 A2A 规范仓库对应版本为准）：
{
"protocolVersion": "0.3.0",
"name": "inventory-agent",
"description": "查询仓库库存，支持按 SKU 预留库位",
"url": "https://<你的内网域名>/a2a",
"version": "1.0.0",
"capabilities": { "streaming": true, "pushNotifications": false },
"defaultInputModes": ["text/plain", "application/json"],
"defaultOutputModes": ["application/json"],
"skills": [
{
"id": "check-stock",
"name": "查询库存",
"description": "输入 SKU 与仓库编码，返回可用数量与预计出库时间",
"tags": ["inventory"],
"examples": ["查一下 SKU-1024 在华东仓的可用库存"]
}
],
"securitySchemes": {
"oidc": {
"type": "openIdConnect",
"openIdConnectUrl": "https://<你的 IdP>/.well-known/openid-configuration"
}
},
"security": [{ "oidc": ["inventory.read"] }]
}关于参考视频
这里不挂固定链接。第三方视频的标题、UP 主和地址会随下架、改名而失效，本文无法逐一核验内容准确性，写死链接反而容易把人带偏。想找视频，用这几个关键词去 B 站、腾讯视频、优酷或抖音检索，优先看发布时间在 2025 年 6 月之后、且贴出官方规范仓库地址的那一类：
- “Model Context Protocol 实战”“MCP Server 从零写一个”
- “A2A 协议 Agent Card”“A2A 任务状态机”
- “Streamable HTTP MCP 迁移”
本周能做的一件事
挑一个只读系统，写一个只有 3 个工具的 MCP Server，接进你日常用的宿主，连续用一周。记录两件事：模型选错工具的次数，以及工具返回内容里出现过多少次“看起来像指令”的文本。这两个数字，决定了你第二阶段该先补审批流程还是先补输入过滤。