一、引言：为什么需要区分 Skill 和 Agent？
2024年末，Anthropic 推出了 MCP（Model Context Protocol），标准化了大模型连接外部工具与数据的方式；2025年10月，Anthropic 又推出了 Agent Skills，并在同年12月将其正式发布为开放标准。这两个概念的出现，标志着 AI 开发正从"手搓 Prompt"的草莽时代迈入"标准化封装"的工业时代。
然而，很多开发者在实践中常常混淆 Skill 和 Agent 这两个概念。它们看起来都是 Markdown 文件，都能指导 AI 完成任务，但本质上代表的是截然不同的架构理念。理解这一区别，是构建可扩展、可维护的 AI 系统的基石。
本文将从概念定义、架构设计、技术实现、应用场景、协作关系等多个维度，对 Skill 和 Agent 进行全面深入的对比分析，帮助你在实际项目中做出正确的架构选择。
二、概念定义：Skill 和 Agent 分别是什么？
2.1 什么是 Agent（智能体）？
Agent 是一个具有自主决策能力的 AI 实体。它拥有自己的系统提示（System Prompt）、工具访问权限、底层模型支撑，以及一个允许它编排工作流和管理状态的智能循环（Agentic Loop）。可以把 Agent 理解为一个"AI 员工"——它在特定的部门中工作，拥有自己的职责范围和决策权限。
Agent 的核心特征：
- 自主性（Autonomy） ：能够独立规划和执行任务，无需人类逐步指导
- 状态管理（State Management） ：拥有独立的工作记忆和上下文沙盒
- 决策能力（Decision Making） ：能根据当前状态选择下一步动作
- 垂直专精（Vertical Specialization） ：专注于特定领域，如调试、代码审查、客户服务等
- 工具调用（Tool Invocation） ：能主动调用外部工具和 API 来完成任务
2.2 什么是 Skill（技能）？
Skill 是一种模块化的、声明式的专业知识包。在物理形态上，它是一个包含 SKILL.md 文件的文件夹，里面封装了让 AI 完成特定类型任务所需的指令、脚本和资源。可以把 Skill 理解为一个"APP"或"岗位 SOP"——它是一套可复用的操作手册，任何 Agent 都可以按需加载使用。
Skill 的核心特征：
- 模块化（Modularity） ：独立封装，可在不同 Agent 和平台间复用
- 声明式（Declarative） ：描述"做什么"和"怎么做"，而非"何时做"
- 渐进式加载（Progressive Disclosure） ：按需加载，优化上下文窗口使用
- 水平通用（Horizontal Applicability） ：跨领域、跨 Agent 通用的能力包
- 可组合（Composable） ：多个 Skill 可以灵活组合，适应不同场景需求
三、一个直觉类比：员工 vs 应用
理解 Skill 和 Agent 最好的方式，是把它们类比到我们熟悉的企业组织中：
| 维度 | Agent（智能体） | Skill（技能） |
|---|---|---|
| 类比角色 | 企业中的员工 | 员工使用的 APP / 工具 |
| 组织方式 | 隶属于部门（HR、财务、研发） | 跨部门通用（Excel、Word） |
| 工作方式 | 主动思考、决策、执行 | 被动调用，按规程执行 |
| 生命周期 | 持续运行，维护状态 | 按需加载，用完释放 |
| 核心价值 | 决策与编排能力 | 标准化与可复用的专业知识 |
换句话说：Agent 是"谁来做"，Skill 是"怎么做" 。Agent 提供决策和编排的主体性，Skill 提供执行和知识的标准化。在一个成熟的 AI 系统中，两者缺一不可。
四、架构层面的深度对比
4.1 信息架构
Agent 和 Skill 在信息组织方式上有本质差异。Agent 的信息是"纵向深入"的——它需要深入理解特定领域的全部上下文，包括历史状态、当前任务、可用工具等。而 Skill 的信息是"横向扩展"的——它封装了某一类操作的标准化流程，不关心谁在调用它。
4.2 渐进式披露（Progressive Disclosure）
Skill 最具工程价值的特性之一是渐进式披露机制，这是解决上下文膨胀（Context Bloat）问题的关键：
| 加载层级 | 内容 | Token 消耗 | 触发条件 |
|---|---|---|---|
| 第一层 | 仅加载技能名称和描述（元数据） | 约 20-50 tokens | 系统启动时自动加载 |
| 第二层 | 加载完整 SKILL.md 指令 | < 5,000 tokens | Agent 判定需要使用该技能时 |
| 第三层 | 加载关联的脚本、文档等资源 | 按需加载 | 指令中引用到具体资源时 |
这意味着你可以给一个 Agent 装备上千个 Skill，但平时只占用极少的上下文空间。只有当任务真正需要某个 Skill 时，完整的指令才会被加载进来。这完美解决了长期以来困扰开发者的 Token 浪费和上下文干扰问题。
4.3 运行时行为对比
| 维度 | Agent | Skill |
|---|---|---|
| 调用方式 | 自主启动，自我驱动 | 被 Agent 或用户触发 |
| 执行模式 | 循环推理 + 决策 + 执行 | 按指令线性执行 |
| 状态管理 | 维护完整会话状态 | 无状态，执行完即释放 |
| 错误处理 | 自主判断并调整策略 | 依赖 Agent 进行异常处理 |
| 并行能力 | 可协调多个子任务 | 单一任务，线性执行 |
| 上下文消耗 | 大量（全局状态 + 工具定义） | 极小（渐进式加载） |
五、技术实现：SKILL.md 与 Agent 的文件结构
5.1 Skill 的文件结构
一个标准的 Skill 遵循 Agent Skills 开放规范（agentskills.io），其文件结构如下：
skill-name/
├── SKILL.md # 必需：技能定义文件（YAML 元数据 + Markdown 指令）
└── Bundled Resources/ # 可选：附加资源
├── scripts/ # 可执行脚本（Python、Shell 等）
├── references/ # 参考文档（API 文档、规范等）
└── assets/ # 输出资源（模板、图标、字体等）
SKILL.md 的核心结构示例：
---
name: my-skill
description: "技能描述——Agent 通过此描述判断是否加载该 Skill"
---
# 技能名称
## 概述
[技能的详细说明]
## 执行指南
1. 第一步操作
2. 第二步操作
## 示例
[提供具体示例]
SKILL.md 的核心由两部分组成：YAML 前置元数据（定义技能名称、描述、触发条件等）和 Markdown 正文（包含详细的执行指令、最佳实践、示例等）。description 字段是技能路由的关键——Agent 正是根据这个字段来判断当前任务是否需要加载该 Skill。
5.2 Agent 的配置
Agent 的配置通常更为复杂，包含系统提示、模型选择、工具列表、权限设置等。在 Claude Code 中，Agent 文件存放在 ~/.claude/agents/ 目录下，以 Markdown 格式编写，但其内容结构和职责与 Skill 有本质区别：
- Agent 定义"我是谁、我的角色是什么、我有哪些权限"
- Skill 定义"如何完成某一类具体任务"
- Agent 引用和编排 Skill，而非反过来
六、Skill、Tool、MCP 三者的关系
很多开发者还会混淆 Skill 与 Tool（工具）和 MCP（模型上下文协议），下面厘清它们各自的定位：
| 概念 | 本质 | 核心作用 | 类比 |
|---|---|---|---|
| Tool（工具） | 可执行函数（有输入、输出、副作用） | 让 Agent "能做事"（执行动作） | 锤子、螺丝刀 |
| Skill（技能） | 结构化知识包（指令 + 脚本 + 资源） | 让 Agent "会做事"（知道怎么做） | 操作手册、SOP |
| MCP（协议） | 标准化接口协议 | 让 Agent "连得上"（安全访问外部系统） | USB 接口 |
| Agent（智能体） | 自主决策实体 | "谁来做"（编排一切） | 员工 |
它们之间的协作关系可以这样理解：Agent 作为决策主体，通过 MCP 协议安全地连接外部系统，调用 Tool 来执行具体操作，并依据 Skill 中封装的知识来决定"何时用什么工具、按什么流程执行"。
如果说 MCP 是 AI 时代的"USB 接口"，那么 Skill 就是"通用驱动程序"，而 Agent 则是"操作系统"。
七、协作模式：Agent 如何使用 Skill？
7.1 单 Agent + 多 Skill 模式
这是最常见的模式。一个 Agent 装配多个 Skill，根据任务类型自动选择合适的 Skill 来执行。例如，一个"全栈开发 Agent"可以同时拥有前端开发、API 设计、数据库迁移、代码审查等多个 Skill。运行时，Agent 根据用户请求判断需要哪个 Skill，按需加载并执行。
7.2 多 Agent + 共享 Skill 模式
在多 Agent 架构中，不同的 Agent 可以共享同一套 Skill 库。例如，"写作 Agent"和"编辑 Agent"可以共享"事实核查 Skill"——写作 Agent 在创作时调用它验证细节，编辑 Agent 在审校时同样可以使用。这种模式极大地提高了知识的复用率。
7.3 Skill 调用 Agent（嵌套模式）
在现代的智能体系统中，Skill 也可以反过来调用 Agent。例如，一个"Bug 修复 Skill"在被触发后，可能会启动三个不同的调试 Agent（静态分析 Agent、运行时调试 Agent、日志分析 Agent），让它们并行工作后汇总结果。这种嵌套模式让系统具备了更强的灵活性。
八、三级架构：Skill → Workflow → Agent
在更成熟的架构设计中，Skill、Workflow（工作流）和 Agent 构成了一个清晰的三级层次结构：
| 层级 | 定义 | 粒度 | 示例 |
|---|---|---|---|
| Skill | 领域知识容器 | 最细粒度 | 博客写作、安全审计、数据分析 |
| Workflow | Skill 内的分步流程 | 中等粒度 | 创建文章、发布文章、SEO 优化 |
| Agent | 独立执行者，编排 Skill | 最粗粒度 | 工程师 Agent、研究员 Agent |
Skill 是领域知识的"容器"（如博客、研究、安全），Workflow 是 Skill 内部的"步骤"（如创建、发布、部署），Agent 是并行执行的"工人"（如工程师、架构师、研究员）。Agent 调用 Skill，Skill 内部包含 Workflow，三者协同完成复杂任务。
九、应用场景对比：何时用 Agent，何时用 Skill？
9.1 适合用 Skill 的场景
- 可重复的标准化任务：如生成特定格式的文档（Word、Excel、PDF、PPT），每次都需要相同的步骤和规范
- 跨项目/跨团队的通用能力：如代码风格检查、事实核查、品牌规范应用等，不同团队都需要的通用操作
- 需要精确控制输出的流程：如填写 PDF 表单、生成合规报告等，容错率极低的任务
- 频繁使用的知识片段：如 API 文档参考、设计模式指南、最佳实践清单等
- 需要上下文效率的场景：当 Agent 需要装备大量能力但不能让上下文膨胀时
9.2 适合用 Agent 的场景
- 需要自主判断和决策的复杂任务：如代码调试（需要分析、假设、验证的循环过程）
- 需要维护长期状态的交互：如客服对话（需要记住历史交互并持续跟进）
- 需要协调多个子任务的工作流：如项目管理（涉及任务分解、优先级排序、资源分配）
- 高度特化的领域专家角色：如"安全审计 Agent"、"数据科学家 Agent"等
- 需要并行处理的场景：多个 Agent 同时处理不同子任务，提高效率
十、工程实践中的关键考量
10.1 上下文窗口管理
上下文窗口是 AI Agent 最稀缺的资源。2025年的大量研究表明，过载的上下文窗口会导致严重的推理失败。Skill 的渐进式加载机制是目前最有效的解决方案之一——运行时 Agent 仅看到 Skill 的元数据（名称和描述），只有在确定需要时才加载完整内容。这让 Skill 的数量可以事实上无上限地扩展，而不影响 Agent 的推理能力。
10.2 安全性
Tool 和 Skill 在安全面上有显著差异。Tool（尤其是通过 MCP 连接的外部工具）需要处理身份认证、权限控制和操作审计等安全问题。安全研究者已发现 MCP 存在一些基础性漏洞，包括"rug pull"（工具安装后定义发生变异）和"tool shadowing"（恶意服务器拦截对可信工具的调用）。Skill 作为基于 Prompt 的知识包，不具有直接的攻击面，但它们也无法在没有 Tool 的情况下执行任何实际操作。因此，企业部署中需要同时关注两个层面的安全治理。
10.3 可移植性与标准化
Agent Skills 已被 Anthropic 在2025年12月正式发布为开放标准。Cursor、OpenCode、Letta 等主流 AI 开发工具已宣布支持该标准。这意味着开发者编写一套 Skill，可以在所有支持该标准的平台上无缝运行，大幅降低了供应商锁定的风险。相比之下，Agent 的配置通常与特定平台深度绑定，可移植性较低。
10.4 测试与质量保障
Anthropic 推出了 Skill-Creator 插件，为 Skill 带来了类似于软件开发中单元测试和基准测试的能力。开发者可以对 Skill 进行定义评估查询、运行基准对比、甚至进行盲测（blind comparison）。这种工程化的测试体系，确保 Skill 不会在模型更新后"悄悄失效"。
十一、产业生态与合作伙伴
Agent Skills 开放标准的发布伴随着一个丰富的合作伙伴生态。Atlassian、Canva、Cloudflare、Figma、Notion、Ramp、Sentry 等头部企业已提供官方 Skill。例如，Atlassian 的 Skill 能让 Claude 把需求文档转化为 Jira 工单、自动生成状态报告、智能分发 Issue；Figma 的 Skill 则让 Claude 理解设计稿并生成代码。
对于企业管理者，Anthropic 还为 Team 和 Enterprise 版本提供了集中式管理控制台，管理员可以控制哪些 Skill 被分配给用户、哪些 Skill 默认启用，实现了企业级的治理能力。
十二、延伸：单 Agent vs 多 Agent 架构
在讨论 Skill 和 Agent 的关系时，还需要理解单 Agent 和多 Agent 架构的选型：
| 维度 | 单 Agent 架构 | 多 Agent 架构 |
|---|---|---|
| 推理方式 | 集中式推理，一个 Agent 规划和执行所有步骤 | 分布式推理，每个 Agent 专注自己的领域 |
| 复杂度 | 简单，易于调试 | 复杂，需要协调层 |
| 适用场景 | 大多数常规任务 | 需要多领域深度协作的复杂任务 |
| Skill 使用 | 一个 Agent 直接加载所需 Skill | 多个 Agent 共享 Skill 库 |
| 业界观点 | Cognition（Devin）推荐此模式 | 企业级复杂场景首选 |
在实践中，大多数场景下使用一个装备了丰富 Skill 的单 Agent 就足够了。只有当任务确实需要多领域深度专家协作时，才考虑多 Agent 架构。过早引入多 Agent 往往会导致系统脆弱性增加。
十三、总结：架构决策框架
回到最初的问题：什么应该是 Agent，什么应该是 Skill？以下是一个实用的决策框架：
| 选择 Skill 当…… | 选择 Agent 当…… |
|---|---|
| 任务有明确、可重复的步骤 | 任务需要自主判断和动态决策 |
| 知识可以跨项目/跨团队复用 | 需要维护复杂的运行时状态 |
| 需要优化上下文窗口的使用效率 | 需要并行协调多个子任务 |
| 需要标准化输出质量和格式 | 需要一个持续运行的专家角色 |
| 希望在多个平台间保持可移植性 | 任务边界清晰，需要独立的权限和沙盒 |
最关键的一句话： Agent 和 Skill 不是非此即彼的选择，而是互补的架构组件。Agent 提供决策和编排的"大脑"，Skill 提供执行和知识的"肌肉记忆"。最优的 AI 系统设计，是让合适的 Agent 在合适的时机调用合适的 Skill。
十四、未来展望
随着 Agent Skills 开放标准的不断成熟，我们可以预见以下趋势：
- Skill 生态爆发：就像 MCP 推动了工具连接的标准化，Agent Skills 将推动"AI 知识"的标准化。未来将出现大量第三方 Skill 市场和社区共享平台
- Agent 智能升级：Agent 将变得更擅长自主发现、评估和选择 Skill，甚至能动态组合多个 Skill 来应对前所未有的新任务
- 企业级治理完善：更细粒度的权限控制、审计日志和合规能力将使 Agent+Skill 架构在受监管行业中大规模落地
- 跨平台互操作：随着开放标准的采纳，Skill 将真正实现"编写一次，到处运行"，打破供应商生态壁垒
AI 开发正在经历从"手工作坊"到"工业化生产"的转变。理解 Skill 和 Agent 的本质区别与协作关系，是每一位 AI 开发者和架构师都需要掌握的核心能力。希望这篇文章能帮助你在这场变革中找到正确的方向。
参考资料
- Anthropic, "Equipping agents for the real world with Agent Skills", 2025年12月
- The New Stack, "AI Agents or Skills? Why the Answer Is 'Both'", 2026年1月
- Arcade.dev, "Skills vs Tools for AI Agents: Production Guide", 2025年12月
- DEV Community, "MCP vs Agent Skills: Why They're Different, Not Competing", 2026年3月
- Daniel Miessler, "When to Use Claude Code Skills vs Workflows vs Agents"
- Builder.io, "Agent Skills vs. Rules vs. Commands", 2026年1月
- agentskills.io — Agent Skills 开放标准规范
- Claude Code 官方文档 — Skills 章节
