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.