当业界仍在争论 AI Agent 应当依赖预定义工作流还是动态学习时，一个更底层的范式正在浮现 —— 让 Agent 拥有类似生物进化的「基因组」，通过编码、变异与自然选择实现自我迭代。Evolver 项目提出的 Genome Evolution Protocol（GEP）正是这一思路的工程化实现。本文将剖析 GEP 的核心抽象、闭环工作流以及关键工程参数，为构建自进化 Agent 系统提供可落地的参考。
基因组编码：Gene 与 Capsule 的双层资产结构
GEP 的核心假设是：Agent 的每一次改进都应当被记录为可复用的进化资产，而非散落的提示词补丁。Evolver 将这类资产抽象为两层结构 ——Gene（基因）与 Capsule（胶囊）。
Gene 是最小粒度的进化单元，定义在 assets/gep/genes.json 中。每个 Gene 包含以下字段：唯一标识符、适用信号类型（如 error_recovery、latency_spike）、具体的变异指令，以及可选的 validation 验证命令数组。验证命令是 GEP 安全模型的关键组成 —— 系统仅允许执行以 node、npm、npx 开头的命令，且拒绝任何命令替换（反引号或 $()）与 shell 操作符（;、&、| 等），每个命令超时上限为 180 秒。
Capsule 则是多个 Gene 的组合，用于处理更复杂的场景。比如一个「处理用户认证失败」的 Capsule 可能包含三个 Gene：日志解析、错误消息生成、以及重试策略。Capsule 的优势在于提供更高层次的抽象，使得进化资产可以在不同任务间复用。
除了资产定义，GEP 还引入 PersonalityState（人格状态）的概念。每次进化运行都被一个显式的 Mutation 对象所门控 ——Mutation 描述了本次进化的意图（创新、优化还是修复）、强度以及预期效果。人格状态则记录了 Agent 的「性格」参数，如风险偏好、响应风格等，这些参数同样可以被进化所修改。这种设计确保了进化过程不是盲目的随机变异，而是有方向、有约束的渐进式迭代。
变异生成：信号提取与策略驱动的闭环
Evolver 的变异生成并非随机突变，而是遵循「信号提取→策略选择→资产匹配」的闭环流程。
信号提取阶段，系统扫描 memory/ 目录下的运行时日志、错误模式和历史事件。关键设计在于「信号去重」机制：当系统检测到连续多次相同或相似的信号时，会判定为「停滞模式」并降低修复优先级，避免陷入修复循环。这对应了生物进化中的「选择压」调整 —— 如果某种变异无法带来实质性改进，进化引擎会自然地转向其他方向。
策略选择由 EVOLVE_STRATEGY 环境变量控制，提供四档预设：
| 策略 | 创新占比 | 优化占比 | 修复占比 | 适用场景 |
|---|---|---|---|---|
balanced |
50% | 30% | 20% | 日常运营，稳定增长 |
innovate |
80% | 15% | 5% | 系统稳定，追求新功能 |
harden |
20% | 40% | 40% | 重大变更后，聚焦稳定性 |
repair-only |
0% | 20% | 80% | 紧急状态，全员修复 |
这一设计将进化意图显式化。团队可以根据 Agent 的当前状态选择合适的策略，如同调整生物种群的选择压。
资产匹配阶段，Selector 逻辑根据提取的信号从 Genes 和 Capsules 中选择最佳匹配项，并输出一个 JSON 格式的 Selector Decision。最终，这些决策被组装成严格协议格式的 GEP Prompt，指导下一轮进化。
选择淘汰：审计追溯与安全门禁
如果变异生成是「出生」，那么选择淘汰就是「筛选」。GEP 通过三层机制实现这一过程。
第一层是 EvolutionEvent 审计。每一次进化运行都会在 assets/gep/events.jsonl 中记录一条不可变的事件记录，包含时间戳、输入信号、选中的基因 / 胶囊、执行的策略，以及最终结果。这一设计使得进化过程完全可追溯，满足合规与调试需求。
第二层是 Review 模式。通过 node index.js --review 可以启用人工确认环节 —— 系统在执行变异前暂停，等待操作者审核并批准。这一模式对应了「人类在环」（Human-in-the-Loop）的工程实践，适用于生产环境或高风险场景。
第三层是 验证命令安全门禁。前文提到的白名单机制并非形同虚设 ——solidify.js 中的 isValidationCommandAllowed 函数会逐项检查 Gene 的 validation 命令。任何试图突破白名单的操作都会被拒绝。对于通过 A2A 协议从外部接入的资产，还额外要求显式的 --validated 标记，且 promotion 过程永不覆盖同名本地 Gene。
此外，Evolver 提供 受保护源文件 机制 —— 核心引擎代码被标记为不可覆盖，防止自主 Agent 绕过进化协议直接修改底层实现。这相当于生物体的「关键基因不可变异」原则。
工程落地的关键参数
将 GEP 应用于实际 Agent 系统时，以下参数值得重点关注：
MEMORY_DIR 指定信号来源目录，默认 ./memory。建议在 Agent 运行时将关键日志结构化写入该目录，确保进化引擎有足够的信号素材。
HEARTBEAT_INTERVAL_MS 控制与 EvoMap Hub 的心跳间隔，默认 360000 毫秒（6 分钟）。若使用网络协作功能，需要合理调整此值以平衡实时性与资源消耗。
EVOLVER_ISSUE_MIN_STREAK 定义触发自动 GitHub Issue 的最低连续失败次数，默认 5 次。结合 EVOLVER_ISSUE_COOLDOWN_MS（默认 24 小时）可以构建自动化的错误上报链路。
WORKER_ENABLED 与 WORKER_DOMAINS 则控制节点在 EvoMap 网络中的角色 —— 开启后节点可以接受来自其他节点的进化任务，实现分布式协作进化。
与 Skill Tree 的本质差异
昨日文章对比了 GEP 与 Skill Tree 的范式差异。从工程实现角度看，两者最核心的区别在于状态表示的可变性。Skill Tree 将能力定义为静态节点，树结构相对稳定；而 GEP 将能力编码为可变异、可组合的基因单元，每一次进化都可能导致基因库的扩充或重构。从这个意义上说，Skill Tree 更接近「能力的目录管理」，而 GEP 则是「能力的进化演化」。后者更适合需要持续自我改进的在线 Agent 系统。
资料来源：GitHub - EvoMap/evolver（https://github.com/EvoMap/evolver）