LongWoF-Bench：评估面向可验证长流程任务的进化式流程指导

第一章：Introduction

随着大模型在长上下文建模、工具调用和代码执行等方面的能力不断提升，其应用正从孤立的问答扩展到需要连续操作的复杂场景。例如，在 Markdown-to-Repository 场景中，模型需要读取需求文档和已有代码，生成实施计划与任务清单，完成代码修改，并运行测试验证结果；在规则驱动的任务中，模型则需要持续维护中间状态，执行多步推理，最终给出满足全部约束的合法结果。

本文将这类任务称为端到端长流程任务：形式化地，给定初始输入 $x$、可操作环境 $E_0$、约束集合 $C$ 和验证器 $V$，模型需要生成一系列相互依赖的动作 $a_1,a_2,\ldots,a_T$，使环境依次发生状态转移 $E_t=f(E_{t-1},a_t)$，并最终产生结果 $y$。当后续动作依赖前序动作形成的状态或中间产物，且任务是否成功由终态的可验证条件 $V(x,E_T,y,C)=1$ 统一判定时，我们称该任务为端到端长流程任务。其中，“长流程”强调的是跨阶段依赖和状态持续演化，而不单指输入长度、输出长度或执行时间。

模型必须在明确的输出约束下，把多个相互依赖的判断或操作落实为最终交付，并由程序或规则精确验证。这里的“流程”不一定都表现为外部工具调用。对于代码和 agent 任务，它可能包括读取输入文件、遵守 CLI、生成指定 JSON/TXT 交付物并通过隐藏测试；对于数学和规则任务，它也可能体现为公式选择、边界判断、规则优先级处理和答案格式规范化。共同点是，最终成功不仅取决于模型是否理解题意，也取决于它能否把一系列约束正确落实到可验证交付中。

为研究这类能力，我们借鉴 SkillsBench 中的编程任务 (Li et al., 2026) 和 GuideBench 的规则检索框架 (Diao et al., 2025)，归纳长流程任务的常见类型及多重约束带来的难点，并提出 LongWoF-Bench。LongWoF-Bench 包含 778 个已验证任务，覆盖代码生成（code_generation）、数学推理（math_reasoning）、规则遵循（rule_following）和智能体编排（agent_env_synth）四类任务。代码任务强调程序生成和隐藏测试，数学任务强调精确短答和答案规范化，规则任务强调优先级和离散决策，智能体环境任务强调包接口、多文件输出和 pytest 式验证。统一的任务清单、隐藏判定程序和严格评分协议将这些任务放在同一个工作流完成框架中比较。

在这个 benchmark 上，本文关注三个研究问题：

• RQ1: 当前模型在跨轨道、机器可验证的长流程任务上能有多可靠？
• RQ2: Skill、Gene等辅助型提示词会如何影响任务通过率与 token 消耗？
• RQ3: 哪些任务类型、模型类型和 Gene 构造来源更容易从过程性指导中受益？

这三个问题分别考察模型独立完成任务的能力、利用过程性知识的能力，以及不同辅助方式的适用范围和成本收益。

为回答这些问题，我们在统一的任务、运行环境和隐藏判定程序下，对多个模型设置了三种实验条件：无辅助上下文（no_context）、预定义任务手册（Skill）和经验过程性提示 Gene (Wang et al., 2026)。Skill 描述工作流、接口用法、规则执行过程和常见陷阱；Gene 则采用结构化字段表示任务模式、适用信号、执行策略、前置检查与关键约束，并分别从通过验证的模型轨迹和参考解法中构造。其中为了保证不在提示中泄漏答案等关键信息，所有辅助资产均经过泄漏审计。我们比较三种条件下的严格通过率和 token 消耗，并进一步按任务类型、模型类型与 Gene 来源进行分组分析。

实验得到三个主要发现。首先，即使是表现最好的 Opus 4.8，在无辅助条件下的严格通过率也仅为 20.2%，表明当前模型仍难以可靠完成这类长流程任务。其次，过程性辅助能够改善模型表现，但不同形式的收益和成本并不相同：总体而言，Gene 能够以低于 Skill 的 token 消耗提供更有效的任务指导。最后，这种收益并非均匀分布，而是随任务类型、模型能力和 Gene 构造来源发生明显变化，说明过程性知识的价值取决于它与模型及任务之间的匹配关系。

