OpenEvolve v0.4.0：本该撤回的改动，仍可能进入评测

OpenEvolve 通过反复提出修改、评测新版本，尝试改进程序。开发者提供起始程序、评价器和迭代次数；评价器负责检查程序并返回指标。模型提出下一份修改时，会收到此前程序及其指标作为上下文，可用的运行反馈也可能进入后续提示。整个过程是在输入程序的不同候选版本之间搜索。工作流程说明、生成与评测源码

这种搜索还可能有一项要求：保留其他代码使用的调用接口。函数名和参数决定了调用方怎样调用它。内部实现可以允许修改，接口却可能必须保持不变。OpenEvolve 的优化指南明确区分了内部改动与函数签名、外部接口的保留。接口约束

v0.4.0 的发布说明介绍了一项执行文本边界的功能：用注释标记划出允许修改的区域，评测前将区域外的改动恢复成父程序的文字。父程序就是当前被修改的版本。这项功能需要通过 enforce_evolve_blocks 主动开启。发布说明

一次函数改名，就能看清恢复步骤该做什么

设想一个合成示例：调用方需要 solve(values)，函数定义放在 EVOLVE-BLOCK-START 和 EVOLVE-BLOCK-END 注释标记之外。两条标记之间的 return sorted(values) 才是允许修改的区域。

提案同时改了两处。标记内的语句变成 return list(sorted(values))；标记外的函数名则变成 solve_fast。第一处符合示例设定的边界，第二处改掉了调用方需要的名字。新表达式和 solve_fast 这个名字都不能证明速度更快。这份虚构提案只用于跟踪两处改动。

编辑自制教学示意。实线路径展示根据源码推断的漏传开关路径；虚线路径展示工作进程开关为 True 时的对照。

预期结果在图右下：函数仍叫 solve，内部采用提案的新语句。当恢复功能已开启，而且两份程序各有一对完整标记时，辅助函数会拼出这个组合。它从父程序取块外文字，包括标记行，再从提案取块内内容。拼好的候选随后可以交给评价器判断。指定文字恢复了，并不能单独说明新的内部实现有用。重建辅助函数、后续评测

开关没有装进传给工作进程的配置字典

沿着配置追到真正使用它的进程，漏传的位置就清楚了。OpenEvolve.run 把主配置交给并行控制器，控制器再启动独立的工作进程。控制器的 _serialize_config 方法准备一个按名称组织设置的字典，用于传递配置。它完整返回的字典中没有 enforce_evolve_blocks。主入口、配置传递代码

进程池将这个字典交给 _worker_init。初始化函数根据收到的配置项重新构造 Config。缺少的设置于是采用类中定义的默认值 False。而工作进程调用恢复辅助函数之前，检查的是自己的这个值。工作进程初始化与恢复条件、配置默认值

对于保存下来的 v0.4.0 提交 f7b633986c0b3dbd0a171f6eb0cb0f0ba4fdfb0c 中未经修改的这条路径，由此可以推断：主进程明确设置的 True 没有被传递，工作进程会跳过恢复。 这是根据交接链得出的源码推断，本文没有报告完整工作进程实跑。图中间解释了这一步：主配置 True → 字典缺项 → 工作进程新建配置得到 False。完整交接链、默认值

默认值 False 符合需要主动开启的设计。这条路径中的缺陷，是已经明确要求开启的 True 在传递时丢了。启用约定、漏传字段的位置

同一处改名，可以一直留到评价器入口

回到那份 solve_fast 提案。如果此前的候选构造成功，之后的代码长度检查也通过，跳过恢复就会让两处改动都留在传给评价器的文本中。提案的内部表达式留下来了，块外改名也留下来了。图左下展示的就是这个结果。恢复条件、长度检查与评测输入

假如评价器要求 solve，它可能拒绝这份候选。这种拒绝不能证明改码边界生效：恰恰可能因为恢复被跳过，改名才到达了评价器。本文没有确定实际评价器的处理结果。在这个示例中，边界负责恢复指定文字，评价器则另行判断收到的候选。

函数名和内部新语句，要一起检查

如果要依赖这项边界，一个有用的诊断是同时查看工作进程实际使用的设置，以及进入评测前一刻的确切候选文本。这个例子的预期组合很明确：函数仍叫 solve，标记内的语句采用 return list(sorted(values))。评测入口、预期重建方式

只检查函数名，也会放过原封不动的父程序，因为它本来就叫 solve。同时确认内部新语句被保留，才能把预期重建与直接丢弃提案区分开。主配置的 True，以及评价器的评分或报错，都没有回答这个问题：究竟是哪一份文本进入了评测？

因此，针对 v0.4.0 的这条交接路径，要依赖改码边界，就需要一直追到评价器入口的候选程序。配置要求与执行效果的差别，在这里落到了具体文字上：允许的内部改动仍在，块外函数名则可能已经恢复，也可能被放了过去。

这轮搜索修改的对象是输入程序。这里的配置追踪没有证明 OpenEvolve 自身的改进机制变强，也没有展示一般意义上的 AI 递归自我改进。

来源范围：冻结的 v0.4.0 提交 f7b633986c0b3dbd0a171f6eb0cb0f0ba4fdfb0c，由保存下来的标签记录标识。图为编辑自制教学示意。本轮修订没有新增实验，未报告完整进程池、工作进程、模型或评价器实跑，也没有独立实测的优化收益。