技能的增长困境
我的 AI Agent 系统从 5 个技能增长到 30 个，用了 3 个月。
前 10 个技能阶段很顺利——每个技能做的事清晰，边界明确，不需要太多协调。
到 15 个时开始出问题：
- 新建技能时发现和现有技能功能重叠 30%
- 某些技能的关系图只有单向，缺了反向依赖
- 有的技能三周没人触发过，但占着注册表位置
到 25 个时变成混乱：
- 不记得某个功能属于哪个技能
- 新来的能力不知道该独立建还是合并
- Gate 覆盖有漏洞但不知道在哪
这就是为什么需要生命周期管理。
全生命周期模型
Phase 1: 发现 (skill-scout)
触发条件: 在日常使用中发现重复模式——"这件事我已经手动做了 3 次了"。
skill-scout 做的事：
- 从使用日志中识别重复操作模式
- 检查现有技能是否已覆盖
- 如果未覆盖 → 评估：是新建技能还是扩展现有技能
- 产出：技能需求卡（含定位、边界、关系预判）
关键决策: "新建 vs 扩展"。判断标准：
- 如果新能力与现有技能共享 >50% 的数据和上下文 → 扩展
- 如果新能力有独立的 SoT 和独立的触发条件 → 新建
- 灰色地带 → 先扩展，等到臃肿了再拆分
Phase 2: 适配
不是所有技能都从零开始——很多是从已有模式"适配"而来：
- 从社区实践中吸收（如某个 prompt engineering pattern）
- 从其他项目经验中提炼
- 从用户反馈中改造
适配阶段的输出是一份完整的 SKILL.md（技能说明书），包含：
- 核心能力定义
- 触发条件
- 输入/输出契约
- 与其他技能的关系声明
- 目录权限声明
Phase 3: 注册
在 private-catalog.yaml 中正式注册，包含：
- name: chat-analyst
layer: domain
status: active
relations:
- target: chat-collector
type: called_by
direction: inbound
- target: team-pulse
type: shares_data
direction: outbound关系图是注册的核心——不只是"有这个技能"，更重要的是它和谁有关、数据怎么流。
Phase 4: 上线运行
技能进入 active 状态，可以被 entry-router 路由到。
Phase 5: 巡逻 (skill-squadron)
这是持续治理的环节——定期检查所有 active 技能的健康度。
巡逻检查的维度：
| 检查 | 问题 | 行动 |
|---|---|---|
| 关系完整性 | A 调 B，但 B 没声明被 A 调 | 补齐反向 relation |
| Gate 覆盖 | 某技能没有任何质量 Gate | 评估是否需要加 |
| 功能重叠 | 两个技能做类似的事 | 合并或划清边界 |
| 活跃度 | 3 周未被触发 | 评估是否退役 |
| SoT 冲突 | 两个技能都声明写同一字段 | 仲裁写入权 |
Phase 6: 退役
当技能不再需要时：
- 状态改为
deprecated - 关系图中标记"已由 XX 替代"
- 保留 SKILL.md（可追溯），不删除
- entry-router 不再路由到它
治理工具
private-catalog.yaml
所有技能的"户口本"。30 个技能，每个都有：
- 基本信息（名称/层级/版本/状态）
- 关系声明（调用关系/数据流向）
关系图可以用 Mermaid 从 YAML 自动生成——这是巡逻时最有用的可视化。
巡逻节奏
| 频率 | 检查内容 |
|---|---|
| 每周 | 活跃度统计（谁被触发了几次） |
| 每两周 | 关系完整性扫描 |
| 每月 | 全量巡逻（含退役评审） |
教训
管理 30 个技能 3 个月的核心教训：
- 注册表比代码重要 — 技能的 SKILL.md 可以慢慢完善，但注册表必须第一天就建
- 关系图比技能本身重要 — 单个技能好理解，但 30 个技能之间的关系是指数级复杂度
- 巡逻不能等问题出现 — 等到两个技能打架时才处理，成本是定期巡逻的 10 倍
- 退役需要勇气 — "万一以后用到呢"会让系统越来越臃肿
核心洞察：AI 技能的管理和代码模块的管理是同一个问题——复杂度的治理。代码有包管理器、CI/CD、依赖审计；AI 技能也需要注册表、关系图、定期巡逻。不是"加技能"让 Agent 变强——是"管好技能"让 Agent 可控。