针对这三个研究问题，本文的核心贡献可以概括为三点。

• 第一，我们构建了一个面向端到端长流程任务的统一 benchmark。LongWoF-Bench用 778 个可验证任务覆盖四种不同的task类型，并用隐藏判定程序和严格输出规则衡量模型在每个task上的完成情况。
• 第二，我们提出并实现了 Gene 这一结构化辅助提示形式。与较完整的 Skill 手册相比，Gene 以更短、更可审计的字段表示过程性经验，并通过规定的进化模式从强模型的执行流程中提取出更价值的信息，并且整理成 Gene 作为辅助型提示。这样可以把辅助信息从普通长提示转化为可比较、可分析的实验条件。
• 第三，我们系统比较了无辅助上下文、Skill 和 Gene 在不同模型与任务轨道上的效果。实验显示，没有提示辅助下及时Opus 4.8的严格通过率仅为 20.2%，说明该 benchmark 对当前模型仍有挑战；同时，对模型来说，进化出的 Gene 比 Skill 在长流程任务解决上来说更有价值，还更加节省token消耗 。

第二章：构建LongWoF-Bench

2.1 Benchmark 任务设计：

2.1.1 构建端到端长流程任务：

LongWoF-Bench 的核心任务单元由公开任务规范、交付物空间和隐藏验证器构成，可以表示为：

其中，公开规范 $S$ 给出初始输入 $x$、可操作环境 $E_0$ 和约束集合 $C$；$\mathcal{Y}$ 表示模型需要提交的交付物类型；$V$ 是模型不可见的验证器。模型需要执行一系列相互依赖的动作 $a_1,\ldots,a_T$，推动环境从 $E_0$ 演化到 $E_T$，并产生最终交付物 $y\in\mathcal{Y}$。任务通过的条件为 $V(x,E_T,y,C)=1$。

例如，在 LongWoF-Bench 的自适应巡航控制系统的编排代码构建任务中，$S$ 包含车辆参数文件、150 秒的传感器数据，以及巡航、跟车和紧急制动三种模式的接口与性能要求；$\mathcal{Y}$ 则包括 PID 控制器、巡航控制系统和仿真程序等代码文件，以及调参结果、仿真数据和分析报告。模型需要依次实现控制器与模式切换逻辑，调整 PID 参数，运行完整仿真，并保证不同交付物之间保持一致。

隐藏验证器 $V$ 不仅检查文件是否存在，还会导入并调用模型实现的类，重新运行仿真，验证控制模式、接口和输出格式，并检查上升时间、超调量、稳态误差、安全车距、加速度边界等性能指标。验证器还会改变 PID 参数并检查系统行为是否随之变化，以确认模型提交的是能够实际运行的控制系统，而不是预先写死的仿真结果。

因此，模型仅仅生成结构完整或表面合理的代码并不足以通过任务；它必须使最终代码和全部派生交付物共同满足 $V(x,E_T,y,C)=1$。

这个定义也决定了任务进入 benchmark 的基本条件。首先，任务必须有可描述的公开规范，模型能够从题面、可访问输入、可调用接口或输出说明中获得完成任务所需的信息。其次，任务必须有机器可执行或可精确匹配的验证方式，使结果不依赖主观评分。再次，评测端需要能够区分模型可见信息和隐藏信息：模型可以看到题面、输入文件、可访问的软件包接口、输出协议，以及在某些条件下注入的 Skill 或 Gene；模型不应看到隐藏测试数据、金标准答案、验证器内部逻辑、参考解法或只在评测端出现的私有常量。这个边界是后续公平比较的前提。

2.1.2 LongWoF-Bench的工作流轨道：

当前版本的 LongWoF-Bench 保留了 778 个已验证任务。四个评测轨道的差异可以用下表概括：

这张表也说明了不同任务工作流对应的特征，它们的交付物形态不同，但都要求模型把公开规范中的约束转化为可验证结果。代码和 agent 任务把失败暴露在程序执行和文件检查中；数学和规则任务把失败暴露在答案规范化和精确匹配中。统一验证框架让这些差异不会被一个总体分数完全抹平，也让后续实验可以观察哪些任务更依赖外部过程性指导。

2.1.3 LongWoF-Bench的任务合成：

