先用一句话理解 Skills 和 A2A
如果说 MCP 解决的是“Agent 怎么接工具和数据”，那么 Agent Skills 和 A2A 解决的是另外两个问题：
Agent Skills 让 Agent 复用一套做事方法；A2A 让不同 Agent 互相委托任务。
它们都不是模型本身，也不是让模型突然变聪明的魔法。它们更像 Agent 工程化之后的两块基础设施：
- Skills：把经验、流程、模板、脚本、参考资料打包，让 Agent 遇到某类任务时知道“该按什么方法做”。
- A2A：让一个 Agent 能发现另一个 Agent 的能力，把任务交给它，并跟踪状态、交换消息、拿回产物。
flowchart LR
user["用户目标"] --> agent["Agent<br/>理解目标，规划步骤"]
agent --> skills["Agent Skills<br/>复用做法：流程、模板、脚本、资料"]
agent --> mcp["MCP<br/>连接工具和数据"]
agent --> a2a["A2A<br/>委托其他 Agent"]
skills --> method["怎么做"]
mcp --> tools["用什么工具和数据"]
a2a --> peers["找谁协作"]举个直观例子：你让一个产品 Agent 准备下周发布计划。它可能加载“发布计划 Skill”，按团队流程列检查项；通过 MCP 查询 Jira、GitHub、数据看板；再通过 A2A 委托法务 Agent 审合同条款，委托数据 Agent 拉指标，委托客服 Agent 汇总用户反馈。
这三者分工不同，但经常一起出现。
为什么只靠提示词不够
很多人第一次写 Agent，会把所有要求都塞进系统提示词：你要怎么审代码、怎么写报告、怎么查资料、怎么处理异常、输出格式是什么、遇到权限问题怎么办。短任务还凑合，一旦任务变多，就会出问题。
第一，提示词越来越长。所有流程都常驻上下文，会浪费模型窗口，也增加互相干扰。
第二，经验不可复用。今天你在一个聊天里调好的“代码审查流程”，明天换个 Agent、换个项目、换个产品，又要重新粘贴一遍。
第三，缺少工程边界。团队知识、脚本、模板、参考文档混在提示词里，很难版本管理、审查、测试和迭代。
Agent Skills 的价值就在这里：它把“怎么做某类事”从一次性提示词里拆出来，变成一个可以维护、可以分发、可以按需加载的能力包。
Agent Skills：把做事经验打包
Agent Skills 可以理解为 Agent 使用的“操作知识包”。根据 Agent Skills 规范，一个 Skill 至少是一个目录，目录里必须有 SKILL.md。这个文件包含 YAML frontmatter 和 Markdown 指令；目录里还可以放 scripts/、references/、assets/ 等材料。
flowchart TB
skill["一个 Skill 目录"]
skill --> md["SKILL.md<br/>必需：名称、描述、主流程"]
skill --> scripts["scripts/<br/>可选：脚本、检查器、转换器"]
skill --> refs["references/<br/>可选：长文档、规范、案例"]
skill --> assets["assets/<br/>可选：模板、图片、表格、示例文件"]
md --> meta["frontmatter<br/>name / description / license / compatibility 等"]
md --> body["Markdown 正文<br/>步骤、边界、输出格式、注意事项"]一个最小的 SKILL.md 大概长这样：
---
name: code-review
description: Review code changes for correctness, security, tests, and maintainability. Use when asked to review a pull request, diff, patch, or changed files.
---
# Code Review
1. Read the diff and surrounding code.
2. Prioritize correctness, security, regressions, and missing tests.
3. Report findings first, ordered by severity.
4. Include file and line references.真实 Skill 往往会更完整：代码审查 Skill 可以带团队审查清单；发票处理 Skill 可以带 OCR 脚本和字段映射表；PPT 生成 Skill 可以带品牌模板；数据分析 Skill 可以带指标口径、SQL 片段和图表规范。
渐进式披露：为什么 Skill 不会一开始全塞进上下文
Skills 的关键设计不是“把提示词换个文件放”，而是渐进式披露。Agent 不需要一开始读完所有 Skill 的全部内容，它通常分三层加载。
sequenceDiagram
participant Agent as Agent
participant Catalog as Skill 目录
participant Skill as SKILL.md
participant Files as references/scripts/assets
Agent->>Catalog: 启动时读取 name + description
Catalog-->>Agent: 只返回轻量元数据
Agent->>Agent: 根据用户任务判断是否匹配
Agent->>Skill: 匹配后读取完整 SKILL.md
Skill-->>Agent: 返回主流程和指令
Agent->>Files: 确实需要时再读参考文件或运行脚本
Files-->>Agent: 返回细节、模板或脚本结果这带来几个好处。
第一，节省上下文。几十个 Skill 可以同时可用，但不需要每次都把所有细节放进模型窗口。
第二，减少误用。只有任务真的匹配时，Agent 才加载相关流程。
第三，方便维护。复杂参考材料可以放进 references/，脚本可以放进 scripts/，模板可以放进 assets/，主文件只保留决策和流程。
第四，便于团队复用。一个 Skill 可以进版本库，可以 code review，可以测试，也可以在不同 Agent 客户端之间迁移。
常见 Agent Skills 可以分几类
“常用 Skill”不是固定排行榜，而是高频工作流。只要某类任务经常重复、需要稳定流程、容易漏步骤，就适合封装成 Skill。
| 类型 | 常见 Skill | 解决什么问题 | 通常会带什么材料 |
|---|---|---|---|
| 软件工程 | 代码审查、测试修复、性能分析、数据库迁移、发布检查 | 让 Agent 按工程流程做事，而不是只写一段看似合理的解释 | 检查清单、命令脚本、错误排查手册 |
| 文档处理 | PDF 提取、合同审查、发票识别、报告生成、PPT 制作 | 把复杂文档流程标准化 | 模板、字段映射、样例、格式规范 |
| 数据分析 | 周报、指标归因、SQL 分析、实验报告、可视化 | 统一指标口径和分析步骤 | 指标字典、SQL 模板、图表规范 |
| 设计与内容 | 品牌文案、海报生成、视频脚本、设计审查 | 固化风格、结构和审美规则 | 品牌手册、示例、素材 |
| 企业流程 | 客服质检、销售跟进、招聘筛选、风控审核 | 把组织经验沉淀成可执行流程 | SOP、话术库、评分表、审批规则 |
| 本地工具 | 浏览器测试、图像处理、表格清洗、压缩转换 | 让 Agent 使用本地脚本和模板完成重复工作 | scripts、assets、测试用例 |
比如“代码审查 Skill”不是告诉 Agent “认真审查代码”这么空。它会规定输出顺序、严重级别、必须看哪些文件、如何引用行号、哪些问题优先、什么时候运行测试、什么时候不要纠结风格。
调用流示例：用 Skill 做一次代码审查
sequenceDiagram
participant U as 用户
participant A as Agent
participant S as code-review Skill
participant Git as Git / 文件系统
participant Test as 测试工具
U->>A: 帮我 review 这个 PR
A->>A: 发现任务匹配 code-review
A->>S: 读取 SKILL.md
S-->>A: 返回审查流程、输出格式、优先级
A->>Git: 读取 diff 和相关上下文
Git-->>A: 返回改动文件和周边代码
A->>Test: 按 Skill 要求运行相关测试
Test-->>A: 返回测试结果
A->>A: 按 Skill 规则筛选 bug、风险、测试缺口
A-->>U: 先列 findings，再列残余风险这时 Skill 提供的是“做法”，Git 和测试工具提供的是“外部能力”。如果 Git、测试、文件读取是通过 MCP 接进来的，那就是 Skills + MCP 的组合。
Skill 不是插件，也不是工具调用
Skill 容易和插件、MCP、函数调用混在一起。一个简单判断是：Skill 主要告诉 Agent 怎么做，工具主要让 Agent 能做什么。
| 概念 | 核心作用 | 例子 |
|---|---|---|
| Skill | 封装流程、经验、模板和参考资料 | “按团队规范审查 PR” |
| MCP Tool | 暴露一个可调用动作 | git_log、query_database、search_web |
| 插件 | 某个产品内的扩展机制 | 浏览器插件、IDE 插件 |
| Function Calling | 模型表达结构化调用意图的方式 | {"city":"上海"} |
一个 Skill 可以指导 Agent 什么时候调用工具，也可以包含脚本；但 Skill 本身不等于工具。它更像一本“操作手册 + 工具包”，工具才是具体执行动作的接口。
A2A：让 Agent 和 Agent 互相协作
A2A 是 Agent2Agent Protocol。根据 A2A 官方文档，它是让不同 AI Agent 之间通信与协作的开放协议，目标是让来自不同团队、框架或厂商的 Agent 能用共同语言互相发现、委托任务、交换消息、返回产物。
为什么需要 A2A？因为有些对象不是“工具”，而是另一个会规划、会追问、会维护状态、会产出复杂结果的 Agent。
比如“查天气”适合当工具；“帮我规划一场跨国旅行”可能需要航班 Agent、酒店 Agent、当地活动 Agent、预算 Agent 共同协作。你当然可以把每个 Agent 硬包装成一个工具，但那会压扁它的能力：工具通常是结构化输入输出，而 Agent 可能需要多轮沟通、澄清条件、处理长任务、分阶段交付。
flowchart LR
user["用户"] --> planner["主 Agent<br/>旅行规划助手"]
planner <-- "A2A" --> flight["航班 Agent<br/>查航班、比价格、改签规则"]
planner <-- "A2A" --> hotel["酒店 Agent<br/>房型、位置、取消政策"]
planner <-- "A2A" --> local["本地活动 Agent<br/>景点、路线、天气"]
planner <-- "A2A" --> budget["预算 Agent<br/>汇率、预算、报销口径"]
flight --> artifact1["航班方案"]
hotel --> artifact2["酒店候选"]
local --> artifact3["行程建议"]
budget --> artifact4["预算表"]A2A 的核心不是“调用函数”，而是“把任务交给另一个 Agent，并能跟踪这个任务的生命周期”。
A2A 的核心角色和对象
A2A 里最重要的是两个角色：A2A Client 和 A2A Server。
A2A Client：发起请求的一方，可以是用户所在的主 Agent，也可以是另一个系统。A2A Server：远程 Agent，对外暴露 A2A 端点，处理任务并返回结果。
然后是几个核心对象。
| 对象 | 像什么 | 作用 |
|---|---|---|
| Agent Card | Agent 的数字名片 | 描述身份、服务地址、能力、认证要求、支持的输入输出形式 |
| Message | 一次对话回合 | 承载用户或 Agent 的文本、文件、结构化数据 |
| Part | Message 或 Artifact 的最小内容块 | 可以是文本、文件引用、结构化数据 |
| Task | 有状态的工作单元 | 用 ID 跟踪长任务、状态变化、取消、失败、完成 |
| Artifact | 最终或阶段性交付物 | 报告、表格、图片、JSON、文件等 |
| Context | 上下文分组 | 把多个 Message 和 Task 归到同一段协作里 |
这里有一个容易混淆的点：A2A Agent Card 里也有 skills 字段，用来描述这个远程 Agent 能处理哪些任务；这不等于上面说的 SKILL.md 格式。前者是 Agent 对外声明的能力名片，后者是 Agent 自己内部加载的操作知识包。中文都可以叫“技能”，但层次不同。
Agent Card：先知道对方能不能接这个活
一个 A2A Client 不应该盲目把任务发给任意远程 Agent。它通常先获取对方的 Agent Card。
sequenceDiagram
participant C as A2A Client / 主 Agent
participant R as A2A Server / 远程 Agent
C->>R: 获取 Agent Card
R-->>C: 返回名称、描述、endpoint、skills、认证方式、输入输出能力
C->>C: 判断是否匹配任务和权限要求
C->>R: message/send 或 message/stream
R-->>C: 返回 Message 或 TaskAgent Card 的价值是让远程 Agent 可以像服务一样被发现和选择，但又不暴露内部实现。主 Agent 只需要知道“它能做什么、怎么联系、需要什么认证、能返回什么形式的结果”，不需要知道它内部用哪个模型、接了哪些私有工具、怎么规划。
Task 生命周期：A2A 不只是一问一答
A2A 支持两种结果：远程 Agent 可以直接返回一个无状态 Message，也可以创建一个有状态 Task。后者适合长任务、多轮任务和需要异步更新的任务。
stateDiagram-v2
[*] --> submitted: message/send
submitted --> working: 远程 Agent 开始处理
working --> input_required: 需要补充信息
working --> auth_required: 需要认证或授权
input_required --> working: 用户补充
auth_required --> working: 授权完成
working --> completed: 产出 Artifact
working --> failed: 执行失败
working --> cancelled: 客户端取消
working --> rejected: 远程 Agent 拒绝
completed --> [*]
failed --> [*]
cancelled --> [*]
rejected --> [*]比如主 Agent 委托数据 Agent 做“分析过去 90 天转化率下降原因”。这个任务可能需要十几分钟，期间数据 Agent 可能发状态更新：正在拉数据、发现缺失字段、需要确认指标口径、生成初稿、输出最终报告。A2A 的 Task、流式更新和推送通知，就是为这类长任务准备的。
常见 A2A Agent 可以分几类
A2A 不是让你把所有工具都变成 Agent。适合通过 A2A 暴露的，通常是有自己专业能力、状态和协作逻辑的远程 Agent。
| 类型 | 常见 Agent | 适合委托什么任务 | 为什么不是普通工具 |
|---|---|---|---|
| 旅行与本地服务 | 航班 Agent、酒店 Agent、本地活动 Agent、地图出行 Agent | 规划路线、比较方案、处理多轮偏好 | 需要澄清偏好、平衡预算、处理动态约束 |
| 企业运营 | 销售 Agent、客服 Agent、CRM Agent、工单 Agent | 跟进客户、汇总反馈、创建工单、查询客户状态 | 有业务上下文和权限边界 |
| 软件工程 | 代码审查 Agent、测试 Agent、发布 Agent、安全扫描 Agent | 审 PR、跑测试、生成发布报告、安全评估 | 需要理解仓库状态和长流程 |
| 数据与分析 | 数据 Agent、BI Agent、实验分析 Agent | 拉指标、归因、生成报表、解释异常 | 需要指标口径、权限和多步查询 |
| 法务与财务 | 合同 Agent、发票 Agent、报销 Agent、采购 Agent | 审条款、核发票、检查预算、生成审批材料 | 高风险，需要审计和人工确认 |
| 内容与设计 | 文案 Agent、设计 Agent、视频 Agent、本地化 Agent | 产出多版本素材，按品牌规范修改 | 输出通常是复杂 Artifact |
一个经验判断：如果它只是“给输入，拿输出”的小函数，用 MCP Tool 更自然；如果它需要理解目标、追问、维护状态、交付复杂产物，用 A2A 更自然。
调用流示例：产品发布计划里的 Skills、MCP、A2A
现在把三者放进同一个完整案例。
用户说：
帮我准备下周新功能发布计划：看一下工程进度、整理风险、拉一下核心指标、给法务过一遍对外文案，最后生成发布 checklist。
一个主 Agent 可能这样工作：
sequenceDiagram
participant U as 用户
participant P as 主 Agent / 发布负责人
participant S as release-planning Skill
participant MCP as MCP 工具层
participant D as 数据 Agent / A2A
participant L as 法务 Agent / A2A
participant C as 客服 Agent / A2A
U->>P: 准备下周新功能发布计划
P->>S: 加载 release-planning Skill
S-->>P: 返回发布流程、风险清单、输出模板
P->>MCP: 查询 GitHub/Jira/CI/文档
MCP-->>P: 返回工程进度、PR、测试状态
P->>D: A2A message/send 拉核心指标和趋势
D-->>P: Task 创建，开始分析
P->>L: A2A message/send 审对外文案
L-->>P: Task 创建，需要确认适用地区
P->>C: A2A message/send 汇总近期用户反馈
C-->>P: 返回 Artifact：反馈摘要
P->>L: 补充地区和发布渠道
L-->>P: 返回 Artifact：法务修改建议
D-->>P: 返回 Artifact：指标报告
P->>P: 按 Skill 模板整合所有结果
P-->>U: 输出发布计划、风险、负责人、checklist这个例子里：
- Skill 告诉主 Agent 发布计划应该怎么做。
- MCP 帮主 Agent 查工程系统、文档、CI 和项目数据。
- A2A 让主 Agent 把专业任务委托给数据、法务、客服 Agent。
- Artifact 是各个远程 Agent 交付回来的报告、建议和摘要。
如果没有 Skills，主 Agent 可能漏掉发布流程；如果没有 MCP，它拿不到真实工程进度；如果没有 A2A，它只能自己假装懂数据、法务和客服上下文。
Skills、MCP、A2A 到底怎么分
把这些概念放在一张表里最清楚。
| 概念 | 回答的问题 | 典型对象 | 例子 |
|---|---|---|---|
| Model | 谁负责理解和生成 | LLM / 多模态模型 | GPT、Claude、Gemini、开源模型 |
| Agent Framework | Agent 怎么运行 | 编排框架、状态、循环、工具接口 | ADK、LangGraph、各类 Agent SDK |
| Agent Skills | 遇到某类任务按什么流程做 | SKILL.md、脚本、参考资料、模板 | 代码审查 Skill、PPT Skill、发票 Skill |
| MCP | Agent 如何用工具和数据 | Tools、Resources、Prompts | 文件、数据库、GitHub、高德地图、公司 API |
| A2A | Agent 如何委托另一个 Agent | Agent Card、Message、Task、Artifact | 主 Agent 委托数据 Agent、法务 Agent |
| RAG | 如何从知识库检索事实 | 向量库、检索器、文档切片 | 查知识库后回答 |
| Function Calling | 模型如何表达结构化调用 | 函数名 + JSON 参数 | 调用天气函数、查询订单函数 |
一句话压缩：
Skills 管“方法”，MCP 管“工具和数据”，A2A 管“协作对象”。
安全和边界：越能做事，越要能停下来
Skills 和 A2A 都会放大 Agent 的能力，也会放大风险。
Skill 的风险在于：它可能带脚本、模板和操作流程。如果 Skill 来源不可信，脚本可能读写不该碰的文件；如果流程写得太激进，Agent 可能跳过确认步骤。所以 Skill 应该像代码一样审查：看来源、看脚本、看权限、看是否有清晰边界。
A2A 的风险在于：你把任务交给了另一个 Agent。远程 Agent 可能来自另一个团队、另一个组织，甚至另一个供应商。它能看到什么输入、保存什么上下文、返回什么产物、如何认证、如何审计，都要明确。
几个实用原则：
- 不可信 Skill 不要随便安装，尤其是带脚本的。
- 高风险操作必须要求人工确认，比如付款、发邮件、下单、改生产数据、提交合同。
- A2A 远程 Agent 只拿完成任务需要的最小上下文。
- Agent Card 里的能力声明不能替代权限控制。
- 远程 Agent 的 Task、Artifact、状态更新要有日志，方便审计。
- 外部文档、网页、用户上传文件都可能包含提示注入，不能让它们覆盖系统规则。
最后用一张脑图收住
mindmap
root((Agent 工程化))
Agent Skills
解决怎么做
SKILL.md
name
description
Markdown 指令
可选目录
scripts
references
assets
渐进式披露
先读元数据
匹配后读主文件
需要时读资源
MCP
解决用什么工具和数据
Tools
Resources
Prompts
A2A
解决找谁协作
Agent Card
Message
Task
Artifact
流式更新
推送通知
可靠性
最小权限
人工确认
审计日志
测试评估如果只带走一句话，就是：
Agent Skills 让 Agent 有可复用的做法，MCP 让 Agent 接上外部工具和数据，A2A 让 Agent 能把任务交给别的 Agent。
等 AI 从“会聊天”进入“能做事”的阶段，真正重要的就不只是模型聪不聪明，而是这些能力能不能被清楚地组织、授权、复用、审计和协作。