capability-evolver：让 AI Agent 自我修复的进化引擎

大多数 Agent 项目卡在同一个地方：上线之后就不再变好。日志里的报错要人去看，效率瓶颈要人去猜，改一版代码再回归测试，一轮下来半天没了。capability-evolver 想干的事有点激进——让 Agent 自己读日志、自己找问题、自己改代码，而且整个过程留下可审计的痕迹。

它由 OpenClaw 官方维护，定位是「元技能」（meta-skill）：不直接替你做业务，而是给 Agent 装上自我检视和迭代的能力。当前版本 v1.27.3，社区下载 6.2k、安装 556，推荐率 99%，被平台判为 BSS 等级 S。整包 135.5 kB，零第三方依赖，跑起来只需要 Node.js。

一、基本信息

二、Agent 为什么需要「进化」这一层

先把这个技能解决的问题说清楚，不然容易把它当成又一个代码生成器。

一个长期运行的 Agent 系统，问题很少来自「模型不够聪明」，更多来自三种慢性损耗。第一种是环境漂移：依赖版本变了、系统命令不兼容了、路径写法在不同平台上失效了，报错来得零散又反复。第二种是性能衰减：记忆文件越滚越大，检索越来越慢，上下文塞满了历史垃圾。第三种是能力缺口：某类任务反复失败，但没人有空回头给它补一个专用处理逻辑。

传统做法是人工巡检——看日志、定位、改代码、测试、上线。这套流程的问题不在于难，而在于「不值得为一个小修复走一遍」。于是小问题一直被拖到大问题。

capability-evolver 的思路是把这条流程自动化，并且给它套上约束。它扫描运行历史，找出错误模式和低效模式，然后生成补丁或优化代码，在限定范围内应用，失败就回滚。整个过程按 GEP 协议记录下来，形成可追溯的进化链。

一句话概括它的设计哲学：允许 Agent 改自己，但每一次改动都要留痕、要限量、要能撤销。

三、三种运行模式：从放开跑，到一步一确认

启动方式就是一条命令，模式由参数决定。这个设计决定了它的安全边界，值得先看清。

默认模式就是全自动，这一点需要特别注意。它的名字「Mad Dog」不是玩笑，意思是发现有价值的问题就直接动手，不等人。对熟练用户在隔离环境里试能力很爽，但如果有人在服务器上不加参数直接跑，等于把改动权限交给了模型判断。

四、GEP 协议：进化过程怎么被记录

GEP 是这套东西和「一堆脚本拼起来的自动改码工具」的分水岭。它把进化拆成三类结构化资产：

每一份资产都有内容哈希，通过 SHA-256 内容寻址。这意味着同一份记录在不同机器上校验值一致，改动一个字节就会得到不同的地址，伪造和篡改在机制上被堵掉。胶囊之间通过父级 ID 构成树状结构，一次进化由哪次进化派生而来，链条是连着的。

一个典型的胶囊长这样：触发信号里包含具体的报错特征（比如某条命令在目标平台上不存在）、命中哪条修复基因、本次改动了 2 个文件共 44 行、置信度 0.85、结果状态为成功。配上环境指纹——Node 版本、平台、架构、内核版本、当前工作目录、捕获时间——事后复盘时能还原「当时是什么环境出的问题」。

这些字段的价值不在于好看，而在于它把「Agent 改了自己的代码」这件事从黑箱变成了流水账。出问题时可以顺着事件日志往上查，是哪次进化引入了变更。

五、安全设计：五道闸门

让程序改自己的代码，最怕的是失控。这套实现里能数出至少五层限制，值得逐条看。

还有一条软约束：高风险人格状态下禁止执行创新类操作。系统内置了「递归自改进系统」的身份注入，会根据运行状态在「修复模式」和「强制优化模式」之间切换，状态不稳时只做保守修复。

另外，它的零依赖设计本身就是一层安全措施。整个包只用 Node.js 内置模块，不引入任何 npm 包，等于把依赖投毒这条路直接堵死。对一个要长期待在服务器上、还要动代码的东西来说，这个选择很关键。

六、真正有价值的地方

零依赖，装完就能跑。没有 node_modules 黑洞，没有版本冲突，没有「装到一半某个包编译失败」。135 kB 的包解压完就是全部内容，审计成本极低——想确认它到底干了什么，把 evolve.js 读一遍就行。

改动是有边界的。60 文件、20000 行的单周期上限，看起来是个技术参数，实际是产品判断：宁可多跑几轮小修复，也不做一次大手术。这个约束让「自动改码」从不可控变成可控。

