/2,821 字/阅读约 11 分钟

我是如何保证 Agent Skill 多而不乱的?

700+ Skill 库的四层治理体系:L1 排序层(选得对)、L2 存储管理层(管得住)、L3 分区保护层(改不坏)、L4 自进化层(不腐烂),叠加快慢双路径检索。

眠月眠月
joker1point

版本:v1.0(2026-09-05)

适用范围:个人 / 小团队的 Agent Skill 库(数百量级,当前 700+)


1. 问题定义

Skill 库规模增长后,必然出现四个失败模式:

#失败模式表现
F1选不对任务来了,不知道该用哪个 skill;调用了不合适的 skill
F2管不住重复安装、来源混乱、多工具(Claude Code / Cursor / TRAE)间不同步
F3改坏了迭代优化时把核心方法论改坏,或核心知识被污染/泄露
F4不进化skill 陈旧失效,踩过的坑不沉淀,同类问题反复出现

核心矛盾:规模 ↑ 必然带来混乱度 ↑。治理目标不是"少",而是"多而不乱"——每个失败模式对应一层治理机制,四层叠加构成完整体系。


2. 总体架构

js
┌────────────────────────────────────────────────────────────────┐
│                       任务请求(用户输入)                        │
└───────────────┬────────────────────────────────┬───────────────┘
                │ 快路径                          │ 慢路径(兜底)
                ▼                                ▼
┌───────────────────────────┐   ┌────────────────────────────────┐
│ 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_scoreGitHub star / 市场数据社区验证:质量与维护活跃度的代理指标每周
uniquenessskill 间相似度计算不可替代性:与同库其他 skill 的功能距离(越独特分越高)安装/更新时
success_rate评估基准质量:该 skill 触发后任务完成率、with/without 提升比每次评估
recencygit log / 更新时间新鲜度:避免陈旧 skill 占据前排每次更新

3.3 综合分公式

js
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 排序结果的用途

  1. system prompt 注入:Top-N(如 30-50 个)skill 的 name + description 注入上下文,其余不占注意力
  2. 冷启动曝光:新装 skill 给予 recency 加成,保证至少 N 次曝光机会后由真实 usage 决定去留
  3. 淘汰预警:长期 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 架构

js
中央库 ~/.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)基础上扩展:

sql
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 分区定义

js
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 进化闭环

js
使用/踩坑 → 记录(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_ratewith/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 兜底检索)

触发条件(两个,满足其一):

  1. 复杂任务前:任务涉及多领域 / 用户明确要求检索 / 快路径 Top-N 明显覆盖不住
  2. 效果不佳时:首轮执行结果不好,怀疑是 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. 设计要点回顾

  1. 每个失败模式都有专属解药:排序↔选不对,Manager↔管不住,分区↔改坏了,自进化↔不进化。不存在"一招通吃",因此是四层而非一层。

  2. 排序解决冷启动,分区解决演进安全:排序是入口选择问题(调用前),分区是写入安全问题(迭代时),两者组合让 skill 既敢进化又不会进化坏。

  3. 晋升机制是体系的灵魂:"同问题 3 次晋升元原则"让体系具备熵减能力——经验自然沉淀为原则,原则又约束新经验的写入。

  4. 慢路径是必要的冗余:任何静态排序都有长尾失误,运行时纠错通道保证体系下限。


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 子 agentAgent 工具链
进化原料usercontext 会话记录仓库 usercontext/

本文档由 2026-09-05 会话整理,方法论原始表述见 usercontext/2026-09-05/usercontext.md。