OpenAI 那份《Competitive Programming with Large Reasoning Models》报告里o3 在 Codeforces 拿到 2724 分、超过 99.8% 人类最让我在意的不是分数而是它自己长出来的调试习惯先写一个暴力正确解再写优化解然后在小测例上和暴力解对拍把边界情况一个个揪出来。想复现这个“自校验调优”回路手头需要一个能执行代码的 Agent还要一个能稳定访问推理模型的 API 通道。我的做法是用 Codex 当执行 Agent把它的模型提供方指到 TaoToken——先到 https://taotoken.net/?utm_sourcetaotoken_aicg_blog_end 创建一把 Key再在 config.toml 里把 Base URL 填成 https://taotoken.net/api。TaoToken 在这里只负责给 Codex 供 Key 和 Base URL不替你写暴力解也不做对拍真正跑题目的还是 Codex。下面是我完整跑通一遍的步骤以及你在配置时会撞到的几个坑。1. 为什么 o3 的自校验回路值得在 Codex 里复现1.1 报告里最值钱的不是分数是那个“自我验证”的动作o3 在 Codeforces 上 2724 分超过 99.8% 的人类参与者。如果只看结果很多人会归功于“模型变大了”“训练数据更多了”。但报告里真正颠覆认知的是行为观察o3 并没有依赖人类设计的专用解题流水线而是通过强化学习自发学会了“先写暴力解再拿暴力解当裁判去校验优化解”的回路。这个回路和人做竞赛题的方式几乎一样——先确保一个慢但一定正确的版本再把它作为参照系来验证快速版本。这个现象说明代码能力的上限不取决于你堆了多少预训练代码而取决于模型有没有在“推理 自我验证”上形成闭环。对于做代码 Agent 的人来说这是一个比分数更有迁移价值的结论。你不必复现 o3 的规模只要把它的策略抽象出来装进本地可用的工具链里就能在日常开发中复用同样的思考方式。1.2 复现实验的角色分配要复现这个策略需要三个角色一个能写代码、能执行测试的 Agent一个具备强推理能力的模型一个能对拍校验的脚本。Codex 天然适合当第一个角色它能生成代码、运行命令、读取结果并继续修改。第二个角色需要接入一个推理模型而 Codex 本身不自带模型它要靠 API 通道去访问。这里就是 TaoToken 的位置——它作为统一 API 通道给 Codex 提供可用的 Base URL 和 API Key。TaoToken 不参与你的实验逻辑不会帮你写暴力解也不会替你做对拍。它只解决一个问题让 Codex 能够稳定地访问到推理模型。所以整个实验链条是你在 Codex 里下指令 → Codex 通过 TaoToken 通道调用模型 → 模型返回代码和思路 → Codex 在本地执行和校验。下面先把 Key 准备好。2. 准备材料从 TaoToken 拿 Key模型 ID 以模型广场为准2.1 注册并创建 API Key打开 TaoToken注册后进入控制台在 API Keys 页面创建一把新的 Key。创建后把密钥复制下来保存为YOUR_API_KEY后面配置环境变量要用。这里提醒一句Key 只显示一次如果关掉页面再回来只能重新创建。拿到 Key 之后不要急着填进 Codex。先确认你要用的模型 ID。TaoToken 的模型广场会列出当前可用的推理模型模型 ID 以 https://taotoken.net/?utm_sourcetaotoken_aicg_blog_end 模型广场当时的列表为准不要凭记忆写死某个版本号。我在第一次配置时就因为想当然写了个不存在的模型 ID结果 Codex 一直报model not found。2.2 需要准备的文件和工具本地需要安装 Codex CLI。如果你还没有先通过官方方式安装并完成初始化。本文不展开 Codex 的安装细节因为重点在接入 TaoToken 的部分。接下来只需要两个东西~/.codex/config.tomlCodex 的配置文件用来声明模型提供方和 Base URL。环境变量TAOTOKEN_API_KEY用来存放你的YOUR_API_KEY避免把密钥明文写进配置文件。注意Codex 的配置里要填的接口地址是https://taotoken.net/api不是官网落地页也不是https://taotoken.net/v1。官网落地页只用于注册、创建 Key、看模型广场和用量而https://taotoken.net/api是填进工具的 Base URL。这两个地址千万不要混。3. 在 ~/.codex/config.toml 里把 Codex 指向 TaoToken3.1 第一步配置模型提供方用编辑器打开~/.codex/config.toml写入以下内容model 你从模型广场复制的模型ID model_provider taotoken [model_providers.taotoken] name TaoToken base_url https://taotoken.net/api env_key TAOTOKEN_API_KEY这里model字段必须是你从 TaoToken 模型广场复制的 ID不要用示例里的任何占位符。base_url固定填https://taotoken.net/api末尾不要加/v1也不要拼上任何路径。env_key告诉 Codex 从哪个环境变量读取 API Key我们统一使用TAOTOKEN_API_KEY。3.2 第二步设置环境变量在终端里执行export TAOTOKEN_API_KEYYOUR_API_KEY为了让 Codex 每次启动都能读到建议把这一行追加到你的 shell 配置文件比如~/.zshrc或~/.bashrc里。配置完成后可以先用codex --version确认 CLI 正常再跑一条最简单的消息测试连通性。如果 Codex 返回了模型响应说明 Key 和 Base URL 都没问题如果报 401检查环境变量里的 Key 是否复制完整如果报 404重点检查base_url是不是写成了https://taotoken.net或者漏了/api。这里要格外强调config.toml里只有base_url需要填接口地址不要往里面填任何带utm_source的链接。带 UTM 的官网地址只用于浏览器访问不能作为 API 端点。Codex 发送请求时会直接打到https://taotoken.net/api两者用途完全不同。4. 让 Codex 按 o3 的策略先写暴力解再做对拍4.1 设计提示词模板配置好通道之后就可以开始复现实验了。我用的提示词模板如下它把 o3 报告里观察到的自我验证回路拆成了五个指令请按照下面的流程解决这个问题 1. 先用最朴素的方式写一个保证正确的暴力解不要考虑复杂度。 2. 写一个随机小数据生成器生成 100 组规模很小的测试用例。 3. 再写一个你认为的高效解尽量优化时间和空间。 4. 在生成的小测试用例上对拍暴力解和高效解找出输出不一致的用例。 5. 根据对拍结果修复高效解重复第 4 步直到全部一致。 6. 最后给出最终解法并说明你通过暴力解发现了哪些边界情况。 问题描述[在这里粘贴题目]这个模板的关键在第 4 步和第 5 步让模型自己生成小数据、自己跑对拍、自己修 bug。这是 o3 报告里那个涌现行为的可操作版本。Codex 会先写一个brute_force函数再写一个fast_solution函数然后写一个随机数据生成器最后在main里循环比较两者输出。整个过程不需要人工干预Codex 会读取测试结果并自动迭代。4.2 一个可运行的对拍脚本示例如果你不想让 Codex 从零生成对拍代码也可以把下面的骨架提前放进项目里让 Codex 填充具体逻辑。以经典的“最大子段和”为例import random def brute_force(arr): n len(arr) ans arr[0] for i in range(n): s 0 for j in range(i, n): s arr[j] ans max(ans, s) return ans def fast_solution(arr): # 这里留给模型去实现比如 Kadane 算法 raise NotImplementedError def random_testcase(): n random.randint(1, 10) return [random.randint(-10, 10) for _ in range(n)] for i in range(100): arr random_testcase() b brute_force(arr) try: f fast_solution(arr) except Exception as e: print(fcase {i}: fast_solution 崩溃, {e}, arr{arr}) break if b ! f: print(fcase {i}: mismatch, arr{arr}, brute{b}, fast{f}) break else: print(all pass)把这个文件交给 Codex告诉它“补全fast_solution并先运行上面的对拍脚本确认通过再运行额外的大数据测试”。Codex 会通过 TaoToken 通道调用模型然后在本地的 Python 环境里执行对拍。TaoToken 在这里不执行任何代码它只负责把 Codex 的请求转发给模型——整个校验动作都发生在你的开发机上。5. 验证调用去 TaoToken 控制台对一下这次 Codex 调用5.1 看控制台里的调用记录和用量对拍跑完后你可能想知道刚才的请求到底有没有走 TaoToken。打开 https://taotoken.net/?utm_sourcetaotoken_aicg_blog_end 登录后进入控制台的用量页面应该能看到刚才 Codex 触发的调用记录包含请求时间、模型 ID 和消耗的 token 数量。如果你看到的记录是空的说明 Codex 可能还在用旧的 provider 配置或者环境变量没有生效。这里也顺便提一个排查技巧在 Codex 里运行codex exec ping如果配置生效终端会正常响应如果不确定可以直接在对话里问 Codex“你现在用的是什么 base_url”它能根据自身配置给出答案。但更可靠的方式还是看 TaoToken 控制台的实时用量。5.2 确认模型 ID 和配额如果你在控制台看到调用记录但模型 ID 和你预期的不一样回到模型广场重新复制正确的 ID并更新config.toml里的model字段。如果你打算长期在 Codex 里跑类似的推理实验建议先看一眼 Coding Plan 的套餐是否匹配你的调用量Key 不够用或怀疑泄露时随时到 API Keys 控制台 删除旧 Key 并新建一把。6. 报错速查401、404、model not found6.1 401 UnauthorizedKey 没读对这个错误几乎都是TAOTOKEN_API_KEY环境变量的问题。先检查终端里echo $TAOTOKEN_API_KEY是否能输出完整的 Key再检查.zshrc或.bashrc里是否写了正确的导出语句。另一个常见原因是复制 Key 时把尾部的空格也带上了导致鉴权失败。如果环境变量没问题就去 TaoToken 控制台重新创建一把 Key旧的可能是被误删或轮换了。6.2 404 Not FoundBase URL 写错了Codex 报 404 时第一件事就是看config.toml里的base_url。正确的写法是https://taotoken.net/api最后面没有/v1没有/chat也没有任何查询参数。如果你把官网落地页的地址填进去了就一定会 404因为浏览器地址和 API 端点不是一回事。另外注意model_provider的名字要和[model_providers.taotoken]这个表头完全一致大小写不同也会导致 Codex 找不到 provider。6.3 model not found模型 ID 是临时的Codex 能通过鉴权但报模型不存在说明model字段写了一个模型广场上不存在的 ID。我犯过的错是直接复制了别人文章里的模型名没去 TaoToken 模型广场核对。模型列表是动态调整的今天可用的 ID 明天可能下线所以配置前务必以 https://taotoken.net/?utm_sourcetaotoken_aicg_blog_end 模型广场当前显示的 ID 为准。不要用任何带日期后缀或版本号的猜测值。7. 跑通以后把“暴力解自校验”变成默认操作如果你顺利跑完一轮对拍你会明显感觉到Codex 给出的最终解法比直接问“请帮我做这道题”要稳得多。原因是它被强制要求先建立一个正确性锚点再在这个锚点上做优化。这个行为模式可以迁移到日常开发里写复杂逻辑前先让 Codex 给你一个直接但正确的版本再让它优化并且用随机数据对拍。不要嫌麻烦很多隐蔽的边界条件就是这么被发现的。这套实验跑通后我建议再去 TaoToken 模型对话 里用同一把 Key 发一条测试消息确认模型 ID 和 Base URL 没填错如果接下来打算让 Codex 长期承担这类推理任务可以打开 Coding Plan 看看套餐和调用量是否匹配。需要新建或轮换 Key 时直接去 控制台 API Keys 操作。Codex 的接入参数如果还想再核对保持base_url https://taotoken.net/api、env_key TAOTOKEN_API_KEY这两个值不要动基本不会再出问题。