可追溯不是口号。事件日志、胶囊、内容哈希、父级链，四样东西凑齐了完整证据链。这在出问题时是救命的——你能说清「第 37 次进化改了什么、为什么改、结果如何」。

环境偏好可注入。通过环境变量（如 EVOLVE_REPORT_TOOL）把本地偏好传进去，核心代码不用改。同一份代码在个人机器和团队服务器上跑，行为可以不同，但代码库保持干净，升级时不会冲突。

会自己刹车。Singleton Guard 防重复启动、RSS 超限自动重启、饱和度检测避免空转，这些不是锦上添花，而是长期运行的必需品。大多数自制脚本死在这三点上。

七、绕不开的问题

自我修改天然不确定。有协议约束也不等于可预测。复杂系统里，一处「合理」的修复可能在别处引出副作用，而且这种副作用往往要跑几天才显形。这是这类工具的本质风险，不是实现缺陷。

审计门槛偏高。events.jsonl 是纯文本流水，但要看懂一次进化的质量，需要理解基因、胶囊、置信度、爆炸半径这些概念。普通用户打开日志大概率是一头雾水，最后还是选择「相信它」——这就等于放弃了审计。

创新冷却期会挡路。为防止对同一个技能反复做重复创新，系统设了冷却机制。日常没问题，但遇到紧急架构调整、需要连续重构时，这个冷却期会变成阻碍，得手动绕过。

A2A 传播需要额外验证。跨 Agent 分享进化成果时，需要显式加 --validated 标志。设计上是对的——防止未验证的基因扩散——但实际操作中，信任建立流程比较繁琐，团队协作时容易卡在这一步。

对 Git 有硬依赖。回滚能力建立在版本控制之上。如果项目没配 git-sync，安全网就是空的，出问题只能人工救。这个前提在文档里写了，但很容易被忽略。

人格状态判断不透明。什么算「高风险人格状态」、依据什么信号判定，文档没有细说。这部分逻辑是黑盒，对需要完全可解释的合规场景不友好。

八、官方风险表与解读

四个风险项里，唯一标到「中」的是配置误用，这个判断很准。技术层面的闸门做得不错，真正的薄弱点在「人」：拿到包直接在服务器上 node index.js，日志不看，git 不配，跑出问题再回头找原因。

另外两个值得注意的细节。一是环境变量里出现了 GEMINI_API_KEY，说明存在外部模型调用的设计，但安全报告没有检测到实际网络请求——可能是预留能力，也可能是未来版本的依赖，涉及数据外发的场景要留意。二是路径遍历目前只在「提示」级别，建议版本更新时关注这块是否补齐。

九、适合谁，不适合谁

十、落地路径：从试跑到值班

比较稳的推进顺序是这样：

1. 沙箱试跑。拿一个可丢弃的项目，直接跑全自动模式，看它一晚上能发现什么、改什么。目的是建立对它判断力的直觉，不是产出可用代码。
2. 配好 Git。把 git-sync 做成定时任务，确保任何时刻都有可回退的提交点。这一步不做，后面都是空中楼阁。
3. 切审核模式。换到真实项目时立刻加 --review，逐条看它想改什么。前几轮会很慢，但这是校准信任的必要成本。
4. 建立观察指标。错误率、平均响应时间、记忆文件体积、单周期变更行数，四个指标足够判断它在变好还是变坏。
5. 再放开循环。确认稳定后切 --loop，用 cron 或进程管理工具托管，配好崩溃重启和日志轮转。
6. 定期归档。memory/ 目录和 events.jsonl 会一直长，按月归档，否则迟早撑爆磁盘。

十一、文件构成

从体积分布能看出重心：协议层（src/gep）占了绝大部分，光 solidify.js 就有 43.9 kB，主流程反而只有 51.1 kB。这说明工程量主要花在「怎么把一次进化稳定地固化下来」，而不是「怎么调用模型」。

十二、常见问题

结语

capability-evolver 属于那种「想清楚了才敢用」的工具。它的工程完成度不低：零依赖、协议可追溯、五层闸门、体积克制，能看出作者对「自我修改」这件事的敬畏。但它同时把判断权交给了使用者——默认全自动、日志要靠专业能力读、回滚要靠 Git 兜底。

如果你的 Agent 系统已经跑到需要人天天看日志的阶段，它值得认真试一次，从沙箱和 --review 开始。如果你只是想让 AI 帮忙顺手改几行代码，那用不上这么重的东西，一个普通的编码助手就够了。