WikiSkill：会自己写
Wiki 的 Skill（复现实测）

思路来源明写在论文里：Karpathy 提出的 LLM Wiki——与其让经验散落在优化历史里，不如把它编译成持续复利的持久知识。现有的 skill 自进化方法（EvoSkill、Trace2Skill、SkillOpt）都没有把"学到了什么"维护成一份独立演化的知识表示。

workspace/
├── raw/                    # 不可变。每轮 rollout 的完整执行轨迹
├── wiki/                   # 永不回滚。跨轮累积、只增不减
│   ├── patterns/           #   每个失败模式或成功策略一个 .md
│   ├── index.md            #   pattern 目录
│   ├── logs.md             #   演化编年史
│   └── skill-impact.md     #   审计链：每次提议改了什么、验证分多少、接受还是拒绝
└── skills/                 # 可回滚。当前生效的 skill 集
    └── <name>/
        ├── SKILL.md        #   注入给 inference agent 的正文
        └── PURPOSE.md      #   这个 skill 对应哪几个 wiki pattern

每一轮 k，四个组件依次工作：

1. Inference Agent 用当前 skill 集 S_k-1 跑训练集。训练 rollout 阶段禁止访问 wiki——论文 §5.1 消融显示，让 inference agent 也能看 wiki 会让最终 skill 质量下降（63.7%→60.9%），因为它会直接从 wiki 抄答案，轨迹失去信息量。
2. Wiki Maintainer 采样最多 8 条轨迹（最多 5 条失败 + 3 条成功，单条截断 15,000 字符），做根因分析，更新 wiki/patterns/。
3. Skill Proposer 以 ReAct 方式工作：先拿 wiki index + skill-impact.md + 训练结果摘要，按需 read_file 看具体 pattern 页和原始轨迹，最后产出一个原子提议——新建或打补丁，只能选一个。
4. Gating and Rollback：候选 skill 在验证集打分，严格大于历史最好分才接受，否则回滚到上一版。

这条设计在实测里是整套机制最脆的一环，§07 详说。

论文用 Gemini-3.5-Flash 和 Qwen/Gemma 系列。用不同模型族是这次复现和论文最大的偏离，结论对比时要记住这一点。

任务集怎么设计（比代码更重要的一步）

复现这类论文最容易翻车的不是实现，是任务集选得不对，导致 skill 根本没东西可学。论文的五个 benchmark（LiveMath / SealQA / SpreadsheetBench / OfficeQA / ALFWorld）共同点是：失败原因是程序性的——步骤漏了、边界约定错了、格式不对——而不是知识性的。

对标 LiveMath 那一类，造了 30 道单步题，五种题型各 6 道，按 2/2/2 切成 train/val/test：

规则全部写在题面里，不存在"必须靠猜"的隐藏约定——否则这就成了作弊 benchmark。弱模型仍然会系统性做错，这正是 skill 该修的东西。

这一步千万别跳过。在跑任何进化循环之前，先用空 skill 集把验证集和测试集各跑 5 遍：

python3 noise.py 5

VAL:  60.0% × 5 次，失败模式每次完全相同 (..XX....XX)   波动 0pp
TEST: 50 / 50 / 70 / 70 / 60                             波动 20pp

验证集在 temperature 0 下完全确定，测试集却有 20 个百分点的波动。这个数字直接决定了：任何小于 20pp 的 test 差异，都无权解释。后面所有结论都要跟这条对齐。

给它的 prompt 里，有一句话对产出质量的影响远超其他所有要求：

配合三条硬性要求：对每条失败轨迹做根因分析（不许停在"模型答错了"，要指名具体的程序性错误）；从成功轨迹提取有效策略防止回归；每个 pattern 页必须包含症状 / 根因 / 可操作的绕过方法三段。

产出质量比预期高很多

这是它在第 4 轮自动写出来的一页（未经任何编辑）：

# Pattern: Calendar Day Business Confusion

## Symptom
The agent incorrectly applies business day filtering logic (removing
weekends and holidays) to questions asking for a simple count of
calendar days.

