返回文档库
harness_evolve/notes/ref09_meta-harness.md

Meta-Harness: End-to-End Optimization of Model Harnesses

一句话总结：把"调 harness"（决定给模型喂什么上下文的那层代码）本身变成一个可自动搜索的优化问题——让一个编程 Agent 通过文件系统读遍所有历史候选的源码 / 执行轨迹 / 分数，再改写出更好的 harness；在文本分类、数学检索、终端 Agent 三个域都超过了人类手工设计的最强 harness。

TL;DR 速览

tags: #harness工程 #自我改进 #agentic-search #context-engineering #code-space-optimization #meta-learning

related: [[ref07_ace-agentic-context-engineering]]（被它超过的主基线）· [[ref08_mce-meta-context-engineering]] · [[ref19_gepa]] · [[ref20_alphaevolve]] · [[ref13_adas-automated-design-agentic-systems]] · [[ref25_learning-to-discover-at-test-time]]（TTT-Discover）· [[ref17_self-harness]] · [[ref23_darwin-godel-machine]]

摘要

LLM 系统的表现不只取决于模型权重，还取决于它的 harness……我们提出 Meta-Harness，一个在 harness 代码上做搜索的外层系统。它用一个 agentic proposer，通过文件系统访问所有先前候选的源码、分数与执行轨迹。

三个域的结果：在线文本分类上比 ACE +7.7 分且上下文少 4×；检索增强数学推理上单个 harness 在 5 个 held-out 模型上平均 +4.7 分；agentic coding 上发现的 harness 在 TerminalBench-2 超过最强手工基线。核心论点：更丰富地访问历史经验，就能实现 harness 工程的自动化。

1 介绍：为什么 harness 值得被自动优化

论文开篇给了一个极有冲击力的动机数字：

仅改变固定 LLM 周围的 harness，就能在同一 benchmark 上造成 6× 的性能差距 [47]。

也就是说——模型不变，只改"外面那层代码"，成败可以差 6 倍。这解释了近一年"harness engineering"为何突然变热（论文引用了 OpenAI、Anthropic、martinfowler 等一串工程博客）。但现状是：harness 工程基本靠人手工做——工程师看失败案例、调启发式、在少数几个设计上迭代。本文要问的就是：这个过程本身能不能自动化？

[!TIP] 什么是 harness（模型外壳 / 支架）？ 在本文语境里，harness 是包裹一个固定 LLM 的一段有状态程序，它决定"模型在每一步看到什么上下文"。具体包括： - 存什么（memory / state 更新策略）——例如把哪些历史样本、哪些中间结论留下来； - 取什么（retrieval 策略）——例如用 BM25/向量检索捞哪些示例； - 怎么呈现（prompt 构造 / 编排逻辑）——例如 few-shot 示例的排列、是否分两次调用先草稿后验证。

直觉类比：模型是"大脑"，harness 是"大脑的秘书 + 工作流程"。同一个大脑，配一个会整理资料、按需递材料的秘书，和配一个一股脑把所有文件糊你脸上的秘书，产出天差地别。本文的目标就是自动培养出好秘书。

自然的起点是"文本优化"，但它不匹配。Harness 工程也是"用历史反馈迭代改进文本/代码产物"，所以看起来像文本优化（OPRO、TextGrad、GEPA、AlphaEvolve、Feedback Descent 等）。但作者指出这些方法都把反馈压缩得太狠，原因是它们为了可扩展性做的工程妥协，而非"长程依赖不重要"的证据：

压缩方式 代表方法 问题
只看当前候选（无记忆） Self-Refine, OPRO, TextGrad 丢掉跨候选的对比信息
主要靠标量分数 AlphaEvolve, AdaEvolve 只知道"失败了"，不知道"为什么失败"
只给短模板 / LLM 摘要 GEPA, Feedback Descent 摘要把可诊断的细节压没了

作者的核心观察是——harness 作用于长时程：一个"存什么/何时取/怎么呈现"的决定，可能在很多推理步之后才显现出后果。压缩反馈恰恰抹掉了把"下游失败"追溯到"上游 harness 决策"所需的信息。下面这张表（Table 1）是全文的动机核心：