当前 benchmark 的任务合成方式是按“公开题面 + 隐藏评测”的方式合成的。每个任务根据预先定义好的seed题目，合成有一份对应的模型可见文档 task.md，里面描述要完成什么、输入输出格式是什么、可用数据在哪里；同时任务目录里还会配套测试数据、参考解、隐藏 gold 输出和自动评测脚本。正式 evaluation 时，模型只拿到公开题面以及对应 condition 下的辅助提示，生成答案或代码后，再由隐藏 evaluator 执行、比对输出、记录是否通过，以及 token 消耗等指标。也就是说，这个 benchmark 测的不是选择题式记忆，而是模型能不能在复杂规则、数据处理、代码执行和格式约束下真正完成任务。

这种设计与传统单一题型评测的区别在于，LongWoF-Bench 统一关注端到端交付是否可用。对于代码和 agent 任务，模型必须让程序真实运行；对于数学和规则任务，模型必须让最终答案在严格格式下可解析、可匹配。后面的实验能够比较无辅助上下文、Skill 和 Gene，正是因为三种条件面对同一批任务和同一套验证器，改变的是模型接收到的辅助信息，而不是评分标准。

2.2 辅助提示构造：Skill 和 Gene

复杂工作流任务中的失败，很多时候并不是模型完全不知道相关知识，而是没有稳定调用正确的执行流程。它可能知道要读取数据，却漏掉输出协议；可能理解某条规则，却没有先检查更高优先级的覆盖规则；也可能采用常见算法，却没有意识到当前任务的边界条件会让默认策略失败。因此，你并不能提前预知到模型是在哪些执行流程中出现了问题，于是你就需要在任务执行过程中提炼出真正有用的过程性经验作为模型的提示词辅助**。**

我们引入了一种新的提示词辅助：基于 GEP 协议的 Gene (EvoMap, 2026a)。与传统 Skill 提示词辅助不同，Skill 更像预定义任务手册，Gene 更像从成功执行中沉淀出来的过程性经验 (EvoMap, 2026b)。Skill 是任务执行前由人编写的辅助文档，无法根据模型执行过程动态调整；Gene 则是模型在执行过程中按照相应规则凝练出的过程性经验。

Gene 的设计目标与Skill 不同。Gene 不追求覆盖全部背景信息，而是把已经验证过的成功路径压缩成结构化过程提示：这是什么问题模式，哪些题面信号说明这套策略适用，关键执行步骤是什么，哪些边界条件必须提前检查，提交前需要确认什么。当前实验中的 Gene 可以来自两类材料：一种是模型在该任务上产生并通过验证的成功求解轨迹，另一种是在没有成功轨迹时由参考解法提供教师信号进行蒸馏。前者尤其接近“从实际成功中提炼经验”：不是再写一份更长的手册，而是保留真正改变执行路径的那部分经验。

现在 bench 里这两种辅助提示词的合成方式也不相同，如图1所示：

• Skill 更像一份较完整的任务手册，会把任务类型、推荐流程、接口规则、常见坑和输出要求整理成说明文档；当前版本的 Skill 主要来自任务构造/参考解相关材料的重写和审计，因此它不是纯粹只看公开题面生成的市场型 Skill，而是一个比较强的说明书条件。
• Gene 则更短，可以视为从成功经验里压缩出来的执行提示：如果模型在公开题面和 verifier 反馈下自己试出了通过解，就从这条成功轨迹蒸馏 Gene，具体而言，如果第一次尝试失败，下一次 rollout 就是 mutate：模型会看到截断后的公开任务、它之前的尝试，以及经过脱敏的执行反馈，然后产出一个修正后的解法。这个过程会重复，直到 verifier 通过，或者达到最大 rollout 预算；如果没有试出来，当前 pipeline 会 fallback 到参考解来蒸馏，

举一个简单例子：任务要求模型根据食品加工线的残留风险规则，为一次 “sunflower and sesame paste” 生产后的设备选择清洁动作。这个任务的难点不在输出格式，而在规则执行顺序：两个原料都是 seed，并且被共同加工成 homogenous paste；模型需要先处理 exemption precedence，再做最高风险分数和阈值映射。