## Root Cause
The agent has over-fitted on the explicit step-by-step procedure for
calculating business days. When presented with a calendar day query,
it defaults to this complex procedure instead of using the simpler
date difference logic.

## Workaround
Strictly distinguish between "calendar days" and "business days":
- calendar days (inclusive): use (end_date - start_date) + 1.
- business days: apply the explicit listing and filtering steps.
Never apply weekend or holiday filters to a calendar day calculation.

ReAct 循环，最多 4 轮，每轮可以回一句 READ: <path> 去看某个 pattern 页或原始轨迹：

for turn in range(4):
    out = llm(convo, ORCH_MODEL)
    m = re.match(r"\s*READ:\s*(\S+)", out)
    if m and turn < 3:
        body = ws.read(m.group(1))[:15000]
        convo += f"\n\nREAD: {...}\n<content>\n{body}\n</content>\n\nContinue."
        continue
    return out

论文强调提议必须是原子的：一轮只碰一个 skill，要么新建、要么打补丁。这不是洁癖——gate 只给一个标量分数，一次改两个地方就无法归因。

1 · 审计链写错了，整个循环就空转（踩得最狠的一个）

第一版实现里，写进 skill-impact.md 的那行 "threshold to beat" 用的是上一轮的 val 分数，而不是 R_best：

# 错的
f"(threshold to beat: {history[-1].get('val', 0):.1%})"
# 对的
threshold = r_best            # 判定当时的门槛，先存下来
accepted = r_val > threshold
f"(threshold to beat: {threshold:.1%})"

gate 的判定逻辑本身是对的，错的只是写给 proposer 看的那份审计记录。后果：

2 · full-injection 是实验设定，不是生产设计

论文 §3.2.1 明确说：active skill 的全文直接注入 inference agent 的 system prompt，理由是"消除 skill 触发和检索失败这个混淆变量"，Limitations 里也承认没有评估 skill 检索。这个选择在实验里是对的，在工程上是危险的——§06 那条完整因果链就是直接后果。真要用在真实场景，必须先解决触发问题：要么按 SKILL.md frontmatter 的 description 做检索，要么至少强制每个 skill 自带 Applies to 边界。

3 · 严格 > + 粗粒度指标 = 门槛过不去

在 10 题验证集上，最小可分辨的进步是10 个百分点——一整道题。wiki 组 it0 和整个 nowiki 组，全都是 60% 打平被拒。但把 gate 放宽成 >= 也不是免费的：scoped 组第一次运行直接接受了 6 个 val 分毫不动的提议，skill 集只是无脑膨胀。真正的解法是把验证集做大，让指标粒度变细，而不是在 gate 的比较符号上做文章。

4 · R_best 是只升不降的棘轮

一旦某轮靠运气冲上高分，之后所有"整体更健康但当期分数更低"的修复都被永久挡住。论文里 R_best 只在接受时更新、从不衰减，没有任何退火或重置机制。值得考虑：给 R_best 加衰减、或连续 N 轮全拒之后允许一次探索性接受——这属于论文之外的东西，只是从失败现象推出来的方向，没有实测验证。

5 · 限流会静默伪造实验结论

失败的 API 调用如果返回空串，会被判分函数打成"答错"，最后得到一张漂亮但完全错误的准确率表。处理方式：全局最小请求间隔 1.5 秒 + 信号量限并发 2 + 指数退避重试 12 次，并且把硬失败次数单独统计。三组正式运行的 summary.json 里 "errors": 0——这一行不是 0，整组数据作废。

空 skill 集把 val/test 各跑 5 遍。如果 test 波动比预期的 skill 收益还大，先去把评测规模做够，别急着写进化循环。

训练集准确率长期在 80–90% 时，失败信号很薄，proposer 会反复在同一道题上打转。每种失败模式至少要有 3–5 个样本。

在 full-injection 下这是唯一能防越界触发的手段，成本只是 proposer prompt 里加一段话。

它是 proposer 唯一的历史感知来源，写错了整套机制归零，而且不会报错。

就算 gate 一个都不通过，wiki/patterns/ 里那些"症状/根因/绕过方法"的页子本身就是可读的资产——对多数团队来说这才是最先能兑现的部分，自动进化那半截是长期目标。