Claude Skills 的设计思路：用文件、脚本和渐进式加载扩展 AI Agent

AI Agent 早期常见的做法，是为每个领域单独做一套智能体：写代码用编码 Agent，做研究用研究 Agent，做金融分析用金融 Agent，做营销材料用营销 Agent。

这种思路直观，但维护成本很高。每个 Agent 都要有自己的提示词、工具、执行环境、知识库和集成方式，能力边界也很容易被写死。一旦模型本身的通用推理能力变强，继续堆大量“专用 Agent”就会显得笨重。

Claude Skills 代表了另一种路线：保留一个通用 Agent，把领域知识、工作流、最佳实践、参考文档和可执行脚本封装成 Skills，让 Agent 在处理具体任务时按需读取。

可以把它理解成：

Agent 负责推理和执行，Skills 负责提供专业知识。

一个通用 Agent 不需要被改造成“金融 Agent”或“医疗 Agent”，只要给它挂上对应领域的技能包，它就能在相关任务里读取专业规则、调用脚本、遵循组织流程。

为什么不再只靠专门的 Agent

专门 Agent 最大的问题不是不能用，而是扩展方式不够经济。

假设一个团队要支持 5 个业务方向：

• 财务建模
• 合同审查
• 销售分析
• PPT 生成
• 内部知识检索

如果每个方向都做一个专用 Agent，系统会变成这样：

flowchart TD
    U[用户任务] --> A1[财务 Agent]
    U --> A2[合同 Agent]
    U --> A3[销售 Agent]
    U --> A4[PPT Agent]
    U --> A5[知识检索 Agent]

    A1 --> T1[财务工具和规则]
    A2 --> T2[法务工具和规则]
    A3 --> T3[销售数据和规则]
    A4 --> T4[演示文稿模板]
    A5 --> T5[内部知识库]

这套结构的问题在于，很多能力其实是重复的：读取文件、调用 API（应用程序编程接口）、写脚本、生成报告、操作表格、整理引用。不同领域真正不同的部分，往往是专业知识和工作流程，而不是 Agent 的底层执行机制。

更合理的结构是保留一个通用 Agent，再用技能包补齐领域能力：

flowchart TD
    U[用户任务] --> A[通用 Agent]

    A --> R[Agent 运行时<br/>Shell / 文件系统 / Python]
    A --> M[MCP 服务器<br/>外部工具和数据源]
    A --> S[Skills 技能库<br/>领域知识和流程]

    S --> S1[财务建模技能]
    S --> S2[合同审查技能]
    S --> S3[PPT 生成技能]
    S --> S4[销售分析技能]

这样一来，Agent 不需要为每个垂直领域重新搭一套系统。新增能力时，更多时候是在新增一个 Skill，而不是新增一个 Agent。

代码成为 Agent 执行数字工作的通用接口

Claude Code 名字上是编码 Agent，但更准确地说，它是一个“通过代码工作的通用 Agent”。

很多数字化任务最终都可以落到代码、文件系统和命令行上：

这种模式下，Agent 的运行时可以非常朴素：

flowchart LR
    A[Agent 推理] --> B[写代码或命令]
    B --> C[文件系统]
    B --> D[Shell]
    B --> E[Python / Node 等运行环境]
    B --> F[外部 API]
    C --> A
    D --> A
    E --> A
    F --> A

只要 Agent 能写代码、运行代码、读写文件、调用外部接口，它就能完成大量知识工作。问题在于：会执行不等于懂专业规范。

一个通用 Agent 可能知道怎样生成 PPTX 文件，但未必知道某个公司的品牌色、字体规范、封面样式和汇报结构；它可能会写财务模型，但未必知道团队内部对 WACC（Weighted Average Cost of Capital，加权平均资本成本）、敏感性分析和可比公司筛选有哪些固定口径。

Skills 要解决的正是这个缺口。

Skills 是什么

Skill 本质上是一个目录，里面放一组有组织的文件。它可以包含说明文档、参考资料、脚本、模板和测试样例。

一个简单的品牌规范 Skill 可能长这样：

anthropic_brand/
├── SKILL.md
├── docs.md
├── slide-decks.md
└── apply_template.py

