1. 从零理解 Meta-Harness它到底在优化什么Meta-Harness 是一套让 coding agent 自动搜索更优 harness 实现的机制。这里的 harness 不是模型权重而是模型外围那一圈“记什么、检什么、怎么把上下文喂给模型”的代码逻辑。你可以把它理解成给 LLM 装的操作台同一个模型操作台设计得好任务通过率能差出十几个百分点设计得差模型再强也会被拖累。它适合谁适合已经在写 Agent、跑评测、调 Prompt 却总觉得“改了半天没方向”的开发者也适合想把 coding agent 真正用进生产链路的人。传统做法是人工看失败样例猜一个改动点改 prompt 或 memory再跑一遍评测。问题在于 harness 是长链条行为系统失败原因往往跨好几个步骤才显现只看最终分数根本定位不到病灶。Meta-Harness 的思路很直接让 coding agent 在完整历史日志上自动搜索更优的 harness 实现把“调 Prompt”升级成“调程序策略”。它的核心设计不是复杂的进化算子而是一个全历史可检索文件系统——proposer 可以用 grep、cat 按需取证而不是把所有历史一次性塞进 prompt。我试过把这套思路落到本地骨架里最直观的感受是反馈信息量决定了搜索质量。只给标量分数proposer 基本在瞎猜给分数加摘要还是丢因果线索只有把原始执行轨迹一起写进文件系统agent 才能做出“可解释的错误归因 策略转向”。论文里的消融数据也印证了这点Scores Only 中位 34.6Scores Summary 中位 34.9而 Full Meta-Harness 含原始 traces 中位直接到 50.0。差距不是一点半点。所以这篇教程的目标很明确带你从零搭一个可运行的 Harness 骨架用 TaoToken 统一 Key 接入 LLM跑通一次完整的 Agent 任务触发与进化日志验证。你不需要先读完论文跟着配置走一遍整套机制自然就懂了。2. TaoToken 前置准备统一 Key 与接入信息在搭骨架之前先把模型调用这条链路打通。Meta-Harness 的 proposer 本身就是一个 coding agent它需要稳定调用 LLM 来生成新的 harness 代码。如果每个模型都单独配 Key、单独改 base_url配置会散得到处都是。TaoToken 在这里的作用就是统一入口一个 Key 覆盖多种模型base_url 固定切换模型只改 model 字段。你需要先拿到 API Key。访问控制台创建https://taotoken.net/console?utm_sourcetaotoken_aicg_blog_endutm_mediumcsdnutm_campaignrewriteutm_contentconsole创建完成后在 API Keys 页面复制密钥https://taotoken.net/api-keys?utm_sourcetaotoken_aicg_blog_endutm_mediumcsdnutm_campaignrewriteutm_contentapi-keys接入地址统一用https://taotoken.net/api注意这个 API 地址不加任何 UTM 参数保持干净。模型对话调试入口在这里配完 Key 可以先去这里验证模型是否通https://taotoken.net/models?utm_sourcetaotoken_aicg_blog_endutm_mediumcsdnutm_campaignrewriteutm_contentmodel-chat如果你打算长期跑 coding agent 和自动进化任务建议直接看 Coding Plan额度模型更适合高频调用https://taotoken.net/coding-plan?utm_sourcetaotoken_aicg_blog_endutm_mediumcsdnutm_campaignrewriteutm_contentcoding-plan接入文档在这里遇到参数问题先查它https://taotoken.net/doc?utm_sourcetaotoken_aicg_blog_endutm_mediumcsdnutm_campaignrewriteutm_contentdocClaude Code 场景的接入说明单独有一页https://taotoken.net/claude-code?utm_sourcetaotoken_aicg_blog_endutm_mediumcsdnutm_campaignrewriteutm_contentclaude-code把 Key 存进环境变量别硬编码进代码export TAOTOKEN_API_KEYsk-你的密钥 export TAOTOKEN_BASE_URLhttps://taotoken.net/api注意API Key 只存在服务端环境变量或本地 shell 里不要提交到 Git 仓库也不要在前端代码里暴露。3. 可复制配置config.toml 与 settings.json骨架分两层配置config.toml 管 Harness 运行参数settings.json 管 coding agent 的模型接入。先建目录结构mkdir -p meta-harness/{config,history,harness,logs} cd meta-harness3.1 config.tomlHarness 运行参数# config/config.toml [harness] name meta-harness-local max_iterations 8 history_dir ./history harness_dir ./harness log_dir ./logs [proposer] model claude-sonnet-4-5 temperature 0.3 max_tokens 8192 system_prompt 你是一个 harness 优化 proposer。读取 history 目录下的历史候选代码、 分数与执行轨迹提出新的 harness 实现。每次只改一个变量 并在提交前说明改动理由与预期影响。 [evaluation] task_set ./tasks/search_set.jsonl metric pass_rate timeout_seconds 300 save_traces true [memory] enable_full_history true retrieval_tool grep max_context_tokens 120000这里几个参数值得展开。max_iterations 控制外循环轮数先设 8 轮够验证机制。enable_full_history 是 Meta-Harness 的关键开关打开后 proposer 能检索全部历史而不是只看当前候选。save_traces 必须为 true否则消融实验里那个 50.0 的中位分数你复现不出来。3.2 settings.jsoncoding agent 模型接入{ llm: { provider: openai-compatible, base_url: https://taotoken.net/api, api_key_env: TAOTOKEN_API_KEY, model: claude-sonnet-4-5, timeout: 120 }, agent: { workspace: ./harness, history_workspace: ./history, allow_tools: [read_file, write_file, grep, run_shell], max_tool_calls: 40 }, logging: { level: info, trace_file: ./logs/agent_trace.jsonl } }base_url 固定指向 TaoToken 的 API 地址api_key_env 指向环境变量名而不是明文。allow_tools 里 grep 是必须的proposer 靠它在历史文件系统里取证。max_tool_calls 先给 40跑通后再按任务复杂度调。3.3 初始化历史文件系统mkdir -p history/iter_000 cat history/iter_000/candidate.py EOF def build_context(task, memory): return fTask: {task}\nMemory: {memory} EOF cat history/iter_000/score.json EOF {iteration: 0, pass_rate: 0.0, note: baseline} EOF这个 baseline 故意写得很简陋就是为了让 proposer 有明确的改进空间。history 目录下每轮一个子目录里面放候选代码、分数、执行轨迹三样东西proposer 用 grep 就能按需检索。4. 验证请求触发一次 Agent 任务与进化日志配置就绪后写一个最小触发脚本跑通一次完整的外循环。# run_harness.py import json import os import subprocess from pathlib import Path from openai import OpenAI client OpenAI( base_urlos.environ[TAOTOKEN_BASE_URL], api_keyos.environ[TAOTOKEN_API_KEY], ) def load_history(history_dir: str) - str: chunks [] for p in sorted(Path(history_dir).glob(iter_*)): code (p / candidate.py).read_text() score (p / score.json).read_text() chunks.append(f {p.name} \n{code}\n{score}) return \n\n.join(chunks) def propose_new_harness(history_text: str) - str: resp client.chat.completions.create( modelclaude-sonnet-4-5, temperature0.3, messages[ {role: system, content: 你是 harness 优化 proposer只改一个变量并说明理由。}, {role: user, content: f历史候选如下\n{history_text}\n\n请提出新的 harness 实现。}, ], ) return resp.choices[0].message.content def evaluate(candidate_code: str, iteration: int) - dict: iter_dir Path(fhistory/iter_{iteration:03d}) iter_dir.mkdir(parentsTrue, exist_okTrue) (iter_dir / candidate.py).write_text(candidate_code) # 这里替换成你的真实评测逻辑 score {iteration: iteration, pass_rate: 0.0, note: pending} (iter_dir / score.json).write_text(json.dumps(score)) return score if __name__ __main__: history_text load_history(./history) new_code propose_new_harness(history_text) result evaluate(new_code, iteration1) print(json.dumps(result, ensure_asciiFalse, indent2))运行python run_harness.py成功的话你会看到类似输出{ iteration: 1, pass_rate: 0.0, note: pending }同时 history/iter_001 目录下会生成 candidate.py 和 score.json。打开 candidate.py你应该能看到 proposer 基于 baseline 提出的改动并且附带改动理由。这就是一次完整的“读取历史 → 提案 → 评测 → 写回”闭环。把评测逻辑换成真实任务后跑满 8 轮观察 logs/agent_trace.jsonl 里的轨迹。重点看两件事proposer 是否在引用历史证据以及每轮改动是否只动一个变量。如果它一次改三四个地方说明 system_prompt 约束不够回去把“每次只改一个变量”写得更硬。5. 本篇常见错排查5.1 401 或鉴权失败先确认环境变量是否真的注入echo $TAOTOKEN_API_KEY | head -c 8如果输出为空说明 shell 没加载。base_url 必须是https://taotoken.net/api结尾不要多加斜杠也不要在 API 地址上附加任何查询参数。5.2 proposer 读不到历史检查 config.toml 里 history_dir 的相对路径。脚本从项目根目录运行时是./history如果你在子目录里执行路径就对不上。另外确认 enable_full_history 为 true否则 proposer 只能看到当前候选。5.3 每轮改动过大导致连续退化这是论文里也出现过的行为早期把结构修复和 prompt 改写同时改动结果连续退化。解决办法是在 system_prompt 里强制“隔离变量”并在评测后把失败轨迹完整写回 history让 proposer 下一轮能看到“哪次改动导致了退化”。execution traces 是决定性信息源别只存分数。5.4 上下文超限max_context_tokens 设太大容易撞模型上限。Meta-Harness 的设计本来就是按需检索而不是全量塞入所以优先用 grep 缩小范围而不是调大 max_context_tokens。如果确实需要更多历史分多次检索别一次性拼进 prompt。5.5 评测超时timeout_seconds 默认 300复杂任务可能不够。先看 logs 里是哪一步卡住如果是模型调用慢检查网络和模型选择如果是任务本身重调大 timeout 并考虑拆分 search set。6. 继续深入从骨架到可用系统跑通骨架只是第一步。接下来三件事决定这套系统能不能真正用起来。第一构建困难 search set。论文里反复强调 search set 的质量直接决定搜索方向太简单的任务 proposer 随便改改就满分学不到东西。第二日志结构化。history 目录下每轮的代码、分数、轨迹要统一命名和格式proposer 检索效率才高。第三先做轻量验证再跑重评测。每轮提案先用小样本快速筛通过后再进全量评测省时间也省额度。模型调用这条链路统一走 TaoToken 的 API 入口就行切换模型只改 model 字段base_url 和 Key 都不用动。需要长期跑 coding agent 和自动进化任务的Coding Plan 的额度模型更合适只是验证模型连通性的去模型对话页面点几下就够。接入参数有疑问的接入文档里都有对照说明。这套机制最值得记住的一点它把优化对象从“短文本提示”升级成了“可执行系统 可追溯历史”。你搭的骨架不需要多复杂但 history 文件系统和 execution traces 这两样必须完整否则 proposer 再强也只能瞎猜。