[!NOTE] Table 1｜各文本优化方法的"每次迭代上下文量（MTok/iter）"

方法 历史 日志内容 MTok/iter
OPRO [51] 窗口 过去的 (解, 分数) 对 0.002
TextGrad [53] 最近一条 当前产物的文字反馈 0.015
AlphaEvolve [35] 窗口 程序库 + 评测分数 0.022
GEPA [1] 摘要 rollout 轨迹的反思式反馈 0.008
Feedback Descent [26] 摘要 对比 + 文字反馈 0.012
TTT-Discover [54] 窗口 上一个解的片段 0.026
Meta-Harness 全部 所有日志与分数 10.0

逐项讲透：MTok/iter 是"评估一个文本产物后、在该论文考虑的最大设定下所能产生的完整上下文"的估计。别人是 0.002–0.026 百万 token（即 2K–26K token），Meta-Harness 是 10 百万 token——高出 2–3 个数量级。作者进一步说，在他们的设定里，单次评估可产生高达 1000 万 token 的诊断信息。这就是"诊断足迹（diagnostic footprint）"远超既有反馈预算的量化证据：不是别人不想用长反馈，而是他们的框架结构塞不下、也没打算塞。

解法：用 Meta-Harness，一个"通过端到端搜索来优化 harness 的 agentic harness"。它的提议者是编程 Agent（能调开发者工具、改代码），而非裸 LLM——因为经验量迅速超出上下文窗口，提议者必须自己决定查阅什么、并通过与代码库的直接交互来验证改动。关键设计：通过文件系统暴露完整历史。实践中在最苛刻的设定下，提议者每次迭代读约 82 个文件、参考 20+ 个先前候选。

2 相关工作：三条线索的交叉点

作者把 Meta-Harness 定位在三条线索的交叉：外部记忆的自适应访问、可执行代码搜索、文本优化。下面把每条线索里的关键前作讲透（这对理解本文的"新在哪"很重要）。

[!TIP] ① 外部记忆 / 自适应访问 - RAG（检索增强生成）[28]：不把整个知识库塞进 prompt，而是按需检索相关片段再生成。奠定了"把大知识源当外部资源、按需访问"的范式。 - 交错检索与推理 [48]（如 IRCoT）：把检索和 chain-of-thought 交替进行，边想边查。 - 记忆型 Agent（MemGPT [37]）：借操作系统"分页"的思路，让 LLM 管理超出上下文的长期记忆。 - 递归语言模型（RLM [56]）：让模型递归地对外部长上下文做访问。

Meta-Harness 用了相同的"自适应访问"模式，但放到了更苛刻的场景：提议者要选择性地检视一个庞大的"代码 + 分数 + 轨迹"历史，去改进上下文管理过程本身。

[!TIP] ② 可执行代码搜索（本文最相似的一支） - ELM / Evolution through Large Models [27]：最早提出"把大模型当进化搜索里的变异 / 交叉算子"。 - FunSearch [39]：在固定程序骨架内进化"指定的函数"，用程序搜索做数学发现。 - ADAS（Automated Design of Agentic Systems）[20]：用一个 meta-agent 从历史发现里"编程出"新 agent。见 [[ref13_adas-automated-design-agentic-systems]]。 - AFlow [58]：在 workflow 图空间里搜索 agentic 系统。 - MemEvolve / 元进化记忆 [57][50]：搜索跨任务持久的记忆设计。

Meta-Harness 的差异：它搜索的是任务专用的 harness（prompt 构造、检索、状态更新，且任务间会 reset），而且外环刻意极简——不靠固定 scaffold、不靠历史 archive、不靠持久记忆机制，只给提议者无限制的文件系统访问权，让 Agent 自己决定看什么、并在完整 harness 实现上搜索，而非在预定义的"上下文管理过程空间"里填空。