其中：

这种设计故意保持简单。文件是最通用的工程原语，可以用 Git 做版本管理，可以放在团队网盘里，也可以直接复制给另一个 Agent 运行环境。技能创建也不必只由工程师完成，产品经理、分析师、运营人员和领域专家都可以把自己的流程整理成 Markdown 文档，再逐步加入脚本。

SKILL.md：技能的入口文件

一个 Skill 至少需要一个 SKILL.md。它通常包含 YAML front matter，用来告诉 Agent 这个技能叫什么、什么时候适合使用。

示例：

---
name: Anthropic Brand Style Guidelines
description: Official brand colors, typography, slide layout rules, and scripts for applying presentation templates.
---

# Anthropic Brand Style Guidelines

Use this skill when creating or editing slide decks that must follow Anthropic brand guidelines.

## Core rules

- Use `#141413` as the dark background color.
- Use oat as the foreground color for intro and outro slides.
- Use `#da7857` for section slides.
- Run `./apply_template.py <pptx>` after editing a presentation.

name 和 description 很关键，因为 Agent 一开始不会读取整个技能目录，而是先看到这些轻量级元数据。描述写得越清楚，Agent 越容易判断什么时候该启用这个 Skill。

不好的描述：

description: Helps with slides.

更好的描述：

description: Use when creating or editing PPTX slide decks that must follow the company's official brand colors, typography, intro slides, section slides, and template rules.

后者把适用对象、文件类型、任务范围和具体能力都说清楚了。

渐进式披露：别把所有知识一次塞进上下文

大模型有上下文窗口限制。一个企业可能有几百个 Skills，如果每次对话都把所有技能说明、参考文档和脚本全部塞进去，上下文很快会被填满，模型还会被大量无关信息干扰。

Skills 采用“渐进式披露”机制：先暴露少量元数据，只有在需要时再加载更详细的内容。

flowchart TD
    A[用户提出任务] --> B[Agent 查看所有 Skill 的元数据]
    B --> C{是否匹配某个 Skill}
    C -- 否 --> D[直接使用通用能力处理]
    C -- 是 --> E[读取对应 SKILL.md]
    E --> F{是否需要更多细节}
    F -- 否 --> G[按 SKILL.md 执行]
    F -- 是 --> H[读取 references 或 docs]
    H --> I[调用脚本或执行流程]

常见的三层结构可以这样理解：

这种机制让 Agent 可以“知道有很多技能”，但不会一开始就被所有细节淹没。只有当任务真正涉及前端设计、财务建模、临床试验方案或 PPT 模板时，对应资料才会进入上下文。

脚本也是 Skill 的一部分

传统工具调用通常依赖预先注册好的函数或服务，例如：

{
  "name": "apply_brand_style",
  "description": "Apply brand style to a presentation",
  "parameters": {
    "file": "string"
  }
}

这种工具化方式适合稳定能力，但也有几个限制：

Skill 里的脚本更像“可读、可改、可运行的工具”。脚本不需要常驻上下文，Agent 只在需要时读取说明并执行。

例如，一个用于给 PPTX 应用模板的脚本可以写成：

# brand_styling/apply_template.py
import sys
from pptx import Presentation

if len(sys.argv) != 2:
    print("USAGE: apply_template.py <pptx>")
    sys.exit(1)

pptx_path = sys.argv[1]
prs = Presentation(pptx_path)

for slide in prs.slides:
    # 示例：根据页面类型设置背景、字体和占位符样式
    # 实际逻辑可以继续封装成函数
    pass

prs.save(pptx_path)
print(f"Updated {pptx_path}")

对应的文档只需要告诉 Agent 什么时候运行它：

## Slide deck styling

- Intro and outro slides:
  - background color: `#141413`
  - foreground color: oat
- Section slides:
  - background color: `#da7857`
  - foreground color: `#141413`

After editing a PPTX file, run:

