AI Agent 中的 Skills 抽象：什么时候该用，什么时候别用

Skills 可以理解为 AI Agent（人工智能代理）的一种“能力包”：它把某个专业能力的说明、调用方式、约束条件、示例和底层实现封装起来，让 Agent 在需要时按统一方式调用。

这个概念听起来很通用，但它的价值并不是在所有场景里都一样。放在 Claude Code 这类专用编程工具里，Skills 很容易被 Commands 和 SubAgent 覆盖；放到企业级 Agent 平台里，它又会变成能力复用、团队协作和生态扩展的关键基础设施。

技术选型的核心问题不是“Skills 好不好”，而是：当前系统有没有遇到 Skills 真正要解决的问题。

1. Skills 到底是什么

在大语言模型驱动的 Agent 系统里，模型本身负责理解用户意图、拆解任务和选择动作，但模型不能只靠“会说话”完成所有事情。它需要调用外部能力，例如：

• 查询数据库；
• 调用业务系统接口；
• 生成报表；
• 发送邮件；
• 执行代码检查；
• 做图片、语音、文本等多模态处理。

这些能力可以直接写成函数，也可以封装成工具，还可以进一步组织成 Skills。

一个 Skill 通常不只是一个函数调用。它更像一个可复用的专业能力单元，里面可能包含：

一个简单的 Skill 描述可以长这样：

name: customer-profile-analysis
description: 根据客户基础信息、历史订单和互动记录生成客户画像。
inputs:
  customer_id:
    type: string
    required: true
  include_risk_score:
    type: boolean
    default: false
outputs:
  profile_summary:
    type: string
  tags:
    type: array
  risk_score:
    type: number
constraints:
  - 只能访问当前租户下的客户数据
  - 不返回手机号、身份证号等敏感字段
examples:
  - input:
      customer_id: "C1024"
      include_risk_score: true
    output:
      profile_summary: "高价值企业客户，近 90 天活跃度较高"
      tags: ["高价值", "企业客户", "活跃"]
      risk_score: 0.18

Agent 不需要知道客户画像是怎么计算出来的，也不需要关心底层调用了几个系统。它只需要知道：存在这样一个能力，什么时候适合用，调用时传什么参数，拿到结果后怎么继续处理。

2. Claude Code 场景里，Skills 为什么不突出

Claude Code 是面向编程任务的专用工具。专用工具的特点是：领域边界清晰、用户类型单一、任务形态稳定、内置能力已经围绕编程深度优化。

在这样的环境里，常见能力可以分成三类。

flowchart LR
    A[开发者需求] --> B{任务类型}

    B -->|快速、明确、低上下文依赖| C[Commands]
    B -->|复杂、需要多轮推理| D[SubAgent]
    B -->|可复用能力包| E[Skills]

    C --> C1[格式化代码]
    C --> C2[生成注释]
    C --> C3[重命名变量]

    D --> D1[前端组件设计]
    D --> D2[API 方案评审]
    D --> D3[复杂重构规划]

    E --> E1[代码审查技能]
    E --> E2[测试生成技能]
    E --> E3[性能分析技能]

Commands：适合快速、确定的操作

Commands 是最直接的能力形式。用户输入一个明确命令，系统立即执行对应动作。

例如：

/format-json
/generate-tests
/explain-error
/review-current-file

这类能力的特点是输入输出非常清楚，不需要复杂的能力抽象。开发者要的是“马上做这件事”，而不是先让 Agent 选择一个技能包，再加载说明，再决定怎么调用。

适合 Commands 的任务通常具备这些特征：

SubAgent：适合复杂、上下文重的任务

SubAgent 更像一个专门负责某类问题的子代理。它可以拥有独立上下文、领域提示词和多轮推理过程。

例如：

• 前端 SubAgent 理解组件结构、状态管理和样式约束；
• 后端 SubAgent 处理接口设计、数据库结构和鉴权逻辑；
• 测试 SubAgent 分析边界条件、异常路径和覆盖率。

