Skill Lifecycle：如何证明 Skill 仍然有效、可触发并安全退休？

[627150795]

这是 #324 Skill 正文该何时加载、压缩后如何恢复 的治理后续。

#324 解决了一个运行时问题：Skill 正文什么时候进入 context，发生 compaction 或 resume 后怎样重新投影。随着 Skill 数量增加，还需要单独讨论它们进入投影之前和离开投影之后的生命周期。

一个 Skill 可能仍然写得正确，却因为描述和用户实际说法逐渐偏离而再也不会被触发。另一个 Skill 可能被 Runtime 找到并加载了，但模型没有遵循其中的关键规则。还有一些 Skill 只需要测试或更新，却可能被一次启发式清理直接标成退休。

OpenAI Codex #41635 给出了一个具体切口。该讨论提出对 AGENTS.md、CLAUDE.md 和 SKILL.md 做本地只读审计，并把 MERGE、UPDATE、DEMOTE、RETIRE 和 TEST 分开。讨论还指出，TEST 不等于 RETIRE。如果宿主没有可靠的 Skill load event，就不能把“没有观察到加载”推断为 unused。

本帖希望讨论一套很小的生命周期合同，不增加另一种 Skill 文件格式。

当前缺口

当前几个事实经常被混在一起：

• 文件或索引中存在一个 Skill；
• Runtime 找到了它；
• 正文进入了当前 context 或 capability projection；
• 本次执行引用了它提供的内容或能力；
• 执行结果有证据表明相关规则被遵守；
• Skill 的引用、宿主兼容范围和行为测试仍然有效。

这些事实不应互相推断。尤其在没有可靠事件时，结果应为 UNKNOWN，不能把 unknown 当成 unused 或 RETIRE。

建议区分的状态

found

索引或搜索找到了 Skill。

loaded

Runtime 把 Skill 放进了当前 context 或 capability projection。

used

本次执行实际引用了它提供的内容或能力。

followed

执行结果有证据表明相关规则被遵守。

verified

Skill 的引用、版本、宿主兼容范围和行为测试仍然有效。

最小记录

每个 Skill 或 instruction 可以先拥有以下元数据：

instruction_id
source_path
version_or_digest
scope
host_compatibility
last_reviewed
reference_health
trigger_examples
load_evidence
adherence_evidence

审计器可以产生 STALE_REFERENCE、DUPLICATE、TRIGGER_UNCOVERED、LOAD_UNKNOWN、TEST_REQUIRED 和 RETIRE_CANDIDATE。这些结果不应合并成一个健康度分数，也不应直接触发删除。

建议的治理边界

• Skill 内容更新需要保留旧版本、diff、owner 和回滚路径；
• 退休操作需要理由和影响范围，不能静默删除安全、路径或权限约束；
• trigger coverage 应包含正例和近邻负例，验证用户说法改变后激活边界是否仍然合理；
• load_evidence 只能说明内容进入了 Runtime，不能自动证明模型遵循了规则；
• adherence_evidence 应尽量绑定到可观察的 Runtime action、validator 或 negative test，而不是只看最终文本；
• 证据不足时，系统应建议 TEST 或 UPDATE，保留人工批准 DEMOTE 和 RETIRE 的边界。

最小可证伪实验

为一个 Skill 准备两个真实触发说法、一个近邻但不应触发的说法，以及一个需要执行验证的规则。分别测试：

1. Skill 被发现但没有加载；
2. Skill 被加载但本轮没有使用；
3. Skill 被加载并影响了一个可观察 action；
4. Skill 内容仍然正确，但 trigger description 已经漂移；
5. 宿主没有 load event 时，审计结果是否保持 UNKNOWN；
6. TEST、UPDATE、DEMOTE 和 RETIRE 是否保留可回滚记录。

与现有工作的关系

#324 讨论 Skill 的发现、读取、compaction 和 resume；这里新增的是内容健康、触发覆盖、遵循证据和治理动作之间的边界。它也不要求 OpenPI 现在判断所有自然语言规则是否被完美遵循。

非目标

• 不要求 Runtime 为所有自然语言规则建立完美的遵循证明；
• 不把单次 Benchmark 失败直接解释成 Skill 应退休；
• 不让启发式清理器直接改变 authority 或删除硬约束；
• 不在本帖中决定所有宿主都必须采用同一个 Skill manifest。

希望讨论的问题

1. OpenPI 应如何定义 Skill stale？引用失效、宿主 API 漂移、trigger drift 和行为评测退化是否需要不同状态？
2. found、loaded、used、followed 各自需要什么最低证据？
3. 没有可靠 load event 时，UNKNOWN 应如何影响清理、评测和后续加载？
4. 谁可以提出 TEST/UPDATE/DEMOTE/RETIRE，谁应批准，旧版本和回滚信息应保存多久？

希望讨论最终回答：

OpenPI 如何在不误删有效能力的前提下，持续知道一个 Skill 是否仍可发现、可加载、可遵循，以及何时应该更新、降级或退休？