本文是「Agent 开发实践与思考」系列第 18 篇。系列目录：
- 2024
- 2025
- 01-28 长任务不失忆：上下文压缩、交接文档与子任务隔离
- 02-25 MCP 用了三个月：工具标准化之后 Agent 设计变了什么
- 03-25 拆解 Coding Agent：为什么”写代码 + 文件系统”是通用 Agent 的内核
- 05-13 Agent 如何用代码完成推理、校验、适配与展示
- 06-03 能看会说的 Agent：语音交互与 Computer Use 这半年
- 06-24 从同步问答到事件驱动：异步 Agent 的架构改造笔记
- 07-08 没有评估就没有迭代：我的 Agent 评估落地记
- 09-09 后训练扫盲：SFT 记知识、RL 学长处，和 Agent 有什么关系
- 10-01 AI Coding 的上下文摘要：几家产品到底在压缩什么
- 10-14 让 Agent 从经验里长本事：失败复盘、经验库与提示词自动优化
- 11-04 能力按需加载：从动态提示词到 Agent Skills（本篇）
能力按需加载：从动态提示词到 Agent Skills
去年六月我写过一篇系统提示词膨胀的记录。业务规则逐条加入后，系统提示词从两百字增加到几千字；修改一处规则时，需要同时检查其他规则是否受影响。当时采用的办法是分层保存内容，并把规则写成可判定的句子。这能改善维护，但不能处理所有能力同时进入同一上下文的问题。按需加载处理的正是这个问题。
Anthropic 发布 Agent Skills 后，我在项目中使用了两三周。它与项目中 rules 的按需加载机制有相似之处，下面记录两种做法的结构、边界和使用中遇到的问题。
Skill 文件及其资源
一个 Skill 是一个目录，目录中必须包含 SKILL.md。文件头部包含名称和一句描述，正文说明这项能力的使用方式。目录还可以包含脚本、模板、参考文档和检查清单；模型在任务需要时再读取这些资源。
渐进式披露指的是：初始上下文只包含每个 Skill 的名称和描述。每份描述通常只有几十个 token，因此可以同时注册多个 Skill 而不占用大量窗口。模型判断某个 Skill 与任务相关后，再读取 SKILL.md 正文。如果正文引用模板或脚本，相关资源也在需要时才读取。这些内容按层级进入上下文。
一个最小的例子：
---
name: weekly-report
description: 按团队口径生成周报，汇总本周代码变更、上线记录与风险项
---
# 周报生成
## 数据口径
- 代码变更以合并到主干的 MR 为准，不含未合并分支
- 风险项分两级：阻塞发布的记为 P0，其余记为 P1
## 输出
使用 template.md 中的格式，先列风险项，再列变更Skill 的基本结构是带有元信息的 Markdown 文件和同目录资源。正文可以较长，因为它通常不在初始上下文中；名称和描述则决定模型是否会加载该 Skill。后文的第一个问题与此有关。
Skill 也降低了编写业务流程的门槛。编写 MCP Server 通常需要实现服务和处理协议；编写 Skill 主要是整理文档和流程，因此业务同学也能将岗位经验整理为 Agent 可用的内容。我们团队这两周出现了第一个由非研发人员编写的 Skill，用于检查客服话术。该版本比研发代写的版本更符合实际口径，原因是作者负责这部分工作。
由模型选择相关知识
传统做法是由开发者预先判断 Agent 可能处理的任务，再把对应知识写入系统提示词。预先注入会占用上下文窗口、增加每次调用的输入内容，并使相关规则与不相关规则混在一起。预先分类也无法覆盖跨类别任务：知识不足时模型缺少规则，知识过多时相关规则更难被采用。
Skill 提供知识目录和每份知识的描述，由模型根据当前任务选择读取的内容。知识选择从路由代码中的预设分类，变为模型在任务执行时的判断。
这与我年初写 MCP 实战时处理的问题相同。当时接入多个 MCP server 后，仅工具描述就占用上万 token，因此需要按需挂载工具。工具和知识都可以按需加载，以减少初始上下文中不相关的内容。相应代价是模型需要额外调用读文件工具，才能获得完整说明。
这种做法依赖模型完成三个步骤：识别任务与知识的关联，主动读取说明，并按照说明执行。两年前的模型经常不会主动读取相关说明，按需加载可能遗漏必要内容。当前模型的指令遵循和任务判断能力使这种机制更可用，但具体效果仍取决于模型和 Host/runtime 的实现。
在使用 Skills 前，我实现过一版路由层方案：客服类任务注入话术规范，查询类任务注入数据口径。这也是按需加载，但任务分类固定在路由代码中；任务跨越预设类别时，可能注入错误的提示词片段。Skills 将选择逻辑交给模型，能覆盖路由规则未列出的交叉场景。
工具、MCP 与 Skill 的职责
工具定义可执行的操作，Skill 定义操作的流程和业务标准。这一划分用于说明职责，不构成协议层面的规定。
MCP 是连接 Host 与工具或其他能力服务的协议。具体工具提供查询、发消息、读写文件等执行能力。Host/runtime 负责发现和注册这些能力，决定工具何时可用，执行调用并处理权限、结果和错误。Skill 是保存在文件系统中的程序性知识，说明任务流程、输出格式和注意事项。它通常由 Host/runtime 读取并注入上下文，本身不能提供工具执行能力；一个 Skill 可以指导模型调用多个工具。
以生成周报为例，Skill 可以定义哪些变更纳入统计、如何划分风险项、使用什么排版格式，以及发送前是否需要人工确认。数据来源由工具提供，Skill 只需说明调用哪些工具获取本周合并记录和发布流水。模型读取周报 Skill 后，按其中流程调用数据工具，再按模板组织结果。其他团队复用这套流程时，可以替换 Skill 中的口径文档而不改动工具层。
工具描述应说明能力、参数和约束，Skill 应说明流程和业务标准。两者可以互相引用，但完整业务流程不适合放入工具描述；Skill 也不能替代工具或 Host/runtime 的执行逻辑。
项目中的 rules 按需加载
项目使用的 AI IDE 支持为 rules 文件配置常驻加载、按文件类型匹配加载、手动加载和模型按需加载。最后一种方式与 Skills 相似：rule 文件在初始上下文中只提供一句描述，模型根据描述决定是否读取全文。
今年在基建收敛项目中，我将内部工具链的使用方式整理为一组 rules。初始上下文只保留几行描述，AI 使用某个库时才读取对应文档。同一批规则由全量常驻改为按需加载后，长任务中模型遗漏早期指令的情况减少了。这与压缩、缓存一样，都在减少上下文中需要长期保留的内容。
rules 方案有两个限制。不同 IDE 的写法、配置位置和加载策略并不通用，更换工具时需要重新组织规则。rules 也缺少统一的元信息和分发结构；其他人复用规则前，需要先理解项目约定，规则之间的边界也由各项目自行定义。
Skills 规定了目录、元信息和资源组织方式，适合与脚本、模板一同纳入版本管理和分发。我的 rules 迁移到 Skills 的成本较低，因为两者都使用按需读取的思路。两者的职责仍然不同：Rules 通常是 Host 根据文件、目录或显式操作加载的约束；Skills 是包含元信息和配套资源的可复用能力包。是否加载由具体 Host/runtime 决定。Skills 不建立工具连接，也不等同于 MCP Server。
使用中的限制
我在两三周的使用中遇到三个问题。
Skill 描述会影响加载决策。在我使用的实现中，渐进式披露使模型主要依据一句描述决定是否读取整份 Skill，具体策略仍取决于 Host/runtime。我写过一个文档处理 Skill，描述为“处理各类文档”。模型处理 Markdown 表格时没有加载它。改为“转换与格式化 Markdown 表格，遇到表格结构问题时使用”后，模型能够关联到该 Skill。描述需要写明使用条件和不适用范围，而不只是定义能力名称。这与去年写工具描述的手艺中处理工具描述的原则一致。
多个 Skill 同时加载时，规则可能冲突。例如，一个要求详细输出，另一个要求精简输出，模型可能在同一输入下采用不同的输出风格。我会控制同时相关的 Skill 数量，将需要统一执行的冲突规则放到全局提示词中，Skill 中只保留局部且不冲突的内容。目前我没有使用到能系统处理这类冲突的管理工具，因此安装新 Skill 时会先检查它与已有规则的关系。
第三方 Skill 还涉及安全问题。Skill 同时包含提示词和可能执行的脚本；安装第三方 Skill 会将外部指令和脚本引入 Agent 的上下文与执行环境。提示词注入的处理原则同样适用：外部内容、工具返回和第三方文档应作为不可信数据处理，不能直接作为指令执行。我会先阅读第三方 Skill 的 SKILL.md 和附带脚本，再决定是否启用；来源不明的 Skill 不安装。Skill 市场中的供应链风险也需要按这一原则处理。
上下文中的知识范围
过去两年，我使用过提示词分层、缓存、压缩和 Skills。提示词分层减少常驻内容，缓存减少重复计算，压缩减少需要保留的内容，Skills 则在任务需要时才提供能力说明。这些方法都在控制上下文中长期保留的信息范围。
我的做法是由人整理知识并说明使用条件，由模型在任务执行时选择相关内容。知识保存在文件中，只有在任务需要时进入上下文。这个边界能减少初始上下文中的无关规则，但仍依赖 Skill 描述、模型判断和 Host/runtime 的加载机制。