这类任务不是“一条命令”能解决的，它需要持续理解上下文，并在多个步骤之间保持推理连贯性。

sequenceDiagram
    participant Dev as 开发者
    participant Main as 主 Agent
    participant Sub as 前端 SubAgent
    participant Code as 代码仓库

    Dev->>Main: 重构这个页面组件
    Main->>Sub: 分析组件结构和依赖
    Sub->>Code: 读取相关文件
    Code-->>Sub: 返回组件、样式、状态逻辑
    Sub-->>Main: 给出重构计划
    Main-->>Dev: 展示方案并执行修改

Skills：夹在中间时容易尴尬

理论上，代码审查、性能优化、测试生成都可以封装成 Skills。但在编程工具里，很多任务会自然落到 Commands 或 SubAgent 上：

Skills 在这里容易变成中间层：没有 Commands 那么直接，也没有 SubAgent 那么深。对程序员来说，额外抽象必须带来明确收益，否则只会增加理解成本。

3. 编程工具不太需要 Skills 的几个原因

3.1 Claude Code 本身就是专用能力集合

专用编程工具已经内置了大量编程相关能力，例如代码理解、文件读取、依赖分析、错误解释、补全和重构。模型和工具链都围绕代码场景优化后，再单独加一层 Skills，不一定能增加多少能力。

这就像在一个已经有成熟 IDE（集成开发环境）的环境里，再把“查找引用”“格式化代码”“跳转定义”包装成一套新插件协议。如果只是当前 IDE 自己用，额外协议的价值并不明显。

3.2 编程任务相对标准化

编程当然复杂，但很多基础动作高度标准化：

• 格式化代码有固定规范；
• 静态检查有成熟规则；
• 测试框架有固定结构；
• 构建、运行、调试有稳定命令；
• 常见技术栈在项目周期内变化不大。

标准化越强，固定命令和专用代理越容易覆盖需求。Skills 适合处理“跨系统、跨场景、需要复用”的能力，如果能力只在一个编程工具内部使用，标准封装层就没那么必要。

3.3 开发者偏好明确的输入输出

程序员通常喜欢可控、透明、可预测的工具链。一个命令能完成的事情，往往不希望绕到一个“技能选择与加载”流程里。

比如格式化 JSON：

jq . data.json

或者在 Agent 工具里：

/format-json data.json

如果这件事被包装成“数据格式化 Skill”，Agent 还要先判断是否选择该 Skill，再加载参数说明，再执行调用。对于简单任务，这就是不必要的间接层。

3.4 个人开发场景缺少大规模复用压力

Claude Code 的典型使用方式是一个开发者在一个项目里持续工作。上下文连续，需求集中，协作边界小。

Skills 的优势来自复用和共享。如果没有多个 Agent、多个团队、多个业务线反复使用同一能力，Skills 的标准化价值就很难体现出来。

4. Agent 平台场景里，Skills 为什么会变重要

当系统从“一个人用的编程助手”变成“企业级 Agent 平台”，问题就完全不同了。

企业里的 Agent 往往要服务销售、客服、运营、财务、法务等多个角色。一个 Agent 可能要同时调用客户关系管理系统 CRM（Customer Relationship Management）、工单系统、知识库、数据仓库、邮件系统和审批流。

这时系统关注的不再是“某个能力能不能做”，而是：

• 多个 Agent 能不能共享同一能力；
• 能力升级时能不能统一发布；
• 不同团队开发的能力能不能互相调用；
• 能力调用有没有统一权限控制；
• 能力质量和版本能不能管理；
• 能不能让第三方开发者贡献能力。

Skills 在这里开始发挥作用。

