你给 Agent 写了一段 5000 字的系统提示词，它什么都知道，但什么都做不好——问题不在 prompt，在你把所有东西塞进了同一个行李箱。
开篇：一次让我彻底改变思路的失败
去年年底，我们团队做了一个客服 Agent 项目。需求很清晰：接入工单系统、知识库和用户画像，帮一线客服做工单分流、问题诊断和解决方案推荐。
我们的第一版实现方案非常「直觉」——写一个超长的系统提示词，把所有业务逻辑都塞进去。工单分类规则、客服升级策略、产品知识要点、退款审批流程、VIP 客户特殊处理方式……林林总总大概 8000 个 token。
然后我们发现了一个有意思的现象：当用户问简单的 FAQ 时，Agent 表现得非常好。但一旦进入比较复杂的场景——比如需要同时判断工单优先级、查库存、核对退款政策——它的准确率就断崖式下跌。
最初我们以为是模型能力不够，于是换了更强的模型。结果好了一点点，但根本问题没变。
后来有一天，团队里一个工程师说了一句话，让我突然想通了：「这不像是模型不够聪明，更像是它在一大堆信息里迷路了。」
他说得没错。我们把所有能力都塞进了一个巨大的 prompt，模型在处理每一个请求时都要先「扫描」全部上下文，然后决定哪些信息跟当前任务相关。当能力包越来越大，这个「扫描和选择」的过程本身就变成了噪音源。
Anthropic 在谈 context engineering 的时候提到过一个概念叫 context rot——不是上下文越大越好，太多信息反而会稀释模型的注意力，让它在关键处失焦。
我们当时遇到的就是这个问题。
后来的解决方案是：把那个 8000 token 的巨型 prompt 拆成了 6 个独立的「能力包」——工单分类、问题诊断、退款审批、VIP 处理、知识检索、升级决策。每个能力包有自己的指令、依赖的工具和参考资料。Agent 根据当前任务只加载需要的那一两个能力包，而不是每次都背着全部家当。
效果立竿见影。复杂场景的准确率从 64% 提到了 89%。
这就是我理解 Agent Skills 的起点：不是让模型知道更多，而是让它在正确的时刻拿到正确的东西。
一、Agent Skills 到底是什么？
先把定义讲清楚。
Agent Skill 是一个自包含的能力单元，封装了完成某个特定任务所需的全部指令、参考资料和工具依赖。
Google ADK 的官方文档给了一个非常精准的定义：Skill 是 agent 可以按需加载的、自包含的功能单元（self-contained unit of functionality）。它把完成一个任务所需的 instructions、resources 和 tools 打包在一起，并且通过分层结构实现按需加载，尽量减少对上下文窗口的占用。
注意两个关键词：自包含和按需加载。
自包含意味着一个 skill 不依赖另一个 skill 的内部状态。你可以把它从一个 Agent 搬到另一个 Agent，从一个项目搬到另一个项目，甚至从一个公司搬到另一个公司。它是独立的、可移植的。
按需加载意味着 Agent 不需要一次性把所有 skill 的内容都塞进上下文窗口。它先看一眼有哪些 skill 可用（只消耗元数据级别的 token），然后根据当前任务决定加载哪个，再按需拉取具体的指令和资源。
这种设计模式在技术上有一个名字，叫 progressive disclosure（渐进式披露）。在前端设计领域它已经用了很多年，核心思想就是：不要一次性把所有信息倒给用户，而是按需、分层地展现。Agent Skills 把同样的理念用在了 AI 的上下文管理上。
二、一个 Skill 长什么样？
一个 Skill 的物理形态非常简单——就是一个文件夹。
my_skill/
├── SKILL.md # 必须：YAML 前置元数据 + Markdown 指令
├── references/ # 可选：参考文档、术语表、示例
├── assets/ # 可选：模板、schema、配置
└── scripts/ # 可选：可执行脚本
SKILL.md 是核心。它分两部分：
第一部分是 YAML 格式的前置元数据（frontmatter），包含 skill 的名称、描述、触发条件等信息。这部分很轻量，通常只有几十个 token。Agent 在发现阶段只需要读这些元数据，就能判断某个 skill 跟当前任务是否相关。
第二部分是 Markdown 格式的指令正文，描述这个 skill 被激活后 agent 应该怎么工作。这部分可能会比较长，但只有在 skill 被真正激活时才会被加载。
举一个具体的例子——一个「指标归因分析」skill：
---
name: metric-attribution-skill
description: 当某个业务指标出现异常波动时，自动拉取分维度数据，输出可能原因与验证路径。
triggers:
- 指标异常
- 归因分析
- 为什么下降/上升
---
# 指标归因分析
## 第一步：确认异常指标
从用户的描述中提取指标名称、时间范围和异常方向（上升/下降）。
## 第二步：拉取分维度数据
调用 `query_metrics` 工具，按以下维度分别查询：
- 地区
- 渠道
- 产品线
- 用户群体
## 第三步：定位主因维度
比较各维度的贡献度变化，找出贡献最大的 1-2 个维度。
## 第四步：生成归因报告
参考 `references/attribution_template.md` 的模板格式输出报告。
你看，这就是一个 skill。没有什么黑科技。它本质上就是一份结构化的、可以被 agent 理解和执行的工作说明书。
三、Skill 和 Tool 的区别是什么？
这是一个我被问过无数次的问题。很多人分不清 Skill 和 Tool 的边界。
一句话讲清楚：Tool 是一个函数调用，Skill 是一套工作流程。
Tool 解决的是「怎么做一个动作」——查数据库、调 API、发邮件、读文件。它是原子性的、无状态的、单步的。
Skill 解决的是「怎么完成一个任务」——它可能包含多步骤的逻辑、判断条件、依赖多个 tool、需要参考资料、有特定的输出格式要求。
举个例子：
- Tool：
query_database(sql)—— 执行一条 SQL 并返回结果 - Skill：「采购建议生成」—— 先查库存水平，再查销售趋势，再查供应商交期，然后综合判断是否需要补货、补多少、向谁买，最后按模板输出一份采购建议
Skill 内部会调用多个 tool，但 skill 本身不是 tool。它是一种更高级的抽象——它封装的不是一个函数，而是一段业务知识。
Anthropic 的工程团队在谈 Agent 架构时有一个很重要的建议：不要急着做 Agent，先做 Skills。 他们的意思是，与其一上来就搞一个能自主规划、自主执行的 Agent，不如先把业务逻辑拆成一个个独立的 skill，让 Agent 在可控的范围内调用这些 skill 来完成任务。这样更稳定、更可审计、也更容易迭代。
四、为什么 Skills 现在突然火了？
Agent Skills 作为一个概念并不新。但它在 2025 年底到 2026 年初突然成了 AI 工程领域最热的话题之一。这背后有几个结构性的原因。
4.1 Agent 进入生产环境后，prompt 膨胀成了普遍问题
当 Agent 只是做 demo 的时候，一个几千 token 的 prompt 就够了。但当它进入生产环境，要处理的场景越来越多，每个场景的规则越来越细，prompt 就开始不可控地膨胀。
我见过最夸张的是一个内部知识助手的 system prompt，光纯文本就有 3 万多 token——各种规则、模板、示例、异常处理、格式要求，全塞在一起。结果模型的表现反而不如早期简单版本。
Skills 的按需加载机制从根本上解决了这个问题。你可以有 50 个 skill，但每次对话只加载 1-2 个。上下文窗口始终保持精简。
4.2 行业标准正在快速收敛
2025 年底 Anthropic 公开了 Agent Skills 的标准规范（agentskills.io），并把它做成了开放标准。这个规范出奇地简单——就是 Markdown 文件加上 YAML 元数据，加上可选的 references、assets、scripts 目录。
然后事情就像推倒了多米诺骨牌一样：
- Google ADK 采纳了同样的规范，通过 SkillToolset 类在 ADK 中原生支持 Skills
- OpenAI 的 Codex CLI 和 ChatGPT 支持了
/home/oai/skills目录 - GitHub Copilot 通过
.github/skills目录支持项目级别的 skill 加载 - Cursor、Windsurf、Gemini CLI 等编码工具纷纷跟进
- Vercel 推出了 skills.sh，一个 skill 目录和排行榜，上线后迅速积累了超过 2 万次安装
- dbt Labs 发布了 dbt agent skills，把 dbt 的最佳实践打包成 skill 供编码 Agent 使用
一个开放标准能在半年内被这么多头部厂商同时采纳，这在 AI 领域是很少见的。它说明这个抽象击中了一个真实的、普遍的工程痛点。
4.3 企业开始意识到「能力资产化」的价值
这是我认为最深层的原因。
过去企业的 know-how 散落在各种地方：某个老员工的脑子里、某份飞书文档里、某个 SQL 脚本里、某个审批流程的按钮背后。当这个老员工离职了、文档过期了、脚本跑不动了，这些 know-how 就丢了。
Agent Skills 提供了一个把这些隐性知识变成显性能力包的标准化方式。你不是在写 prompt，你是在封装一个可以被反复调用、可以被审计、可以被版本管理、可以被传承的业务能力。
这才是 Skills 真正的价值——它改变的不是 Agent 怎么工作，它改变的是企业怎么管理自己的智力资产。
五、三层加载机制：为什么 Skills 比长 prompt 高效
Skills 的技术核心是它的三层渐进加载（progressive disclosure）机制。理解这个机制，你就理解了为什么它比直接写长 prompt 好。
L1：元数据层（Discovery）
Agent 启动时，只读取每个 skill 的 YAML frontmatter——名称、描述、触发条件。这一层的 token 开销极小，通常每个 skill 只有 20-50 个 token。就算你注册了 50 个 skill，这层的总开销也不到 2500 token。
Agent 拿到这份「能力清单」后，就知道自己有哪些本事。但此刻它不知道每个本事的具体细节——就像你知道自己有一本《高级 Python 编程》放在书架上，但你没翻开它。
L2：指令层（Activation）
当用户的请求匹配到某个 skill 的触发条件时，Agent 加载这个 skill 的完整指令。这是 SKILL.md 文件的 Markdown 正文部分。通常几百到几千 token。
此刻 Agent 知道了「怎么做」，但还没拿到具体的参考资料。
L3：资源层（Execution）
在执行过程中，如果需要查阅参考文档（references/）、使用模板（assets/）、或运行脚本（scripts/），Agent 再按需加载。
这种分层机制带来的好处是数学级别的。假设你有 20 个 skill，每个 skill 的完整内容是 3000 token。如果全塞进 prompt，就是 6 万 token。但用三层加载，每次对话实际消耗的可能只有 3000-6000 token——因为你只加载了 1-2 个相关的 skill。
这不只是省钱的问题。更重要的是，模型的注意力集中了。 它不需要在 6 万 token 的噪音里找关键信息，它眼前只有跟当前任务最相关的那份指令。
六、从开发场景到企业业务场景：Skills 的两种用法
目前 Agent Skills 的应用主要分两个方向，一个已经非常成熟，另一个正在快速发展。
6.1 开发者场景：让编码 Agent 更专业
这是当前 Skills 应用最成熟的领域。
一个典型的场景：你在用 Claude Code 写 ADK 项目，但 ADK 是 2024 年底才发布的新框架，模型的训练数据里没有足够的 ADK 知识。于是你安装一个 ADK skill，它包含了 ADK 的正确 import 方式、项目结构规范、常见设计模式、API 用法等信息。安装之后，Agent 生成的 ADK 代码质量显著提升——从「看起来像但跑不起来」变成「可以直接复制粘贴」。
dbt Labs 发布的 dbt agent skills 也是同样的逻辑。它把 dbt 的最佳实践——怎么探索数据、怎么写模型、怎么做测试、怎么用 Semantic Layer——打包成了 skill。安装之后，编码 Agent 在做 dbt 相关工作时就不再依赖过时的训练数据，而是用的最新、最官方的实践指导。
这个方向的 skill 生态正在爆发式增长。GitHub 上已经有大量的 awesome-agent-skills 类的整理，Vercel 的 skills.sh 目录也在快速扩展。
6.2 企业业务场景：把 know-how 变成可调用的能力
这是我个人认为 Skills 更有想象空间的方向。
回到我在直播分享中经常讲的观点：企业真正长期值钱的，不只是知识库，而是被封装出来的业务能力。
什么是业务能力？举几个例子：
- 指标归因 skill：某个指标异常波动时，自动拉取分维度数据，输出可能原因和验证路径
- 订单异常诊断 skill：综合订单状态、履约日志、客服记录和库存信息，判断异常源头
- 采购建议 skill：根据库存、销售趋势、促销计划和供应商交期，生成补货建议
- 客服分流 skill：对工单做初步判断，决定是否转专家、转质检还是走标准流程
- 报告生成 skill：先拉数、再分析、再按模板生成管理者能读的版本
这些能力今天散在不同人的脑子里、不同的 SOP 文档里、不同的脚本里。它们没有被标准化，没有被版本管理，没有被评测过。
当你把它们封装成 skill，事情就不一样了：
- 可复用：任何 Agent 都可以加载这个 skill，不需要重新教
- 可审计：skill 的逻辑是透明的，任何人都能看到它是怎么工作的
- 可版本化：业务逻辑变了，更新 skill 文件就行，Git 有完整的变更历史
- 可评测：你可以给每个 skill 建一套测试集，定期跑评测看效果有没有退化
- 可治理：哪些 Agent 加载了哪些 skill，一目了然
这就是 AI 时代的资产观变化：从沉淀文档，到沉淀 skill。
七、Skill 工程：怎么设计一个好的 Skill
写一个 skill 很容易。写一个好的 skill，需要一些工程思维。
7.1 单一职责
一个 skill 应该只做一件事。「客服全能助手」不是一个好 skill；「工单分流」是一个好 skill。粒度太大，模型容易迷失；粒度太细，管理成本过高。经验法则是：一个 skill 对应一个你能用一句话描述清楚的任务。
7.2 明确边界条件
好的 skill 不只说「怎么做」，还说「什么时候不该做」。比如，退款审批 skill 应该明确说：超过 5000 元的退款必须转人工，不能自动审批。这些边界条件是 skill 安全性的关键。
7.3 自带评测锚点
每个 skill 最好附带一些「预期输入-预期输出」的示例。这些示例不仅帮助模型理解任务，更重要的是可以作为自动化评测的基线。当你更新了 skill 的逻辑，跑一遍这些示例，就知道有没有退化。
7.4 分层组织资源
把核心逻辑放在 SKILL.md 的指令正文里，把参考文档放在 references/，把模板和 schema 放在 assets/。不要把所有东西都塞进一个文件。分层的好处是：Agent 可以按需加载，不需要的东西不占上下文。
7.5 写给模型看，也写给人看
Skill 的指令不只是 prompt——它也是一份内部文档。新同事来了，看一遍 skill 目录，就知道这个团队有哪些已经标准化的能力。写 skill 的时候保持清晰的步骤编号、明确的条件判断、具体的工具调用说明。模型能理解，人也能理解。
八、Skill 的安全问题：不能忽视的另一面
在兴奋地讨论 Skills 的同时，有一个安全问题正在被研究者关注：skill 文件本身可能成为 prompt injection 的攻击面。
2025 年有一篇研究论文标题就叫「Agent Skills Enable a New Class of Realistic and Trivially Simple Prompt Injections」。它的核心发现是：当 Agent 从外部加载 skill 文件时，如果这个 skill 文件被恶意篡改（比如在 instructions 中嵌入了隐藏指令），Agent 可能会执行非预期的操作。
这不是杞人忧天。在一个企业环境中，如果 skill 的分发渠道没有被妥善管理——比如从未经审核的开源仓库直接安装——风险是真实存在的。
应对策略包括：
- Skill 来源管控：只从受信任的仓库或内部注册中心加载 skill
- 内容审核：skill 文件在安装前需要经过代码审查，跟代码审查一样
- 权限最小化：每个 skill 只能访问它需要的工具和数据，不能越权
- 运行时监控：监控 skill 执行过程中是否有异常行为
Vercel 的 skills.sh 目录已经开始做两层安全扫描。这个方向会越来越重要。
九、Self-Extending Agent：Skill 的终极形态
讲到最后，我想说一个让我非常兴奋的方向：Agent 自己写 Skill。
Google 开发者博客最近发了一篇文章，介绍了一种叫 skill factory 的模式：你给 Agent 一个「元 skill」（meta skill），这个元 skill 的作用是教 Agent 怎么写新的 SKILL.md 文件。于是 Agent 就变成了一个可以自我扩展的系统——遇到新任务时，它可以自己创建一个 skill，然后在后续的工作中复用。
这意味着什么？意味着 Agent 的能力不再是静态的。它可以从工作经验中不断沉淀新的 skill，就像一个人从新手成长为专家的过程。
当然，这个方向目前还很早期，有很多质量和安全问题需要解决。生成的 skill 需要经过人工审核才能进入生产环境。但方向是明确的：Skill 不只是人写给机器的指令，它也可以是机器从经验中提炼的知识。
十、未来展望：Skill 经济正在成型
最后说几个判断。
第一，Skill 会成为 AI 时代新的「包管理」概念。 就像 npm 管理 JavaScript 包、pip 管理 Python 包一样，未来会有成熟的 skill 注册中心、版本管理、依赖解析和安全扫描。skills.sh、agentskills.io 这些项目已经在铺路了。
第二，企业内部的 skill 库会成为核心竞争力。 模型是通用的，tool 是标准的，但 skill 是你独有的。你的「指标归因 skill」里沉淀的是你们公司特有的业务逻辑和判断经验，这个东西别人买不到。
第三，Skill Engineering 会成为一个新的工程角色。 就像过去十年出现了 Data Engineer、ML Engineer、Platform Engineer 一样，未来会出现专门做 Skill Engineering 的人——他们既懂业务流程，又懂 AI 工程，擅长把隐性的专家经验封装成可靠的、可评测的、可治理的 skill。
Fortune 最近一篇文章的观点我很认同：未来最有价值的开发者，是那些能把人类专业知识拆解成可复用的 Agent Skills 的人。 他们不是被 AI 替代的人，而是教 AI 怎么工作的人。
写在最后
回到开篇的那个客服 Agent 项目。
当我们从「一个巨型 prompt」切换到「6 个独立 skill」之后，不只是准确率提升了。更让我意外的是：整个团队的协作方式变了。
以前修改业务逻辑，需要改一个 8000 token 的 prompt，每次改动都像在做一次全身手术，牵一发动全身。现在修改某个能力，只需要改对应的 skill 文件，其他 skill 完全不受影响。
以前有新场景要支持，需要把新逻辑硬塞进已经很臃肿的 prompt 里，祈祷不要打坏已有的功能。现在直接写一个新 skill，挂载上去就行。
以前老员工离职，他脑子里的判断逻辑就丢了。现在那些逻辑沉淀在 skill 文件里，Git 有完整历史，新人来了打开 skills 目录看一遍就知道这个团队已经积累了哪些能力。
所以我现在越来越坚定地相信一件事：
在 AI 时代，企业最值得投资建设的，不只是模型能力和知识库，还有一套可复用、可审计、可持续演进的 Skill 体系。
Skill 不是一个技术热词。它是企业 know-how 的新载体。
参考资料：
- 1. Google ADK, Skills for ADK Agents documentation (2026)
- 2. Anthropic, Agent Skills specification (agentskills.io, 2025-2026)
- 3. Anthropic, "Don't Build Agents, Build Skills Instead" (2025)
- 4. Anthropic, "Lessons from Building Claude Code: How We Use Skills" (2026)
- 5. Google Developers Blog, "Developer's Guide to Building ADK Agents with Skills" (2026)
- 6. dbt Labs, "Make your AI better at data work with dbt's agent skills" (2026)
- 7. Vercel, skills.sh directory and agent-skills repository (2026)
- 8. "Agent Skills Enable a New Class of Realistic and Trivially Simple Prompt Injections" (2025)
- 9. GitHub, awesome-agent-skills curated list (skillmatic-ai, 2026)
- 10. Spring AI, "Agent Skills - Modular, Reusable Capabilities" (2026)
作者是一名长期从事 Data + AI 系统落地的架构师，关注数据工程、上下文工程、Agent 系统和企业级 AI 治理。欢迎讨论交流。