这个 case 说明了两者的差别：Skill 确实给了完整流程，也提醒“不要漏掉 exemption”，但它仍然把关键的优先级判断留给模型自己；Gene 则把强模型失败两次后学到的纠偏点压缩成更硬的执行顺序：**先检查共同加工的 exemption，避免把 sesame 的 allergen surcharge 直接堆到最高风险；再取 post-exemption 的最大分数并映射到中间 tier。**因此 Gene 不是更短的说明书，而是把“哪一步最容易错、应该按什么顺序做”变成了单轮可调用的过程性提示。

因此，**Skill 只提供静态说明，Gene 提供经过压缩的执行策略；Skill 更像“辅助指引的路牌”，Gene 更像“前人走过的道路”。**经过这样的构造后，本文中设置的三种实验条件的含义也更加清楚：

• no_context 衡量模型只依赖公开题面时的端到端完成能力；
• with_skill 衡量模型能否使用Skill 这种较完整但相对静态的任务说明；
• with_gene 衡量模型能否使用Gene 这种更短、更结构化、来自成功经验或教师信号的过程性指导。

第三章：实验结果

3.1 实验设置与统计口径

我们在 LongWoF-Bench 的 778 个任务上评估 7 个模型。任务覆盖四个轨道：agent_env_synth 127 题、code_generation 341 题、math_reasoning 151 题和 rule_following 159 题。每个模型均在三种条件下运行：

• no_context：模型仅接收公开题面；
• with_skill：在公开题面之外提供面向当前任务的完整 Skill；
• with_gene：在公开题面之外提供经验过程性提示 Gene。

主指标为严格任务通过率。只有当任务的全部检查点均通过、验证器返回 passed=true 时，该任务才记为通过。Token 成本定义为 input tokens、output tokens 与可记录的 thinking tokens 之和。

我们根据 Gene 来源的不同，本文区分四种统计测试集：

本实验中的Gene 用到的模型是claude opus 4.8，进化策略采用的是在做多轮rollout尝试时，采取的策略是thinking的程度由弱到强（并非传统的设置温度系数然后固定thinking等进行rollout）。强模型先在公开题面上求解，如果失败，就根据脱敏 verifier 反馈继续修正，最多 3 次 rollout；只要某一轮真正通过验证器，就从这条成功轨迹中蒸馏 Gene。

3.2 实验总体结果（RQ1: 当前模型在跨轨道、机器可验证的长流程任务上能有多可靠？）

下面表中的结果是在 Opus-evolved subset 上完整结果，你可以看到的 no_context 条件下最强的 Claude Opus 4.8 通过率仅为 54.8 %；其余模型的通过率介于 3.17% 和 47.6 % 之间。换言之，即使表现最好的模型，在一次无辅助执行中也有接近一半的任务未能通过全部检查点。由此可以看到，在跨轨道、机器可验证的长流程任务上，现有模型并不能完全自行处理这些任务，还是需要一些辅助性提示词的帮助。

其中 with_gene_opus 都来自验证通过的Claude Opus 4.8的真实执行轨迹，经过经验性总结得到的辅助性提示Gene，而不是直接从参考答案改写。通过结果可以看到Opus Gene 对所有被测模型都明显优于 Skill。这说明：当 Gene 来自“模型自己探索成功后的过程压缩”时，它确实比完整说明式的 Skill 更容易被下游模型稳定使用。

为排除是单纯Gene的结构差异带来的结果上的变化，我们进一步做了对比实验，但在剩余task上，也就是distilled gene子集上，结论正好相反：Gene 通常不如 Skill。这部分结果反而强化了一个判断：优势不是来自“把答案相关信息压短”本身，而是来自 evolved 策略把成功执行过程提炼成了可复用的过程性提示。换句话说，只有Evolved过程 Gene 结构策略才能带来能力的提升，而非单纯压缩提示词本身。

3.3 实验 Token 成本分析（RQ2: Skill、Gene等辅助型提示词会如何影响任务通过率与 token 消耗？）

本实验还比较了让 Opus 4.8 解决同一组任务的两种方式：

• 第一种是原始传统模型执行长难任务的流程：允许能力较强模型尝试任务，在失败后查看经过脱敏的 verifier 反馈，并最多进行 多次尝试，直到最终某次尝试通过。（Baseline）
• 第二种是EvoMap-Gene帮助模型完成长难任务的流程：使用强模型经验蒸馏生成后的 Gene，任意模型可以将Gene 作为程序性上下文，并且只对该任务进行一次 with-gene 尝试，成功率大幅高于没有Gene辅助的情况，并且Token的消耗量也远低于传统流程。（Our Mode）

