很多人在评估 AI agent 平台时，都会卡在一个问题上：给智能体一个 tool，和给它一个 skill，到底有什么区别？
最短的答案是：tool 让智能体做一件事，skill 教智能体在真正行动之前，该怎么想。这听起来像学术区别，直到你亲眼看到一个挂了 58 个工具的 agent，在处理第一条用户消息之前，就已经烧掉 55,000 tokens 的上下文。这个数字来自 Anthropic 的工程团队，也正是行业后来全面转向 skills 的原因。
本文会讲清 AI agent skills 到底是什么，它和 tools、plugins 的边界在哪，skill 被激活时底层发生了什么，以及你该如何判断一个平台的 skills 架构到底是“可上生产”，还是只是市场文案。
什么是 AI Agent Skill？
AI agent skill，本质上是一种模块化能力包：它通常是一个文件夹，里面放着 instructions、scripts 和 reference materials，用来教智能体如何处理某个专门领域的问题。你可以把它想成一本训练手册：需要的时候拿起来，用完再放下。
比如，一个用于财务报告的 skill，可能会包含：
- 如何组织 executive summary 的说明
- 一个从会计 API 拉数据的脚本
- GAAP 格式规范的参考材料
- 关于哪些结论必须带 citation 的 guardrails
智能体并不会一直背着这些知识走。它只会在任务需要时，把这个 skill 加载进来。
Anthropic 在 2025 年底把这个概念正式化，推出了 Agent Skills 标准。格式刻意做得很简单：一个带 YAML metadata 的 SKILL.md，外加可选的 scripts/、references/、assets/ 子目录。标准发布几周内，OpenAI、Google、GitHub、Cursor 等都采用了同类格式。到 2026 年初，它已经基本成了事实标准。
它之所以有力量，正因为它足够简单。Skill 是一个 markdown 文件，不是什么数据库 schema，也不是什么编译后的二进制。只要你能写清楚说明，就能做出一个 skill。
Skills、Plugins、Tools 到底怎么区分
这三个词经常被混着讲，但它们其实在完全不同的架构层级上解决不同问题。
| Tools | Skills | Plugins | |
|---|---|---|---|
| 它是什么 | 一个执行动作的原子函数 | 改变 agent 处理问题方式的知识包 | 一个用于安装分发的打包单元，里面可以包含 skills、tools、configs |
| 抽象层级 | 最低：单次操作 | 中间：领域能力 | 最高：可安装分发单元 |
| 例子 | query_database(sql) | 一个教 agent 诊断数据库性能问题的文件夹 | 一个 “Database Ops” plugin，里面有 3 个 skills + 5 个 tools + 一套配置 |
| Token 成本 | schema 往往一直加载，成本可能很高 | 元数据启动时加载（约 80 tokens），正文按需加载 | 取决于里面装了什么 |
| 通常由谁创建 | 开发者写函数签名和 API 集成 | 领域专家写说明，开发者写脚本 | 平台团队把内容打成可安装包 |
关键洞察是：tools 负责执行，skills 负责准备。
当 agent 调用 tool，外部世界会发生事：数据库被查了、文件被写了、API 被调了。当 agent 激活 skill，它的上下文先发生变化。它获得一套领域知识、行为模式和可引用资源，然后再决定要用哪些 tools，以及该怎么用。
这不是措辞上的小差别，它决定了你的系统里“智能”究竟放在哪。
在一个 tool-heavy 的架构里，agent 本身是通用的，真正的智能更多来自于工具接口是否设计得好。Agent 的任务是选择和编排。这基本就是早期 LangChain 和很多 OpenAI 集成的思路。
在一个 skill-heavy 的架构里，智能更多存在于 agent 自身。Tool 退化成更简单的 utility，而 agent 则携带领域能力，而不只是“我有一串函数可调用”。这正是 Anthropic 一直在推的模型，它之所以越来越被接受，是因为它确实解决了 tools-only 架构一扩规模就爆炸的问题。
AI Agent Skills 在底层是怎么工作的
让 skills 真正可用的关键架构，叫做 progressive disclosure（渐进披露）。它把上下文加载拆成三层：只在需要时加载更多内容。
第 1 层：Discovery
启动时，agent 只加载每个 skill 的一行摘要，也就是 name 和 description。中位数成本大概是每个 skill 80 tokens。17 个 skill 的库，总成本也不过 1,700 tokens 左右。这意味着 agent 可以“知道自己会什么”，而不需要在上下文窗口里同时背着几十项完整能力。
第 2 层：Activation
当 agent 判断某个 skill 和当前任务相关时，才会把完整的 SKILL.md 正文加载进上下文。这一层是真正的 instruction body：步骤、决策树、格式规则、guardrails。正文中位数大约 2,000 tokens，通常建议不要超过 5,000。
比如一个财务分析 skill 可能会写：
“当用户给出收入数据时，先计算 trailing twelve-month growth，再展示预测。如果同比增长率超过 200%，先把它标记为 outlier，再要求用户确认。”
第 3 层：Execution
复杂 skill 还会继续引用别的文件：更长的文档、模板、脚本。只有在具体子任务需要时，这些内容才会再被加载。而最重要的一点是：脚本是在上下文窗口之外执行的。 一个 Python 脚本去处理数据，消耗的是零 tokens。它跑完，把结果返回给 agent，流程继续。
这种三层结构，和“一开始把所有东西全塞进 prompt”相比，平均 token 消耗能下降大约 40%，同时任务准确率还能提升 15%-20%。至少在早期实测里，趋势是很明确的。
如果你在搭建 agentic AI workflow，就必须理解这种 progressive loading 方式。它同时决定成本和质量。
为什么 Skills 比“写个超强 system prompt”更重要
很多人会问：“那为什么不直接写一个超好的 system prompt？”
这是最常见的反对意见，而且值得正面回答。一个 20,000-token 的超级 prompt，里面同时覆盖财务分析、文档格式、设计原则和项目管理，听起来很全面。但在实践里，它会制造三个问题。
问题 1：注意力被稀释。 Transformer 会把注意力分配到上下文中的所有 tokens。一个 20K 的 prompt，意味着当前任务要和 19,000 个无关指令竞争注意力预算。2025 年很多团队的研究都证明了，同一模型在被无关上下文包围时，针对具体任务的表现会显著变差。“Lost in the middle（中间遗失）”不是传说，是一个已经被充分验证的现象。
问题 2：没有生命周期管理。 Mega-prompt 永远都在。你没法在用户从财务分析切换到写博客时，把那一大段财务规则卸掉。Skills 之所以有效，就是因为它可以激活，也可以在概念上“退出”。任务需要什么就加载什么，做完之后，正文指令就不再持续占用主动注意力。
问题 3：它根本扩不动。 一个组织有 50 个 use case，就要在 mega-prompt 里写 50 段；有 500 个 use case，这个 prompt 的长度就已经超过不少模型的上下文窗口了。Skills 能扩规模，是因为每个 skill 都是独立的。增加新能力，只要新建一个文件夹，不用去改那份所有人共用、所有能力互相依赖的大 prompt。
2026 年初爆火的 Manus，就是通过不断改写它内部的 todo list，把当前目标推到最近上下文里，来应对这个问题。它的典型任务大概要 50 次 tool call。如果没有主动的上下文管理，agent 很快就会漂走。这就是为什么静态 prompt 很难支撑动态工作流。
一个设计良好的 Skill 应该长什么样
一个能上生产的 skill，无论文件结构看起来多简单，本质上都应该有五个组成部分。
presentation-design/
SKILL.md # Instructions + metadata
scripts/
validate_layout.py # 确定性检查
references/
brand-guidelines.md # 只有做品牌相关工作时才加载
export-specs.md # 只有导出时才加载
assets/
template.html # 起始模板
1. 清晰的触发条件。 名字和 description 必须足够清楚，让 agent 知道到底什么时候该激活这个 skill。“Presentation design” 太模糊；“创建、编辑或排查 slide deck 和视觉演示内容”才算可执行。因为 agent 的激活判断基本只靠这行 metadata。
2. 收敛的说明边界。 SKILL.md 的正文应该把一个领域讲深，而不是三个领域都讲浅。如果它必须涉及别的 skill 负责的事情，最好直接写“handoff to [other skill]”，而不是把对方的说明复制一份进来。
3. 确定性脚本。 任何“正确性比创造力更重要”的环节，都应该优先变成 script，而不是交给 LLM 推理。比如校验 slide layout 是否符合无障碍标准，用 script；排序一份财务数据，用 script；生成一个更有感染力的 headline，才交给 LLM。这个分工会同时提升可靠性并压低成本。
4. 被引用的深度材料。 很长的参考资料不应该塞进 SKILL.md 主体。比如一个 presentation skill 的 brand guideline 可能就有 8,000 tokens。如果每次激活都把它整份载入，那就是纯浪费。只有在用户明确说“匹配我们的品牌”时再加载，才是高效做法。
5. Guardrails。 Agent 不该做什么，和它该做什么一样重要。比如财务 skill 就应该明确写：“Never present projected returns without a disclaimer.”、“Never round numbers in a way that changes the conclusion.” Guardrails 要防的，是最贵的一类错误：自信、错误、还很像真的输出。
AI Agent Skills 在真实系统里怎么用
内容生成类 Skills
AtomStorm 的多智能体架构里，不同 agent 会在不同任务下激活不同的 skills。比如用户要做 pitch deck，系统会分别激活：
- presentation planning skill：负责叙事结构、页序、受众判断
- visual design skill：负责版式、字体、色彩和视觉层次
- quality review skill：负责一致性检查和品牌对齐
每个 skill 都是独立加载的。正因为用了 多智能体协作方式，单个 agent 才不需要自己背全套能力。
研究分析类 Skills
企业部署里也经常用 skills 做领域研究。比如一个 due diligence skill，可能会包含 SEC filing 扫描规则、风险评估矩阵模板，以及调用财务 API 的脚本。Agent 在写邮件时完全不需要这些，但当任务命中时，它们就会被精准加载出来。
设计与布局类 Skills
当 vibe design 平台收到“帮我做一张微服务系统架构图”这样的请求时，会激活一个专门懂服务边界、数据流、API 连接和基础设施分层视觉表达的 skill。这个 skill 还可能引用 C4 model、UML component diagrams 之类的参考资料，但只有当用户的请求暗示需要某种特定 notation 时，它们才会被加载。相关背景可以继续看 什么是 vibe design。
评估 AI 平台时，应该怎么判断它的 skills 架构
不是每个平台说“我们有 skills”，就意味着同一种东西。你真正要问的是下面这些问题。
| 该问什么 | 强信号 | 弱信号 |
|---|---|---|
| Skills 怎么加载？ | Progressive disclosure，按需激活 | 启动时全量塞进上下文 |
| 用户能自己创建 skills 吗？ | 开放格式（SKILL.md 或等价方案） | Vendor lock-in，不允许自定义 |
| Skills 和 tools 怎么协作？ | Skills 带着领域上下文去编排 tools | 只是换个名字，本质上还是 tool 列表 |
| 规模上去之后怎么办？ | 支持 sub-agent delegation、context lifecycle management | “往 prompt 里继续加 skills 就好了” |
| 支持 scripts 吗？ | 支持，且在上下文外确定性执行 | 不支持，所有环节都靠 LLM 推理 |
| 是否支持 HITL？ | Skills 可以定义 approval checkpoint | 完全自治，没有用户控制点 |
最后一点尤其关键。没有 Human-In-The-Loop（HITL）的 skills，本质上就是自动流水线。有些场景这没问题；但对财务报告、法律文档、客户演示这类高风险任务来说，“能停下来让用户确认”，不是锦上添花，而是必要条件。
Agent Skills 的下一步：可组合性和 Marketplace
这个领域正在明显往两个方向发展：composability（可组合性） 和 marketplace（技能市场）。
所谓 composability，就是多个 skill 可以在同一个任务里叠加协作，而不会互相打架。
当 AtomStorm 生成一份 pitch deck 时，presentation planning skill、visual design skill 和 brand consistency skill 都会共同作用在同一个 artifact 上。但它们不会互相踩，因为每个 skill 管的是输出的不同维度。这就是可组合性的真实形态，而它背后依赖的是非常克制的 skill 边界设计。
至于 marketplace，则很像当年浏览器扩展、VS Code 插件和手机 App 的演化过程：第三方开发者发布 skill，不同平台都能消费。SKILL.md 格式之所以有希望，是因为它足够低门槛。哪怕你不会写程序，只要你能把某个领域的知识和流程写清楚，也可能做出一个能提升 agent 表现的 skill。
当然，这里面有一个很真实、现在还没有解决完的问题：质量控制。一个有 1,000 个 skill 的 marketplace，里面一定既有高质量能力，也会有相互冲突、写得糟糕、甚至方向错的能力。Agent 到底该怎么优雅处理冲突指令？这件事今天还没有被彻底解决。谁跟你说“已经完全解决了”，基本都在卖东西。
怎么开始尝试 skills-based 工作流
如果你正在评估 AI agent 平台，别只看 feature list，要直接问：这个平台是怎么管理上下文的？
先从一个高价值 skill 开始。 选一个团队每周都做的重复任务：报表模板、设计审查 checklist、客户 onboarding 流程。把你对这个任务的经验写出来，就像你在培训一个新同事。这就是你的第一个 skill。
测试它是否真的是按需加载。 平台会在需要时才加载 skill，还是一启动就把所有东西全扔进上下文？这个答案会直接决定系统未来是能扩到 20 个、50 个、100 个 skill，还是很快撞墙。
衡量质量，不要只看速度。 一个设计良好的 skill，应该能提升 agent 在某个领域任务上的准确率。如果加了 skill 之后输出质量没有任何变化，那大概率说明 agent 根本没有真正用好它。
2026 年真正从 AI agents 里拿到大价值的组织，不是拥有最多 tools 的组织，而是拥有最被精心策展的 skills 的组织：按需加载、精准执行、做完就卸载的模块化领域能力。这才是能扩规模的架构。
亲自看看 skills-based AI 怎么工作：试一下 AtomStorm 的多智能体工作流，看看不同专职 agents 如何围绕同一个内容一起协作。可免费开始。