```bash
python ./apply_template.py ./deck.pptx

这种组合有一个很实用的特点：领域专家可以先写规则，工程师再把重复操作沉淀成脚本；当 Agent 多次写出类似脚本时，也可以把脚本保存进 Skill，变成可复用能力。

---

## Skills 和 MCP 的关系

MCP（Model Context Protocol，模型上下文协议）解决的是 Agent 如何连接外部工具和数据源的问题。Skills 解决的是 Agent 如何获得领域知识和流程指导的问题。

两者不是同一层能力。

| 组件 | 解决的问题 | 例子 |
|------|------------|------|
| MCP 服务器 | 连接外部系统和数据 | 搜索网页、查数据库、读 Slack、访问 Notion |
| Skill | 指导 Agent 如何完成专业任务 | 竞争分析框架、财务建模流程、品牌规范、临床试验方案模板 |

一个竞争分析任务可能同时用到 MCP 和 Skill：

```mermaid
sequenceDiagram
    participant User as 用户
    participant Agent as Agent
    participant Skill as 竞争分析 Skill
    participant MCP as MCP 服务器
    participant Sources as 外部数据源

    User->>Agent: 生成某产品的竞争分析报告
    Agent->>Skill: 读取分析框架和报告结构
    Skill-->>Agent: 返回调研步骤、指标口径、输出模板
    Agent->>MCP: 请求搜索、内部数据库、Notion、Slack 数据
    MCP->>Sources: 拉取相关资料
    Sources-->>MCP: 返回资料
    MCP-->>Agent: 返回结构化数据
    Agent->>Agent: 汇总、比较、生成报告
    Agent-->>User: 输出竞争分析报告

MCP 负责“拿到东西”，Skill 负责“知道该怎么做”。

完整 Agent 架构

把这些组件放在一起，可以得到一个较清晰的 Agent 架构：

flowchart TD
    U[用户任务] --> L[Agent Loop<br/>规划、推理、检查下一步]

    L --> R[Agent Runtime<br/>代码执行、Shell、文件系统]
    L --> M[MCP Servers<br/>连接外部工具和数据源]
    L --> S[Skill Library<br/>领域知识、流程、脚本、模板]

    S --> S1[SKILL.md]
    S --> S2[Docs / References]
    S --> S3[Scripts]
    S --> S4[Templates]

    R --> F[(本地文件)]
    M --> D[(外部数据库)]
    M --> N[Notion / Slack / Web / SaaS]

    F --> L
    D --> L
    N --> L

各层职责要分开：

这种分层的好处是新增能力时不必改动整个系统。要让 Agent 更懂前端设计，可以加一个前端设计 Skill；要让它访问内部 CRM（客户关系管理）系统，可以接一个 MCP 服务器；要让它能稳定处理 Excel，可以补充一个电子表格 Skill 和对应脚本。

常见 Skill 类型

Skills 生态里可以大致分成三类。

基础技能偏通用，目标是让 Agent 稳定处理常见文件和工作流。
合作伙伴技能偏集成，让 Agent 更容易使用某个产品或服务。
企业技能最贴近业务，因为它承载的是组织内部长期积累下来的规则、口径和流程。

一个 Skill 应该怎么设计

设计 Skill 时，不要一开始就把所有东西都堆进去。更好的做法是先回答四个问题：

1. 这个技能适合什么任务？
2. Agent 判断是否启用它时，需要看到哪些关键词？
3. 执行任务时必须遵守哪些规则？
4. 哪些重复操作可以沉淀成脚本？

一个推荐目录结构如下：

financial_modeling/
├── SKILL.md
├── references/
│   ├── dcf-methodology.md
│   ├── comparable-companies.md
│   └── sensitivity-analysis.md
├── templates/
│   └── dcf_model_template.xlsx
├── scripts/
│   ├── build_dcf_model.py
│   └── validate_outputs.py
└── examples/
    └── sample_prompt.md

SKILL.md 可以这样写：

---
name: Financial Modeling
description: Use for DCF valuation, comparable company analysis, earnings analysis, investment update reports, and pitch materials that require finance-specific modeling assumptions and output formats.
---

# Financial Modeling

Use this skill when the task involves investment banking, equity research, valuation, M&A analysis, or financial model generation.

## Workflow

1. Clarify company, period, currency, and data source.
2. Retrieve financial statements or user-provided data.
3. Choose the right model type:
   - DCF for intrinsic valuation
   - Comparable company analysis for market benchmarking
   - Earnings analysis for quarterly updates