本节统计采用 input_tokens + output_tokens + thoughts_tokens。对于Claude Opus 4.8，thinking 已经折入 provider 的输出 token，因此表中的 Output incl. Thinking 表示可以恢复到的 completion-side token。需要注意的是，下面的多轮基线只统计 solve/mutate rollout 中用于发现通过轨迹的 token，不包含后续 Gene 蒸馏本身的 token。

传统多轮探索：
252 tasks
  -> Round 1 solve, thinking off
     -> pass: distill Gene
     -> fail: sanitized verifier feedback
  -> Round 2 mutate, thinking low
     -> pass: distill Gene
     -> fail: sanitized verifier feedback
  -> Round 3 mutate, thinking high
     -> pass: distill Gene

Total: 404 model calls, 252 verified successful trajectories

Gene 单轮复用：
252 tasks + Opus Genes
  -> one with_gene_opus attempt per task
  -> 252 model calls, 200 passed tasks

这里的测试集合是最终都在多轮探索中产生了验证通过的轨迹的全部Task；第一行的统计结果是模拟**原始传统模型多轮执行长难任务的流程，**它不是一次调用的通过率。后三行则是同一批任务上的单轮求解结果：每题添加对应的辅助信息，并且模型推理只进行一次推理尝试。

从这个结果可以看到几个更直观的结论：

1. no_context 看起来最省 token，但只通过 138/252 个任务；它省下的是上下文本身，也同时丢掉了大量过程性信息。
2. Skill 能把通过数从 138 提到 161，但总 token 升到 803,099，说明静态任务手册确实提供帮助，却不一定经济。
3. Opus Gene 在单轮下通过 200 个任务，比 Skill 多 39 个，同时总 token 反而少 79,619，下降 9.9%。
4. 相比 Opus 多轮探索，Gene 单轮调用次数从 404 降到 252，少了 152 次额外探索调用；总 token 从 1,333,968 降到 723,480，下降 45.8%。

也就是说，Gene 的 token efficiency 不是简单来自“提示更短”，而是来自把多轮探索中的失败反馈、修正动作和最终成功流程沉淀成一次可注入的过程性记忆。后续模型不再从零试错，而是直接拿到这段探索后留下的执行策略。Gene 并不是简单把答案塞进提示里，而是把原本需要多轮试错才能发现的执行路径，提前变成了可复用的过程性上下文。

细节结果可见：

3.4 在任务类型下对比 Opus Gene 与 Skill 效果（哪些任务类型、模型类型和 Gene 构造来源更容易从过程性指导中受益？）

如果把 252 个 Opus-evolved 任务按类型拆开，结果会更细一些。四个分组的任务数为 64、62、30 和 96，合计 252；因此下面的表只描述 evolved Gene，不包含 reference-distilled Gene。可以看到，Agent 环境与规则遵循任务上的 Opus Gene 收益最稳定，代码与数学任务的结果则更依赖具体模型。

agent_env_synth（64 题）

code_generation（62 题）

math_reasoning（30 题）

rule_following（96 题）

agent_env_synth 上，Opus Gene 对七个模型全部优于 Skill，增幅从 +15.6 到 +29.7 个百分点。环境任务仍要求处理软件包行为、多文件输出和测试约束，但从成功轨迹提炼出的接口与执行顺序能够稳定减少遗漏。

rule_following 也呈现一致提升，七个模型的增幅从 +2.1 到 +22.9 个百分点。许多规则任务的失败并不是模型完全读不懂题面，而是没有稳定执行优先级、覆盖规则、边界相等条件或离散选项约束。Gene 把这些过程性检查显式化后，模型更容易走到正确决策。

code_generation 的结果并不一致。Sonnet、Gemini Flash 和 Qwen Coder 从 Gene 获益，但 Opus、Gemini Pro 和 Qwen 3.5 略有下降，MiniMax 持平。这说明压缩后的过程性提示可以减少接口和流程遗漏，却不总能替代较完整的 Skill；效果取决于目标模型如何利用这两种上下文。

