复现《Absolute Zero》那套 proposer/solver 自博弈之前先在 TaoTokenhttps://taotoken.net/?utm_sourcetaotoken_aicg_blog_endutm_content把 Key 和通道建好。笔记里的 proposer 要借 python 执行器给候选题打 learnability 分solver 按答对答错领 reward每轮生成 B64 个样本3.1–3.3 的过滤规则还得反复改脚本、多次运行验证确定性Codex 一跑就是好几个小时会话断在中途前面几轮迭代基本白做。通道这件事在 TaoToken 只占两步——拿 Key、填 Base URL真正花时间的是让 Codex 读懂原文伪代码把校验脚本和测试补齐判分逻辑、脚本执行、结果比对全部留在你自己的机器上。下面按笔记的推进顺序把这条链路一段段落到~/.codex/config.toml和你的 python 工程里。1. proposer 的 learnability 打分为什么把 Codex 逼成了长会话工具1.1 候选题不是随便出的先过 python 执行器这一关《Absolute Zero》的设定是零数据没有现成题库题目由 proposer 自己造。但造出来的题不能直接进训练池笔记里写得很清楚候选题要先借 python 工具跑一遍——转成{prompt, 代码, 输入输出}这样的结构交给执行器判一次能不能跑通、跑出来的结果跟预置答案对不对得上都会折算进 learnability 分数。也就是说 proposer 的命题权是被执行器卡住的题太水solver 稳过拿不到梯度题太难solver 全错同样没有有效信号。只有落在“有点难但能学”的区间里这条样本才算有价值。落到复现层面这是一个非常具体的活把伪代码里的打分分支翻译成 python 函数再配一个受控的执行环境。难点不在算法而在细节——异常怎么捕获、超时怎么设、返回结构怎么统一、分数落在哪个区间算有效。原文只给了判定条件没给可直接运行的实现你只能一边对公式一边补代码。1.2 solver 的 reward 与 B64一轮迭代到底有多长solver 这边相对直白答对给正分答错给负分再按题目的可学习程度做加权。真正决定工程体量的是批量——每轮要生成 B64 个样本每个样本都要走完 propose → 过滤 → 判分然后才回到 proposer 更新一轮。64 个样本不是 64 行日志而是 64 次脚本改动的机会、64 组可能冒出来的报错再叠上“多跑几次确认确定性”同一批样本要被执行器反复过。这正是需要 Codex 的场景不是一次问答而是一个能连续读原文、读你的脚本、读报错、改代码、再解释改动理由的会话。这类会话通常跨越几十分钟到几小时中间夹杂几十次文件读写和命令输出。任何一次模型请求失败都会让上下文里的推理链断掉重启之后你还得重新交代“刚才改到 3.2 的哪一条”。所以先把通道固定下来再谈脚本顺序不能反。1.3 会话长度的成本结构决定了你要先配环境把一轮迭代拆开看Token 消耗大头有三处读长文档与长脚本、反复生成补丁、以及多轮验证时重复贴出的执行输出。前两处跟模型上下文长度强相关第三处跟你的会话管理习惯相关。很多人把 B64 跑成 B8 的效果不是模型不行而是每次验证都把整份日志贴回对话几轮之后上下文被日志挤满真正的代码反而“看不见”了。后文 5.3 会专门讲怎么把状态写到文件里而不是留在上下文。2. 把 Codex 的 config.toml 接到 TaoToken 通道2.1 拿 YOUR_API_KEY 这一步只在落地页做打开 https://taotoken.net/?utm_sourcetaotoken_aicg_blog_endutm_content 注册账号进控制台创建一把 API Key记下它——多数平台只在创建时完整展示一次。顺手看一眼模型广场把你打算让 Codex 用的模型 ID 抄下来后面config.toml里model字段要填这个值。Key 不要硬编码进任何 python 脚本或 git 仓库用环境变量存脚本只读环境变量。到这一步为止你在落地页要做的事情就三件注册、建 Key、看可用模型。别在落地页上找“运行入口”它不负责执行你的脚本。2.2 ~/.codex/config.toml 里改哪几行Codex 的配置走 TOML文件默认在~/.codex/config.toml。要接自定义通道核心是把model_provider指向一个你自己定义的 provider并在 provider 段里写base_urlmodel YOUR_MODEL_ID model_provider taotoken [model_providers.taotoken] name TaoToken base_url https://taotoken.net/api env_key TAOTOKEN_API_KEY wire_api chat几点必须对齐base_url就是https://taotoken.net/api末尾不要加/v1也不要带任何查询参数。env_key是环境变量名不是 Key 本身。终端里执行export TAOTOKEN_API_KEYYOUR_API_KEY或者写进你的 shell 配置。wire_api按你所用通道的接口形态选拿不准就先按chat试报错再对照文档调整。model先填一个你确认可用的模型 ID跑通链路之后再换别的。这套配置只解决“请求发得出去”不解决“脚本写得对”。判分逻辑、执行器、测试用例依然是你本地工程里的东西。2.3 模型 ID 以模型广场当时列表为准网上流传的 ID 往往带日期后缀抄错一个字符就是 404 或者模型不存在。正确做法是每次开新工程前回 https://taotoken.net/?utm_sourcetaotoken_aicg_blog_endutm_content 的模型广场看一眼当前可用的 ID直接复制粘贴进config.toml。切换模型时只改model这一行model_provider段完全不动这样你在会话中途换模型不会破坏已有上下文。如果你打算把 proposer 和 solver 用不同模型跑一个偏生成、一个偏推理建议开两份配置或者用两个终端会话别在一个config.toml里来回改——改完不重启旧值还在缓存里很容易出现“明明改了却还是老模型”的错觉。3. 把 3.1–3.3 的过滤规则交给 Codex 改成能跑的校验脚本3.1 不抛异常语法层和执行层要分开判“候选题不抛异常”这条最容易写混。语法错误和执行期异常发生在不同阶段判定方式也不一样语法层用ast.parse扫一遍就够执行层必须真的跑一次才能发现除零、越界、类型不匹配。把这两层拆成两个函数让 Codex 分别补测试也分开写import ast def is_syntax_ok(src: str) - bool: try: ast.parse(src) return True except SyntaxError: return False def run_case(src: str, inputs: str, timeout: float 2.0) - dict: # 由你在本地实现并执行把 stdout / 异常类型 / 耗时结构化返回 ...注意职责边界Codex 负责读懂伪代码、生成这两个函数的骨架和单元测试真正的exec、沙箱、超时控制由你在本地环境和脚本里完成。把执行结果成功/失败、异常类型、耗时整理成短 JSON 贴回对话比整段 stderr 有效得多。3.2 禁用 os/sys用 AST 名单别用字符串黑名单“禁用敏感包”这条写法上的坑比想象中多。用字符串搜索os in code会把变量名close、注释里的单词一并命中正确做法是遍历 AST 的Import/ImportFrom节点比对模块名是否落在禁止集合里BANNED {os, sys, subprocess, shutil, socket, ctypes} def uses_banned(src: str) - bool: tree ast.parse(src) for node in ast.walk(tree): if isinstance(node, ast.Import): for alias in node.names: if alias.name.split(.)[0] in BANNED: return True elif isinstance(node, ast.ImportFrom): if node.module and node.module.split(.)[0] in BANNED: return True return False让 Codex 帮你补这段的时候把“禁止集合要可配置”“命中后要返回命中的模块名而不是只返回 True”一起写进提示里。返回模块名日志里才能看出是过滤规则生效还是脚本自己写崩了。3.3 多次运行结果一致种子、容差、集合顺序确定性这条最难因为它的失败往往是间歇性的。要让 Codex 帮你把不确定性来源一条条列出来并写进测试随机数有没有固定种子、浮点比较用了绝对相等还是容差、返回集合有没有排序、字典遍历顺序有没有依赖、外部输入有没有被缓存。对应的测试骨架大致是def assert_deterministic(fn, args, runs: int 3, tol: float 1e-9): outs [fn(*args) for _ in range(runs)] for a, b in zip(outs, outs[1:]): assert abs(a - b) tol, f不稳定: {a} vs {b}runs设几次由你决定原文里强调的就是“多跑几次再判”一次跑通不算数。把这段测试交给 Codex 生成后由你在本地循环执行把失败的那几组参数和输出贴回对话让它定位是哪一处引入了随机性。3.4 分工写清楚Codex 生成与解释本地执行与贴回整条链路里最容易出问题的是职责混淆。Codex 不连你的工程环境也不执行你的代码它只负责读原文、读脚本、生成补丁、解释改动原因。你的本地负责运行校验脚本、收集报错、把结构化结果贴回对话。建议约定一个固定格式{case_id: p-017, stage: filter, ok: false, error: ZeroDivisionError, hint: 输入含 0}每条只贴几十个字符几十条也不会把上下文撑爆。这个约定本身也可以让 Codex 帮你写成一个小函数挂在你的测试 runner 末尾。4. 一条 hello world 级 seed 验证 propose→过滤→判分4.1 日志里先确认请求走的是 TaoToken配置改完不要直接上 B64。先拿原文开头那种最简单的 seed输出固定字符串的那类走一遍最小链路propose 一次 → 过一遍过滤 → 判一次分。观察三件事请求是否成功返回、日志里记录的 Base URL 是不是https://taotoken.net/api、返回里 usage 是否有数值。Base URL 不对说明config.toml没生效或者环境变量没读到usage 为空说明你调的可能不是生成接口。4.2 再逐步换成 p,i,o,m 那批任务hello world 跑通之后再上真任务。p,i,o,m那批样本建议逐条加别一次全丢进去先跑 3 条看过滤规则命中了哪几条、判分区间落在哪里再扩到 10 条、20 条。每扩一次把统计结果通过数、异常数、被禁用包拦下的数量、确定性失败的组数贴回对话让 Codex 继续调脚本。这样做的好处是出问题时你能立刻定位是新样本引入的还是规则本身写错了。4.3 会话续跑状态写进文件别留在上下文长会话最实在的一个习惯每完成一批样本把进度写进progress.json字段包括已完成样本 ID、当前过滤规则版本、最近一次失败原因。会话万一中断重启后只需把这份文件和脚本一起给 Codex它能立刻接上不用你复述半小时历史。这一步本身就是典型的 agent 编排技巧——把状态外置到文件系统而不是依赖模型记忆。5. 长会话下最常见的几种报错5.1 401 / 403Key 放错了位置config.toml里写的是env_key TAOTOKEN_API_KEY意思是“去读这个环境变量”不是“这个变量的值是 Key”。如果环境变量没导出或者名字拼错一个字母请求就会以鉴权失败返回。排查顺序先echo $TAOTOKEN_API_KEY看有没有值再确认env_key里的名字和变量名完全一致最后确认这个终端就是启动 Codex 的那个终端。Key 失效的话回 https://taotoken.net/?utm_sourcetaotoken_aicg_blog_endutm_content 重新建一把。5.2 404base_url 末尾多写了 /v1这是最高频的一类。https://taotoken.net/api和https://taotoken.net/api/v1在配置层面只差四个字符但请求路径会直接错位。检查方法很土但有效打开config.toml把base_url那一行完整读一遍确认末尾是api而不是api/v1也确认没有误粘贴查询参数。改完记得完全退出并重启 Codex 进程让配置重新加载。5.3 上下文被日志撑满导致重复改同一个函数典型症状是同一段过滤逻辑改了三遍每遍都“像第一次见”。原因通常是每轮都把完整执行日志贴回对话把真正的代码挤到上下文之外。解法是回到 3.4 的三字段结构化反馈日志留在本地文件对话里只出现摘要。5.4 别指望 Codex 替你在本地执行校验脚本、执行器、超时控制全部是本地动作。Codex 能写出这些代码、能解释报错、能给出修改方案但它不会连上你的机器去跑。凡是看到“让模型直接执行诊断脚本”的写法都值得警惕——正确的闭环永远是生成 → 本地执行 → 贴回结果 → 再改。6. 一轮自博弈跑完回控制台对一下这次调用等你把 hello world 和前十条p,i,o,m样本都跑通别急着开满 B64。先做一次成本核对这一轮 proposer 生成、solver 作答、多轮验证各花了多少然后再决定要不要放量。核对的方式很直接去 TaoToken 模型对话 用同一把 Key 发一条测试消息确认模型 ID 和 Base URL 都没填错如果准备连续跑几周的自博弈迭代可以打开 Coding Plan 看套餐额度够不够需要再建一把专用 Key 的时候控制台 API Keys 就在这里。三个页面看一遍基本能判断你的迭代是卡在模型侧还是卡在脚本侧——后者居多而后者恰恰是 Codex 最该干活的地方。