同样用大模型，为什么有的团队替代了半个部门，有的只能写写文案？关键在 Skills

星浩AI
0 阅读12分钟

大模型已经很聪明了，为什么还要多出一层叫 Skills 的东西？

一、导读

大模型很聪明，但落地时常常卡在三点：缺稳定流程（输出难复现）、缺领域常识（行规与红线难约束）、缺上下文管理（规则塞进 Prompt 又贵又难维护，每次重说又易漏）。

skill-1.png

Skills 要解决的，就是把「聪明却依赖每次口述规则」收拢成可复用、可约束、可沉淀的「业务拍档」。

二、三个阶段：从只会聊，到会调用工具，再到会规划执行

为了看清楚 Skills 的价值，我们先粗暴地把大模型在企业里的应用分成三个阶段。

skill-2.png

1. 聊天助手：聪明，但只会「跟着聊」

这是最早大家接触大模型的样子：

  • 你问，它答；你给它一点上下文，它会沿着你的话往下推；
  • 写文案、润色、翻译、解释概念，只要问题问得清楚，结果一般还不错。

但问题是：

  • 它不会主动规划流程：不会告诉你「这件事应该先干 A 再干 B」；
  • 它不会自己记流程：今天告诉它的经验，下次还得从头教；
  • 它不会稳定复现：换一轮对话，同样的问题可能给出完全不同的展开方式。

适合场景：临时问答、灵感碰撞、个人效率提升。
不适合场景：有明确 SOP、需要长期稳定执行的业务流程。

2. 「有手有脚」的工具调用者：能执行，但不会总结经验

后来我们给大模型接上了各种工具：

  • Function Calling / Tools / MCP ……
    它可以：
    • 查数据库、调 HTTP API、读写文件系统；
    • 用脚本去做自动化处理；
    • 把外部世界的数据拉回模型世界里分析。

这一层的本质是：
让模型「能真正调用外部工具与数据」，不再只是嘴上说说。

但新问题又来了：

  • 工具说明写在 System Prompt 里，内容一多就「上下文爆炸」；
  • 工具接口变更、文档更新，Prompt 很难跟着维护；
  • 不同项目、不同团队之间，很难复用同一套「工具使用经验」。

模型开始会「干活」，但还停留在临时工 + 手工管理工具手册的阶段。

3. 能规划、能执行，但规则每次都要重讲

当我们有了 Agent SDK / Agent 框架之后，事情进一步升级：

  • Agent 能感知一个固定的运行环境（代码仓库、数据库、文件系统等）；
  • 能把复杂需求拆成多步：规划 → 执行 → 校验 → 调整；
  • 能在一个较长的对话/任务生命周期内保持上下文。

听起来已经很接近「数字员工」了，但仍有三个关键缺口：

  1. 缺流程：没有一份稳定的 SOP 去约束它「每次应该怎么干」；
  2. 缺行规：不懂你所在行业/团队的「潜规则」和合规边界；
  3. 缺经验沉淀：一个项目踩过的坑，不会自动转化为下一次的约束和优化。

综合以上痛点，把规则写进一份可复用的「操作手册」，让 Agent 按需读取、在不同任务里反复用。
这，就是 Skills。

三、Skills 到底是什么？

可以这样理解 Agent Skills：

Skills 是包含指令、脚本与资源的技能包。 Agent 可以发现并按需加载它们，从而更准确、更高效地完成特定任务；

skill-3.png

  • 行为规范：写清楚「应该怎么做、不能怎么做」（流程、约束、输出格式）；
  • 专业知识：沉淀「这个领域/团队的行规、模板、示例」（参考资料、脚本）；
  • 使用时机：通过元数据（name + description）让 Agent 自动判断「什么时候该用这个 Skill」。

这三者打包成一个模块化的 Markdown 文件（SKILL.md），能教会各类 AI 工具、智能体与大模型在特定场景下按你的方式做事，且支持自动触发、团队共享与工程化管理——彻底告别重复的提示词输入。一句话：Skills 就像给 AI 的一本专业手册，按需查阅、按章执行，不必每次都从零学起。

核心形式

一个 Skill 的核心形式很简单：

  • 一个 Skill = 一个文件夹
  • 必须包含：SKILL.md 文件（包含说明和元数据）
  • 可选包含：其他资源文件（如脚本、示例、参考文档）

Skill 的核心就是一个 Markdown 文件（SKILL.md），用于教 AI 在特定场景下按你的方式做事。其他资源文件（脚本、示例等）是可选的，按需添加。

一个 Skill 在磁盘上通常就是一个文件夹，里面大致会有这几类东西：

