当前阅读：自进化 Skills 与 Agent 自我改进
本模块讲"长期运行的 Agent 系统如何越用越强"：不是模型偷偷改代码，而是把"成功模式自动抽象为 Skill"和"失败模式自动归因并产生修复候选"做成严格受控的流水线，每一步都有评审、Pins、回滚、审计。学习顺序：先有发现与打包机制，再有自我修正闭环，最后是失控风险与护栏；三篇之后你应当能设计一套与代码 CI/CD 同等级严格的运行时进化机制。
自进化 Skills 与 Agent 自我改进
05 工具与框架模块讲的是"工程师人工设计、打包、挂载 Skill"；06 评估与进化讲的是"怎么衡量 Skill/Harness 的好坏"；07 本体论讲的是"系统共享的事实与状态怎么定义"。走到 08，我们回答一个更进一步的问题：
当 Agent 系统在真实任务里反复成功或反复失败时，系统自身能不能自动把这些经验沉淀为新的 Skill 或修复现有 Skill？并且在这个过程中，能力不漂移、技能不污染、权限不上升、结果依然可审计？
本模块的核心主张：自进化可以做，但要像做"代码 CI/CD 流水线"一样做。进化本身不是"魔法"，而是一条有 proposer/reviewer、有 fixtures、有回归、有 Pins、有灰度、有回滚、有审计、有护栏的流程。
模块定位
| 问题 | 本模块回答的是 |
|---|---|
| 重复出现的成功模式怎么抽成 Skill？ | Skill 的自动发现与自动打包机制 |
| 执行失败时怎么归因、怎么自动修 Skill 或产新 Skill？ | 从执行失败到自我修正：生成新 Skill 的闭环 |
| 怎么防止"进化着进化着就变乱了"？ | 自进化的失控风险与护栏设计 |
进入前你应当已经知道
- 已读 Agent Skills 和 Harness 设计
- 已读 Harness 与 Skill 评估体系
- 已读 Cruxible：用 YAML 写可执行本体论 与 受治理的写入：direct/proposal_only/角色/审批组/证据与 Attestation
因为本模块大量沿用了 07 里的"proposal_only / candidate groups / independent reviewer / attestations / outcome contracts / config + lock digest pins / procedure lifecycle (pending/live/supersedes/retired)"这些工程抽象，把它们从本体状态治理提升到"Skill 进化治理"。
本模块学习顺序
本模块文章（已发布）
| 文章 | 类型 | 解决的问题 | 状态 |
|---|---|---|---|
| Skill 的自动发现与自动打包机制 | 核心 | 把重复成功的运行时模式变成可部署 Skill，全程 proposal_only + 评审 + Pins + 灰度 | ✅ 已发布 |
| 从执行失败到自我修正：生成新 Skill 的闭环 | 核心 | 把失败分类/归因/修复/评审/回滚做成可审计闭环 | ✅ 已发布 |
| 自进化的失控风险与护栏设计 | 工程 | 6 类失控模式（污染/漂移/静默覆盖/护栏自废/漂移/激励偏离）+ 18 条自检清单 | ✅ 已发布 |
| 待写 | 实战 | 把前述机制落地到 07 ontology 模块之上的一套最小可运行 scaffold（参考 cruxible procedure schema） | 📝 待写 |