努力忏悔修行说实话，做 Agent 相关开发的朋友最近应该都被四个词轰炸过：Agent、A2A、MCP、Skills。我在群里见过最典型的一个问题：一会儿说 MCP 把 Agent 能力拉满，一会儿说 Skills 才是 Agent 的灵魂，现在谷歌又丢出一个 A2A，问是不是要统一天下了——真正的初学者直接懵掉。
这些词不是平级替换关系，也不是同一个东西的四个叫法。它们分别处在「谁在干活、怎么找外援、用什么工具、按什么套路干」四个不同维度上。这篇文章就把这四个概念拆开讲清楚，再用手把手的实操例子告诉你：这些名词在一个 Agent 项目里到底怎么落位。
1. 先把四个词从“模糊印象”变成“清晰定义”
1.1 Agent：不只是聊天机器人，而是有目标、能行动的“执行者”
Agent 这个词本身不是新概念，但大模型时代它被重新定义了。过去我们说 Agent，更多是指一条自动化脚本：如果满足条件 A，就执行动作 B。现在聊 AI Agent，通常指一个以大语言模型为“大脑”的自治系统，它能接收目标，自己拆任务、做规划、选工具、执行动作，并不断根据结果调整下一步。
一个典型的 Agent 循环可以概括成四步：
- 感知当前状态，比如读取用户输入或环境信息；
- 用模型做推理，决定下一步要做什么；
- 调用外部工具去执行，比如查数据库、发请求、写文件；
- 观察执行结果，再回到第 2 步，直到任务完成。
所以你平时用的“ChatGPT 聊天框”，如果没有工具调用和自主规划能力，严格来说它只是一个聊天应用，不是一个完整的 Agent。而市面上说的“AutoGPT”“Manus”“Claude Code”这类产品，背后跑的是 Agent 循环，所以它们能自己列方案、翻文件、执行代码。
在 Agent 架构里，模型只是发动机，真正让它“用得起来”的是周边能力：能访问哪些数据、能操作什么系统、遵循什么规则。这就要引出后面的三个词了。
1.2 A2A：谷歌提出的 Agent 与 Agent 之间的协作协议
A2A 是 Agent2Agent 的缩写，2025 年由谷歌在 Cloud Next 大会上作为开放协议发布。它解决的问题是：不同厂商、不同框架的 Agent，如何互相找到对方、安全地传递任务、并同步任务状态。
为啥要单独搞一个 Agent 之间的协议？因为现在 Agent 生态太割裂。你用一个开源框架跑了一个 Agent A，我用闭源平台配置了一个 Agent B，它们彼此不认识。如果任务需要 A 去委托 B 完成某个子流程，总不能每次都人肉搬运结果。A2A 做的就是一套“工作语言”：通过标准的 Agent Card 描述 Agent 能力，通过 JSON-RPC over HTTP 在 Agent 之间收发任务请求，再通过任务对象维护执行状态。简单说，它让 Agent 之间的合作像发送电子邮件一样有规范可循，而不是各说各话。
我对 A2A 的理解是：它定位在“组织与组织之间的合作接口”，不是 Agent 内部用来调用工具的接口。类比到真人团队，A2A 更像是两个公司签合作框架协议，而不是公司内部某个员工怎么操作电脑。
1.3 MCP：模型上下文协议，给 Agent 接“外部世界”的统一插口
MCP 全称 Model Context Protocol，是由 Anthropic 推出、如今已经被行业广泛接受的一个开放协议。如果只用一句话解释：MCP 是 AI 应用与外部工具、数据源之间的标准接口。
没有 MCP 之前，每个 Agent 接一套工具都要写一堆自定义代码。你接一个数据库要写 Python 脚本，再给 Agent 做一层 function calling 适配；接一个设计稿平台又得重新写一套。这种“一对一”接法维护成本极高。MCP 把这件事做成了类似 USB-C 的统一插口：工具方实现一个 MCP Server，暴露自己的资源或工具；AI 应用里的 MCP Client 只要按同一协议去连接，就能统一发现和调用这些工具。
现在我常用的配置方式是：在 Claude Desktop 或 Codex 的配置文件里加一段 MCP Server 地址，里面写上工具名和命令，Agent 立刻多出一批真实可操作的能力。比如连上 Figma MCP，它就能直接读设计稿的属性、切图、查看图层结构；连上蓝湖 MCP，就能把蓝湖设计数据同步到工作流里。开发效率不是高了一点，而是量级变化。
MCP 和普通 API 的差别在于：API 只是露出一个“能力端点”，而 MCP 把能力的描述格式、输入输出约定、调用方式都标准化了。Agent 可以动态发现“这个 Server 支持哪些工具”，不需要你在代码里提前写死。
1.4 Skills：沉淀给模型复用的“本领包”
如果说 MCP 解决的是 Agent 能碰什么，那么 Skills 解决的是 Agent 知道怎么把活干好。Skills 在大模型应用里通常指一类结构化、可维护、可复用的能力文件，里面包含任务触发条件、执行步骤、规则、示例和检查清单。Claude Code Skills、OpenAI Codex Skills 都是这种思路。
为什么需要 Skills？因为大模型虽然聪明，但它默认只知道“通用的世界知识”，并不知道你团队内部的标准流程、代码规范、踩坑记录。你要让 Agent 稳定地写出符合你们规范的前端页面，就得把“前端开发 skills”喂给它。Skills 的作用是把过去散落在各部门的经验，整理成一套 Agent 可以即时读取和执行的说明书。
需要注意的是，Skill 不是普通 Prompt。普通 Prompt 是写在会话里的临时指令，改了就没了。Skill 是放在固定目录下的独立文件，有名字、有描述、有正文结构，可以被检索、被共享，也可以做成“技能市场”供别人下载。Claude Code 早期的 Skills 示例就是 .claude/skills/<skill-name>/SKILL.md，文件里面用 YAML Front Matter 写元信息，用 Markdown 写操作流程。
需要模型API调用？ 免费领10W Token，多模型网关一键接入 Claude、DeepSeek 等主流模型。
2. 四者的关系与区别：一套组合拳，不是平级黑话
2.1 用“开公司”来理解 Agent、A2A、MCP 和 Skills 的协作关系
单说抽象概念容易绕，我拿开公司类比。
- Agent 是项目经理。它接收老板（用户）布置的目标，拆分任务、安排人手、检查结果，对最终交付负责。
- MCP 是公司内部的办公系统和工具表格。项目经理想用 CRM、ERP、设计协作工具，不需要自己发明接口，只要这些系统都符合某种标准，就能直接接入。
- Skills 是员工培训手册和 SOP。比如“前端开发说明书”里写了代码规范、分支命名、验收标准。项目经理接活后，知道要先翻对应手册，再按手册去指挥员工干活。
- A2A 是公司与公司之间的合作标准。项目经理发现这个项目需要外包另一家专业公司的资源，双方不用临时谈每个细节，按统一框架交换任务、同步进度即可。
这四个层级并不互斥。一个真实项目里，项目经理可以一边查内部手册（Skill），一边调用办公系统工具（MCP），遇到自己不擅长的模块再通过外部合作标准（A2A）委托给别的项目经理。它们各管一段，共同组成一套完整的 Agent 生产力体系。
2.2 A2A 和 MCP 是竞争关系吗？很多人在这里搞混
A2A 和 MCP 都叫“协议”，于是有人下意识以为它们是竞品。其实它们的抽象层次完全不同。
MCP 解决的是“Agent 如何连接工具和数据”，它连接的两端，一端是 AI Agent，另一端是工具服务器。A2A 解决的是“Agent 如何连接另一个 Agent”，它连接的两端都是对等的智能体。
拿生活经验说：MCP 是你和扳手之间的接口标准；A2A 是你和另一个维修师傅之间沟通的协议。工具归工具，人归人。一个平台完全可以在内部用 MCP 让 Agent 调用各种工具，再用 A2A 跟外部团队协作。
网上有人对比“MCP 和 A2A 谁能赢”，本质上是搞错了问题。更合理的架构描述是：A2A 负责 Agent 之间的横向协同，MCP 负责 Agent 对外部能力的纵向打通。两者可以落进同一个系统，互相补充，而不是互相替代。
2.3 MCP 和 Skills：经常被混为一谈，但它们解决不同痛点
我见过不少人把 MCP 和 Skills 当成同一类资产，这也不怪大家，因为它们都能让 Agent“变得更强”。但两者的关键差异很明显：MCP 提供的是一个实时运行时的外部能力，Skills 提供的是静态可复用的做事经验。
再具体一点：
- MCP Server 里通常跑着真实业务逻辑，能查询数据库、能操作第三方系统、能获取最新设计稿。Agent 调用 MCP 工具，是“用一根管线接到真实世界”。
- Skill 则是一份文档型的本领规范。它不会替 Agent 去操作任何东西，但会告诉 Agent 操作的时候需要注意什么、按什么步骤来、什么情况要停下来确认。
实践中两者经常搭配出现。举个例子：我用前端开发 Skills 规定“拿到设计稿后先识别关键视觉规范，再输出语义化标签”，同时接一个 Figma MCP，让 Agent 能实时读取设计稿数据。Skill 告诉 Agent“看什么”，MCP 帮 Agent“看到东西”。缺了 Skill，Agent 可能胡乱调工具；缺了 MCP，Agent 有规范也看不到真实对象。
顺便澄清一个相关热词：Computer Use 和 MCP 的区别。Computer Use 是让模型通过屏幕截图和鼠标键盘操作图形界面，相当于人看着屏幕点按钮；MCP 是让模型通过结构化协议直接调用底层接口，更像程序员的命令行方式。两者可以互补，但如果你有 MCP 可用，通常比 Computer Use 更稳定，因为不需要处理一堆视觉识别的干扰。
2.4 Agent、Skills 与 MCP 在调度上怎么配合
如果你在写自己的 Agent 循环，这三者的配合顺序大约是这样：
- Agent 接到任务后，先从可用 Skills 列表里做一次“知识检索”，判断这份任务属于哪个领域，应该参考哪份 SOP。
- Agent 根据 Skill 的指导拆分里程碑，决定哪些环节需要调用外部能力。
- 对需要真实数据的环节，Agent 通过 MCP Client 查询工具 Server，把结果带回推理上下文。
- Agent 根据 Skill 中的检查项逐条验收，输出最终结果。
所以你会发现，Skill 负责“提高决策质量”，MCP 负责“扩大行动范围”。在代码层面，MCP 通常注册成工具列表交给模型；而 Skill 通常被系统提示词或预检索流程视作参考资料。模型在 plan 阶段消费 Skill，在 execute 阶段消费 MCP。这两个机制虽然名字都带“能力”，实际处在 Agent 生命周期的不同位置，放在一起用是常态。
2.5 一张表快速区分四个核心术语
| 概念 | 一句话定义 | 粒度 | 典型代表 | 主要解决的问题 |
|---|---|---|---|---|
| Agent | 能自主规划与行动的执行体 | 整体系统 | AutoGPT、Claude Code、Manus | 把目标变成结果 |
| A2A | Agent 之间协作的通信协议 | 系统间协作 | Google Agent2Agent | 不同 Agent 之间互通任务 |
| MCP | 模型连接工具/数据的标准协议 | 能力接入 | Figma MCP、蓝湖 MCP | 让 Agent 能操作真实系统 |
| Skills | 可复用的任务执行知识包 | 决策指南 | Claude Code Skills | 让 Agent 按规范高质量干活 |
3. 自己动手：从 Skill 到 MCP 再到 A2A 的最小实践
3.1 写一个真正可用的 AI Skill，不要停留在概念
看再多文档不如手写一个 Skill。以 Claude Code / Codex 风格的 Skills 为例，我常用目录结构是：
text复制my-frontend-skill/
├── SKILL.md
└── examples/
└── example.html
SKILL.md 的文件头写元信息，正文写规范。下面是一个极简但能跑的示例：
markdown复制---
name: frontend-design-restore
description: 根据设计稿还原前端页面时使用。帮助判断布局、间距、色彩和代码规范。
---
# 前端页面还原 Skill
## 适用场景
- 拿到 Figma 或蓝湖设计稿，需要生成页面代码。
- 修改已有页面以对齐设计稿样式。
## 执行步骤
1. 先读取设计稿关键信息，包括视口尺寸、色板、字体 token。
2. 对比目标代码框架的样式变量，不要硬编码所有颜色。
3. 按“结构层 -> 样式层 -> 交互层”的顺序输出代码。
4. 写完后对照设计稿逐项检查间距和圆角。
## 检查清单
- [ ] 颜色来自设计系统变量，而不是随手写的 hex。
- [ ] 图片资源使用了设计稿导出的真实资源地址。
- [ ] 页面用到了语义化标签。
- [ ] 移动端断点已覆盖。
如果只是把这段 Skill 扔进系统 Prompt，作用会打不少折扣。Skill 的价值在于它是一份“随时可被检索的资产”：Agent 收到前端任务时，能识别出这个 Skill 的描述，自动加载对应规则来指导输出。
实操心得：开头一定要把名称和描述写清楚，描述里尽量包含触发场景和领域关键词。因为模型是靠这段描述来判断“要不要用这个 Skill”的。我一开始把描述写得太泛，结果 Agent 什么活都想套这个流程，反而干扰常规代码输出。
3.2 给 Agent 配置一个 MCP Server，体会工具接入
Skill 写完后，再配一个 MCP Server 试试。假设你本地有一个基于 Node.js 的服务，想暴露一个“读取 JSON 配置文件并返回结构”的工具，可以按 MCP SDK 的最小写法做一个服务器：
javascript复制import { McpServer } from "@modelcontextprotocol/sdk/server/mcp.js";
const server = new McpServer({
name: "simple-config-server",
version: "0.1.0",
});
server.tool(
"read_config",
{ filePath: { type: "string" } },
async ({ filePath }) => {
const fs = await import("fs/promises");
const content = await fs.readFile(filePath, "utf8");
return { content: [{ type: "text", text: content }] };
}
);
server.listen(3000);
实际项目中，你更多是把已经存在的 MCP Server 配进客户端。比如 Codex 的配置文件里会有类似这样的设置：
json复制{
"mcpServers": {
"figma": {
"command": "npx",
"args": ["-y", "figma-mcp-server"],
"env": {
"FIGMA_API_KEY": "your_token"
}
}
}
}
配好后你在对话里让它“读取这个设计图（paste URL）”，Agent 会通过 MCP 工具实时拿到设计稿信息，而不只是依靠视觉截图。这种体验会瞬间让你理解：为什么大家说 MCP 是 Agent 能力的“通用插口”。
提示：MCP Server 的 transport 常见有两种：stdio 和 SSE。本地开发用 stdio 就很方便，远程团队协作可以部署成 HTTP/SSE 服务，客户端配置改成 URL 即可。
3.3 把 Skill 和 MCP 放进同一个 Agent 工作流
接完工具后，我们再还原一个真实场景：你的 Agent 接了一个蓝湖 MCP，同时你装了一个「结构图 Skills」用于在需求评审前画出合理的系统结构图。
任务描述可以是：
text复制从蓝湖项目里获取当前页面模块的交互说明，
先加载结构图 Skill，画一张登录模块的流程结构图，
再按前端还原 Skill 的要求，生成页面代码骨架。
Agent 在工作时，会先从 Skills 目录检索到结构图和前端还原两份知识，再用蓝湖 MCP 拉取真实设计信息。两个机制各司其职，最终产物既有结构分析，也有代码，整个链路无需人工复制粘贴。
这就是为什么我说“概念单独拎出来都不难，难的是组合起来用”。在实际项目里，Skills 往往代表你们团队的隐性经验，MCP 代表你们团队已有的工具资产。Agent 则是把经验与资产实时组合的执行中枢。
3.4 A2A 协作场景怎么理解和验证
A2A 的普及度目前还赶不上 MCP，但已经有不少框架在做尝试。比如 AgentScope 2.0 就提到支持 A2A 模式的智能体协作。到底是什么意思？我的理解是：你写的 Agent 不再只是单机执行任务，而是可以通过 A2A 协议看到“外部 Agent 的能力清单”，并把一个复杂任务拆一部分出去让别人完成。
A2A 中有几个关键概念你需要知道：
- Agent Card：一个描述 Agent 名称、能力、输入输出格式的“公开介绍页”。外部 Agent 可以读取这张卡，判断能不能把任务委托给它。
- Task：一次协作的最小工作单元。会包含输入、状态（进行中/已完成/失败）、结果等字段。
- 消息与推送：Agent 之间通过 JSON-RPC over HTTP 传递请求和状态更新。
一个极简抽象流程是：
text复制Agent A 收到用户需求后，
发现其中“专业数据分析”超出自身能力。
A 通过 Agent Card 发现 Agent B 支持该能力。
A 创建一个 Task，把分析数据发送给 B。
B 执行完，把结论回传给 A。
A 汇总后输出给用户。
在还没有大规模 A2A 基础设施的时候，你可以做什么准备？最实际的是：自己 Agent 的工具和任务接口尽量标准化，别把一次任务写成一个整体黑盒，而是拆成“可描述输入输出”的原子操作。这样以后无论接 A2A 还是别的协议，都不需要重构。
4. 常见误区、问题排查与避坑记录
4.1 误区一：把 Skill 当成“高级 Prompt”就够了
很多人一看 Skill 不过是个 Markdown 文档，就说“这不就是套了壳的 Prompt 吗？”这种理解会误导项目设计。Skill 跟 Prompt 有本质区别：Prompt 是一次性的临时输入，Skill 是长期积累的资产，具备文件结构、可检索性和可维护性。
一个容易被忽略的坑是：Skill 文件不是越长越好。有人习惯把公司几十页设计规范全部塞进去，结果 Agent 在加载时抓不住重点，反而稀释了核心步骤。更好的做法是给每个 Skill 定一个“最小可用篇幅”，正文里只放关键检查点，再通过 references 指向更长的规范文档按需读取。
还有个细节：Skill 里要写“不要做什么”。模型的负面约束和正面指令同样重要。比如“不要生成非语义化 div 嵌套”“不要擅自替换设计稿中的字体变量”。没有这些反面约束，Agent 经常会在边界场景里放飞自我。
4.2 误区二：有了 MCP 就能取代 Skills，反之亦然
我确实见过团队想“用 MCP 把公司工具全部接进来”，然后认定 Agent 能力打通了。结果一跑任务，Agent 虽然能调工具，但完全不知道公司内部约定是先走设计评审、再写代码、最后走测试用例，导致输出东西没法直接用。
反过来，只堆 Skills 不接工具也不行。Skill 能告诉 Agent“你应该查一下订单中心的返回结构”，但如果没通过 MCP 连上订单系统，Agent 只能靠猜。Skills 本质上是“让经验流动”，MCP 本质上是“让数据与操作流动”，两个都必须有。
如果你用搜索引擎看热词，会发现很多“AI Skills 怎么写”“Codex Skills 如何使用”的搜索量陡增。这背后是大家在补一个共识：真正让 Agent 进入业务实践，光靠底层模型本身不够，行业经验必须被结构化地外置。Skills 和 MCP 就是这种外置能力的两种形态，两者相互配合，才是 Agent 工程化的正确姿势。
4.3 排查实录：MCP Server 的工具“注册不上”怎么办
网上高频问题里，“Figma MCP 在 Codex 中工具总是注册不上”让我印象很深。这个问题也常见于蓝湖 MCP 或其他本地 MCP Server。遇到时按这个顺序排查：
- 检查配置格式。Codex 和 Claude Desktop 的 MCP 配置字段略有不同，名称、command、args 大小写别写错。
- 确认 API Key 或 Token 有效。Figma 的 Token 需要能访问对应文件，蓝湖需要在云文档里给 Token 开通读取权限。
- 验证 Transport 方式。本地命令是否真的能通过 npx 启动？先单独在终端跑一遍命令，看能不能拉起服务。
- 重启客户端。很多 MCP 工具只在客户端启动时扫描一次，中途改配置不会自动生效。
- 查看日志。Codex 和 Claude 都提供 MCP 调试日志，日志里一般会直接写着连接失败原因，比如网络超时、认证 401 等。
最容易踩的坑是 Token 权限。我之前连设计平台，配置没问题、服务也能启动，但工具注册总是 401，最后发现是 Token 没开“文件读取”资源权限。所以先授权、再验证连通性、最后才查客户端配置，效率最高。
4.4 A2A 还没普及，现阶段最容易犯的错是“擅自创建私底协议”
有些人看到 A2A 要来了，就想“那我先自己定义一套内部 Agent 间的消息格式”，方便以后对接。这没问题，但要避免把内部实现搞成和行业标准完全无法兼容的黑话。
更好的做法是在内部框架里用 A2A 的概念建模：每个服务暴露一份能力描述（类似 Agent Card）；服务间传递任务时，明确任务编号和状态流转（创建、处理中、成功、失败）；状态更新走统一事件。这样以后真去对接外部 A2A 网关，改动面会很小。
如果你还需要快速验证 A2A，最简单的办法是去看官方示例仓库里的两个 Agent 示例，通常它们会模拟“下订单 Agent”和“库存查询 Agent”之间的任务流转。套到本地跑一遍比读十篇文档都有用。
4.5 安全与权限，所有人都该提前注意
引入 MCP 和 Skill 之后，Agent 的权限半径变大了。Skill 里如果被写入“执行这条 curl 命令并忽略错误”，极端情况下等于约定了一批高风险动作。MCP Server 如果暴露了删除接口，而 Agent 又被赋予了自由决策权，风险会成倍放大。
我自己的原则有三个：
- 最小权限分配：给 Agent 配 MCP Server，只暴露当前任务必要的工具，不要全库开放。
- Skill 内容做评审：团队内部 Skill 要像代码评审一样过一遍，尤其是涉及命令行、数据库操作的内容。
- 保留人工确认机制：对删除、发布、支付等高危操作，尽量在 Agent 工作流里加一道审批节点，而不是让 Agent 一路自动冲到底。
写在最后
概念本身不贵，五分钟能看完；真正值钱的是你在项目里把它们用顺手的经验。我最近反复尝试把团队里的前端规范沉淀成 Skills，再通过蓝湖 MCP 把设计数据接入 Agent 工作流，最大的体会是：这些东西不是互相替代的关系，而是同一个目标下的不同零件——目标就是让 Agent 真的能靠谱地干活。
如果你刚入门，我建议不要急着上 A2A。先把一个场景跑通：写一个属于自己的 Skill，配一个最常用的 MCP Server，让 Agent 在一个有限任务里同时用到两者。等到这一步越来越顺，再去看 Agent 之间的协同标准，你会发现那些协议其实也不难理解。
最后再分享一个小技巧：每解决一个重复性任务，就把它整理成 Skill 提交到团队仓库。习惯坚持半年，你的 Agent 会比别人的聪明一大截。