AIClaw 里有不少可复用能力：工具、MCP、自定义命令、记忆、计划状态、频道接入，以及 Skills。Skill 越多，一个问题就会变得越来越明显：如果每次对话都把所有 Skill 的完整说明一次性塞进 prompt，成本会上升，模型也更容易被无关上下文干扰。
这篇文章讲的不是一个"刚发布的新功能"，而是 AIClaw 当前代码库里已经存在、而且很值得单独展开说的一个设计：Skills 的两阶段加载。
它的目标很直接：
- 让 Agent 先知道"有哪些 Skill 可以用"
- 但不要让每轮对话都承担全部 Skill 的上下文开销
- 真正需要时，再读取某个 Skill 的完整
SKILL.md
为什么要做成两阶段
很多 Agent 系统一开始 Skill 很少，直接把说明全文注入还不觉得重。可一旦 Skill 库变大，问题就会变成日常成本：
- 普通任务也要带上大量其实用不到的说明
- prompt 变长，调试更难
- 专项能力越多，基础对话越臃肿
AIClaw 在 README 里把这个设计说得很清楚：先注入 Skill 的名字、描述和路径，只有在需要时，模型再去读取完整说明。
这意味着 Skill 在运行时不是"默认全文展开"，而是"默认先暴露索引"。
第一阶段：注入轻量索引
第一阶段给模型的是一个紧凑目录，而不是整本手册。模型先看到的是：
- Skill 名称
- Skill 描述
- Skill 所在路径
这些信息已经足够支撑大部分规划判断。比如模型可以先判断：
- 当前任务是否需要某个 Skill
- 需要的是哪个 Skill
- 现在有没有必要继续读取它的完整说明
这一步的价值不在于"省一点 token"这么简单，而在于让 Skill 发现能力和详细执行说明分离开来。
第二阶段：按需读取完整 SKILL.md
当模型判断某个 Skill 真有用时，再去读取完整指令。这样做有几个实际好处：
- 大量 Skill 可以共存，而不会把所有对话都拖重
- 简单任务保持轻量
- 复杂任务仍然能拿到深度说明
这是一种很实用的上下文管理方式：不是把所有能力一次性铺平，而是先给目录，再按需展开。
AIClaw 里 Skill 不止一种状态
从当前代码和前端页面看，AIClaw 把 Skill 至少分成了三类。
1. Built-in Skills
内置 Skill 随应用一起提供。启动时，AIClaw 会把编译时嵌入的内置 SKILL.md 同步到工作区对应目录，保证运行时能以统一的磁盘结构读取它们。
这个细节很重要。因为它说明内置 Skill 不是"写死在某个常量里"，而是会落到工作区可观察的目录结构上，便于后续扫描和展示。
2. Local Skills
本地 Skill 来自工作区的 skills/ 目录。前端会把它们和内置 Skill 分开列出来，并展示版本、作者、目录名、入口文件等信息。
这里能看出 AIClaw 对 Skill 的理解不只是"提示词片段"。Skill 既可以只是说明文档，也可以带可执行入口，成为一个可复用的能力包。
3. Pending Skill Candidates
这是当前实现里非常有意思的一层。
Skills 页面明确写了：当一次 Agent 运行成功，并且使用了 3 个或以上不同工具时，系统会把候选 Skill 归档到 skills-pending/。它不会直接变成正式 Skill，而是先进入待审状态。
随后用户可以在页面里：
- Preview 预览完整内容
- Promote 转正为正式 Skill
- Discard 丢弃候选
这个流程很关键，因为它把"Agent 在一次运行中总结出的可复用方法"变成了一个可审阅、可管理的资产，而不是自动污染现有提示词库。
为什么一定要有 Promote 这一步
如果 Agent 自动产出的 Skill 立刻生效，系统很快就会堆积大量噪声，甚至引入不稳定指令。AIClaw 当前的处理更稳妥：先归档，再人工确认。
从 handler 和前端实现看，转正时至少要补齐两类信息：
- 最终 Skill 名称
- Skill 描述
然后候选内容才会被提升到正式 Skills 目录中，在后续会话里成为可用资产。
这个设计的价值在于：
- Agent 可以不断沉淀工作方法
- 但是否进入长期能力库，交给人来做最后判断
一个实际工作流
如果按当前产品逻辑来理解，Skill 工作流大致是这样的：
- 在工作区安装内置或本地 Skill。
- Agent 在 prompt 构造时先看到一个轻量 Skill 索引。
- 真正需要某个 Skill 时，再读取完整
SKILL.md。 - 多工具成功执行后，系统把潜在可复用流程归档到
skills-pending/。 - 用户在后台预览、转正或丢弃这些候选。
这套机制把"复用能力"做成了一个有生命周期的对象，而不是一次性堆进 system prompt 的纯文本。
举个例子
假设一个团队在 AIClaw 里装了这些 Skill：
- 深度调研
- 网页抓取
- 浏览器自动化
- 数据清洗
- 报告整理
如果采用"一阶段全文注入"，哪怕你只是做一个简单文件修改任务，也可能带上很多本轮根本不需要的说明。AIClaw 现在这套两阶段方式则更克制：先知道这些 Skill 存在，需要时再展开具体内容。
这种设计对复杂 Agent 平台尤其重要。因为随着可用能力越来越多，真正决定系统是否可维护的，不只是"能不能扩展"，而是"扩展之后 prompt 会不会失控"。
这套设计的价值
从现有仓库实现来看，AIClaw 在 Skills 上做出的取舍很务实：
- 先暴露可发现性
- 再按需读取详细说明
- 内置、本地、待审候选分层管理
- 自动沉淀和人工转正结合
如果你把 AIClaw 当作一个 self-hosted Agent 平台来看，这其实是一种很成熟的工程思路：不是把所有能力都无差别塞进上下文，而是把 Skill 做成"可索引、可延迟加载、可审核升级"的资产系统。
对长期运行的 Agent 来说，这比单纯增加更多提示词更重要。