flowchart TB
    U1[客服 Agent] --> R[Skill Registry]
    U2[销售 Agent] --> R
    U3[运营 Agent] --> R
    U4[数据分析 Agent] --> R

    R --> S1[发送邮件 Skill]
    R --> S2[客户画像 Skill]
    R --> S3[数据可视化 Skill]
    R --> S4[工单创建 Skill]
    R --> S5[情感分析 Skill]

    S1 --> M[邮件系统]
    S2 --> CRM[CRM 系统]
    S3 --> DW[数据仓库]
    S4 --> T[工单系统]
    S5 --> LLM[大语言模型服务]

这个结构里，Skill Registry 是能力注册中心。不同 Agent 不再各自实现一套“发邮件”“查客户”“生成报表”的逻辑，而是通过统一描述和统一接口调用共享能力。

5. 没有 Skills 时，企业 Agent 研发会遇到什么问题

5.1 重复造轮子

假设企业里有三个 Agent：

• 客服 Agent：需要发送邮件、创建工单、查询客户信息；
• 销售 Agent：需要发送邮件、查询客户信息、生成销售报表；
• 运营 Agent：需要发送邮件、生成报表、分析用户行为。

如果没有统一能力封装，每个团队都可能自己实现一遍“发送邮件”和“查询客户信息”。

flowchart LR
    A[客服 Agent] --> A1[发送邮件实现]
    A --> A2[查询客户实现]

    B[销售 Agent] --> B1[发送邮件实现]
    B --> B2[查询客户实现]

    C[运营 Agent] --> C1[发送邮件实现]
    C --> C2[报表生成实现]

这种重复实现有几个后果：

• 接口参数不一致；
• 错误处理不一致；
• 权限控制不一致；
• 日志格式不一致；
• 后续维护要改多处代码。

5.2 能力孤岛

一个团队做出了很好用的“客户画像分析”，另一个团队却用不了，因为两边的 Agent 框架、数据格式和调用协议都不同。

能力不能流动，就会形成孤岛。每个 Agent 都是一个封闭系统，越做越重，越做越难维护。

5.3 维护成本随 Agent 数量增长

第三方系统接口一改，所有直接调用它的 Agent 都要改。一个提示词模板存在缺陷，所有复制过这段逻辑的项目都要排查。

Agent 数量越多，分散维护的成本越高。

使用 Skills 后，维护边界可以收敛到能力层：

flowchart LR
    A[多个 Agent] --> B[客户画像 Skill]
    B --> C[CRM API v1]

    C -.接口升级.-> D[CRM API v2]
    B -.只修改 Skill 内部适配.-> D
    A -.调用方式不变.-> B

Agent 仍然调用同一个 Skill，底层 API 升级由 Skill 内部适配。只要输入输出契约不变，上层 Agent 不需要跟着改。

5.4 团队协作缺少共同语言

多团队开发 Agent 时，大家需要回答这些问题：

• 已经有哪些能力可以复用？
• 每个能力适合什么场景？
• 调用参数是什么？
• 失败时返回什么？
• 谁负责维护？
• 当前稳定版本是哪一个？

Skills 把这些信息标准化后，团队协作就有了共同语言。能力不再是某个项目里的私有代码，而是平台上的可发现、可调用、可治理资源。

6. Skills 的核心机制：上下文工程与按需加载

大语言模型 LLM（Large Language Model）的上下文窗口有限。Agent 不可能在每次对话开始时，把所有工具说明、API 文档、业务规则和示例都塞进去。

Skills 的设计重点是“上下文工程”：让模型在正确的时间看到正确的信息，而不是一开始看到所有信息。

6.1 只暴露摘要，不一次性加载全部细节

Agent 初始只需要知道 Skill 的名称和简要描述：

- name: send-email
  description: 发送邮件，支持收件人、主题、正文和附件。

- name: customer-profile-analysis
  description: 根据客户数据生成客户画像和风险评分。

- name: sales-funnel-chart
  description: 根据销售数据生成漏斗图和阶段转化率。

