附录 A 提议器的定性行为
本节考察提议器在搜索过程中如何使用文件系统，基于 TerminalBench-2 运行（10 次迭代，Claude Opus 4.6）。
A.1 文件访问统计
为验证提议器确实实质性地使用了文件系统，而非默认进行局部编辑，我们记录了每次迭代的所有文件读取操作。
Table 8 总结了结果。提议器每次迭代中位数读取 82 个文件（范围 69-99），大致均匀分布在先前 Harness 源代码（41%）和执行轨迹（40%）之间，其余为分数摘要（6%）和其他文件（13%）。这证实了提议器的访问模式是非马尔可夫的：它通常检查大部分可用历史，而非仅基于最近的父代进行优化。
| 统计量 | 值 |
|---|---|
| 每次迭代读取文件数（中位数） | 82 |
| 每次迭代读取文件数（范围） | 69-99 |
| 文件类型分布 | |
| Harness 源代码 | 41% |
| 执行轨迹 | 40% |
| 分数/摘要文件 | 6% |
| 其他 | 13% |
Table 8：TerminalBench-2 搜索运行中的提议器文件访问统计（10 次迭代，Claude Opus 4.6）。提议器广泛读取文件系统，对先前源代码和执行轨迹的关注大致相当。
A.2 定性行为：对先前失败的因果推理
TerminalBench-2 搜索日志揭示了一条清晰的叙事弧线，其中提议器从自身的回退中学习。它不是在局部编辑中随机游走，而是形成了关于早期候选方案为何失败的明确诊断，然后转向更安全的设计模式。下方日志框内的所有文字均为提议器在每次迭代中记录的推理的原文引用（强调为我们所加）。
迭代 1-2：有前景的 bug 修复被提示编辑所混淆。 前两次迭代都将合理的结构性修复与提示模板修改捆绑在一起，且两者都相对 64.4% 的 Terminus-KIRA 基线大幅回退。迭代 1 针对泄露的终端标记导致的观测损坏问题，并添加了一个循环断路器：
假设：CMDEND 标记片段在长时间运行的任务中泄露到 LLM 的观测中，导致模型混淆并进入无限的无工具调用循环。剥离这些标记 + 添加循环断路器将恢复被浪费的步骤。
该候选方案还引入了一个新的面向清理的提示模板和一个验证检查表。迭代 2 提出了一种不同的状态机修复：
双重确认完成机制导致验证螺旋。在轨迹中观察到智能体早期就解决了任务，但因每次验证命令重置 _pending_completion 而额外浪费了 15-40+ 步，需要再次执行 task_complete → checklist → verify 循环。
该第二个候选方案完全移除了 pending-completion 机制，同时也保留了标记剥离和新提示。它仍然出现了回退，这使得提议器拥有了两个失败的候选方案——它们有不同的结构性变更但共享同一个提示干预。
迭代 3：提议器识别出混淆因素。 到迭代 3 时，提议器明确推断出回退主要不是由结构性 bug 修复本身导致的：
先前尝试：evo_marker_fix (58.9%, -5.6pp)，evo_single_confirm (57.8%, -6.7pp) --- 两者均回退。回退的根本原因：提示模板变更（清理指令）导致智能体在任务完成前删除了必要的状态。结构性 bug 修复被有害的提示变更所混淆。evo_strip_only 隔离了两个已验证的结构性修复。
这是轨迹中的关键因果步骤。提议器注意到前两次失败的共同因素不是特定的 bug 修复，而是面向清理的提示重写。因此，它恢复了原始提示，仅测试标记剥离和循环断路器。由此产生的候选方案仍然略有不足（63.3%，-1.1pp），但其损失远小于早期版本，这支持了混淆因素的诊断。
迭代 4-6：对已诊断失败模式的直接修复仍然回退。 接下来的三次迭代继续探索同一设计空间区域，但现在对完成逻辑为何脆弱有了更明确的理论。迭代 4 将失败归因于一个具体的状态机 bug，其中验证命令重置完成标志并将智能体困在重复的检查表循环中：
移除两行将完成标志重置的 self._pending_completion = False 代码，这些代码在中间命令运行时重置了完成标志。这修复了一个状态机 bug：(1) 智能体调用 task_complete → 看到 QA 检查表，_pending_completion = True (2) 智能体运行验证命令 → _pending_completion = False（bug！）(3) 智能体再次调用 task_complete → 再次看到检查表 → 无限循环。
提议器甚至引用了具体的轨迹证据，指出 configure-git-webserver 产生了基线失败，智能体在有效解决任务后陷入了 30-60 步的验证螺旋。迭代 5 尝试在保留确认的同时弱化清理语言，但仍然编辑了提示并严重回退。迭代 6 回到更安全的 evo_strip_only 基础，并提出了一项系统级优化：
当终端输出未变化时，空命令轮次浪费了完整的 LLM 往返。智能等待（在下一次 LLM 调用前最多轮询窗格 3 × 5 秒）可在长时间运行的任务上节省 5-15 个轮次。
该变更也出现了回退。至此，提议器已经学到了一个具体的经验教训：即使局部假设看似合理，对提示和完成流程的修改仍然具有高风险。
迭代 7：获胜候选方案。 在连续六次回退之后，提议器将策略从修改控制循环转变为在循环开始之前添加信息：
所有 6 次先前迭代都从 64.4% 基线回退，因为它们修改了完成流程、提示模板或观测处理。evo_env_bootstrap 采取了不同的方法——纯加性。它在第一次 LLM 调用前通过单个 shell 命令收集环境快照，并将其附加到初始提示。不修改任何其他方法。这应该能在依赖关系密集的任务上消除 3-5 个浪费的探索轮次，同时不会在已经通过的任务上产生回退风险。
该候选方案是迄今为止的最佳结果。重要的不仅是迭代 7 获胜，而是提议器清楚地阐述了为何它应该更安全：它避免触碰先前脆弱的完成机制，而是添加了主要在困难任务上有用的信息。
迭代 8：组合。 找到一个加性改进后，提议器接下来尝试将其与一个早期的结构性修复组合：
组合两个正交修复——环境快照（节省早期探索轮次）+ 带无工具调用循环断路器的标记剥离——将产生 +1-3pp 的提升，因为它们解决的是独立的失败模式，不触碰提示或确认流程（在先前 7 次迭代中有 5 次导致了回退）。
迭代 10：跨运行迁移。 提议器引用了一次先前独立搜索运行的结果：
演化历史显示"不清理服务制品"带来了 +18pp 的提升。迭代 9 (evo_no_cleanup_directive) 针对相同的思路，但在评估前崩溃了。
总结。 搜索轨迹表明提议器所做的不仅仅是随机变异。在前七次迭代中，它识别出一个混淆因素，直接测试了隔离混淆因素的假设，观察到控制流和提示编辑仍然脆弱，然后刻意转向一种纯加性修改——该修改成为本轮运行中的最佳候选方案。随后它尝试将该获胜思路与早期修复组合，甚至跨运行迁移经验教训。这种对先前失败的因果推理正是完整历史文件系统访问所赋能的，也是压缩反馈优化器无法支持的。