[!TIP] ③ 文本优化方法（被本文当作对照/基线） - ProTeGi [38]：用"文字版梯度下降 + beam search"自动优化 prompt。 - OPRO [51]：把 LLM 当优化器，喂它历史 (解, 分数) 让它提新解。 - TextGrad [53]：把"文字反馈"当作可反传的"梯度"，串起多组件优化。 - GEPA [19]：反思式 prompt 进化，用 rollout 轨迹的反思反馈，能超过 RL。见 [[ref19_gepa]]。 - AlphaEvolve / OpenEvolve [35][43]：LLM 引导变异的进化式编码 Agent，配程序库 + 标量分数。见 [[ref20_alphaevolve]]。 - Feedback Descent [26]：靠成对比较做开放式文本优化（同组作者前作）。

它们不太适合 harness 工程的原因：优化目标是一个完整可执行过程，相关反馈分散在代码 / 分数 / 轨迹里，很难提前"总结"好。Meta-Harness 让提议者能对着失败样例和它们的执行轨迹去推理，提出有针对性的改动，而不是只对聚合分数或摘要做反应。

一句话把本文的"祖源"说清：它把信用分配（credit assignment）与元学习（meta-learning）[40;46;3;17;44] 的老思想，搬到了"近期编程 Agent 能力跃升"所解锁的新范围里——不更新权重，而是在 harness 层做信用分配：用过去 rollout 的经验，刻意推理"哪些步骤/组件该为失败负责"，再改写治理未来行为的外部代码。

3 方法：一个"优化 harness 的 harness"

3.1 优化目标

harness 是包裹固定模型 \(M\) 的有状态程序。给定任务分布 \(\mathcal{X}\)，对任务实例 \(x \sim \mathcal{X}\)，用 harness \(H\) 跑出一条轨迹 \(\tau \sim p_M(H, x)\)；任务奖励 \(r(\tau, x)\) 给轨迹打分。目标是找到使期望最终奖励最大的 harness：

\[ H^{*} = \arg\max_{H}\ \mathbb{E}_{x \sim \mathcal{X},\ \tau \sim p_M(H, x)}\big[\, r(\tau, x)\,\big] \tag{1} \]
符号 含义
\(M\) 固定（冻结）的语言模型，搜索过程中不改权重
\(\mathcal{X}\) 任务分布（如"文本分类任务" / "IMO 级数学题"）
\(H\) 一个 harness = 有状态程序（决定每步给 \(M\) 看什么上下文）
\(x\) 从 \(\mathcal{X}\) 采样的任务实例
\(\tau \sim p_M(H, x)\) 在 \(H\) 和 \(M\) 共同作用下产生的 rollout 轨迹（含 prompt、工具调用、模型输出、状态更新）
\(r(\tau, x)\) 任务专用奖励函数（如分类准确率、数学题是否答对）
\(H^{*}\) 使期望奖励最大的最优 harness

[!TIP] 把式 (1) 讲透 + 举例 逐项物理含义：我们在程序空间里找一个 \(H\)，让"从任务分布里随机抽题、用这个 harness 驱动固定模型作答"的平均得分最高。注意三点： 1. 优化变量是 \(H\)（一段代码），不是模型权重——这是它和 RL/微调的根本区别。 2. 期望套了两层随机：外层是抽哪道题（\(x\sim\mathcal X\)），内层是同一道题模型输出的随机性（\(\tau\sim p_M\)）。所以评估要多次采样求平均。 3. 多目标时用 Pareto 支配：当同时在意准确率和上下文成本，不预先合成一个标量，而是报告 Pareto 前沿（见 §4.1 的 Figure 3）。

具体例子（在线文本分类）：\(\mathcal X\) = LawBench 的罪名分类题；\(H\) = "先检索 5 个最相似的已标注样本 → 出草稿标签 → 再检索支持/反对样本做二次验证"这套两段式程序；\(\tau\) = 这套程序在某道题上产生的两次模型调用 + 中间检索 + 最终标签；\(r\) = 最终标签是否正确（0/1）。式 (1) 就是在问：什么样的检索+验证控制流，能让固定的 GPT-OSS-120B 在这批题上平均答对率最高？

3.2 搜索循环（核心图）

Figure 2: Meta-Harness 搜索循环

