Agent Skills：为什么成熟 Agent 不应该把所有能力都塞进 System Prompt

上一篇我们讨论了 Agent Prompt 的设计原则：

好的 Prompt，不是规则越多越好，而是结构越清晰越好。

但当 Agent 的能力越来越多时，一个新的问题会出现。

假设一个 Agent 同时支持：写代码、分析 PDF、生成 PPT、处理 Excel、查询数据库、部署服务、分析日志、搜索网页。

最直接的做法，是把所有规则全部写进 System Prompt。于是 Prompt 会越来越长：

Coding Rules
+ PDF Rules
+ PPT Rules
+ Excel Rules
+ Database Rules
+ Deployment Rules
+ ...

最后可能变成几万 Token 的"万能说明书"。

这显然不是一个好设计。更合理的方法是：只在需要的时候，加载需要的能力。

这就是 Agent Skills 背后的核心思想。

为什么不能把所有知识都放进 System Prompt？

把所有能力都提前塞进 Context，主要有三个问题。

第一，浪费 Token。 如果用户只是让 Agent 修改一个 Go 文件，那么 PPT 生成规范、Excel 操作规则、PDF 解析流程全部都是无效信息。

第二，干扰模型注意力。 Context 中的信息越多，真正和当前任务相关的内容占比越低。

第三，维护困难。 当所有能力都集中在一个巨大 Prompt 中时，修改一个规则就可能影响其他能力，System Prompt 越来越难维护。

这和软件工程中的"大型单体函数"非常类似。能力越来越多以后，最自然的方向就是模块化。

什么是 Agent Skill？

可以把 Skill 理解为Agent 某一类能力的独立操作手册。

例如一个项目的 Skill 目录可能是这样组织的：

skills/
├── coding/SKILL.md
├── pptx/SKILL.md
├── pdf/SKILL.md
├── spreadsheet/SKILL.md
└── database/SKILL.md

其中 SKILL.md 可能包含：什么时候使用这个 Skill、推荐工作流程、工具使用方式、注意事项、常见错误、验证方法等。

例如一个 PDF Skill 的内容大概是这样的：

WHEN:
- 用户要求分析 PDF
- 提取 PDF 内容
- 修改 PDF

WORKFLOW:
1. 读取文件
2. 检查页面结构
3. 提取内容
4. 执行任务
5. 验证输出

只有当 Agent 判断当前任务需要处理 PDF 时，才加载这些内容。

核心思想：Progressive Disclosure

Skills 背后的核心设计原则叫 Progressive Disclosure，渐进式披露。

意思是：不要一开始把所有信息全部告诉模型，而是随着任务需要逐步展开。

例如第一层只告诉 Agent：

Skill: pptx
Description: 用于创建和修改 PowerPoint。

这一层可能只有几十个 Token。如果用户说"帮我做一份产品发布 PPT"，Agent 判断需要 pptx skill，于是再加载 skills/pptx/SKILL.md。如果 Skill 中又提到"复杂图表参考 chart-guide.md"，只有真正需要绘制复杂图表时，再继续读取 chart-guide.md。

于是整个加载过程变成：

Skill Metadata
   ↓
SKILL.md
   ↓
Detailed Reference
   ↓
Templates / Scripts

而不是把"所有能力、所有规范、所有参考文档、所有模板"一次全部塞进 Context。

这就是 Progressive Disclosure。

Skill 最重要的不是"我能做什么"

很多人在写 Skill Description 时会这样写：

This skill helps with backend development.

问题是，这句话并不能帮助模型判断什么时候应该加载这个 Skill。

更好的描述应该是：

Use when:
- 设计 REST API
- 调试 Go 后端服务
- 分析数据库访问逻辑

Do not use when:
- 只修改前端样式
- 只需要翻译文本

也就是说，一个好的 Skill Metadata 最重要的问题不是"我是什么？"，而是**"什么时候应该调用我？"**。

因为 Skill 的第一步其实是一个 Routing 问题。

Skill 本质上也是 Context Engineering

表面上看，Skill 好像是在解决"Agent 如何获得更多能力"。

但从 Context Engineering 的角度看，它真正解决的是**"哪些知识应该什么时候进入 Context？"**