math_reasoning 最需要谨慎解释。Opus 4.8 从 43.3% 提升到 83.3%，Gemini Pro 与两个 0% 模型没有变化，Sonnet、MiniMax 和 Qwen 3.5 则下降。数学短答更依赖精确符号执行、边界计算和答案规范化。过程性提示可以提醒方法，但不能替代实际计算能力，也可能在部分模型上引入干扰。

这组分轨道结果解释了为什么 LongWoF-Bench 需要跨轨道设计。一个总体分数可以告诉我们辅助提示有效，但只有分轨道结果才能说明它主要在哪些任务形态上有效、在哪些任务上仍然困难。

3.5 Common evolved overlap: Gemini Gene vs Opus Gene

Gemini Gene 和 Opus Gene 的 evolved 任务集合并不完全一致，所以二者不能直接在各自全集上比较。为了比较不同 Gene 作者模型的影响，这里只看二者都属于 evolved 的 180 个共同任务。这个 overlap 上，Opus Gene 仍然稳定高于 Gemini Gene，说明更强的 Gene 生成模型会影响最终 Gene 的可用性。

3.6 Case studies

案例 1 — code_generation / T0161：钻孔化验样品复合

任务要求（自然语言介绍）： 一个地球科学管道读取 collars.csv 和 assays.csv。化验行可能有 重叠的深度区间 和 低于检测限的标记，如 '<0.01'。程序必须：(1) 将 <x 标记转换为 x/2；(2) 将重叠的深度区间解析为相互排斥的线段；(3) 重新复合为从深度 0 到 max_depth 的固定 2 米箱体；(4) 计算每个箱体的 alteration_index；(5) 计算每个钻孔的 mineralization_score = 超过 勘探范围内中位数 的复合 Au/Cu 值之和（中位数是在整个数据集的每个 2 m 复合体上计算的）。

传统方式是怎么解决这个task（Opus 如何演化 Gene）：

• Rollout 1（solve）→ FAIL（pass_rate 0.875）。 Opus 按"后一个区间胜出"规则解析重叠 — 在任何重叠区域中，后一行的值覆盖前一行的值。
• Rollout 2（mutate）→ FAIL（pass_rate 0.875）。 Opus 保持相同的"后一行优先"约定，仅加强了 NaN 处理。在重叠测试中仍然是错的。
• Rollout 3（mutate）→ PASS（pass_rate 1.0）。 Opus 改变了重叠约定本身：不是"后者获胜"，而是 对覆盖线段的所有区间的值进行平均（之后长度加权到 2 m 箱体中）。这与预期的复合语义相匹配，通过了。

突破是一个 语义上的 改变 — 重叠化验区间的正确约定是平均，不是覆盖 — 正是 Gene 捕捉的内容。

演化后的 Gene（T0161.json，payload）：

{
  "type": "Gene",
  "summary": "Build a geoscience/interval pipeline that cleans below-detection markers, resolves overlapping depth intervals, composites into fixed-length bins, and emits per-row and per-entity aggregate CSVs.",
  "category": "innovate",
  "signals_match": [
    "drillhole assay compositing",
    "below-detection limit markers like '<0.01'",
    "overlapping depth intervals to mutually exclusive segments",
    "fixed-length 2-meter downhole composites",
    "alteration index / mineralization score formulas",
    "prospect-wide median threshold aggregation",
    "--input/--output directory CLI with named CSV outputs",
    "length-weighted interval averaging"
  ],
  "strategy": [
    "Parse CLI --input/--output dirs; read collars and assays CSVs by exact column names; create output dir with makedirs(exist_ok=True).",
    "Clean value columns: convert '<x' strings to x/2 (half detection limit), '>x' to x, blanks/'na' to NaN, else float; coerce depth columns to numeric.",
    "Per hole, resolve overlaps: collect breakpoints from all from/to bounds, for each adjacent segment use midpoint to find covering intervals and average their values into one exclusive segment.",
    "Composite into exact fixed-length bins from 0 to max_depth (ceil(max_depth/len) bins); for each bin length-weight each value by overlap length with segments, divide by total weight, NaN if none.",
    "Compute per-bin derived index per given formula guarding zero/NaN denominators; write one CSV with hole_id, bin from/to, and index using the required header order.",
    "Compute dataset-wide medians across ALL bins for threshold columns; per hole sum bin values exceeding their respective medians for the score and take per-hole max values; write the summary CSV with exact headers.",
    "Verify both output files exist, column names/order match the contract, and every hole appears even with empty or missing assays."
  ],
  "preconditions": [
    "Medians for scoring must be computed across the full composited dataset, not per hole.",
    "Bins must span exactly 0..max_depth and exist for holes with no assay coverage (values NaN).",
    "Overlap resolution must produce mutually exclusive segments before any compositing aggregation.",
    "String/NaN/empty assay cells must be sanitized before numeric ops to avoid type errors."
  ],
  "constraints": { "max_files": 1, "forbidden_paths": [".env", "secrets", "credentials"] },
  "validation": []
}