组成部分说明
SKILL.md（必须）技能的核心文件：前半段是元数据（YAML 块，至少包含 name 和 description），后面是给 Agent 看的指令、步骤和约束（用什么、怎么做、注意什么）。这是整个 Skill 的「专业手册」。
脚本（可选）可执行的代码（如 .py、.sh），用于数据处理、格式转换、调用外部 API 等，由 Agent 在需要时按说明调用。
示例 / 参考文件（可选）模板、示例输出、补充说明文档等，放在同一目录或子目录里，按需被读取，不在一开始全部塞进上下文。

这种结构带来的好处就是：先看元数据，需要时才读 SKILL.md 和脚本，用完可释放。

3.1 一个最小可用的 Skill 目录长什么样？

下面是一个「最小可用」但足够工程化的 Skill 目录示例（你可以把它当成模板来复用）：

enterprise-report/
├── SKILL.md
├── scripts/
│   ├── fetch_data.py          # 拉数 / 调 API
│   └── validate_output.py     # 校验输出结构与合规项
└── references/
    ├── style_guide.md         # 写作口径 / 风格规范
    └── examples/
        ├── input_example.md   # 示例输入
        └── output_example.md  # 示例输出

你会发现它没有任何神秘的地方：就是文件夹 + 文档 + 脚本 + 参考资料。这也是 Skills 容易被团队沉淀和复用的原因——天然适配 Git，适配协作，且便于持续迭代。

更重要的是，这种结构带来的三个特性：

  • 自动触发：Agent 通过元数据自动判断任务是否相关，无需人工指定「现在用哪个 Skill」；
  • 团队共享：一份 Skill 写好，全团队可用；放在 Git 仓库里，版本可控、协作顺畅；
  • 工程化管理：文件夹结构清晰、文档与脚本分离、支持持续迭代，告别「把规则塞在 Prompt 里」的散装管理方式。

3.2 SKILL.md 里通常写什么？

一个常见的 SKILL.md 结构是「元数据 + 指令正文」。下面是一个示意片段（仅用于说明写法）：

---
name: enterprise-report
description: 在用户需要生成正式报告/合规文档时使用。自动拉取数据、套用写作规范并输出可审计结果。
---

# Enterprise Report

## Workflow
1. 读取 references/style_guide.md，确定口径与合规约束。
2. 调用 scripts/fetch_data.py 拉取必要数据（必要时重试）。
3. 生成报告草稿，并显式标注数据来源与风险提示。
4. 调用 scripts/validate_output.py 校验格式与合规项；若失败，修正后再输出。

## Output format
- 输出为 Markdown
- 摘要 ≤ 300 字
- 末尾必须包含「风险提示」

这里的重点不是「写得多漂亮」，而是：把规则写清楚、把步骤写清楚、把可执行的部分交给脚本。

3.3 SKILL.md 元数据：先把两个核心字段写对

上面的示例只用了最核心的 name、description，其实在官方规范里，元数据字段远不止这两个，还包括触发条件、可见性、可用工具、生命周期钩子等一整套配置项。

但在入门阶段，你只要把 name 和 description 写对，就已经能支撑 80% 以上的场景：

  • name：用小写字母 + 数字 + 短横线，起一个语义清晰、便于检索的名字（比如 python-naming-standard），最好能一眼看出做什么。
  • description：一句话说清「在什么任务 / 场景下应该启用这个 Skill」，这是 Agent 自动选择技能时最重要的判断依据之一。

其他更工程化的字段（比如 argument-hint、user-invocable、allowed-tools、hooks 等），主要用于控制「谁能调、怎么出现在 UI 里、能用哪些外部工具、执行前后要不要挂钩子」，我们会在后面的「设计与工程篇」单独拆一篇详细讲解，这里先建立直觉就好。

3.4 Agent Skills 的工作原理：三层渐进式加载

Agent Skills 的关键是 渐进式披露（Progressive Disclosure）：不一次性把所有 Skill 的细节塞进上下文，而是分三层、按需加载。

层级名称做什么何时加载
1技能发现读取所有 Skill 的元数据（name + description），判断任务是否与某个技能相关。元数据常驻在系统提示中，体量小、可长期保留。
2加载核心指令若判定相关，自动读取该 Skill 的 SKILL.md 正文，获取流程、约束与输出要求。仅在与该 Skill 相关时加载。
3加载资源文件读取额外文件（如 references/ 下的示例、模板），或通过工具执行脚本（如 scripts/ 下的 .py、.sh）。只在执行过程中需要时才加载，用完可释放。

这样 Agent 既能挂载大量 Skill，又不会撑爆上下文窗口，成本和可维护性都更可控。

skill-4.png

用一个比喻来理解。还记得查《新华字典》时的「部首检字法」吗？

  • 你不会把整本字典背下来，只会记住「怎么查字」；
  • 真正需要查某个字时，才翻到对应页，看清楚释义；
  • 用完就合上书，不会一直把整本字典塞在脑子里。

Skills 的设计思路和这很像：先发现（层级 1）→ 再读手册（层级 2）→ 按需用资料和工具（层级 3）。这就是渐进式披露。

