AI Skill 系统设计：可组合的 AI 能力单元

发表于2026-03-23|更新于2026-05-08|AI

|总字数:3.7k|阅读时长:12分钟|浏览量:

引言：为什么需要 Skill 这个抽象层

在 AI Agent 的开发实践中，我们逐渐发现了一个问题：直接让 Agent 使用零散的工具（Tool）虽然灵活，但在面对重复性的复杂任务时效率低下。就像程序员不会每次写代码都从汇编指令开始——我们需要函数、模块、库——Agent 也需要比 Tool 更高层次的抽象。这个抽象就是 Skill。

如果把 Agent 的能力层级比作一座金字塔：

        Agent（自主决策与目标管理）
       /      \
    Skill    Skill（可组合的能力单元）
   /    \    /    \
Tool  Tool  Tool  Tool（原子操作）

Tool 是原子操作（读文件、查天气、执行 SQL），Skill 是封装了领域知识、工作流逻辑和工具组合的可复用能力单元。Agent 在最上层做决策，调遣 Skill 来完成任务。

Skill 的定义与构成

Skill 是什么

一个 Skill 由四个核心要素构成：

Prompt 模板：告诉 LLM 它的角色、目标、工作方式和输出格式。这是 Skill 的”大脑”。
工具集合：Skill 完成任务所需的专属工具。可以是通用工具的子集，也可以是 Skill 专属的特定工具。
领域知识：嵌入在 prompt 中的专业信息——行业术语、最佳实践、常见陷阱、领域规则等。
工作流逻辑：完成任务的步骤模式——先做什么、后做什么、什么情况下分支。

Skill 的接口设计

一个设计良好的 Skill 接口应该包含以下信息：

name: "code-review"
description: >
  对代码变更进行全面的代码审查，包括逻辑正确性、性能、
  安全性、可维护性和代码风格。适用于 pull request review、
  提交前自查等场景。
parameters:
  - name: target_files
    type: list[str]
    description: 待审查的文件路径列表
  - name: review_focus
    type: string
    enum: ["general", "security", "performance", "style"]
    description: 审查侧重点
    default: "general"
expected_output:
  format: markdown
  sections: ["摘要", "严重问题", "改进建议", "风格建议"]

Skill 的接口设计原则与工具的接口设计原则一脉相承：名称精确、描述详尽、参数约束明确、输出可预期。但 Skill 的描述需要额外传达”这个 Skill 在什么情况下适用”和”它与其他 Skill 的关系”。

Skill 与 Tool、Agent 的边界

这是实践中最容易混淆的概念，我们通过一个示例来厘清：

场景：生成一份市场分析报告

Tool 层面：search_web("新能源市场 2026")、calculate_market_share(company_data)、generate_chart(data)——每个都是单个操作。
Skill 层面：一个 market-analysis Skill 封装了”搜索数据 → 整理分析 → 生成图表 → 撰写报告”的完整工作流，以及市场分析的方法论知识——PEST 分析框架、SWOT 分析模板、行业数据来源等。
Agent 层面：Agent 判断用户需要市场分析，调用 market-analysis Skill，检查输出是否满足用户期望，如果不满足则要求改进或调整。

核心区分标准：

维度	Tool	Skill	Agent
粒度	原子操作	完整任务	目标驱动
知识	无	领域知识嵌入	跨领域综合
决策	无	流程内决策	高层决策
复用	跨场景通用	领域内复用	通常不直接复用
示例	`query_database`	`数据分析报告生成`	`数据分析师 Agent`

Skill 的组合模式

真正的威力来自 Skill 的可组合性——就像 Unix 哲学中的管道，将简单的 Skill 组合成复杂的能力。

顺序管道（Sequential Pipeline）

Skill A 的输出成为 Skill B 的输入：

1	数据采集 Skill → 数据清洗 Skill → 数据分析 Skill → 报告生成 Skill

这种模式的实现要点是输出格式的标准化：每个 Skill 的输出必须包含足够的结构化信息，让下游 Skill 能够直接消费。通常的做法是要求 Skill 在输出末尾附带一个 JSON 格式的数据摘要。

并行扇出（Parallel Fan-out）

多个 Skill 同时处理不同的数据切片或不同的分析维度：

用户输入 → 同时启动：
            ├── 法律合规 Skill（审查法律风险）
            ├── 安全审查 Skill（检查安全漏洞）
            └── 性能分析 Skill（评估性能影响）
         → 合并结果 → 综合建议

条件分支（Conditional Branching）

根据当前状态或中间结果决定执行哪个 Skill：

输入文档 → 判断文档类型：
              ├── 技术文档 → 技术文档翻译 Skill
              ├── 法律文件 → 法律翻译 Skill（需要术语库支持）
              └── 通用文本 → 通用翻译 Skill

递归自改进（Recursive Self-Improvement）

Skill 自身的输出经过评估后，再次调用自身进行改进：

1	初稿 Skill → 质量评估 → 未达标准？→ 改进版 Skill（带反馈）→ 评估 → 达标 → 输出

这种模式特别适合创作类场景——写作、翻译、设计等——其中”一遍过”很难达到高质量。

Skill 库的管理