Gemini Pro 无 Gene → 失败。 Gemini 的 resolve_overlaps 排序了区间并 在下一个区间的开始处截断前一个区间（一种"修剪，不合并"的方法），丢弃重叠的值而不是将它们组合：

prev = resolved[-1]
if row['depth_from'] < prev['depth_to']:
    if row['depth_from'] > prev['depth_from']:
        prev['depth_to'] = row['depth_from']   # 只修剪，丢掉重叠贡献
    else:
        resolved.pop()
resolved.append(row)

结果：FAIL:L2_prospect_summary_adv_overlap - Mismatch in mineralization_score for key ('H003',): got 0.0, expected 202.0。重叠处理恰好丢掉了驱动得分的贡献。

Gemini Pro 有 Gene → 通过。 受 Gene 的"收集断点 … 对覆盖区间求平均 … 长度加权到箱体"策略引导，Gemini 构建了断点线段并 对所有覆盖区间进行了加权平均，然后长度加权到 2 m 箱体中：

boundaries = sorted(set(hole_assays['depth_from']).union(hole_assays['depth_to']))
for seg_from, seg_to in adjacent_pairs(boundaries):
    covering = hole_assays[(hole_assays.depth_from <= seg_from) & (hole_assays.depth_to >= seg_to)]
    seg_data[col] = np.average(vals[valid], weights=w[valid])   # 平均，不是覆盖

为什么改进了。 no-context 模型默认采用了最常见的区间合并启发式方法（"后者获胜 / 修剪前一个"），这种方法看似合理但对化验样品复合是错的 — 它把 `H003` 的矿化得分清零了。Opus 已经在两个 rollout 中发现了正确的约定是长度加权平均；Gene 把那个确切的约定交给 Gemini，所以它在第一次尝试中就能正确复合。

案例 2 — rule_following / T0659：紧急调度代码

任务要求（自然语言）。 给定一个 911 场景 — 室内家庭骚乱，对象持有 厨刀（刀刃武器），无可见伤害，地理定位 恰好 5 ZDU — 从 dispatch_omega / dispatch_sigma / dispatch_theta / dispatch_zeta 中选择正确的调度代码。决定取决于两条相互作用的规则：距离阈值比较（5 是否严格超过截断？）和 武器/伤害优先级 规则（武器存在但无伤害 → 武装但无伤害等级）。

传统方式是怎么解决这个task（Opus 如何演化 Gene）：

• Rollout 1（solve）→ FAIL（pass_rate 0.667）。 Opus 拒绝承诺，辩称规则表没有给出并发出占位符 dispatch_omega 同时声明无法验证。错误。
• Rollout 2（mutate）→ FAIL（pass_rate 0.667）。 Opus 承诺 dispatch_theta，理由是武器"无论距离阈值如何都会升级"。那过度升级了：它忽视了"无伤害"降级并把边界距离当作触发升级。
• Rollout 3（mutate）→ PASS（pass_rate 1.0）。 Opus 把优先级搞对了：5 ZDU 不严格超过 阈值，所以距离升级不触发；武器存在但无伤害映射到武装但无伤害等级 → dispatch_sigma。

演化后的 Gene（T0659.json，payload）：