Figure 2 逐元素解读（这张图就是全文方法的心脏）： - 左侧「Filesystem w/ All Experience」：一个树状文件系统，根目录 / 下每个子目录（1, 2, …）是一个历史候选 harness，里面存着它的源码、执行轨迹、分数。这是提议者的"记忆"，也是它的反馈通道。 - 步骤 ①「Propose Harness Code」：一个 Agent（图里那个想着 "Maximize" 的小机器人）读文件系统里的历史经验，提出一份新的 harness 代码。注意箭头从 filesystem 指向 Agent 再指向 "Harness"——它是读历史→写新代码。 - 中间「Harness + LLM」→「Tasks」→ 步骤 ②「Evaluate」：把新 harness 套在固定 LLM 上，在评测任务上跑，得到分数。 - 步骤 ③「Store all Logs to Filesystem」：把这次的全部日志（提议的代码、推理轨迹、评测分数）写回文件系统的一个新目录，然后循环重复。 - 闭环含义：每一轮都让"可供查阅的历史经验"增长一点，于是提议者的诊断能越来越有据可依。

[!NOTE] Algorithm 1｜Meta-Harness 外层循环（伪代码复述） 输入: 任务 X, 模型 M, 提议者 P, 迭代数 N 初始化: 种群 H（一组有效的初始 harness，如 zero-shot/few-shot/ACE/MCE） 初始化: 文件系统 D ← ∅ # 存代码、分数、轨迹 for H in 种群: # 先评估所有初始 harness E_H ← Evaluate(H, M, X) D ← D ∪ {(H, E_H)} for t = 1..N: P 查询文件系统 D # 检视先前 harness 与分数 P 提出 k 个新 harness {H_1..H_k} for H in {H_1..H_k}: if H 通过接口校验: D ← D ∪ {(H, Evaluate(H, M, X))} 返回 D 中 harness 的 Pareto 前沿 关键：它维护一个种群和 Pareto 前沿，但不设父代选择规则——提议者可以自由检视任何历史 harness 及其轨迹。跑固定轮数后，只在 Pareto 前沿上做一次最终 test-set 评估。提议者永远看不到 test-set 结果，它唯一的反馈来自 search set 和搜索期间记录的执行轨迹。

3.3 为什么"代码空间搜索 + 文件系统全历史"是关键

作者把"设计上的克制"讲成了方法论主张：

[!TIP] 为什么必须是"编程 Agent"而不是"裸 LLM"？ 因为历史经验量（可达千万 token）远超任何上下文窗口。裸 LLM 只能被动接收外环替它组装好的固定 prompt；而编程 Agent 能主动用 grep/cat 去检索、导航历史产物、并通过实际改代码来验证想法。换句话说，"该看什么"这个决定本身，被从"外环设计者"手里下放给了"Agent 自己"——这正是 Meta-Harness 能随着底层编程 Agent 变强而自动变强的原因。

3.4 实现要点

4 实验：三个域，都打赢手工基线

Figure 1: Meta-Harness 的两个头条结果

Figure 1 解读（全文的"招牌图"）：(左) 在线文本分类的搜索进度——纵轴 best performance，横轴 harness 评估次数。Meta-Harness（红）只用约 4 次评估就追平次好方法（TTT-Discover / OpenEvolve）跑满 40 次的最终精度，并继续爬升、最终高出 10+ 分，远超 ACE、few-shot、zero-shot 的水平线。(右) TerminalBench-2 上 Haiku 4.5 各 harness 的 pass rate——Meta-Harness（红）37.6% 排第 1，超过 Goose(35.5)、Terminus-KIRA(33.7)、Mini-SWE-Agent(29.8)、Terminus-2(28.3)、Claude Code(27.5) 等所有"人手写"的 harness。两个面板分别对应本文"文本优化更快更强"和"agentic coding 超过手工"两大主张。

4.1 在线文本分类

设置：LLM 逐条收到带标签样本、更新记忆、在 held-out 测试集评估。基座 = GPT-OSS-120B。三个数据集（按难度和领域多样性选）：LawBench（罪名，215 类）、Symptom2Disease（22 类）、USPTO-50k（反应物，180 类）。种群从 zero-shot / few-shot / ACE / MCE 初始化，跑 20 迭代 × 每轮 2 个候选 = 40 个候选。