假设 Agent 拥有 50 个 Skill。如果全部加载：

50 Skills × 2000 Tokens = 100K Tokens

但当前任务可能只需要其中两个。通过 Progressive Disclosure，只加载真正用得上的 Skill，最终可能只需要几千 Token。

所以 Skill 本质上是一种 Context Loading Strategy。

Skill 和 Tool 有什么区别？

Skill 和 Tool 很容易混淆。可以简单理解成：

• Tool —— Agent 能做什么动作（能力）
• Skill —— Agent 应该如何完成一类任务（流程）

例如 read_file、write_file、run_shell 都是 Tool，它们提供"读取文件、修改文件、执行命令"的能力。

而 Coding Skill 告诉 Agent：

先阅读相关代码
再定位问题
然后最小化修改
最后运行测试

所以可以记成：Tool = Capability，Skill = Procedure。Skill 往往会组合多个 Tool。

例如：

Coding Skill
   ↓
search_code
   ↓
read_file
   ↓
write_file
   ↓
run_test

这和上一篇讲的 SOP 是一脉相承的——只不过 SOP 不再全部放进 System Prompt，而是被拆成独立 Skill。

Skill 还能提升可维护性

如果所有规则都放在 System Prompt，那么任何修改都会影响整个 Prompt。

而 Skill 化以后：

System Prompt
├── Core Rules
└── Skill Routing

Skills (各自独立)
├── coding
├── pdf
├── pptx
├── database
└── deployment

每个能力可以独立开发、测试、修改、版本管理。这和软件工程中的"模块化、低耦合、高内聚"非常相似。

因此 Skill 不只是一个 Prompt 技巧，它实际上是一种 Agent 能力模块化设计。

什么内容应该放 System Prompt，什么应该放 Skill？

可以用一个简单原则判断。

如果规则几乎所有任务都需要遵守，那么适合放 System Prompt。例如：

• 不要泄露敏感信息
• 遵守用户明确约束
• 高风险操作需要确认
• 优先验证结果

如果规则只有某类任务才需要，则更适合放 Skill。例如：

• PPT 页面排版规范
• PDF 文档解析流程
• 数据库迁移步骤
• Go 项目测试规范

可以总结成：

System Prompt = 全局规则
Skill         = 领域规则

这能够让 Stable Prefix 保持更小、更稳定。

Skill 也不是越细越好

当然，模块化也不能走向另一个极端。

如果把 Skill 拆得过细：

read-go-file skill
write-go-file skill
run-go-test skill
format-go-code skill

模型反而需要花大量精力判断该调用哪个 Skill。

更合理的粒度通常是一个 Skill 对应一类完整任务，例如：

• Go Backend Development
• PDF Processing
• Presentation Creation
• Data Analysis

Skill 内部再通过 Workflow 组织多个步骤。

所以一个好的 Skill 应该满足：边界清晰、触发条件明确、能够独立完成一类任务、内部流程完整。

一个成熟 Agent 的能力结构

最终，可以把一个 Agent 设计成：

Agent
├── Model
└── Harness
    ├── Core System Prompt
    ├── Tool Interface
    ├── Skill Router
    │   ├── Coding Skill
    │   ├── PDF Skill
    │   ├── PPT Skill
    │   └── Database Skill
    ├── Context Management
    └── Agent Loop

模型一开始只看到：核心规则 + 工具 + Skill Metadata。随着任务推进，再逐步加载真正需要的信息。

这就是 Small Core + On-demand Capability。

结语

当 Agent 能力越来越复杂时，继续往 System Prompt 里加内容，并不是一个可持续的方法。

更好的方向是：

System Prompt → 全局行为
Skills        → 领域工作流程
Tools         → 具体动作

然后通过 Progressive Disclosure：先告诉模型有哪些能力，模型判断需要什么，再加载相关 Skill，需要时继续读取详细资料。

这样不仅可以减少无关 Context，还能让 Agent 的能力更加模块化、可维护。

所以从 Context Engineering 的角度来看：

Skill 的核心价值，不只是给 Agent 增加能力，而是控制能力相关知识何时进入 Context。

参考资料

• 《深入理解 AI Agent》第 02 章：上下文工程