- Published on
- Word count
- 2,821 字 · 阅读约 11 分钟
我是如何保证 Agent Skill 多而不乱的?
- Authors

- Name
- 眠月
版本:v1.0(2026-09-05)
适用范围:个人 / 小团队的 Agent Skill 库(数百量级,当前 700+)
1. 问题定义
Skill 库规模增长后,必然出现四个失败模式:
| # | 失败模式 | 表现 |
|---|---|---|
| F1 | 选不对 | 任务来了,不知道该用哪个 skill;调用了不合适的 skill |
| F2 | 管不住 | 重复安装、来源混乱、多工具(Claude Code / Cursor / TRAE)间不同步 |
| F3 | 改坏了 | 迭代优化时把核心方法论改坏,或核心知识被污染/泄露 |
| F4 | 不进化 | skill 陈旧失效,踩过的坑不沉淀,同类问题反复出现 |
核心矛盾:规模 ↑ 必然带来混乱度 ↑。治理目标不是"少",而是"多而不乱"——每个失败模式对应一层治理机制,四层叠加构成完整体系。
2. 总体架构
┌────────────────────────────────────────────────────────────────┐
│ 任务请求(用户输入) │
└───────────────┬────────────────────────────────┬───────────────┘
│ 快路径 │ 慢路径(兜底)
▼ ▼
┌───────────────────────────┐ ┌────────────────────────────────┐
│ L1 排序层 │ │ 子Agent 全量检索 │
│ 多指标综合排序 → Top-N │ │ 触发条件:复杂任务 / 首轮效果不佳 │
│ 注入 system prompt │ │ (skill-matcher subagent) │
└─────────────┬─────────────┘ └───────────────┬────────────────┘
│ │
▼ ▼
┌────────────────────────────────────────────────────────────────┐
│ L2 存储管理层(skills-manager) │
│ 中央库 ~/.skills-manager/ → Preset 分组 → 软链接分发到各工具 │
│ SQLite: skills-manager.db(单一事实来源 Single Source of Truth)│
└─────────────────────────────┬──────────────────────────────────┘
│ 每个 skill 内部
▼
┌────────────────────────────────────────────────────────────────┐
│ L3 分区保护层(每个 skill 内部) │
│ ┌─────────────────────────────────────────────────────────┐ │
│ │ 不可修改区(核心) │ 可修改区(外围) │ │
│ │ SKILL.md 元原则(≤15条) │ references/*.md 经验卡片 │ │
│ │ 红线 / 方法论骨架 │ 模板 / 示例 / 临时结论 │ │
│ │ 变更需人工确认 + 日期标注 │ 使用中自由迭代 │ │
│ └─────────────────────────────────────────────────────────┘ │
└─────────────────────────────┬──────────────────────────────────┘
│ 使用反馈回流
▼
┌────────────────────────────────────────────────────────────────┐
│ L4 自进化层 │
│ 使用数据 → 评估基准(with/without 对比)→ 触发分析 → 迭代 │
│ 同一问题出现 3 次 → 升级为元原则(不可修改区) │
│ 新经验与元原则冲突 → 触发元原则修订(带日期标注) │
└────────────────────────────────────────────────────────────────┘
一句话总结:排序解决"入口选择"(调用前),分区解决"写入安全"(迭代时),Manager 解决"物理秩序"(存储分发),自进化解决"时间秩序"(持续有效);快慢双路径解决"注意力经济"(上下文纯净度)。
3. L1 排序层:多指标综合排序
3.1 为什么必须多指标
任何单一指标都会失真:
- 只看 使用频率 → 马太效应,新 skill 永远没有曝光机会,长尾价值技能被埋没
- 只看 star 数 → 社区热度 ≠ 个人场景匹配,热门 skill 可能对你无用
- 只看 独特性 → 冷门但功能与热门 skill 重叠的会被高估
多指标加权可以在三个维度间互相制衡。
3.2 指标定义
| 指标 | 数据来源 | 含义 | 更新频率 |
|---|---|---|---|
usage_freq | 调用日志 | 个人实证:最近 N 天该 skill 的触发次数(带时间衰减) | 每次会话 |
community_score | GitHub star / 市场数据 | 社区验证:质量与维护活跃度的代理指标 | 每周 |
uniqueness | skill 间相似度计算 | 不可替代性:与同库其他 skill 的功能距离(越独特分越高) | 安装/更新时 |
success_rate | 评估基准 | 质量:该 skill 触发后任务完成率、with/without 提升比 | 每次评估 |
recency | git log / 更新时间 | 新鲜度:避免陈旧 skill 占据前排 | 每次更新 |
3.3 综合分公式
score = w1·norm(usage_freq) # 0.35 个人实证最重
+ w2·norm(community_score) # 0.15 社区验证
+ w3·norm(uniqueness) # 0.20 不可替代性
+ w4·norm(success_rate) # 0.20 质量
+ w5·norm(recency) # 0.10 新鲜度
权重设计原则:
- 个人实证 > 社区验证:自己的使用数据比 star 数更真实
- 独特性权重必须足够高:防止前排全是"通用但可互相替代"的 skill
- 各指标先归一化(min-max 或 z-score),消除量纲差异
3.4 排序结果的用途
- system prompt 注入:Top-N(如 30-50 个)skill 的 name + description 注入上下文,其余不占注意力
- 冷启动曝光:新装 skill 给予
recency加成,保证至少 N 次曝光机会后由真实 usage 决定去留 - 淘汰预警:长期 score 低于阈值且 usage=0 的 skill,进入"待清理"清单(不自动删除,人工确认)
4. L2 存储管理层:skills-manager 统一管理
4.1 核心原则
- 单一事实来源:所有 skill 的原始副本只存于中央库
~/.skills-manager/skills/,SQLite(skills-manager.db)记录全部元数据 - 单一管理入口:安装 / 更新 / 删除 / 启用禁用 / 标签,全部通过
skills-manager-cli或桌面应用操作,禁止手工散拷 - 项目级最小注入:项目只通过软链接挂载真正需要的 skill,节约上下文
- 多工具分发:Preset(预设分组)→ 软链接同步到 Claude Code / Cursor / Codex / TRAE 等各工具的 skills 目录
4.2 架构
中央库 ~/.skills-manager/skills/(+ skills-manager.db 元数据)
│
├── Preset "Web Dev" → skill1 ✓, skill2 ✓
├── Preset "Code Analysis" → skill2 ✓, skill3 ✓
└── Preset "Team Core" → ...
│
▼ 软链接分发
~/.claude/skills/ ~/.cursor/skills/ .trae/... 各项目 .agents/skills/
4.3 元数据模型(DB schema 扩展)
现有 skills 表(id, name, description)基础上扩展:
ALTER TABLE skills ADD COLUMN category TEXT; -- 分类(classify_skills.py 产出)
ALTER TABLE skills ADD COLUMN score REAL; -- L1 综合分
ALTER TABLE skills ADD COLUMN usage_freq INTEGER DEFAULT 0;
ALTER TABLE skills ADD COLUMN community_score REAL DEFAULT 0;
ALTER TABLE skills ADD COLUMN uniqueness REAL DEFAULT 0;
ALTER TABLE skills ADD COLUMN success_rate REAL DEFAULT 0;
ALTER TABLE skills ADD COLUMN mutable INTEGER DEFAULT 0; -- L3: 1=可修改区技能
ALTER TABLE skills ADD COLUMN last_used TIMESTAMP;
ALTER TABLE skills ADD COLUMN source_url TEXT; -- 溯源
4.4 分类体系
按功能域分类(关键词规则 + 人工校对),当前类目:dev-tools / doc-suite / web-browser / ai-research / design-creative / comm-suite / deploy-cloud 等。分类用于:
- 浏览导航(人类视角)
- 独特性计算的候选范围缩小(同分类内先比对)
- Preset 的组装单元
5. L3 分区保护层:可修改区 / 不可修改区
5.1 设计动机
自进化(L4)意味着 skill 会被持续修改,但核心方法论必须稳定。不设分区,进化过程本身会成为最大的质量风险(一次错误迭代毁掉整个 skill),也防不住核心知识被污染或蒸馏。
5.2 分区定义
my-skill/
├── SKILL.md ← 【不可修改区】元原则层
│ 核心方法论骨架、红线、触发规则
│ 上限 15 条元原则
│ 变更条件:人工确认 + 日期标注(如 "2026-09-05 修订")
├── references/ ← 【可修改区】经验卡片层
│ ├── lesson-*.md 场景/问题/根因/方案/反模式/溯源 六元组
│ └── ... 使用中自由追加、修改、淘汰
├── templates/ ← 【可修改区】模板
└── evals/ ← 【可修改区】评估用例(随经验同步更新)
5.3 分区规则
| 规则 | 内容 |
|---|---|
| 写入门槛 | 可修改区:子 agent / 自动流程可直接写。不可修改区:必须人工确认,git commit 留痕 |
| 晋升通道 | 可修改区同一问题出现 3 次 → 提炼为元原则,晋升到不可修改区(写入 SKILL.md) |
| 修订通道 | 新经验与既有元原则冲突 → 不许静默覆盖,必须触发元原则修订,修订处标注日期 |
| 容量控制 | 元原则 ≤ 15 条(超限必须合并或淘汰旧条目),防止不可修改区膨胀 |
| 溯源要求 | 每张经验卡片必须带"溯源"字段指回原始出处(文档/对话/项目),不可凭空生成 |
| 安全边界 | 不可修改区同时是 anti-distill(反蒸馏)的保护对象:对外分享时核心知识中性化,仅可修改区可导出 |
5.4 分层的信息学依据
- 不可修改区 = 低熵高稳定:变更成本高、频率低、影响全局
- 可修改区 = 高熵高迭代:变更成本低、频率高、影响局部
- 晋升机制 = 熵减通道:把散落的经验(高熵)收敛为原则(低熵)
6. L4 自进化层:使用中持续迭代
6.1 进化闭环
使用/踩坑 → 记录(usercontext 会话级)
→ 蒸馏(经验卡片进 references/,即 dev-lessons 模式)
→ 评估(skill_benchmark: with_skill vs without_skill 对比)
→ 触发分析(skill_trigger_analyzer: 假阳性/假阴性统计)
→ 迭代 SKILL.md 描述 / 断言 / 元原则
↻ 循环,全程留 iteration-N 快照可回滚
6.2 进化的三类信号
| 信号 | 来源 | 动作 |
|---|---|---|
| 触发信号 | skill_trigger_analyzer | 假阳性 → 收紧 description;假阴性 → 放宽 |
| 效果信号 | skill_benchmark / usage success_rate | with/without 无提升 → 降权或整改 |
| 经验信号 | 会话中的踩坑记录(usercontext) | 蒸馏为经验卡片;3 次重复 → 晋升元原则 |
6.3 防退化约束
- 每次迭代保留
iteration-N快照(skill-workspace 机制),支持回滚 - 评估报告 HTML 可视化(eval_viewer),迭代间可比对
- 不可修改区的变更走 git 留痕 + 人工确认,杜绝"进化变退化"
7. 检索架构:快慢双路径
7.1 快路径(默认)
排序后的 Top-N skill 元数据(name + description)直接注入 system prompt。特点:
- 零额外延迟,命中常规任务
- 上下文成本受控:只注入 N 个,而非全库 700+
7.2 慢路径(子 agent 兜底检索)
触发条件(两个,满足其一):
- 复杂任务前:任务涉及多领域 / 用户明确要求检索 / 快路径 Top-N 明显覆盖不住
- 效果不佳时:首轮执行结果不好,怀疑是 skill 选错了
执行方式:派 skill-matcher 子 agent 对全库(或分类子集)做一遍语义检索,返回最合适的 skill 列表,再重新执行任务。
设计本质:700+ skill 不可能全部注入上下文还能保持模型注意力。快慢双路径 = 用"延迟检索"换"上下文纯净度",等价于 CPU 的 L1 缓存 vs 全盘搜索:
- L1(快路径)= 排序预取,命中率靠 L1 排序层保障
- 全盘搜索(慢路径)= 排序失灵时的纠错机制
关键认知:慢路径不是性能妥协,而是必要的冗余——任何静态排序都存在长尾失误,必须有运行时纠错通道。
8. 度量与验收
| 指标 | 定义 | 目标 |
|---|---|---|
| 快路径命中率 | 常规任务正确命中 skill 的比例 | > 90% |
| 慢路径触发率 | 需要子 agent 兜底检索的任务占比 | < 20%(过高说明 L1 排序失效) |
| 上下文占用 | system prompt 中 skill 元数据 token 数 | 受控(Top-N 上限) |
| 进化有效率 | 迭代后 benchmark 提升的比例 | > 50% |
| 元原则稳定性 | 不可修改区月变更条数 | ≤ 3(频繁变更说明分区失效) |
| 重复率 | 库内功能重复的 skill 对数量 | 持续下降 |
9. 设计要点回顾
每个失败模式都有专属解药:排序↔选不对,Manager↔管不住,分区↔改坏了,自进化↔不进化。不存在"一招通吃",因此是四层而非一层。
排序解决冷启动,分区解决演进安全:排序是入口选择问题(调用前),分区是写入安全问题(迭代时),两者组合让 skill 既敢进化又不会进化坏。
晋升机制是体系的灵魂:"同问题 3 次晋升元原则"让体系具备熵减能力——经验自然沉淀为原则,原则又约束新经验的写入。
慢路径是必要的冗余:任何静态排序都有长尾失误,运行时纠错通道保证体系下限。
10. 与现有组件的映射
| 体系层 | 已落地组件 | 位置 |
|---|---|---|
| L1 排序 | check_top_skills.py、scan_skills.py | 仓库根目录 |
| L1 分类 | classify_skills.py / classify_skills_v2.py | 仓库根目录 |
| L2 管理 | skills-manager(中央库 + Preset + 软链接 + SQLite) | skills/skills-manager/SKILL.md |
| L3 分区 | dev-lessons、anti-distill | ~/.agents/skills/dev-lessons/ |
| L4 进化 | skill_benchmark.py、skill_trigger_analyzer.py、eval_viewer.py、darwin-skill | 仓库根目录 / skill 库 |
| 快路径 | system prompt 中的 skill 列表注入 | Trae / 各 IDE 配置 |
| 慢路径 | skill-matcher 子 agent | Agent 工具链 |
| 进化原料 | usercontext 会话记录 | 仓库 usercontext/ |
本文档由 2026-09-05 会话整理,方法论原始表述见 usercontext/2026-09-05/usercontext.md。