当模型判断某个任务需要调用 customer-profile-analysis 时，再加载更详细的信息：

• 输入参数；
• 字段类型；
• 权限约束；
• 返回结构；
• 调用示例；
• 常见错误；
• 版本说明。

这个过程叫渐进式披露，也可以叫按需加载。

sequenceDiagram
    participant User as 用户
    participant Agent as Agent
    participant Registry as Skill Registry
    participant Loader as Skill Loader
    participant Skill as 具体 Skill

    User->>Agent: 分析客户 C1024 的流失风险
    Agent->>Registry: 检索可用 Skills 摘要
    Registry-->>Agent: 返回客户画像、风险评分等 Skill 摘要
    Agent->>Loader: 加载客户画像 Skill 详细说明
    Loader-->>Agent: 返回参数、示例、约束
    Agent->>Skill: 调用 customer-profile-analysis
    Skill-->>Agent: 返回画像和风险评分
    Agent-->>User: 生成解释和建议

这样做有两个好处：

1. 上下文不会被大量无关说明占满；
2. 模型在真正需要调用某项能力时，能拿到足够详细的指导。

6.2 Skill 不是简单函数，而是“可被模型理解的能力包”

普通函数面向程序调用，Skill 面向 Agent 决策。它不仅要能执行，还要让模型知道什么时候该用、怎么用、不能怎么用。

对比一下：

Skill 的关键不是“把函数换个名字”，而是把能力变成 Agent 可以发现、理解、选择和调用的资源。

7. Skills 与传统硬编码 Agent 的区别

传统 Agent 开发经常从硬编码开始：遇到什么意图，写什么分支；需要什么能力，直接在 Agent 代码里调用对应接口。

def handle_user_request(intent, payload):
    if intent == "send_email":
        return send_email(payload)
    elif intent == "create_ticket":
        return create_ticket(payload)
    elif intent == "query_customer":
        return query_customer(payload)
    elif intent == "generate_report":
        return generate_report(payload)
    else:
        return fallback(payload)

这种方式在早期很快，但能力越来越多后，Agent 会变成一个巨大单体。每加一个能力都要改核心代码，每改一个接口都可能影响多个流程。

Skills 模式把能力从 Agent 主逻辑中拆出去：

def handle_user_request(user_input):
    task = planner.parse(user_input)

    candidates = skill_registry.search(task)
    selected_skill = planner.select_skill(task, candidates)

    skill_spec = skill_loader.load(selected_skill.name)
    arguments = planner.build_arguments(task, skill_spec)

    result = skill_executor.call(selected_skill.name, arguments)
    return responder.generate(task, result)

架构差异可以这样理解：

这不是说硬编码一定不好。原型阶段直接写分支最快，专用工具里内嵌能力也更直接。Skills 适合的是能力边界开始扩张、复用压力开始出现、协作成本开始上升的阶段。

8. 判断要不要引入 Skills 的四个维度

8.1 能力复用频率

如果一个能力只服务一个 Agent，而且短期内不会被其他场景使用，直接实现通常更合适。

如果同一个能力会被多个 Agent 调用，例如发送邮件、生成报表、查询客户、创建工单，就值得封装成 Skill。

8.2 能力复杂度

简单动作不适合过度封装。

比如“把文本转成小写”：

text.lower()

这类操作封装成 Skill 只会增加调用成本。

复杂能力更适合 Skill，例如“生成客户流失风险报告”可能需要：

1. 查询客户基本信息；
2. 查询历史订单；
3. 查询客服互动记录；
4. 调用风险评分模型；
5. 生成摘要；
6. 输出结构化建议。

这种能力封装成 Skill 后，上层 Agent 只需要面对一个清晰接口。

8.3 协作规模

个人项目、小团队、单一 Agent，沟通成本很低，直接约定即可。

大型团队、多部门、多 Agent 平台需要统一规范，否则能力会快速碎片化。Skills 在这里承担的是工程协作基础设施的角色。