[!TIP] 两个被对标的 SOTA 手工 harness - ACE（Agentic Context Engineering）[59]：用"反思式记忆整理"随时间构建上下文——把有用的经验沉淀进一份不断被增删改的上下文里。是本文文本分类的主基线。见 [[ref07_ace-agentic-context-engineering]]。 - MCE（Meta Context Engineering）[52]：维护并进化一个"自然语言技能库"用于上下文构造。见 [[ref08_mce-meta-context-engineering]]。

结果（Table 2）：Meta-Harness 达 48.6% 平均准确率，超 ACE 7.7 分、超 MCE 8.6 分；且上下文更省——只用 11.4K token，ACE 要 50.8K、MCE 要 28.5K。

Harness USPTO S2D Law 平均Acc 附加上下文(K)↓
Zero-Shot 12.0 63.2 7.0 27.4 0
Few-Shot (all) 15.0 78.3 29.0 40.8 12.3
MCE [52] 14.0 83.0 23.0 40.0 28.5
ACE [59] 16.0 77.8 29.0 40.9 50.8
Meta-Harness 14.0 86.8 45.0 48.6 11.4

Pareto 前沿（Figure 3）：因为在代码空间做自由优化，可以联合表达"要准确率也要省上下文"的偏好，得到一条平滑的 accuracy–context 前沿。

Figure 3: 准确率 vs 上下文 token 的 Pareto 前沿

Figure 3 解读：横轴是附加上下文（字符数），纵轴是测试准确率。★ 是 Meta-Harness 发现的 harness（红色实心为 Pareto 前沿），紫色圆点是 few-shot，橙/蓝大标记是 MCE/ACE。关键信息：Meta-Harness 的整条前沿都压在所有对比方法的左上方——同样上下文预算下精度更高，或同样精度下上下文更省。注意 ACE 在 ~50K 上下文处精度还不如 Meta-Harness 在 ~10K 处。

最重要的科学发现——消融（Table 3）：为隔离"提议者接口里哪部分最关键"，比较三种条件：

提议者能看到 Scores Code Summary Traces 中位Acc↑ 最佳Acc↑
只给分数 ✓ ✓ ✗ ✗ 34.6 41.3
分数+摘要 ✓ ✓ ✓ ✗ 34.9 38.7
Meta-Harness（完整） ✓ ✓ – ✓ 50.0 56.7

[!IMPORTANT] 原始执行轨迹（raw traces）是让 harness 搜索奏效的决定性成分。 完整接口的中位候选都超过两个消融条件的最佳候选。更耐人寻味的是："分数+摘要"几乎不比"只给分数"好（34.9 vs 34.6），说明 LLM 生成的摘要没能恢复缺失信号，甚至可能因为压掉了诊断细节而有害。这直接支撑了 §1 的论点：反馈不能压缩。

对比文本优化器（Table 4）：同样的评估预算下，GEPA 32.6 / Best-of-N 34.0 / OpenEvolve 39.1 / TTT-Discover 34.1 / Meta-Harness 50.0（中位）。而且 Meta-Harness 用 0.1× 的评估次数就追平 OpenEvolve/TTT-Discover 的最终精度，之后继续爬升、最终高出 10+ 分。

[!TIP] TTT-Discover（Learning to Discover at Test Time）[54/55] 一种"测试时发现"方法：把问题当成 discovery problem，用 PUCT（一种 UCT/MCTS 变体的复用规则）在候选提议间做选择。本文只取了它的"文本优化组件"来做对照。见 [[ref25_learning-to-discover-at-test-time]]。

OOD 泛化（Table 5）：在 9 个搜索时未见过的数据集上，Meta-Harness 平均 73.1%，超 ACE（70.2%）2.9 分，在 6/9 数据集上最好——说明它学到的是通用的分类策略而非过拟合。有个有趣副观察：naive 地把 few-shot 示例加到 32 个以上，会在 7/9 任务上反而变差。

发现的分类 harness（Figure 5）：搜索发现的是一个"两段式"策略而非单一 prompt：

Figure 5: Draft-Verification 分类 harness

