技能介绍

它解决什么问题

把 solver 对着评测器反复改、反复跑，很容易退化成一次黑箱过程：改了什么、为什么改、分数为什么涨，全凭记忆。结果是三类典型失败——没有证据，分数掉了却查不出回归来源；没有回滚，一次大改把历史最好结果覆盖掉；没有复用，同样的失败下一轮再来一遍。多轮评测、长日志分析和 subagent 分工还会让 token 成本失控。

它如何工作

核心原则只有一条：先保证评分器可信，再优化 solver。每次改动都必须绑定明确假设、可回滚快照、评测证据和复盘记录。

启动清单：确认评分器状态、指标目标与中断条件、文件权限边界、运行模式（人工审核 / 沙箱自治 / 混合）、轮数与 token 预算。没有评分器时优先补评测，而不是急着写 solver。
工程目录：在项目根目录创建 .funsearch-runs/，集中存放 current_state.md、leaderboard.jsonl、wins.jsonl、failures.jsonl 等迭代证据。
每轮循环：读取状态 → 检索历史经验 → 在 decision.md 写明本轮假设与回退条件 → 只改允许的 solver 文件并保存快照 → 用项目已有命令跑评测 → 在 retrospective.md 复盘并更新经验库。
策略切换：连续 3 轮无提升换策略族，连续 5 轮无提升做策略重构，避免在已枯竭的假设空间里继续微调。
经验复用：默认 Markdown + JSONL + 标签检索，每轮只把 context_pack.md 里的相关经验放进上下文，而不是把全部历史无差别塞进去。

适用边界与注意点

它不是自动刷分器，而是一套需要你持续参与的工程协议。评分器、测试集和 benchmark 数据默认只读，修改它们必须走人工审核点。跨平台方面默认支持 Windows / Linux / macOS，脚本优先用 Python 标准库与 pathlib，不要写死平台相关命令。token 预算要在启动时确认，否则自迭代很容易在长日志和 subagent 并行中烧掉预算。