当组织内部的 Skill 数量增长到几十甚至上百个时，就需要系统化的管理：

分类体系

Skill Library
├── 开发类
│   ├── code-review
│   ├── unit-test-generator
│   ├── api-doc-generator
│   └── refactoring-advisor
├── 数据类
│   ├── data-analysis
│   ├── report-generator
│   └── chart-creator
├── 写作类
│   ├── blog-post-writer
│   ├── thesis-editor
│   └── translation-pipeline
└── 运维类
    ├── incident-analyzer
    ├── log-summarizer
    └── config-auditor

版本管理

Skill 也需要版本控制。当一个 Skill 被修改后，依赖它的上层 Skill 或 Agent 工作流可能会受到影响：

name: "data-analysis"
version: "2.1.0"
changelog:
  - version: "2.1.0"
    changes: "新增对时序数据的自动趋势检测"
  - version: "2.0.0"
    breaking: "输出格式从纯文本改为结构化 JSON + Markdown"
  - version: "1.0.0"
    changes: "初始版本"

版本管理的关键原则：

语义化版本：主版本号变更表示输出格式或接口不兼容、次版本号变更表示功能增强但向后兼容、修订号表示 prompt 优化或 bug 修复。
锁定依赖：在生产环境中，Agent 使用的 Skill 应该锁定具体版本，避免自动升级导致行为变化。

发现机制

当 Skill 库规模较大时，Agent 需要一个有效的 Skill 发现机制。类似于工具的”选择”问题，Agent 需要在众多可用 Skill 中找到最匹配当前任务的那一个。

class SkillRegistry:
    def find_skills(self, task_description: str, top_k: int = 5) -> list:
        """基于任务描述寻找最相关的 Skill"""
        task_embedding = embed(task_description)

        candidates = []
        for skill in self.skills.values():
            # 综合 Skill 名称和描述的语义
            skill_text = f"{skill.name}: {skill.description}"
            skill_embedding = embed(skill_text)
            score = cosine_similarity(task_embedding, skill_embedding)
            candidates.append((score, skill))

        candidates.sort(reverse=True)
        return [skill for _, skill in candidates[:top_k]]

案例研究：Claude Code 的 Skill 系统

Claude Code 的 Skill 系统是 2026 年生产环境中比较成熟的 Skill 实现，值得深入分析。

设计理念

Claude Code 的 Skill 系统建立在这样一个前提上：AI 编程助手不应该每次都在零散的工具层面操作，而应该在更高的”能力”层面思考。Skill 不是工具的简单包装，而是将”如何完成某类任务”的知识编码为可复用的单元。

Skill 的结构

每个 Skill 包含：

触发规则：什么情况下应该激活这个 Skill（如”用户提到了论文”、”项目用了特定框架”）。
系统指令扩展：Skill 激活后，会在 Agent 的系统 prompt 中注入额外的知识和指令。
专属工具：Skill 可以注册自己的工具（如论文写作 Skill 提供 GB/T 7714 引用格式生成工具）。
工作流模板：完成任务的标准步骤模式。

Skill 的加载流程

用户输入
  → Agent 分析输入，匹配 Skill 的触发规则
  → 匹配成功的 Skill 被激活
  → Skill 的系统指令注入 Agent 的上下文
  → Skill 的专属工具被注册到 Agent 的工具列表
  → Agent 在 Skill 的指导下执行任务
  → 任务完成，Skill 的上下文可以被卸载

这种”热插拔”的设计让 Agent 的基础能力保持精简，同时允许在需要时动态加载专项能力。

对 Skill 设计的启示

从 Claude Code 的实践中，我们可以归纳出几个 Skill 设计的关键原则：

独立性强：Skill 之间尽量减少耦合。每个 Skill 应该能独立运作。
指令精确：Skill 的系统指令要精细打磨。一两句话的差异可能导致完全不同的行为。
边界清晰：明确 Skill 的适用场景和不适用的场景，避免 Skill 在不该激活的时候被误触发。
可测试：每个 Skill 都应该有对应的测试用例，验证其在典型场景和边缘场景下的表现。

Skill 开发工作流

一个 Skill 从构想到成熟，通常经历以下阶段：

1. 定义阶段

明确 Skill 的目标、输入、输出和约束。回答几个关键问题：

这个 Skill 解决什么用户问题？
它的输入是什么，输出是什么？
它与现有的 Skill 是什么关系（替代、补充还是组合）？
它的质量如何衡量？

2. 开发阶段

编写 Skill 的 Prompt 模板、配置工具集、注入领域知识。

# 开发阶段的核心工作物
name: "thesis-writing"
prompt_template: |
  你是一位专业的学术论文写作助手。

  角色定位：
  - 你精通学术论文的结构规范（GB/T 7713-1987）
  - 你熟悉引用格式标准（GB/T 7714-2015）
  - 你了解目标学校/期刊的格式要求

  工作流程：
  1. 分析论文主题，确定章节结构
  2. 逐章撰写，确保逻辑连贯
  3. 检查引用格式的规范性
  4. 审阅全文，优化表达

  注意事项：
  - 保持学术语言的严谨性
  - 避免过于口语化的表达
  - 所有数据和论断需要引用支持