概念卡片：MCP 与 Agent 协议

一句话机制：Agent 与外界的三种关系各由一个协议解决——MCP 管「连工具」（对物，连接性）、Agent Skills 管「怎么用工具」（知识/SOP，能力）、A2A 管「Agent 之间协作」（对智）。核心洞察是「连接性（够得着）≠ 能力（会用）」，所以连接层和知识层必须分层。

三协议一张表辨析

维度	MCP	Agent Skills	A2A
提出方	Anthropic	Anthropic	Google
解决什么	Agent ↔ 工具/资源的标准接口	领域知识/工作流封装	Agent ↔ Agent 协作
本质	「手」（够得着外部世界）	「操作手册/SOP」（告诉怎么用）	「共同语言」（让异构 Agent 对话）
类比	USB 接口/驱动	软件应用（知道怎么设置双面打印）	互联网协议栈
传输	工具调用	文件（SKILL.md）	HTTP + JSON-RPC 2.0 + SSE
关键词	连接性（Connectivity）	能力（Capability）	互操作性（Interoperability）

MCP 的两个根本问题（催生 Skills）

上下文爆炸：MCP 客户端连接时 tools/list 加载所有工具的完整 JSON Schema，可能数万 token（仅 Playwright MCP 就占 200k 窗口的 8%），多轮对话迅速累积。
能力鸿沟：能连上数据库 ≠ 会写高效安全的 SQL；能访问文件系统 ≠ 懂项目代码结构。

Skills 的渐进式披露（三层，破解上下文困境）

层	内容	token 成本
元数据	只读 `SKILL.md` 的 YAML frontmatter	约 100 token/技能（50 个技能≈5k）
主体	按需读 `SKILL.md` 全文（指令/示例）	1k~5k token
附加资源	按需加载脚本/文档/数据文件	用脚本执行，不占上下文

效果：传统 MCP 直连 16,000 token → Skills 包装后仅 500 token。
SKILL.md 规范：name（kebab-case）+ description（智能体选技能的唯一依据，必写清「做什么/何时用/价值」）为必需；allowed_tools 白名单、required_context 可选。
设计原则：确定性优先——复杂计算/格式解析交给脚本，避免 LLM 幻觉。

A2A 核心对象与机制

Agent Card：智能体名片（JSON），含能力描述 + 端点 + 认证 + Skills 列表，是互操作性的起点。
Task：有状态工作单元（Task ID、状态 working/completed/input-required、历史、Artifacts）。
Message / Part / Artifact：消息 / 多模态单元（text/file/data）/ 最终成果物。
方法：tasks/send、tasks/get、tasks/sendSubscribe（SSE 推送）、tasks/pushNotification（Webhook）。
原则：简洁（复用 HTTP/JSON-RPC/SSE）、企业级就绪、异步优先、模态无关、不透明执行（黑盒，不管 Agent 内部实现）。

不变量（必须成立的约束）

连接性与能力必须分离：MCP 提供「手」、Skills 提供「操作手册」，二者互补而非竞争，混合架构（Skills 编排 + MCP 执行）是企业级最佳实践。
MCP 负责「对物」、A2A 负责「对智」：一个主 Agent 通过 MCP 调外部 API，通过 A2A 把子任务委派给远程 Agent。
渐进式披露是解决上下文矛盾的关键：按需加载，而非一次性塞满上下文。

常见误解

以为 MCP 和 Skills 是竞争关系 → 是互补：MCP 管连接、Skills 管知识。
以为 A2A 和 MCP 是同一件事 → A2A 是「协作对话」（Agent↔Agent），MCP 是「工具调用」（Agent↔Tool），方向不同。
以为「从 Function Call → Tool Call → MCP → Skill」只是换名字 → 是「连接性/能力分离」的架构演进，不只是表现形式的优化。

关联

总览：AI大模型技术栈总览
Agent 五要素：[概念卡片：AI Agent](./概念卡片：AI Agent)
源：B40-资源/语雀-Code-Summary/AITech/（MCP与AgentSkills的关系 / ClaudeSkillsvsMCP / 谷歌Agent2Agent协议共 3 篇）