Evolver：让 Agent 自己演化自己的 Harness

前言

AlphaEvolve 用进化算法改进代码，发现了 56 年来对 Strassen 矩阵乘法算法的首次改进。但 AlphaEvolve 是用来改进数学算法的，不是用来改进 Agent 自身的。

如果一个 Agent 能用类似的思路，审查自己的运行日志，发现自己的错误模式，然后自动给自己打补丁——这件事能工程化吗？

EvoMap/evolver 给出了一个完整的尝试。

Evolver 是什么

Evolver 不是一个 Agent 框架，而是一个协议约束的自演化引擎：

Agent 检查自己的运行历史
提取信号，选择策略
生成代码补丁，验证变更
把成功的经验沉淀成可复用的资产

整个过程有审计轨迹，有回滚机制，有爆炸半径控制。

核心问题：Agent 怎么让自己变得更好

大多数 Agent 的 prompt 调优流程：

1	跑一圈 → 看日志 → 人工改 prompt → 再跑一圈

这个循环里最贵的是人。

Evolver 要自动化这个循环。

它的输入是：

Agent 的运行时日志
会话记录
内存文件

它的输出是：

代码补丁
新的技能定义
更新后的记忆

中间的决策过程被一个叫 GEP（Genome Evolution Protocol） 的协议严格约束。

拆解一：信号提取与反停滞机制

信号提取流程

每个演化 cycle 从 extractSignals() 开始，扫描：

最近的会话日志
今日日志
内存文件
历史演化事件

用正则匹配和统计分析提取信号。

信号种类

类型	信号示例	说明
错误类	`log_error`、`errsig:<text>`、`recurring_error`	同一错误出现 3 次以上
缺失类	`memory_missing`、`user_missing`、`session_logs_missing`	数据缺失
机会类	`user_feature_request`、`capability_gap`、`perf_bottleneck`	改进机会
工具滥用	`high_tool_usage:<tool>`、`repeated_tool_usage:exec`	某工具调用超 10 次
停滞类	`repair_loop_detected`、`evolution_stagnation_detected`	修复循环检测

反停滞设计

系统会检查最近 10 次 EvolutionEvent：

信号压制：如果一个信号在最近 8 次里出现了 3 次以上，直接压制这个信号——不让系统在同一个问题上反复打转
强制创新：如果所有信号都被压制了，会强制注入 evolution_stagnation_detected 和 stable_success_plateau，迫使系统从 repair 跳到 innovate
失败切换：连续 5 次失败后，占主导地位的 Gene 的匹配信号会被剥离，强制选一个不同的 Gene

这解决了自演化系统最容易掉进去的陷阱——修复循环：

1 2	Agent 发现一个错误 → 尝试修复 → 修复失败引入新错误 → 再次检测到错误 → 再次尝试相同策略（循环）

Evolver 用信号频率统计 + 强制创新切换打断这个循环。

拆解二：记忆图谱的因果推理

记忆图谱结构

Evolver 的记忆图谱存储在 memory/graph/ 目录下，记录四种节点：

1	SignalSnapshot → Hypothesis → Attempt → Outcome

工作流程

每次 cycle 开始时：

关闭上一次 Attempt 的 Outcome（成功还是失败）
记录当前的 SignalSnapshot
生成 Hypothesis（信号 + 选中的 Gene + Mutation）

getMemoryAdvice()：策略级因果学习

分析历史 Hypothesis → Attempt → Outcome 链条，计算每个 Gene 的成功率：

成功率 < 0.18 且尝试过 2 次以上的 Gene → ban 掉
全局成功率 < 0.12 且尝试过 3 次以上的 Gene → ban 掉
成功率最高的 Gene → 标记为 preferred

这不是简单的”上次成功就再用”，而是一个因果推理链：

在特定信号条件下，用某个 Gene 生成某个 Mutation，执行后结果如何？

下一次遇到相似信号，系统会跳过已经证明无效的策略，优先选成功率高的。

对比其他方案

项目	记忆机制	特点
OpenClaw	会话历史	只记内容，不记因果
Codex	推理轨迹	保模型思维连续性，不保跨 session 策略学习
Evolver	记忆图谱	唯一在 harness 层面做了策略级因果学习

拆解三：爆炸半径控制与固化流程

max_files 约束

每个 Gene 都定义了自己允许修改的最大文件数：

修复错误的 Gene → 限制在 3 个文件以内
创建新技能的 Gene → 允许 5 个文件

这是编译期确定的爆炸半径约束，不依赖运行时判断。

与 Codex 的对比

维度	Codex	Evolver
控制对象	Agent 当前能做什么操作	Agent 对自身的修改能影响多大范围
机制	Starlark + Guardian + 用户确认	max_files + forbidden_paths
类型	运行时权限控制	变更管理

固化流程（solidify）：安全闸门

Evolver 的固化流程是整个系统的安全闸门：

Git 状态检查 → 不在 Git 仓库里就拒绝运行
协议违规检查 → Mutation 或 PersonalityState 对象缺失/格式错误就拒绝
爆炸半径计算 → 用 git diff 统计变更的文件数和行数
约束校验 → 对照 Gene 定义的 max_files、forbidden_paths 检查

GEP 协议：Genome Evolution Protocol

GEP 借了生物学的隐喻，但底层是一套严格的 JSON schema 和状态机。

核心组件

Genome（基因组）
  └── Gene（基因）
        ├── match_signals: 匹配的信号模式
        ├── mutations: 变异操作列表
        ├── max_files: 最大修改文件数
        └── forbidden_paths: 禁止修改的路径

演化循环

┌─────────────────────────────────────────┐
│  1. extractSignals() 提取信号            │
│  2. getMemoryAdvice() 获取历史建议       │
│  3. selectGene() 选择最优 Gene           │
│  4. generateMutation() 生成变异          │
│  5. execute() 执行变更                   │
│  6. validate() 验证结果                  │
│  7. solidify() 固化或回滚                │
│  8. updateGraph() 更新记忆图谱           │
└─────────────────────────────────────────┘

总结

Evolver 的核心价值在于：

✅ 自动化演化循环：从人工调优到自动迭代
✅ 反停滞机制：避免修复循环，强制创新
✅ 因果学习：策略级记忆，而非内容级记忆
✅ 爆炸半径控制：变更影响范围可预测、可约束
✅ 审计与回滚：完整的演化轨迹，可追溯、可回滚

这是 Agent 基础设施的重要演进方向——从”做好当前任务”到”让自己变得更好”。

参考链接

如有问题欢迎在评论区留言交流！