Figure 5 解读：Stage 1 草稿——检索 5 个最相似样本，出一个初始标签 D；Stage 2 验证——以草稿标签 D 为条件再检索：5 个"同为 D 的确认者（confirmers）"+ 5 个"不同标签的挑战者（challengers）"，让模型决定维持还是修订 D。关键的被发现行为是：第二次检索同时依赖 query 和草稿标签，因此能针对模型当前的猜测递上反例，而不是只给泛泛的近邻。样本太少（<5）时退化为普通单次 few-shot。这就是"省上下文"的原因——两次调用都用很短的检索上下文。

4.2 检索增强的数学推理

设置：给奥数解题增加"从大语料检索示例"的能力。语料 ≥50 万道已解题（8 个开源数据集，仔细去重 + 去污染）。用 Meta-Harness 优化 40 迭代、250 题 search set，产出 109 个候选检索 harness。用 GPT-OSS-20B 选出单个 harness，然后在 200 道 IMO 级题 + 4 个搜索时未见过的模型（GPT-5.4-nano/mini、Gemini-3.1-Flash-Lite、Gemini-3-Flash）上评估。

结果（Table 6）：发现的检索 harness 在全部 5 个 held-out 模型上都超过 no-retrieval 基线，平均 +4.7 分；也超过最强固定基线 BM25 检索 1.3 分，且避免了 dense 检索 / random few-shot 在多个模型上出现的回退。

Figure 8: 被发现的数学检索 harness（四路由）

Figure 8 逐路由解读：一个词法路由器（keyword + 少量 regex，专为几何记号）把每道题唯一地分到四条路由之一，不做跨路由聚合： - 组合数学：BM25 取 20 → 去重到 8 → 按词法分数 + 难度重排 → 保留 3（主路由，显式权衡"多样性 vs 难题匹配"）。 - 几何：1 个固定的 hard NuminaMath 参考 + 2 个原始 BM25 近邻，不重排（搜索一致偏好原始结构匹配）。 - 数论：BM25 取 12 → 用词法分数 + 难度 + "早点说出技巧的解"加分 → 保留 3。 - 代数/其他：BM25 取 10 → 重排 → 根据 top 检索分数的集中程度自适应地决定示例数。

值得注意：这个最终 harness 是搜索过程自主合并两条成功谱系的产物（一条贡献了更强的几何路由，一条贡献了更强的组合路由）。BM25 索引用了保留 LaTeX token（如 \frac、^{2}）为原子的数学感知分词器。

[!TIP] BM25 与 TF-IDF（这两条路由的基础检索件） - TF-IDF：给"词频（在本文档里出现多少次）× 逆文档频率（在整个语料里多稀有）"打分——常见词降权、稀有词升权，衡量一个词对某文档的代表性。 - BM25：TF-IDF 的改进版，是信息检索几十年的词法检索强基线。它对词频做饱和处理（一个词出现 10 次不等于比出现 5 次强一倍）并做文档长度归一化。相对"稠密向量检索（dense retrieval）"，BM25 是稀疏词法匹配——不需要额外的 embedding 模型，本文的 harness 就完全在 BM25 之上做代码空间优化，而没有引入 dense encoder。

4.3 Agentic Coding：TerminalBench-2

设置：TerminalBench-2 有 89 个需要长时程、全自主执行的困难任务。从两个强开源基线（Terminus 2、Terminus-KIRA）初始化搜索。这里把 benchmark 当 discovery problem：搜索和最终评估在同一 89 任务上（因为 benchmark 小而贵，切分会削弱信号；并辅以人工 + regex 审计防止任务串泄漏/过拟合）。

结果（Table 7）： - Opus 4.6：Meta-Harness 达 76.4%，超手工的 Terminus-KIRA（74.7%），在该基座上排第 2（唯一更高的 ForgeCode 81.8% 无法从公开代码复现）。 - Haiku 4.5：达 37.6%，超次好的 Goose（35.5%）2.1 分，排第 1。越弱的基座，harness 优化的收益越大。

Figure 9: 被发现的 TerminalBench-2 harness

