最近几个月，AI Agent 相关的协议标准密集出现：MCP、A2A、ACP、ANP、AP2... 这些协议都有各自的定位，诞生是为了解决的是不同层次的问题，形成互补，逐渐完善万物与Agent的有效通讯。
这里试图把常见的协议捋一捋，把层次搞清楚把协议使用的场景搞明白。
先搞清楚分层
Agent 系统的通信问题，可以拆成几个独立的层：
- 工具集成层：LLM 怎么调用外部工具、数据库、API（MCP 的地盘）
- 智能体协调层：多个 Agent 之间怎么分工、委派任务（A2A、ACP）
- 网络与身份层：跨公司、跨互联网的 Agent 怎么互相发现和信任（ANP）
- 支付授权层：Agent 怎么代替人完成金融交易（AP2）
- 调用手段：curl、API、CLI，不是协议，是工具，永远有用
- 行为封装层：Skills / Prompt Templates，解决"LLM 怎么做"，不是通信问题
大多数混乱来自于把不同层的东西放在一起比较。
一个生产级的 Agent 系统，通常会同时用到多个层：MCP 负责工具调用，A2A 负责多 Agent 协作，curl/CLI 作为兼容层快速接入已有 API，Skills 封装标准化行为。
逐个拆解
MCP：LLM 的工具插头
MCP（Model Context Protocol）是 Anthropic 发起、现由 Linux 基金会维护的工具集成协议。它解决的问题很具体：让 LLM 能够标准化地调用外部工具。
工作方式是：开发者把工具封装成 MCP Server，LLM 通过统一的接口发现并调用这些工具。截止文章发布，目前社区已有 18,000+ 个 MCP Server，覆盖数据库、文件系统、浏览器、代码执行等几乎所有常见场景。
优势很明显：标准化程度高，能力自动发现，LLM 不需要知道工具的具体实现细节。
但我个人觉得 MCP 有点重。实现一个 MCP Server 需要遵循完整的协议规范——初始化握手（initialize / initialized 两步）、协议版本协商、能力声明（client 和 server 双向 capabilities），以及通过 tools/list 暴露结构化的工具描述（含 JSON Schema 参数定义），才能让 LLM 做能力发现。整个通信基于 JSON-RPC 2.0，还要选择并实现具体的传输层（stdio 或 HTTP+SSE）。对于简单的 API 封装来说，这些前置成本不低，灵活性也受限。
如果你只是想让 Agent 调用一个内部接口，用 OpenAPI 文档 + curl 其实更快。
对于 2B/2C 的 SaaS 产品来说，MCP 是值得接入的。 它相当于官方提供了一个统一的数据和能力访问入口，用户可以直接把你的产品接入自己的 Agent 工作流，这是一个新的增长渠道。
这里面几个实体分工也很清楚：
- LLM 负责判断"什么时候需要用工具"以及"该调用哪个工具"；
- MCP Client 负责和 Server 建立连接、拉取工具清单、把工具结果回填给 LLM；
- MCP Server 负责把外部能力按 MCP 规范暴露出来；
- Tool 则是真正执行动作的底层系统，比如数据库、文件系统、搜索接口或内部 API。
A2A：Agent 之间的任务语言
A2A（Agent-to-Agent Protocol）是 Google 发起的多 Agent 协调协议，同样已捐给 Linux 基金会。
它解决的问题是：当一个复杂任务需要多个专业 Agent 协作完成时，它们怎么互相发现、委派任务、同步状态。
核心机制是 Agent Card，每个 Agent 在 /.well-known/agent.json 发布自己的能力描述，其他 Agent 可以自动发现并决定是否委派任务。任务有完整的生命周期管理：提交、执行中、完成、失败，支持长任务和流式响应。
Salesforce、ServiceNow、Google ADK 都已在生产环境接入 A2A，是目前多 Agent 协调的事实标准。
如果每个人/每个组织/每个部门/每个角色 有一个自己的数字分身，很多事情Agent之间通讯达成共识就行。 Agent2Agent 沟通会远比人对人沟通高效地多。 已经可以看到在Agentic Coding 领域，多Agents协作的具体例子了。充分发挥每个模型的能力，在性价比和质量上达到平衡。
比如说用Claude 沟通需求与规划（总指挥），MiniMax 执行代码（长任务高性价比），Codex 审查代码（换个脑子），Kimi端到端测试（多模态）。通过A2A代理任务和回收任务是一个典型场景
ACP：REST 友好的替代路径
ACP（Agent Communication Protocol）由 IBM 和 AGNTCY 联合发起，同样归入 Linux 基金会，并逐步与 A2A 生态融合。
它和 A2A 解决的是同一层的问题，区别在于实现哲学：ACP 完全基于标准 REST HTTP，用 OpenAPI 规范描述接口，不需要任何新的 SDK 或工具链。
如果你的团队已经有成熟的 REST 基础设施，API 网关、负载均衡、监控全套都在，ACP 的接入成本几乎为零。curl 直接就能调。
另一个优势是原生多模态支持，用 MIME multipart 格式，文本、图片、音频、文件可以在同一个请求里传输，不需要额外处理。
ANP：去中心化的长期赌注
ANP（Agent Network Protocol）走的是完全不同的路：用 W3C 去中心化身份（DID）做 Agent 的身份认证，不依赖任何中心化注册表。
理论上，任意两个 ANP Agent 可以在互联网上互相发现、验证身份、建立信任，不需要提前认识，也不需要共同信任的第三方。
这个愿景很美，但 2026 年还不是生产就绪的状态。DID 基础设施还在成熟中，工具链和生态都不完善。如果你在做跨公司、跨互联网的 Agent 协作，可以关注，但不建议现在押注。
curl / CLI：永远有用的兼容层
curl 和 CLI 工具不是协议，但在 Agent 生态里有独特的价值。
把一个能力封装成 CLI 工具，加上清晰的文档和鉴权，Agent 可以直接调用，人也可以直接用。不需要新的基础设施，不需要实现任何协议规范，上手极快。
更重要的是，CLI 工具天然支持组合拼装。Unix 管道的哲学在 Agent 时代依然成立：小工具、单一职责、可组合。
对于内部工具、快速原型、或者已有 REST API 的快速接入，curl/CLI + 文档的方式往往比实现完整的 MCP Server 更务实。
Skills：行为模块化，不是通信协议
Skills（技能/提示词模板）解决的是另一个维度的问题：怎么让 LLM 的行为标准化、可复用。
它不是通信协议，不管 Agent 之间怎么通信。它管的是：当 Agent 执行某类任务时，应该遵循什么流程、用什么格式输出、有哪些约束。
Skills 通常运行在 MCP 或 A2A 之上，是应用层的封装。把 Skills 和协议混为一谈是常见的误区。
怎么选
场景驱动，不要为了用协议而用协议：
| 场景 | 推荐方式 |
|---|---|
| LLM 需要调用工具或数据库 | MCP，生态最成熟 |
| 多 Agent 协作、任务委派 | A2A，企业级支持最好 |
| 已有 REST 基础设施，低摩擦接入 | ACP |
| 快速原型、内部工具、已有 API | curl/CLI + 文档 |
| 标准化 LLM 行为、复用提示词 | Skills |
| 跨互联网去中心化协作 | 关注 ANP，等 2027+ |
对于 SaaS 产品，MCP 接入是值得投入的。它不只是技术标准，更是一个新的分发渠道，让你的产品能被用户的 Agent 工作流直接调用。
我的思考
这波协议标准化，我的判断是：有能力就接入标准协议，但不要迷信协议。
标准协议的价值是真实的：规范了行为，减少调用时的 token 消耗，稳定性更高，也更容易被其他系统集成。但实现成本也是真实的，MCP 对于简单场景来说确实偏重。
我自己更倾向于一个务实的路径：用 curl/CLI 封装一层 Skill，做好鉴权和文档，Agent 能用，人也能用，可以组合拼装。等规模上来了，再考虑是否升级到 MCP 或 A2A。
这波协议标准化意味着一件事：Agent 会成为你产品的新用户。你的 API 设计、文档质量、鉴权方式，不只是给人看的，也是给 Agent 看的。提前把这个想清楚，是值得的。