4. Generate model outputs using the templates in `templates/`.
5. Validate assumptions and formulas with `scripts/validate_outputs.py`.

## Important rules

- Always state assumptions explicitly.
- Do not mix currencies without conversion.
- Keep WACC and terminal growth assumptions visible.
- Include sensitivity analysis when building DCF models.

这个入口文件不需要把全部金融知识写完，只要让 Agent 知道适用场景、总体流程和关键规则。详细方法可以放到 references/ 里，模板和脚本则按需调用。

适合用 Skills 的场景

Skills 不是所有 Agent 问题的答案。它最适合封装“稳定、可复用、带有专业口径”的知识和流程。

判断一个流程是否该做成 Skill，可以看它是否满足三个条件：

• 会被重复使用；
• 有明确的专业规则；
• 可以通过文档、模板或脚本表达出来。

满足得越多，越适合沉淀成 Skill。

垂直领域里的用法

金融服务是很典型的场景。一个金融 Skill 库可以包含：

• DCF（Discounted Cash Flow，贴现现金流）模型构建；
• 可比公司分析；
• 季度盈利分析；
• 投资研究报告生成；
• M&A（Mergers and Acquisitions，并购）尽职调查；
• 路演和推介材料制作。

医疗和生命科学也适合用 Skills，因为专业流程复杂，且很多任务有稳定范式：

• 生物信息学流程，例如 scVI-tools、Nextflow、单细胞 RNA（Ribonucleic Acid，核糖核酸）测序分析；
• 临床试验方案生成；
• 科学问题筛选；
• FHIR（Fast Healthcare Interoperability Resources，快速医疗互操作资源）开发；
• 事先授权审查，把覆盖要求、临床指南和患者记录交叉核对。

这些任务的共同点是：Agent 不只是要“会写”，还要知道行业规范、输出格式、校验步骤和术语口径。Skills 把这些经验显式写进文件系统，Agent 才能稳定复用。

使用 Skills 时要注意的坑

1. description 写得太泛

Agent 是否启用某个 Skill，很大程度取决于元数据。描述太短、太抽象，会导致该用时不用，或者不该用时误用。

推荐写法是包含：

• 任务类型；
• 领域关键词；
• 文件类型；
• 输出形式；
• 适用边界。

2. 把长文档全部塞进 SKILL.md

SKILL.md 应该是入口和导航，不是百科全书。长规范、完整手册、案例库应放进 references/，让 Agent 需要时再读。

3. 脚本缺少使用示例

Agent 能读代码，但清晰的命令示例仍然重要。每个脚本最好配一行可直接运行的命令：

python scripts/build_dcf_model.py --input data/company.csv --output output/model.xlsx

4. 没有版本管理

Skills 会承载组织流程和专业口径，应该像代码一样管理版本。至少要做到：

• 用 Git 记录变更；
• 重要技能经过 review；
• 保留变更说明；
• 旧任务能追溯当时使用的技能版本。

5. 忽略安全边界

Skill 里可能包含脚本，脚本可能读写文件、调用网络或处理敏感数据。生产环境里需要配合沙箱、权限控制和审计机制，避免 Agent 执行超出任务范围的操作。

Skills 改变的是 Agent 的扩展方式

Claude Skills 的关键不在于“又多了一种插件格式”，而在于它把 Agent 能力扩展拆成了两个层面：

• 通用能力放在 Agent 和运行时里，例如推理、规划、写代码、读写文件；
• 专业能力放在 Skills 里，例如领域知识、流程规范、模板和脚本。

这种拆分让 Agent 不必为每个领域重新定制一套系统。新增一个业务能力，更像是给团队知识库增加一个可执行、可版本化、可按需加载的技能包。

当 Skills 与 MCP 配合使用时，结构会更完整：MCP 负责连接外部世界，Skills 负责告诉 Agent 如何专业地完成任务，运行时负责执行代码和处理文件，Agent Loop 负责规划与决策。对企业级 Agent 来说，这种分层比堆大量专用 Agent 更容易维护，也更容易把团队经验沉淀下来。