8.4 生态开放性

如果系统只在内部使用，Skills 的生态价值有限，但仍然能解决复用和维护问题。

如果平台希望让第三方开发者贡献能力，Skills 就需要承担“接入协议”的角色。开发者只要遵循规范，就能让自己的能力被平台上的 Agent 调用。

9. 哪些场景适合 Skills

一个典型企业级 Agent 平台可以这样设计：

flowchart TB
    User[用户] --> Gateway[Agent Gateway]

    Gateway --> A1[客服 Agent]
    Gateway --> A2[销售 Agent]
    Gateway --> A3[运营 Agent]

    A1 --> Planner[任务规划器]
    A2 --> Planner
    A3 --> Planner

    Planner --> Registry[Skill Registry]
    Registry --> Loader[Skill Loader]
    Loader --> Executor[Skill Executor]

    Executor --> Auth[权限校验]
    Auth --> Obs[日志与监控]
    Obs --> S1[邮件 Skill]
    Obs --> S2[工单 Skill]
    Obs --> S3[客户画像 Skill]
    Obs --> S4[报表 Skill]

    S1 --> Email[邮件系统]
    S2 --> Ticket[工单系统]
    S3 --> CRM[CRM]
    S4 --> Warehouse[数据仓库]

这个架构里，Skills 不只是调用接口的包装层，还承担了治理职责：

• 权限校验；
• 调用审计；
• 版本管理；
• 失败重试；
• 限流熔断；
• 文档和示例管理；
• 能力检索和推荐。

10. 哪些场景不适合 Skills

10.1 原型验证阶段

产品方向还没确定时，快速验证比抽象设计更重要。过早引入 Skills，容易把时间花在规范、注册、加载和治理上，而不是验证用户是否真的需要这个能力。

原型阶段可以先直接写：

if user_wants_report:
    data = query_data()
    chart = build_chart(data)
    return summarize(chart)

等到报表能力被多个 Agent 复用，再抽成 Skill。

10.2 专用工具开发

如果目标是做一个像 Claude Code 这样的专用工具，且核心能力已经围绕某个领域深度优化，Commands 和 SubAgent 往往更自然。

10.3 小规模项目

如果项目里只有两三个 Agent，能力数量少，团队也很小，完整 Skills 体系可能是过度工程。

轻量做法是先定义清晰的函数接口和文档，把未来可能复用的能力整理出来，不必一开始就做完整的注册中心、版本系统和生态协议。

10.4 极端性能敏感场景

Skills 会引入额外步骤：

• 检索候选 Skill；
• 加载 Skill 说明；
• 生成调用参数；
• 执行统一权限和日志逻辑；
• 通过标准执行器调用。

大多数业务场景可以接受这些开销，但如果系统对延迟非常敏感，例如毫秒级交易链路，就要谨慎评估。高频、简单、确定的调用可以保留为直接 API，不一定经过 Agent 和 Skills。

11. 设计 Skills 时容易踩的坑

11.1 粒度过细

如果每个小函数都封装成 Skill，Agent 会面对大量候选能力，选择成本上升，上下文也会被污染。

不合适的拆法：

parse-date Skill
format-date Skill
validate-date Skill
convert-timezone Skill

更合适的拆法：

date-time-processing Skill

这个 Skill 内部再提供日期解析、格式化、校验和时区转换能力。

11.2 粒度过粗

如果一个 Skill 什么都能做，Agent 很难判断它到底适合什么任务。

不合适的描述：

name: business-helper
description: 处理各种业务问题。

更好的描述：

name: customer-risk-analysis
description: 根据客户信息、订单记录和服务互动记录，评估客户流失风险并生成原因解释。

Skill 的边界要清楚，描述要具体。

11.3 只封装调用，不写约束

Agent 调用能力时，最怕“能调用，但不知道不能怎么用”。

Skill 说明里至少要写清：

