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