换个角度，Skills 就像给 AI 代理发放的专业手册：手册里写好了「这个场景应该怎么做、用什么资源、注意什么边界」，Agent 不会每次都从零学习，而是根据任务自动调用手册中的知识。这样既避免了「每次都要重新教一遍」，又保证了「每次都按同一套标准执行」。

3.5 动态变量：先知道有这回事就够了

除了结构和元数据，Agent Skills 规范还提供了一组动态变量，可以在 SKILL.md 里引用「当前调用传入的参数数组」「当前会话的唯一 ID」之类的信息，用来做日志、审计或更精细的输出控制。

你可以先简单记住两件事：

  • 可以拿到调用时传入的参数（比如做轻量的参数检查、拼接输出）；
  • 可以拿到当前会话 ID（比如为每个会话写独立日志文件，方便排查问题）。

这些动态变量如何完整使用、如何组合出「会话级日志 Skill」「操作审计 Skill」等高级玩法，我们会在第 3 篇的工程实践里配合具体目录结构和示例一并展开，这里只埋个钩子，让你知道 Skill 不是死板的文案，而是可以「读参数、读环境」的。

四、Skills 带来的三个核心价值

从落地角度看，Skills 能同时带来三类很实在的价值。

skill-5.png

1. 准确性：让输出可预期、可复现

  • 没有 Skills：同一类任务，每次依赖模型「即兴发挥」，风格和细节难以统一；
  • 有 Skills：SOP 和约束写在 SKILL.md 里，模型被引导按固定流程和规范执行，结果更稳定、可审计。

典型场景：报告格式、邮件措辞、代码审查 checklist…… 凡是「有行规」的任务，用 Skill 固化下来，比靠 Prompt 随口叮嘱要可靠得多。

2. 安全性：把合规和边界写进流程

  • 没有 Skills：容易出现「模型不知道不该说什么、不该做什么」的情况，需要人在事后纠错；
  • 有 Skills：可以把「禁止用语」「必须标注数据来源」「必须附风险提示」等要求写进 Skill，让模型在生成过程中就遵守。

对金融、医疗、法务等强合规场景，Skills 相当于给 Agent 装上了一本「红线手册」。

例如在合规文档生成里，你可以把「禁止绝对化表述」「必须标注数据来源」「必须附风险提示」写进 Skill，并配套一个 validate_output.py 在落盘前做检查。这样合规性不再靠“记得提醒”，而是靠流程保证。

3. 成本效率：少浪费 Token，多复用经验

  • 没有 Skills：要么把所有工具说明、业务规则塞进 System Prompt（上下文爆炸、贵且难维护），要么每次对话重新口述（重复消耗、且容易漏）；
  • 有 Skills：轻量元数据常驻，详细内容按需加载；同一份 Skill 可以在多个项目、多个对话中复用，经验沉淀一次，处处生效。

从 TCO（总拥有成本）看，Skills 是在用「结构化的知识资产」换「每次对话的 Token 与维护成本」。

一个常见的降本方式是把长规范放到 references/：平时只加载元数据；只有在命中某个技能时才读取那份规范。相比把整份规范常驻在 System Prompt 里，这种「按需读取」的架构性节省非常可观。

五、小结

下面用一张表，把大模型在企业中的三种形态收束一下：每种形态能干什么、短板在哪、Skills 究竟补在谁身上。

skill-6.png

形态能力概括主要短板Skills 的作用
聊天助手问答、润色、翻译、解释；你问它答，即兴发挥。不记流程、不主动规划、输出难以复现。不主攻这一档，更适合个人随手用。
工具调用者调 API、跑脚本、读写文件；能把「外面」的数据拉进来用。工具说明堆在 Prompt 里难维护，跨项目难复用。把「怎么用工具、按什么规范用」写成 Skill，按需加载。
会规划的 Agent拆任务、多步执行、感知环境；能规划→执行→校验。缺固定 SOP、缺行规与合规边界、经验无法沉淀。主战场：操作手册 + SOP + 小工具，一次写好、多处复用。

一句话：
大模型已经很聪明了，但「聪明」不等于「能稳定、合规、低成本地完成你公司的具体业务」。Skills 要做的，就是把这层差距补上——让 Agent 从「聪明但散装的对话助手」，变成「值得托付业务的拍档」。

  • Agent Skills 官方标准站点：https://agentskills.io
  • Anthropic 官方工程文章（Agent Skills 实战理念）：https://www.anthropic.com/engineering/equipping-agents-for-the-real-world-with-agent-skills
  • Anthropic 官方 Skills GitHub 仓库：https://github.com/anthropics/skills

下一篇我们会聊：Skills、MCP、SubAgents 在企业里到底该怎么选、怎么组合。如果你有特别想先搞清楚的场景，欢迎在评论区提，我会在后续文章里优先拆解。

avatar
文章
阅读
粉丝