• 谁可以调用；
• 需要哪些权限；
• 输入字段有哪些限制；
• 是否允许访问敏感数据；
• 失败时会返回什么；
• 是否有调用频率限制；
• 是否会产生外部副作用，例如发邮件、建工单、扣库存。

11.4 缺少版本管理

Skill 一旦被多个 Agent 使用，就不能随意改输入输出结构。

推荐使用语义化版本：

name: customer-profile-analysis
version: 2.1.0
compatibility:
  deprecated_versions:
    - 1.0.0
  breaking_changes:
    - "risk_score 从整数百分制改为 0~1 浮点数"

破坏兼容的修改要走新版本，旧版本保留一段迁移期。

11.5 没有观测能力

Skill 被调用后，需要知道：

• 谁调用了它；
• 调用了多少次；
• 平均耗时是多少；
• 失败率是多少；
• 失败原因是什么；
• 哪些 Agent 依赖它；
• 哪个版本仍在被使用。

没有这些数据，Skill 规模变大后很难治理。

12. Skills 后续会往哪些方向演进

12.1 智能推荐

当 Skill 数量变多后，Agent 不能只靠关键词匹配选择能力。更好的方式是结合语义检索、历史调用效果和任务上下文，推荐最合适的 Skill。

flowchart LR
    A[用户任务] --> B[语义理解]
    B --> C[Skill 向量检索]
    B --> D[权限过滤]
    C --> E[候选 Skill]
    D --> E
    E --> F[效果排序]
    F --> G[选择最合适的 Skill]

12.2 组合与编排

复杂任务通常不是一个 Skill 能完成的。Agent 需要把多个 Skills 组合成工作流。

例如“给高风险客户生成挽留方案并通知客户经理”：

flowchart TD
    A[输入客户 ID] --> B[客户画像 Skill]
    B --> C[风险评分 Skill]
    C --> D{是否高风险}
    D -->|否| E[返回低风险说明]
    D -->|是| F[挽留方案生成 Skill]
    F --> G[邮件 Skill]
    G --> H[通知客户经理]

这要求 Agent 具备规划能力，也要求 Skills 的输入输出格式足够稳定，方便串联。

12.3 质量保证

开放生态中，Skill 数量越多，质量越需要治理。平台需要提供：

• 自动化测试；
• 沙箱执行；
• 安全扫描；
• 权限审核；
• 调用评分；
• 版本回滚；
• 灰度发布。

否则能力市场会变得不可控。

12.4 多模态 Skills

早期 Skills 多数围绕文本和 API 调用。更完整的 Agent 平台还会需要：

• 图像理解 Skill；
• 语音识别 Skill；
• 视频摘要 Skill；
• 文档解析 Skill；
• 图表生成 Skill；
• 多模态检索 Skill。

这会要求 Skill 描述协议支持文件、图片、音频、视频等输入输出类型。

12.5 安全与权限控制

Skill 可以访问外部系统，也可能产生真实业务动作。安全机制必须放在核心位置。

尤其是这些能力：

• 发送邮件；
• 创建订单；
• 修改客户信息；
• 发起审批；
• 查询敏感数据；
• 调用付费接口；
• 执行代码。

权限不能只靠模型“自觉遵守”，需要在 Skill 执行层做强约束。

13. 选型结论

Skills 的价值高度依赖场景。

在 Claude Code 这类专用编程工具里，用户需求集中在代码任务上，Commands 足够处理快速操作，SubAgent 适合复杂推理，Skills 夹在中间不一定能带来明显收益。

在企业级 Agent 平台里，问题变成了能力复用、跨团队协作、版本治理、权限控制和生态扩展。Skills 把分散能力封装成标准化资源，让多个 Agent 可以像调用公共基础设施一样使用它们。

可以用一张表快速判断：

一句话概括：专用工具追求直接，平台系统追求复用；单点能力靠函数和命令，多 Agent 生态需要 Skills。