24 万★的技能框架不会版本管理自己的技能；91★的小仓库反而会。这块拼图不是技术问题，是观念问题：技能是代码，代码就应有 commit、diff 和 revert。
系列前两篇解决了"AI 知道代码长什么样"（索引层）和"AI 的循环怎么跑"（Harness 层）。最终篇解决最玄也最实用的问题：Agent 会不会越用越聪明？答案拆成三半：观察怎么触发、进化怎么门控、以及——被所有人忽略的——进化之后怎么管理。
我把生态里最认真的三个自进化实现拆开看了：
| 项目 | 观察触发 | 进化门控 | 版本化 |
|---|---|---|---|
| ECC（24 万★） | per-tool hooks 捕捉纠正/报错/重复流程 | 置信度 0.3–0.9，带证据计数 | ❌ 只有导入导出 |
| skill-creator（官方） | eval 失败驱动重写 | 盲测 A/B（独立评分 Agent） | 快照目录，手动回滚 |
| seed（91★） | 任务完成时自省 | 无（纯自觉） | ✅ git，自我目录即仓库 |
注意最后一列。24 万★的项目没有版本管理自己的技能；91★的小仓库反而有。技能被改坏了怎么办？ECC 的答案是导出再导入——这等于说"备份靠复制粘贴"。
以 ECC 的 continuous-learning-v2 为例（文档写得极认真，值得通读）：
observations.jsonl。v2 特意从"会话结束时捕获"改成"每次工具调用捕获"，理由是可靠性——hook 触发即捕获，没有遗忘窗口/evolve 把相关本能聚合成完整技能；/prune 清理过期候选；项目内验证过的本能可以在第二个项目再现时晋升全局（防跨项目污染）我的 Kotlin 实现（harness-engineering 的 EvolutionLoop）遵循同样的三段，外加最后一步它没有的——
loop.observe(Observation("counter", "read-only 下执行写入",
"写入被拒；应改用 workspace-write 或先落盘工件", failure = true))
loop.observe(Observation("counter", "read-only 下执行写入",
"再次被拒；确认规则", failure = true))
val instinct = loop.distill().first() // 置信度随证据成长：0.45 → 0.6 成熟线
val head = loop.evolve(instinct, gate, baselineReport)
// head = "2ed1d67" —— 一次真实的 git commit
store.rollback(head) // 回滚 = git revert，回到 22262a6skill-creator 的门控设计最讲究：候选技能必须和基线盲测对比——两个独立 Agent 分别带着"有技能"和"无技能"跑同样任务，第三个评分 Agent 打分，赢了才发布。这把"写技能"从玄学变成了可度量的实验。
但门控的强度有个反直觉的最优值。Lilian Weng 的文章引用了 autoresearch 上的一个发现（94.6k★）：给生成的技能加严格的测试过滤，反而降低了下游任务表现。过度过滤自我改进 = 把"敢试错"的进化优势阉割掉了。
门控的正确姿势：轻验证（能跑、格式对、比基线不差）+ git 兜底（坏了随时回滚）。让 git 当安全网，而不是让过滤器当守门员。
这个案例就发生在写 harness 仓库的当晚。demo 运行时，ScriptedWorker 在 READ_ONLY 沙箱里尝试写工件，被拒绝两次——同一情况重复出现。放进观察循环：
22262a6你可以在仓库 demo 里亲手复现这四步。它小，但完整：失败 → 本能 → 门控 → 提交 → 可回滚。
三篇连起来，是我眼中"Agent 代码理解基建"的最小完备集：
共同点一眼可见：把"智能"用在刀刃上，把其余一切交给确定性工程。LLM 负责决定做什么，基建负责保证做得对、做得起、做得回。这不是对 AI 的不信任，恰恰是让它可持续信任的前提。
全部实现：harness-engineering · repowise-zh（中文指南） · android-agent-skills · awesome-agent-harnesses（生态全景）