Figure 9 解读：绿色块是从 Terminus-KIRA 继承的部分（原生工具调用、30KB 输出上限、多视角完成清单）；红色的「Env bootstrap」是 Meta-Harness 唯一发现并加入的新组件——在 Agent 循环开始前，用一条复合 shell 命令采集沙箱快照（工作目录、/app 列表、可用语言及版本、包管理器、可用内存）注入初始 prompt。它消除了 Agent 通常要花 2–4 个探索轮次去"摸清环境里装了什么"的浪费；命令有 15 秒超时且静默失败，不会在异常环境里搞崩 Agent。整个改动只在 Terminus-KIRA 上加了约 80 行。按任务分析：相比 Terminus-KIRA 在 7/89 任务上有提升，最大提升在需要事先无法假定的领域专用工具的任务（蛋白质组装、光线追踪等）。

4.4 最有说服力的定性证据：提议者会对失败做因果推理

附录 A.2 逐字引用了 TerminalBench-2 搜索日志里提议者的推理，呈现出一条清晰的"从自身回退中学习"的叙事弧——这是"完整历史文件系统访问"最有力的存在性证明：

迭代 提议者做了什么 结果
1–2 把"结构性 bugfix"和"prompt 模板改动"捆在一起改 都从 64.4% 基线大幅回退
3 识别出混淆变量：两次失败的共同因子不是 bugfix，而是"清理型 prompt 重写让 Agent 提前删掉了必要状态"；于是回退 prompt、只留结构性修复 回退幅度大减（-1.1pp），支持了混淆诊断
4–6 针对诊断出的失败模式做直接修复，但仍改动了 prompt/完成逻辑 继续回退 → 学到"改 prompt/完成流是高风险的"
7 战略转向：不再改控制流，而是在循环开始前纯增量地注入环境快照（env bootstrap） 成为全程最佳候选
8 尝试把 env snapshot 与更早的 marker 剥离修复组合 组合两个正交修复
10 跨运行迁移：引用另一次更早搜索里"别清理服务产物 = +18pp"的结论 跨 run 复用经验

[!NOTE] 这段轨迹说明提议者做的远不止随机变异：它识别混淆 → 直接检验隔离混淆的假设 → 观察到控制流/prompt 改动依旧脆弱 → 刻意转向纯增量修改 → 再尝试组合、甚至跨运行迁移教训。这种"对历史失败的因果推理"正是压缩反馈的优化器无法支持的。

5 讨论与总结

[!TIP] 附录 D 的工程经验（对复现/迁移极有价值） 1. 写好那份 skill：skill 文本是引导搜索的主界面，其质量是"循环能否奏效"的最强杠杆。应约束输出与安全行为（禁止什么、产出什么产物、优化什么目标），而不要约束诊断过程。作者说迭代 skill 文本比改迭代数/种群大小更影响搜索质量；正式跑之前先用 3–5 迭代的短 run 调 skill。 2. 从一个基线 + 对它而言很难的 search set 开始：baseline 已经饱和的话没什么可优化。保持 search set 小到能跑约 50 次完整评估（分类 50–100 例、数学 88 题）。 3. 一切都记成易导航的格式（JSON、层级化、一致命名，让 regex/grep 好用）。 4. 可选：给日志配一个小 CLI（列 Pareto 前沿、看 top-k、diff 两个 run）。 5. 昂贵评测前先做轻量校验（import 模块、实例化、在几个例子上跑一遍）。 6. 把评测自动化到提议者之外（跑 eval 简单到不值得让提议者做）。

个人思考

与其他论文的关联（放进本项目的坐标系）

方法论启示（可迁移的通用思路）

  1. "不要压缩反馈"是一个可推广的原则：只要优化对象的失败是长程、可诊断的，就应尽量把原始轨迹留给优化器，而不是喂它摘要。Table 3（摘要≈只给分数）是我见过对"过早摘要有害"最干净的证据。
  2. 把"该看什么"下放给 Agent：与其在外环手工设计 parent-selection / retrieval，不如给 Agent 一个可 grep 的文件系统，让能力增长自动转化为搜索质量增长。
  3. 代码作为搜索空间 = 免费的正则化 + 可审计性——这对任何"自动设计"任务都成立。

在我的工作中能怎么用

开放问题 / 疑问

局限性