MCP、A2A、AGENTS.md——Agent 标准之争，开发者到底该跟哪个
AI Agent 生态里目前有三个标准在抢地盘：Anthropic 的 MCP（9700 万次安装）、Google 的 A2A 协议、OpenAI+Google 联推的 AGENTS.md。很多人搞不清它们的关系——是竞争还是互补？我从官方文档和架构层面拆解一下，附选型建议。
先搞清楚一件事：它们不在同一层
这是最多人搞混的地方。MCP、A2A、AGENTS.md 看起来像三个"Agent 标准"在打架，但它们解决的问题完全不在同一个层面。
一个类比：HTTP 和 HTML 都是 Web 的标准，但 HTTP 管传输，HTML 管内容，它们不是竞争关系。MCP、A2A、AGENTS.md 也是这样。
┌─────────────────────────────────────────────┐ │ AGENTS.md — 指令层 │ │ 告诉 Agent "你在这个项目里应该怎么做" │ ├─────────────────────────────────────────────┤ │ A2A — Agent 间通信层 │ │ Agent A 怎么发现并调用 Agent B │ ├─────────────────────────────────────────────┤ │ MCP — 工具接入层 │ │ Agent 怎么连接数据库、API、文件系统等工具 │ └─────────────────────────────────────────────┘MCP 管 Agent→工具，A2A 管 Agent→Agent，AGENTS.md 管人→Agent。三层，不冲突。
MCP：Agent 的"USB-C 接口"
MCP（Model Context Protocol）是 Anthropic 在 2024 年底推出的，定义了 AI Agent 怎么连接外部工具和数据源。
你可以把 MCP 想成 USB-C：不管你要连数据库、GitHub、Slack 还是 Google Drive，都走同一个协议。Agent 不需要为每个工具写适配代码。
// MCP Server 端：声明"我能做什么"server.tool("query_database","执行 SQL 查询",{sql:z.string()},async({sql})=>{constrows=db.prepare(sql).all();return{content:[{type:"text",text:JSON.stringify(rows)}]};});// Agent 端：自动发现并调用// Agent 不需要知道工具的实现细节，MCP 协议处理通信截至 2026 年 3 月，MCP 累计安装量超过9700 万次，有200+ 个官方和社区维护的 Server（GitHub、Slack、PostgreSQL、Notion、Jira、Salesforce 等），已经成为事实上的行业标准。
但 MCP 有一个被低估的问题：上下文消耗。
据 Morph 的分析，一个标准的 MCP 配置（接 3 个 Server）会在 200K token 的上下文窗口里占掉大约 72% 的空间——光是工具定义就要 143K token。还没开始干活，上下文就快满了。
200K token 上下文的实际分配（接 3 个 MCP Server）： ├── 工具定义: ~143K token (72%) ← 还没开始干活就占满了 ├── 系统提示: ~5K token (3%) ├── 用户消息: ~2K token (1%) └── 剩余给模型思考和输出: ~50K token (25%)这就是为什么我之前测过的"工具超过 12 个准确率下降"——不只是决策负担，还有上下文被工具定义挤占的物理限制。
MCP 的适用场景：Agent 需要读写外部系统（数据库、API、文件）。几乎所有 Agent 都需要 MCP。
A2A：Agent 之间怎么对话
A2A（Agent-to-Agent）是 Google 主导推出的协议，解决的是一个 MCP 管不到的问题：Agent 之间的通信。
MCP 让 Agent 能调用工具，但如果你有多个 Agent 需要协作呢？比如一个 Agent 负责写代码，另一个负责 review，第三个负责部署。它们之间怎么交接任务、传递上下文？
A2A 的做法是定义一种标准化的"Agent Card"——每个 Agent 声明自己的能力，其他 Agent 可以发现并调用它：
{"name":"code-reviewer","description":"Review code for security and quality issues","capabilities":["code_review","security_scan"],"endpoint":"https://my-agent.example.com/a2a","input_schema":{"type":"object","properties":{"diff":{"type":"string"},"language":{"type":"string"}}}}A2A 最大的亮点是跨框架互操作。一个用 Google ADK 写的 Agent 可以通过 A2A 调用一个用 LangGraph 写的 Agent——不需要知道对方是什么框架实现的。
据 Composio 的分析，Google ADK 是目前 A2A 支持最完整的框架。CrewAI 在 2026 年也加了 A2A 任务委托。但其他框架（LangGraph、AutoGen）的 A2A 支持还很初级。
A2A 的适用场景：多 Agent 协作（Agent 团队）。如果你只有一个 Agent，不需要 A2A。
AGENTS.md：给 Agent 的"项目说明书"
AGENTS.md 是 OpenAI 和 Google 联合推出的规范，定义了怎么在项目里给 AI 编程 Agent 写行为指令。
它的定位不是通信协议，而是一个配置文件格式。把 AGENTS.md 放在项目根目录，所有支持的 AI 工具（目前 55+ 个）都能读取它。
<!-- AGENTS.md 示例 --> # Project Rules ## Code Style - Use TypeScript strict mode - snake_case for variables, PascalCase for components - No `any` type ## Architecture - Follow repository pattern for data access - All business logic in service layer - Controllers only handle HTTP request/response ## Forbidden - No direct database access from controllers - No console.log in production code - No hardcoded secrets之前的痛点是每个工具有自己的配置格式——Claude Code 用 CLAUDE.md，Cursor 用 .cursorrules，Copilot 用 .github/copilot-instructions.md。同样的规则要写三遍。
AGENTS.md 的价值是写一次，所有工具都认。
据 The Prompt Shelf 的分析，两种策略都可行：
All-in AGENTS.md：只维护一份 AGENTS.md，所有工具都读它。优点是简单。缺点是无法利用某些工具的特有功能。
分层配置：AGENTS.md 放通用规则，CLAUDE.md / .cursorrules 放工具特有配置。优点是灵活。缺点是要维护多个文件。
AGENTS.md 的适用场景：团队里用多种 AI 编程工具，需要统一代码规范。
选型决策矩阵
| 你的需求 | 该用什么 |
|---|---|
| Agent 需要读写数据库/API/文件 | MCP |
| 多个 Agent 需要协作交接任务 | A2A |
| 统一 AI 编程工具的代码规范 | AGENTS.md |
| 单 Agent + 多工具 | MCP（不需要 A2A） |
| 多 Agent + 多工具 | MCP + A2A |
| 团队用 3+ 种 AI 编程工具 | AGENTS.md + 各工具配置 |
| 只用 Claude Code 一个工具 | CLAUDE.md 就够了 |
大多数开发者目前只需要 MCP + AGENTS.md。A2A 等你真的需要多 Agent 协作时再看——大部分场景一个 Agent 就够了。把精力放在 MCP Server 的工具设计和 AGENTS.md 的规则编写上，收益远大于折腾 A2A。
被忽视的问题：上下文成本
三个标准叠加使用时，最容易踩的坑是上下文爆炸。
MCP 的工具定义吃上下文（每个工具 100-300 token），AGENTS.md 的规则吃上下文（通常 500-2000 token），A2A 的 Agent Card 也吃上下文。
一个"配置齐全"的 Agent 还没开始干活，上下文就可能被占掉 30-70%。
实操建议：
控制上下文消耗的三条规则： 1. MCP Server 不超过 3 个（控制工具定义的 token 量） 2. AGENTS.md 不超过 50 行（写关键规则，不写废话） 3. 工具描述尽量精简（每个工具一句话，不要写段落）如果你需要更多工具但不想撑爆上下文，可以用动态加载——按当前任务只加载相关的 MCP Server，不是一次性全加载。通过 API 网关统一管理模型调用时，也可以根据上下文大小自动路由到上下文窗口更大的模型。
常见问题
Q: MCP 会被 A2A 替代吗？
A: 不会。MCP 管 Agent→工具，A2A 管 Agent→Agent，两个层面。Milvus 的一篇分析提到"Is MCP Dead?"，结论是不会——MCP 的 9700 万安装量和 200+ Server 生态已经形成了网络效应，短期内没有替代者。
Q: AGENTS.md 和 CLAUDE.md 只能二选一吗？
A: 可以共存。AGENTS.md 放通用规则（55+ 工具都认），CLAUDE.md 放 Claude Code 专用配置（比如 thinking effort 设置）。两个文件不冲突，Claude Code 两个都读。
Q: 国内开发者需要关注 A2A 吗？
A: 目前不急。A2A 的主要场景是企业级多 Agent 系统，大部分个人开发者和小团队用一个 Agent 就够了。等你的系统复杂到需要"Agent 调 Agent"的时候再看。MCP 和 AGENTS.md 的优先级远高于 A2A。
Q: 72% 上下文被工具定义占掉，怎么办？
A: 三个办法：减少 MCP Server 数量（3 个以内）、精简工具描述（每个工具一句话）、用动态加载按需注册工具。最根本的方案是选上下文窗口更大的模型——Claude 有 200K，GPT-5.5 有 100 万，上下文窗口大了这个问题就缓解了。
Q: 这三个标准会统一成一个吗？
A: 短期不会。它们解决不同层面的问题，合并在一起反而会变得臃肿。长期看更可能的趋势是：三层标准各自成熟，但通过清晰的接口规范协同工作——就像 TCP/IP 协议栈一样，每层有自己的标准，组合起来构成完整的通信体系。Linux Foundation 下面已经成立了 Agentic AI Foundation，在推动这些标准之间的协调。MCP、A2A 和 OpenAI 的 AGENTS.md 都是这个基金会的核心贡献。2026 年下半年应该能看到更清晰的协作框架。