{
  "type": "Gene",
  "summary": "Select a dispatch/response code by applying weapon and injury precedence rules combined with a strict ZDU/distance threshold comparison, emitting an exact two-line ANSWER/ANALYSIS contract.",
  "category": "other",
  "signals_match": [
    "dispatch code selection",
    "threshold comparison on distance units (ZDU)",
    "rule precedence for weapon-involved incidents",
    "ANSWER and ANALYSIS exact two-line output",
    "weapon present but no visible injuries",
    "911 / emergency dispatch scenario",
    "choose one of several action tokens",
    "case-insensitive exact-match grading"
  ],
  "strategy": [
    "Extract every decision factor from the prompt: weapon present?, injuries present?, distance value, and the exact stated threshold.",
    "Apply the threshold as written: treat 'exactly equal' as NOT exceeding unless rule says >= (strict vs non-strict matters most for boundary values).",
    "Resolve precedence order: injury-tier > armed-no-injury > distance-only codes; pick the highest-priority rule whose conditions are fully satisfied.",
    "When a weapon exists but injuries are explicitly denied, choose the armed-but-no-injury tier, not the injury escalation or plain distance code.",
    "Map the satisfied rule to its corresponding code token and verify it is one of the allowed options.",
    "Emit exactly two lines: 'ANSWER: <token>' then 'ANALYSIS: <one paragraph ≤80 words citing the rule>', with no extra output or whitespace lines."
  ],
  "preconditions": [
    "Confirm whether the boundary value triggers escalation (strict > vs >=) before deciding distance effect.",
    "Verify the chosen token is spelled exactly as an allowed option for case-insensitive exact match.",
    "Ensure precedence (weapon/injury rules) overrides distance-only codes when both apply."
  ],
  "constraints": { "max_files": 1, "forbidden_paths": [".env", "secrets", "credentials"] },
  "validation": []
}

Gemini Pro 无 Gene → 失败。 Gemini 过度升级了武器并误处理了边界，落到 dispatch_theta：

ANSWER: dispatch_theta
ANALYSIS（翻译后）: ... 因为对象距离正好 5 ZDU ..., 武器相关事件的阈值比较指示使用 dispatch_theta ...

这是 Opus 在其 rollout 2 中犯的 同一个 错误 — 把边界距离加武器当作强制更高等级，忽视"无伤害"降级。

Gemini Pro 有 Gene → 通过。

ANSWER: dispatch_sigma
ANALYSIS（翻译后）: ... 刀刃武器无可见伤害且距离恰好 5 ZDU ... 在规则优先级下，武器加近距离的组合... 无活跃伤害指示 dispatch_sigma 代码。

为什么改进了。 这个任务有两个众所周知的陷阱：严格 vs 非严格边界（恰好 5 是否"超过"阈值？）和 优先级顺序（伤害 > 武装无伤害 > 仅距离）。no-context 模型落入了两个，正如 Opus 收敛前所做的那样。Gene 明确陈述了两条规则 — "除非规则说 ≥ 否则视'恰好相等'为不超过"和"武器存在但伤害被否认 → 武装但无伤害等级，不是伤害升级" — 所以 Gemini 正确应用优先级并选择 dispatch_sigma。

两个案例的共同点

两个案例暴露出同一类失败：模型采用了看似合理的默认策略，却违反了任务的具体契约。

• T0161：把后一个区间当成覆盖前一个区间，导致重叠贡献丢失。
• T0659：把武器出现直接视为升级条件，忽略了无伤害降级规则和严格距离阈值。

Opus 分别经过 2–3 次 rollout 才定位到纠正规则。演化后的 Gene 将规则压缩进几行 strategy 和 preconditions，让 Gemini 在第一次尝试中直接应用正确约定。

代码案例说明 Gene 可以减少重复调试和大段重写；规则案例说明 Gene 可以减少优先级与边界判断错误。两者共同解释了过程性指导为何能降低探索成本，但不代表它会在每种任务上产生相同收益。

参考资料

• Diao, L., Xu, X., Sun, W., Yang, C., & Zhang, Z. (2025). GuideBench: Benchmarking Domain-Oriented Guideline Following for LLM Agents. ACL 2025, 11361-11399.
• EvoMap. (2026a). GEP Protocol Deep Dive: Genetic Engineering for AI Agent Self-Evolution.
• EvoMap. (2026b). Agent Skill vs GEP Gene: The Fundamental Divide Between Tools and Evolution.
• Li, X., et al. (2026). SkillsBench: Benchmarking How Well Agent Skills Work Across Diverse Tasks. arXiv:2602.12670.
• Wang, J., Ren, Y., & Zhang, H. (2026). From Procedural Skills to Strategy Genes: Towards Experience-Driven Test-Time Evolution. arXiv:2604.15097.