OpenClaw x EvoMap 喺 CritPt Physics Solver 上嘅系統性評測與進化分析報告
1. 摘要（Executive Summary）
本報告對 OpenClaw（集成 EvoMap，可進化多類 gene）喺 CritPt Physics Solver 上嘅表現進行咗系統性測試與復盤。我哋嘅目標係驗證：EvoMap 係咪能夠令 OpenClaw 等 agent 快速學習領域知識，以更低成本完成領域任務，並將高頻有效流程沉澱為可複用資產，支撐後續擴展。
結論以一句話概括：呢條進化鏈路係一部從「語言模仿者」向「物理仿真工程師」轉型嘅技術路線圖——分數提升嘅主因唔係「更識講」，而係將推理工程化成可執行閉環，並逐步將閉環固化成可複用嘅 gene/skill。
2. CritPt Benchmark：佢到底喺評測咩？
2.1 評測對象：研究式物理推理嘅「交付鏈路能力」
喺 CritPt Physics Solver 場景中，我哋唔會將「寫出睇落合理嘅解釋」當作完成任務；更重要嘅係交付一個可判分、可執行、可驗證嘅結果載體（通常係符合模板嘅 Python 函數輸出）。因此 CritPt 對系統嘅評測重點天然偏向：
- 建模：能否將物理假設與約束形式化為可計算嘅數學結構；
- 實現：能否穩定產出可運行代碼（而非僅文本）；
- 驗證：能否通過自檢/斷言/邊界測試抑制顯而易見嘅物理不合理；
- 可靠性：能否喺多次運行中保持穩定交付（而非偶然一次正確）。
2.2 二階段交付範式（Two-step formatted answering）
CritPt 嘅關鍵特徵之一係「二階段交付」：第一階段自由推理；第二階段強制將最終答案寫入規定嘅 Python 代碼模板（只提交最終代碼，唔混入解釋文本），以便自動判分與規模化評測。
2.3 一個示例（示意用，唔對應真實題目）
以下係結構同構示意：重點展示「提交物係可執行函數」，而唔係敘述性文本。
示意題：要求返回一個浮點數作為最終答案（第二階段只允許輸出代碼）。
def solve():
import math
L = 1.0
g = 9.81
T = 2.0 * math.pi * math.sqrt(L / g)
return float(T)
3. 被測系統與版本演進（Beta -> v2.2）
我哋將系統演進劃分為 5 個階段：Beta（v0.x）-> v1.0 -> v2.0 -> v2.1 -> v2.2（規劃）。總體路線係先將「可判定產物鏈」跑通，再將「修復/校驗/物理可信」逐層固化為默認策略。
主版本-基因映射表
| 版本 | 核心目標（解決嘅主導失敗模式） | 關鍵 Gene（狀態） | 代表能力（可執行/可操作） | 收益（已觀測 + 預期） |
|---|---|---|---|---|
| Beta | 暴露開環文本解題問題：輸出可讀但唔一定可判定、可執行、可穩定計分 | （無顯式主基因） | 文本推理為主，缺少結構化自檢與強約束交付 | 已觀測：建立咗問題暴露基線；後續價值：明確咗「必須產出可執行結果」方向 |
| v1.0 | 從「識講」到「識算」：建立可執行產物鏈 | gene_gep_innovate_from_opportunity（已驗證主貢獻） | 將題目轉為代碼求解任務；形成可運行、可提交嘅結果形態 | 已觀測：首次穩定進入非零準確率區間；可評分提交能力建立 |
| v2.0 | 將失敗當監督信號：形成自我糾錯閉環 | gene_gep_repair_from_errors（已驗證主貢獻） | Code -> Run -> Error -> Fix -> Run 迭代修復；最小可逆補丁策略 | 已觀測：可交付率與魯棒性繼續提升；準確率爬升 |
| v2.1 | 從「能跑」到「更穩」：強調交付一致性與運行穩態 | gene_test_driven_development（隱性/建議顯式化） | 斷言/邊界檢查/格式約束前置；提交前輕量自檢 | 已觀測：準確率提升到 17.14%；預期：進一步降低交付異常與判題側損耗 |
| v2.2 | 從「能算」到「算得啱」：提升物理有效性與知識可信性 | gene_active_research（已定義，待深度激活） | 量綱一致性校驗；不確定公式/常數觸發檢索確認；知識索引沉澱 | 已觀測：當前最高準確率 18.57%；評測側 timeout_rate=0；預期：減少公式幻覺、提升可審計性與跨題穩健性 |
跨版本支撐基因
| Gene | 作用定位 | 建議對應階段 |
|---|---|---|
| gene_gep_optimize_prompt_and_assets | 提升提示詞與資產組織嘅一致性、可審計性 | v1.0-v2.2 全階段支撐 |
| gene_web_fetch_search_fallback | 檢索能力受限時嘅回退路徑，避免「無信息盲解」 | v2.1-v2.2 支撐增強 |
| gene_memory_bridge | 跨會話記憶銜接，減少迭代遺忘 | 全階段基礎設施層 |
3.1 Beta：開環語言模仿階段
Beta 嘅關鍵問題在於：模型主要喺做「文本表演」，缺少穩定嘅可驗證產物錨點。
因此即使消耗咗唔少 token，都容易因答案唔可判定、格式唔合規或事實性幻覺而失分。
從評測結果嚟睇，Beta 輪次準確率為 0.00%，說明「能回答」並唔等於「可判定且可得分」。
3.2 v1.0 | 概念驗證（The Innovation）：從 Text Generation -> Model-Based Reasoning
核心躍遷：從「直接估答案」轉向「優先產出可運行代碼與可判定結果」。
關鍵基因為 gene_gep_innovate_from_opportunity，代表能力重心係：
- 將問題轉寫為可執行形式；
- 用運行結果替代純語言主觀推斷；
- 對失敗與異常結果進行基本區分（成功/失敗/不可用）。
該階段嘅主要價值係建立「可交付」基線，而唔係一次性追求高準確率。
3.3 v2.0 | 增強反饋（Enhanced Feedback Loop）：Self-Correction 閉環修復
核心躍遷：將運行失敗轉化為監督信號，形成 Run -> Error Signal -> Retry/Fix 嘅閉環。
關鍵基因為 gene_gep_repair_from_errors，能力重點係：
- 對失敗事件進行結構化記錄；
- 以最小改動進行迭代修復；
- 通過多輪嘗試提升「可提交率/可判定率」。
該階段提升嘅重點仍係「交付率與可判定性」，而唔係每題一次命中。
3.4 v2.1 | 魯棒推進（Robustness Push）：從能跑到更穩、更強
v2.1 階段體現咗策略與執行效率嘅協同優化。
喺保持可交付能力嘅同時，系統對複雜題嘅覆蓋和解題深度繼續提升，評測側準確率提升到 17.14%。
呢個說明進化機制已唔再只修「局部 bug」，而開始優化整體解題質量與收益結構。
3.5 v2.2 | 高分峰值（Best-Score Stage）：向「算得啱」邁進
v2.2 達到咗當前最高評測準確率 18.57%。
- 評測側：timeout_rate=0、server_timeout_count=0（無評分超時）；
呢個說明系統已經具備衝高能力，下一步係將高分能力進一步固化為「高分 + 穩定」嘅雙優能力。
4. 結果與診斷：token 軌跡、成本口徑與「學到模式」嘅外觀
4.1 成本與 token 嘅口徑
上圖嘅成本軸默認使用對數尺度，避免 $0.81 嘅點被擠喺原點附近；可切換為線性。Cost 口徑：僅考慮生成答案需要嘅 token（thinking + final answer）。
4.2 token 先上升後下降：從顯式推理到隱式程序化
我哋觀察到 token 先上升後下降，呢個係工程系統中「學到某種模式」嘅典型外觀：系統從「顯式推理（寫出嚟）」過渡到「隱式程序化（封裝複用）」。呢條路線唔係「模型更識講」，而係「推理被工程化成可執行閉環」，並將高頻閉環逐步沉澱為可複用資產。
進一步地，token 嘅變化反映嘅係「顯式展開嘅過程成本」：早期將流程寫喺回覆裏（長）；後期當流程固化為 skill/gene，唔需要每次喺自然語言裏重複腳手架與試錯日誌，於是外顯 token 下降，但內部過程更可靠，得分反而繼續升。
5. 官方評測流程（可複現、可審計）
本節用於明確：分數嚟自官方評測鏈路，而唔係本地自算。
5.1 生成 submission（Generation）
每道題生成一段可執行 Python 代碼（generated_code），按題目 ID 寫成 submission JSON 文件，路徑為：
results/generations/<RUN_ID>/submissions/<challenge>/<problem_id>.json
批量生成命令：
bash scripts/run_generation.sh
5.2 提交官方評測（Grading）
我哋使用官方評測腳本將 <RUN_ID> 嘅 submissions 作為 batch 提交到 Artificial Analysis 嘅 CritPt 評測 API，服務端返回 accuracy/timeout 等指標，本地僅負責保存回包。提交前需要準備環境變量 CritPt_API_KEY（評分腳本從 .openclaw/.env 讀取）。
提交命令：
bash scripts/run_grading.sh <RUN_ID>
回包文件落盤路徑：
results/evaluations/<RUN_ID>/aggregate_report.json
5.3 回包字段解讀（點樣「讀數」）
aggregate_report.json 常見關鍵字段包括：
total_files_found：掃描到嘅 submission 文件數total_submissions_loaded：成功加載嘅 submission 數failed_to_load：加載失敗列表（為空表示全部可讀）summary.accuracy：正確率（0~1 嘅比例，唔係百分數；換算百分數需 x100）summary.timeout_rate：超時比例- （有時）
judge_error_count：判題錯誤數量（常見係生成代碼唔可執行/函數唔符合模板/混入解釋文字等）
{
"timestamp": "2026-02-16T11:59:30.909403",
"total_files_found": 70,
"total_submissions_loaded": 70,
"failed_to_load": [],
"summary": {
"total_submissions": 70,
"accuracy": 0.18571428571428572,
"timeout_rate": 0,
"server_timeout_count": 0
},
"metrics": {
"accuracy": 0.18571428571428572,
"timeout_rate": 0,
"server_timeout_count": 0,
"judge_error_count": 1
}
}
6. 點解主 Benchmark 揀 CritPt（而唔係 Math500/AIME）
我哋揀 CritPt 作為主 Benchmark，係因為佢更能放大 OpenClaw+EvoMap 嘅差異化能力：工具鏈閉環、工程魯棒性、可驗證嘅物理有效性、可審計與可複用嘅進化資產；而 Math500/AIME 更適合作為補充與回歸驗證。
7. Skill / Knowledge / Gene：資產化解釋（「點解能省 token」）
對外解釋時建議使用「知識--技能--基因」嘅工程三層抽象：
- Knowledge（知識）：事實與約束集合（公式、常識邊界、工具行為規律）；
- Skill（技能）：可執行過程模組（建模、求解、Traceback 修復、斷言注入、量綱檢查等）；
- Gene（基因）：決策偏置與流程編排（何時觸發邊啲 skill、順序、閾值、停止條件）。
呢三者嘅作用鏈條係：Knowledge 提供正確性依據 -> Skill 將依據變成可執行動作 -> Gene 將動作編排成默認策略與複用結構。其直接工程收益之一係「外顯 token 下降」：大量重複腳手架、反覆試錯與解釋性自證被內化為默認流程，對外只輸出最終可判定產物，因此會出現「更短輸出但更高穩定性/得分」嘅軌跡外觀。
8. 附錄：生成 Prompt（備案）
以下為報告中記錄嘅生成提示詞（原樣備案）：
Use as many relevant internal skills and strategies as possible.
Think deeply, verify intermediate assumptions, and aim for the best possible final answer.
You may use available tools only when they improve correctness.
Return only final Python answer code with no markdown fences.
If a code template is provided, fill the template directly.
f"Problem ID: {task.problem_id}",
f"Problem type: {task.problem_type}",
"Problem statement:",
task.problem_description.strip()
9. 進化任務嘅設計
主目標：最大化 accuracy
次目標：最小化 timeout_rate / judge_error / fallback / generation_failed
數據地址（必須使用呢啲路徑）：
1) 題目數據（用於理解任務分佈）：
CritPt/data/public_test_challenges/json/Challenge_*.json
2) 歷史官方評測結果：
results/evaluations/*/aggregate_report.json
3) 歷史生成摘要：
results/generations/*/run_summary.json
4) 歷史分數總表（優先讀取）：
/analysis/scoring/scoring_runs.csv
獎勵公式（formula_version=v1）：
定義：
acc = accuracy
to = timeout_rate
jer = judge_error_count / max(total_submissions,1)
gfr = gen_failed / max(gen_total_tasks,1)
fbr = gen_fallback_count / max(gen_total_tasks,1)
主獎勵：
R_main = 100 * (0.88*acc - 0.06*to - 0.03*jer - 0.01*gfr) - 5*fbr
穩定性獎勵：
R_stability = 100 * (0.6*(1-gfr) + 0.4*(1-fbr))
總獎勵：
R_total = 0.85*R_main + 0.15*R_stability
