这次新闻节奏很快OpenAI 刚在数学推理赛道放出一个大招用 Codex 在 FrontierMath 等超高难度数学基准上“连破 10 道难题”社区项目 Fable 跟着就在 24 小时内“复现”了其中 5 道。很多人第一反应是“OpenAI 又被抄作业了”。但做技术的人应该先问一个问题Fable 复现的到底是什么是模型权重还是评测闭环答案大概率是后者。换句话说这次的重点不是“谁抄了谁”而是 OpenAI 已经把手里的 agent 评测 harness 开源了。任何团队只要按同样的任务闭环跑一遍就能在数学推理、代码生成、自动修 bug 这类场景里快速验证自己的模型或者第三方模型能做到什么程度。这篇文章我会拆清楚三件事Codex 和 FrontierMath 到底在解决什么问题、Fable 24 小时复现的工程思路是什么、以及你自己怎么在本地把 Codex CLI 跑起来并把它接到批量任务和 API 工作流里。如果你关心本地部署、agent 评测、接口调用和自动化解题这篇文章可以直接收藏。下面直接进入正题。1. 核心能力速览先把这次新闻涉及的两个核心项目拆开看。左边是 OpenAI 官方的 Codex右边是社区项目 Fable。两者在技术链路上是“上游能力”和“下游复现”的关系。能力项说明项目类型AI 编程 Agent / 代码智能体 数学推理评测闭环开源情况OpenAI 已开源 Codex harness仓库可从 GitHub 获取Fable 为社区复现项目具体开源细节需以仓库为准核心功能自然语言生成代码、自动执行、自动检查结果、根据反馈迭代修复可用于解答数学题、编写脚本、批量处理问题显存需求走官方 API 时本机几乎无显存压力本地运行开源模型时显存取决于模型大小需按实际环境测试支持平台命令行工具适合 macOS / Linux / WindowsWSL等环境具体以官方文档为准启动方式CLI 命令启动支持交互式对话和一次性任务执行是否支持 API支持 OpenAI API 协议可接入兼容服务是否支持批量任务可以通过脚本循环调用接口配合日志和重试机制实现适合场景数学/编程题自动求解、代码生成与修复、Agent 评测对比、私有任务批处理流水线从这张表能看出来Codex 的价值不只是“AI 会解数学题”而是它把“出题 → 生成代码 → 执行 → 验证 → 迭代”这条 agent 闭环标准化了。Fable 能快速复现本质上是因为这条闭环已经不再依赖 OpenAI 内部系统而是可以通过公开的 harness 和 API 接口复制。2. 这个新闻到底在说什么Codex、FrontierMath 与 Fable先说 Codex。Codex 是 OpenAI 旗下的代码智能体它在终端里运行接收自然语言任务然后自动写代码、执行代码、查看结果并根据结果反复修改。和普通聊天式 AI 的区别在于Codex 是真的会“动手跑代码”的而不是只把代码贴在对话框里让你自己复制。这次 OpenAI 对外展示的结果是让 Codex 去解 FrontierMath 这类基准测试里的题目。FrontierMath 是 Epoch AI 推出的数学基准集难度极高涉及数论、组合数学、代数等前沿领域。很多常规大模型在这类题目上正确率接近于零所以“解出 10 道”在学术评测语境里是有分量的进展。再看 Fable。从新闻标题看Fable 是一个社区项目在 24 小时内“复现”了其中 5 道。这里的“复现”不是复制 OpenAI 的模型权重也不是用相同参数重新训练而是复现整套推理闭环把数学题转换成可编程验证的任务。调用一个大模型生成候选求解代码。执行代码并拿到对错反馈。把错误信息返回给模型让它继续修正。直到通过测试或达到最大迭代次数。这套流程正是 OpenAI 开源 harness 的核心。Fable 只用了 24 小时就跑了 5 道题说明两件事第一OpenAI 的 harness 工程质量足够高外部团队不需要从零搭起第二解决这些数学题的关键瓶颈已经不是单纯的模型智力而是任务拆解和自动验证设计是否合理。所以不要把这个新闻当成“开源社区两天追上 OpenAI”。更准确的理解是OpenAI 把评测方法开源了社区第一次可以在同一套规则下测试自己的模型。对普通开发者来说这意味着你可以把同样的方法用到自己的领域比如自动修复仓库里的 bug、批量处理格式转换、跑回归测试等。3. 适用场景与使用边界3.1 适合谁用做 AI 推理能力评测的研究者。这类人最需要标准化的评测闭环而不是自己重复造轮子。OpenAI 开源 harness 之后可以直接用同一套题来对比 GPT 系列、开源模型、微调模型的表现。做自动编程和代码修复的开发者。Codex 的工作流是“写代码 → 执行 → 看报错 → 改代码”这个闭环能直接接到 CI/CD 流水线里。做批量任务处理的工程团队。如果你们有一批结构化任务需要交给大模型完成比如从文档提取信息、生成固定格式代码、批量测试脚本Codex 的 CLI 和 API 模式都能很好地支撑。对本地部署感兴趣的个人开发者。Codex CLI 本身是轻量客户端不需要本地 GPU只要有一个可用的模型接口就能跑起来。3.2 不适合什么场景不适合当普通聊天机器人用。Codex 的核心是代码执行和迭代而不是闲聊。不适合处理没有明确验证标准的任务。数学题可以跑代码验证对错但“帮我写一段优美的文案”这种没有客观标准的任务Codex 的自动迭代优势发挥不出来。不适合完全离线、不允许调用外部 API 的涉密环境。如果必须完全本地部署需要额外搭一套本地模型服务显存和性能要求会明显提高。3.3 合规边界使用这类 agent 工具时有三条边界必须守住合法授权。不要用 AI 去处理未授权的受版权保护内容比如未经允许解析某本书、抓取某个平台的数据然后商用。隐私保护。不要把内部代码、个人隐私数据直接提交给第三方 API。敏感场景优先考虑本地部署或私有化网关。评测诚信。不要用 AI 自动生成答案去参与在线竞赛、考试或需要人工完成的评测这是学术不端也会影响后续对模型能力的真实判断。4. 环境准备与前置条件如果你想自己跑通 Codex CLI这一步很重要。环境配置不复杂但需要提前确认几个依赖项。4.1 官方 Codex CLI 环境从目前公开的文档和社区实践来看Codex CLI 是一个终端工具主要依赖以下环境操作系统macOS、Linux或 Windows 上的 WSL。Node.js建议安装 LTS 版本推荐 20 以上具体以官方 README 要求为准。Git用于拉取仓库和后续版本更新。网络环境能正常访问 OpenAI 服务或兼容接口。API Key需要一个可用的 OpenAI API Key或者兼容 OpenAI 协议的第三方服务密钥。本地终端建议使用 iTerm2、Windows Terminal 或 VS Code 集成终端。4.2 Fable 复现类项目的环境Fable 这类项目如果涉及本地模型推理需要注意Python 3.10 或更高版本。CUDA 环境如果本机有 NVIDIA GPU需要装好显卡驱动和 CUDA Toolkit。PyTorch建议安装最新稳定版和你的 CUDA 版本对应。模型权重具体用哪个模型要看 Fable 项目的 README。可能是 GPT 系列 API也可能是开源模型。磁盘空间一个 7B 参数的模型量化后也需要 6-8GB 左右磁盘空间13B 或 70B 模型要求更高。没有具体材料的情况下最稳妥的做法是先看项目仓库的 requirements.txt 或 environment.yml按官方说明装依赖不要凭经验猜版本。4.3 获取 API KeyOpenAI 的 API Key 获取方法以官方平台为准注册账号后在 API Keys 页面创建密钥。需要注意API Key 只显示一次创建后马上保存。不要把 Key 硬编码到代码仓库里建议用环境变量或 .env 文件管理。如果使用第三方兼容服务要确认它是否完整支持 OpenAI API 协议特别是“消息格式”和“工具调用”能力这会影响 Codex 的迭代效果。4.4 通用检查清单在开始部署前花两分钟检查一遍是否安装了 Node.js 18是否能执行 npm 或 yarn是否有一个可用的 API Key是否已经确认目标项目仓库的依赖说明磁盘空间是否足够建议至少留 5GB。端口是否空闲Codex 本机启动时不依赖固定端口但如果后续接入 Web 服务要检查端口冲突。5. 本地部署与启动Codex CLI 实操这部分我按“安装 → 登录 → 单任务 → 交互模式”的顺序展开。命令以 Codex CLI 的通用用法为例实际参数以项目仓库 README 为准。5.1 安装 Codex CLICodex CLI 通过 npm 发布安装命令是npm install -g openai/codex如果你的环境存在 npm 下载慢或安装失败的问题可以切换到国内镜像源npm config set registry https://registry.npmmirror.com安装后再执行一次npm install -g openai/codex装完检查版本codex --version如果终端提示找不到命令检查 Node.js 全局 bin 目录是否在 PATH 中或者用 npx 方式运行。5.2 登录或设置 API KeyCodex CLI 安装后会引导登录。执行codex login如果你已经有 API Key也可以直接通过环境变量提供export OPENAI_API_KEY你的API Key为了不把 Key 写死在 shell 配置里推荐用 .env 文件管理# .env OPENAI_API_KEY你的API Key然后在终端执行set -a source .env set a5.3 跑第一个任务先跑一个最简单的任务确认整个链路是通的codex 用 python 写一个函数输入是整数 n输出第 n 个斐波那契数执行后Codex 会生成代码、运行测试、判断结果是否符合要求。如果它发现结果不对会自动修改代码继续尝试。第一次跑通后你会看到输出中既有 Python 代码也有执行结果。如果不想交互确认可以加自动模式codex --full-auto 用 python 写一个函数输入是整数 n输出第 n 个斐波那契数全自动模式适合批量任务但注意要给足超时时间避免任务卡住。5.4 交互式会话模式进入交互模式后可以连续提多个问题Codex 会保留上下文codex在交互界面里输入你的需求它会逐步执行。这个模式适合调试和试错也适合观察模型是怎么分步解决复杂问题的。5.5 启动时容易踩的坑npm 安装成功但命令找不到检查 Node.js 的 bin 路径重新打开终端。第一次登录弹浏览器失败直接用 API Key 环境变量方式。请求超时检查网络或者增加超时配置。模型参数报错确认使用的模型名是否和你 API 服务商提供的模型一致。6. Fable 复现思路解析24 小时做对了什么Fable 能在 24 小时内复现 5 道题说明它的切入点非常精准。虽然公开材料有限但从“复用 OpenAI 开源 harness”这条线索可以推断出它的工程路径。6.1 先跑通官方 demo再拆任务Fable 的第一优先级不是训练新模型而是把 OpenAI 开源的 harness 跑起来。先看它自带的示例任务是什么输入格式是什么输出格式是什么验证逻辑在哪里。只有先把上游代码跑通后续替换模型和换题才可控。6.2 把数学题转成自动化验证闭环数学题和普通编程题不一样。编程题有明确的测试用例数学题可能是“证明某个结论”或“求某个表达式的值”。Fable 思路是先把每道题改造成代码可执行的验证流程比如把“求值”变成“写一个函数输出结果然后用标准答案比对”。这一步是复现的关键。用伪代码描述这个闭环def solve_and_verify(problem): # 1. 把数学题描述拼成 prompt prompt build_prompt(problem) # 2. 调用模型生成候选代码 code model.generate_code(prompt) # 3. 在沙箱环境执行代码 result execute_in_sandbox(code, problem.test_inputs) # 4. 和标准答案比对 if result problem.expected_answer: return pass else: # 5. 把报错和结果返回给模型让它继续修 feedback f输出结果不对{result} updated_code model.fix_code(code, feedback) return solve_and_verify_with_code(problem, updated_code)模型的迭代次数要限制比如最多 10 次。如果 10 次还没通过就记录失败原因下一轮再优化 prompt 或验证逻辑。6.3 把每道题的执行结果落盘复现项目能不能稳定取决于日志设计。Fable 应该会对每道题记录初始 prompt、第一次生成的代码、执行结果、报错信息、第几次迭代通过、最终代码。这些日志既是调试依据也是复现报告的数据源。6.4 复现的边界在哪Fable 复现的是“评测闭环的可行性”不是“模型的数学能力”。它证明了如果你有一个足够强的模型再加上标准化的验证闭环是可以在 FrontierMath 这类任务上拿到结果的。但如果换成较弱的小模型同样的闭环也不一定能解出来。模型能力仍然是底座harness 只是把模型能力的上限尽量逼出来。7. 接口 API 与批量任务Codex CLI 本身是终端优先的应用但它的底层能力可以通过 OpenAI API 协议暴露出来。这也是 Fable 这类项目能快速跑流程的基础。7.1 通用 API 调用格式如果你想把 Codex 的解题能力接到自己的工具链里可以直接用 OpenAI 兼容接口。以下是一个通用模板import requests import json API_URL https://api.openai.com/v1/chat/completions API_KEY 你的API Key # 实际模型名以你的服务商为准 model_name 你的模型名 prompt 请用 python 解决下面这道数学题 给定正整数 n判断 n 是否能被 3 整除。 要求 1. 输出可直接运行的 python 代码。 2. 代码末尾打印最终结果。 3. 不要输出额外解释。 payload { model: model_name, messages: [ {role: user, content: prompt} ], max_tokens: 2048, temperature: 0.2 } headers { Authorization: fBearer {API_KEY}, Content-Type: application/json } resp requests.post(API_URL, headersheaders, jsonpayload, timeout120) data resp.json() if resp.status_code 200: content data[choices][0][message][content] print(模型输出) print(content) else: print(f请求失败{resp.status_code} {data})注意三点第一这个模板只是通用示例具体请求路径、模型名、参数名要以实际服务的文档为准。第二temperature 控制随机性数学题建议设低一点比如 0.1 到 0.3。第三max_tokens 不要太低否则模型可能写到一半被截断。7.2 批量任务设计如果手头有几十道题要做不建议手动一条条复制。推荐的做法是先建一个 JSONL 输入文件每一行是一道题{id: 1, problem: 求方程 2x 5 13 的解输出 x 的值。} {id: 2, problem: 判断 2025 是不是质数输出 True 或 False。} {id: 3, problem: 计算 1 到 100 所有奇数之和输出数字。}然后用 Python 脚本循环读取逐条调用 APIimport json import time import requests API_URL https://api.openai.com/v1/chat/completions API_KEY 你的API Key def solve_problem(problem_text, model_name, max_retry3): payload { model: model_name, messages: [ {role: user, content: problem_text} ], max_tokens: 2048, temperature: 0.2 } headers { Authorization: fBearer {API_KEY}, Content-Type: application/json } for attempt in range(max_retry): try: resp requests.post(API_URL, headersheaders, jsonpayload, timeout180) if resp.status_code 200: return resp.json()[choices][0][message][content] else: print(fattempt {attempt 1} failed: {resp.status_code}) except Exception as exc: print(fattempt {attempt 1} error: {exc}) time.sleep(3) return None with open(problems.jsonl, r, encodingutf-8) as fin: lines fin.readlines() outputs [] for line in lines: item json.loads(line) result solve_problem(item[problem], 你的模型名) outputs.append({ id: item[id], problem: item[problem], result: result }) print(f{item[id]} - {result}) time.sleep(1) # 控制请求频率避免触发限流 with open(outputs.jsonl, w, encodingutf-8) as fout: for out in outputs: fout.write(json.dumps(out, ensure_asciiFalse) \n) print(批量任务完成)批量任务最容易遇到三个问题请求限流、单条超时、结果截断。建议在脚本里加上请求频率控制、单条任务重试、以及输出字符串长度检查。7.3 和其他 API 协议的兼容问题社区里经常有人问 OpenAI API 协议和 Anthropic API 协议有什么区别。简单说OpenAI 的/v1/chat/completions接口使用messages数组而 Anthropic 的/v1/messages接口使用system字段单独传系统提示词。如果你内部有多个模型服务建议统一走一个网关层把不同的协议转换成统一格式否则上层应用每换一个模型就要改一遍调用逻辑。8. 资源占用与性能观察这次新闻里的“解数学题”任务资源占用差异非常大。8.1 走官方 API 时的资源占用如果直接调用 OpenAI 的 API本机只需要一个轻量 CLI 客户端和网络连接。CPU 占用很低内存占用通常在几百 MB 级别显存可以认为不占用。但要注意 API 请求耗时Agent 任务不是单次请求而是多次“生成 → 执行 → 迭代”一次完整解题可能产生十几个请求所以时间消耗和 token 消耗都比较高需要提前做好成本预算。8.2 本地模型推理时的资源占用如果 Fable 这类复现项目选择在本地跑开源模型那资源占用就完全不一样了。以 7B 参数模型为例4bit 量化模型显存占用大约 6GB 到 8GB。13B 参数模型显存要求提高到 10GB 以上。70B 参数模型即使量化也需要 40GB 以上显存或者用多卡并行。在没有材料支撑的情况下不能给出精确数字。更稳妥的判断是先看项目 README 推荐的模型规格再根据本机显存决定是选择小模型量化版本还是直接走 API。8.3 如何观察资源占用本地跑任务时用以下命令实时观察# 查看 GPU 显存使用 nvidia-smi -l 1 # 查看 CPU 和内存 htop # 查看某个进程的资源占用 ps aux | grep python如果显存接近上限优先做三件事降低并发数、换小尺寸模型、开启量化。8.4 影响性能的关键参数模型参数量直接决定显存占用和推理速度。输入长度数学题描述越长上下文处理时间越长。迭代次数Codex 类 agent 的性能瓶颈主要是迭代次数而不是单次推理速度。并发数并发太高可能导致 API 限流或显存溢出。输出长度max_tokens 设置过大会拖慢响应设置过小会导致答案截断。9. 常见问题与排查方法下面把最容易遇到的问题列成一张排查表。问题现象可能原因排查方式解决方案npm 安装 Codex CLI 失败网络问题、Node 版本过低查看 npm 报错日志执行 node -v 检查版本切换镜像源升级 Node.js 到 LTS 版本终端提示 codex 命令不存在Node 全局 bin 目录不在 PATH执行 which node 和 npm bin -g 查看路径把 bin 目录加入 PATH或改用 npx codex登录时报错API Key 不对、网络受限检查环境变量用 curl 测试接口连通性重新生成 API Key检查网络配置请求返回 401Key 无效或权限不足检查 Key 是否复制完整查看账户余额重新创建 Key确认账户有可用额度模型返回空内容请求格式错误、模型名不对打印完整响应 JSON核对 model 名称和 messages 格式数学题多次迭代仍然失败prompt 没有给出验证标准检查 prompt 是否把“怎么算对”说明白在提示词里增加示例、要求输出固定格式批量任务中途中断单条 API 请求超时、限流查看错误日志检查返回的状态码 429增加重试机制降低请求频率设单条超时本地模型推理卡死显存不足、模型加载失败运行 nvidia-smi 查看显存换小模型、开量化、降低并发数评测脚本突然报错依赖版本不一致、缺少库查看 traceback核对 requirements按官方 requirements 重建虚拟环境端口冲突应用占用了默认端口执行 lsof -i:端口号 查看占用换端口或关闭占用进程补充一点排查 agent 任务问题时先看日志再复现单条任务。agent 类任务最怕“黑盒式跑批”一旦失败找不到任何中间过程。所以无论用 Codex CLI 还是自己写脚本第一步永远是记录每轮生成的代码和反馈信息。10. 最佳实践与使用建议基于这次 Codex 和 Fable 的工程链路我给出几条可以直接落地的建议。10.1 先把“验证闭环”搭起来大部分 AI 任务失败的原因不是模型不够聪明而是缺少验证标准。你可以像 Fable 一样先不急着调模型而是把一个题目变成“生成代码 → 跑测试 → 返回错误”的最小闭环。闭环通了再换更强的模型。10.2 单条跑通再跑批量批量任务之前一定要用 3 到 5 条样本验证接口、prompt 和结果解析。批量跑的时候给每条任务加唯一 ID方便定位失败项。10.3 用日志和失败重试保护任务至少要做到每条任务保存完整输入输出。失败任务自动重试 2 到 3 次。重试仍失败的任务单独落盘不阻塞后面的任务。设置合理的超时时间比如单条 120 到 300 秒。10.4 API Key 和隐私安全不要提交 API Key 到代码仓库。内部代码和敏感数据不要直接发送到第三方服务。如果必须走外部 API建议在请求前做脱敏处理。10.5 场景正确的模型选择解数学题、跑代码优先选代码能力强的模型温度设置低。生成文案、润色文本可以选通用对话模型温度可以稍高。本地部署显存够用的情况下选 7B 模型会比较平衡追求效果再考虑更大模型量化版本。11. 总结与下一步OpenAI 这次最值得关注的点不是“10 道数学题”本身而是它把 agent 评测的 harness 开源了。Fable 在 24 小时内复现 5 道题说明这套“出题 → 生成 → 执行 → 验证 → 迭代”的闭环已经可以脱离 OpenAI 内部环境被外部团队复制。如果你对这块感兴趣下一步建议是先把 Codex CLI 安装跑通用一道简单编程题验证整个链路再挑一个你手头有客观验证标准的问题仿照 Fable 的思路把 prompt、验证脚本、重试机制搭起来最后再考虑接 API 和批量任务。最容易踩的坑是跳过验证闭环直接让模型“自由发挥”结果要么得不到标准答案要么出错了也找不到原因。这套东西一旦跑通你会发现它能直接复用到很多工作流里不只是数学题还有自动修 bug、批量处理数据、接口回归测试等。先跑通最小闭环再逐步扩大任务范围这是最稳的路线。
Codex开源Agent评测闭环：FrontierMath突破与Fable复现实战
这次新闻节奏很快OpenAI 刚在数学推理赛道放出一个大招用 Codex 在 FrontierMath 等超高难度数学基准上“连破 10 道难题”社区项目 Fable 跟着就在 24 小时内“复现”了其中 5 道。很多人第一反应是“OpenAI 又被抄作业了”。但做技术的人应该先问一个问题Fable 复现的到底是什么是模型权重还是评测闭环答案大概率是后者。换句话说这次的重点不是“谁抄了谁”而是 OpenAI 已经把手里的 agent 评测 harness 开源了。任何团队只要按同样的任务闭环跑一遍就能在数学推理、代码生成、自动修 bug 这类场景里快速验证自己的模型或者第三方模型能做到什么程度。这篇文章我会拆清楚三件事Codex 和 FrontierMath 到底在解决什么问题、Fable 24 小时复现的工程思路是什么、以及你自己怎么在本地把 Codex CLI 跑起来并把它接到批量任务和 API 工作流里。如果你关心本地部署、agent 评测、接口调用和自动化解题这篇文章可以直接收藏。下面直接进入正题。1. 核心能力速览先把这次新闻涉及的两个核心项目拆开看。左边是 OpenAI 官方的 Codex右边是社区项目 Fable。两者在技术链路上是“上游能力”和“下游复现”的关系。能力项说明项目类型AI 编程 Agent / 代码智能体 数学推理评测闭环开源情况OpenAI 已开源 Codex harness仓库可从 GitHub 获取Fable 为社区复现项目具体开源细节需以仓库为准核心功能自然语言生成代码、自动执行、自动检查结果、根据反馈迭代修复可用于解答数学题、编写脚本、批量处理问题显存需求走官方 API 时本机几乎无显存压力本地运行开源模型时显存取决于模型大小需按实际环境测试支持平台命令行工具适合 macOS / Linux / WindowsWSL等环境具体以官方文档为准启动方式CLI 命令启动支持交互式对话和一次性任务执行是否支持 API支持 OpenAI API 协议可接入兼容服务是否支持批量任务可以通过脚本循环调用接口配合日志和重试机制实现适合场景数学/编程题自动求解、代码生成与修复、Agent 评测对比、私有任务批处理流水线从这张表能看出来Codex 的价值不只是“AI 会解数学题”而是它把“出题 → 生成代码 → 执行 → 验证 → 迭代”这条 agent 闭环标准化了。Fable 能快速复现本质上是因为这条闭环已经不再依赖 OpenAI 内部系统而是可以通过公开的 harness 和 API 接口复制。2. 这个新闻到底在说什么Codex、FrontierMath 与 Fable先说 Codex。Codex 是 OpenAI 旗下的代码智能体它在终端里运行接收自然语言任务然后自动写代码、执行代码、查看结果并根据结果反复修改。和普通聊天式 AI 的区别在于Codex 是真的会“动手跑代码”的而不是只把代码贴在对话框里让你自己复制。这次 OpenAI 对外展示的结果是让 Codex 去解 FrontierMath 这类基准测试里的题目。FrontierMath 是 Epoch AI 推出的数学基准集难度极高涉及数论、组合数学、代数等前沿领域。很多常规大模型在这类题目上正确率接近于零所以“解出 10 道”在学术评测语境里是有分量的进展。再看 Fable。从新闻标题看Fable 是一个社区项目在 24 小时内“复现”了其中 5 道。这里的“复现”不是复制 OpenAI 的模型权重也不是用相同参数重新训练而是复现整套推理闭环把数学题转换成可编程验证的任务。调用一个大模型生成候选求解代码。执行代码并拿到对错反馈。把错误信息返回给模型让它继续修正。直到通过测试或达到最大迭代次数。这套流程正是 OpenAI 开源 harness 的核心。Fable 只用了 24 小时就跑了 5 道题说明两件事第一OpenAI 的 harness 工程质量足够高外部团队不需要从零搭起第二解决这些数学题的关键瓶颈已经不是单纯的模型智力而是任务拆解和自动验证设计是否合理。所以不要把这个新闻当成“开源社区两天追上 OpenAI”。更准确的理解是OpenAI 把评测方法开源了社区第一次可以在同一套规则下测试自己的模型。对普通开发者来说这意味着你可以把同样的方法用到自己的领域比如自动修复仓库里的 bug、批量处理格式转换、跑回归测试等。3. 适用场景与使用边界3.1 适合谁用做 AI 推理能力评测的研究者。这类人最需要标准化的评测闭环而不是自己重复造轮子。OpenAI 开源 harness 之后可以直接用同一套题来对比 GPT 系列、开源模型、微调模型的表现。做自动编程和代码修复的开发者。Codex 的工作流是“写代码 → 执行 → 看报错 → 改代码”这个闭环能直接接到 CI/CD 流水线里。做批量任务处理的工程团队。如果你们有一批结构化任务需要交给大模型完成比如从文档提取信息、生成固定格式代码、批量测试脚本Codex 的 CLI 和 API 模式都能很好地支撑。对本地部署感兴趣的个人开发者。Codex CLI 本身是轻量客户端不需要本地 GPU只要有一个可用的模型接口就能跑起来。3.2 不适合什么场景不适合当普通聊天机器人用。Codex 的核心是代码执行和迭代而不是闲聊。不适合处理没有明确验证标准的任务。数学题可以跑代码验证对错但“帮我写一段优美的文案”这种没有客观标准的任务Codex 的自动迭代优势发挥不出来。不适合完全离线、不允许调用外部 API 的涉密环境。如果必须完全本地部署需要额外搭一套本地模型服务显存和性能要求会明显提高。3.3 合规边界使用这类 agent 工具时有三条边界必须守住合法授权。不要用 AI 去处理未授权的受版权保护内容比如未经允许解析某本书、抓取某个平台的数据然后商用。隐私保护。不要把内部代码、个人隐私数据直接提交给第三方 API。敏感场景优先考虑本地部署或私有化网关。评测诚信。不要用 AI 自动生成答案去参与在线竞赛、考试或需要人工完成的评测这是学术不端也会影响后续对模型能力的真实判断。4. 环境准备与前置条件如果你想自己跑通 Codex CLI这一步很重要。环境配置不复杂但需要提前确认几个依赖项。4.1 官方 Codex CLI 环境从目前公开的文档和社区实践来看Codex CLI 是一个终端工具主要依赖以下环境操作系统macOS、Linux或 Windows 上的 WSL。Node.js建议安装 LTS 版本推荐 20 以上具体以官方 README 要求为准。Git用于拉取仓库和后续版本更新。网络环境能正常访问 OpenAI 服务或兼容接口。API Key需要一个可用的 OpenAI API Key或者兼容 OpenAI 协议的第三方服务密钥。本地终端建议使用 iTerm2、Windows Terminal 或 VS Code 集成终端。4.2 Fable 复现类项目的环境Fable 这类项目如果涉及本地模型推理需要注意Python 3.10 或更高版本。CUDA 环境如果本机有 NVIDIA GPU需要装好显卡驱动和 CUDA Toolkit。PyTorch建议安装最新稳定版和你的 CUDA 版本对应。模型权重具体用哪个模型要看 Fable 项目的 README。可能是 GPT 系列 API也可能是开源模型。磁盘空间一个 7B 参数的模型量化后也需要 6-8GB 左右磁盘空间13B 或 70B 模型要求更高。没有具体材料的情况下最稳妥的做法是先看项目仓库的 requirements.txt 或 environment.yml按官方说明装依赖不要凭经验猜版本。4.3 获取 API KeyOpenAI 的 API Key 获取方法以官方平台为准注册账号后在 API Keys 页面创建密钥。需要注意API Key 只显示一次创建后马上保存。不要把 Key 硬编码到代码仓库里建议用环境变量或 .env 文件管理。如果使用第三方兼容服务要确认它是否完整支持 OpenAI API 协议特别是“消息格式”和“工具调用”能力这会影响 Codex 的迭代效果。4.4 通用检查清单在开始部署前花两分钟检查一遍是否安装了 Node.js 18是否能执行 npm 或 yarn是否有一个可用的 API Key是否已经确认目标项目仓库的依赖说明磁盘空间是否足够建议至少留 5GB。端口是否空闲Codex 本机启动时不依赖固定端口但如果后续接入 Web 服务要检查端口冲突。5. 本地部署与启动Codex CLI 实操这部分我按“安装 → 登录 → 单任务 → 交互模式”的顺序展开。命令以 Codex CLI 的通用用法为例实际参数以项目仓库 README 为准。5.1 安装 Codex CLICodex CLI 通过 npm 发布安装命令是npm install -g openai/codex如果你的环境存在 npm 下载慢或安装失败的问题可以切换到国内镜像源npm config set registry https://registry.npmmirror.com安装后再执行一次npm install -g openai/codex装完检查版本codex --version如果终端提示找不到命令检查 Node.js 全局 bin 目录是否在 PATH 中或者用 npx 方式运行。5.2 登录或设置 API KeyCodex CLI 安装后会引导登录。执行codex login如果你已经有 API Key也可以直接通过环境变量提供export OPENAI_API_KEY你的API Key为了不把 Key 写死在 shell 配置里推荐用 .env 文件管理# .env OPENAI_API_KEY你的API Key然后在终端执行set -a source .env set a5.3 跑第一个任务先跑一个最简单的任务确认整个链路是通的codex 用 python 写一个函数输入是整数 n输出第 n 个斐波那契数执行后Codex 会生成代码、运行测试、判断结果是否符合要求。如果它发现结果不对会自动修改代码继续尝试。第一次跑通后你会看到输出中既有 Python 代码也有执行结果。如果不想交互确认可以加自动模式codex --full-auto 用 python 写一个函数输入是整数 n输出第 n 个斐波那契数全自动模式适合批量任务但注意要给足超时时间避免任务卡住。5.4 交互式会话模式进入交互模式后可以连续提多个问题Codex 会保留上下文codex在交互界面里输入你的需求它会逐步执行。这个模式适合调试和试错也适合观察模型是怎么分步解决复杂问题的。5.5 启动时容易踩的坑npm 安装成功但命令找不到检查 Node.js 的 bin 路径重新打开终端。第一次登录弹浏览器失败直接用 API Key 环境变量方式。请求超时检查网络或者增加超时配置。模型参数报错确认使用的模型名是否和你 API 服务商提供的模型一致。6. Fable 复现思路解析24 小时做对了什么Fable 能在 24 小时内复现 5 道题说明它的切入点非常精准。虽然公开材料有限但从“复用 OpenAI 开源 harness”这条线索可以推断出它的工程路径。6.1 先跑通官方 demo再拆任务Fable 的第一优先级不是训练新模型而是把 OpenAI 开源的 harness 跑起来。先看它自带的示例任务是什么输入格式是什么输出格式是什么验证逻辑在哪里。只有先把上游代码跑通后续替换模型和换题才可控。6.2 把数学题转成自动化验证闭环数学题和普通编程题不一样。编程题有明确的测试用例数学题可能是“证明某个结论”或“求某个表达式的值”。Fable 思路是先把每道题改造成代码可执行的验证流程比如把“求值”变成“写一个函数输出结果然后用标准答案比对”。这一步是复现的关键。用伪代码描述这个闭环def solve_and_verify(problem): # 1. 把数学题描述拼成 prompt prompt build_prompt(problem) # 2. 调用模型生成候选代码 code model.generate_code(prompt) # 3. 在沙箱环境执行代码 result execute_in_sandbox(code, problem.test_inputs) # 4. 和标准答案比对 if result problem.expected_answer: return pass else: # 5. 把报错和结果返回给模型让它继续修 feedback f输出结果不对{result} updated_code model.fix_code(code, feedback) return solve_and_verify_with_code(problem, updated_code)模型的迭代次数要限制比如最多 10 次。如果 10 次还没通过就记录失败原因下一轮再优化 prompt 或验证逻辑。6.3 把每道题的执行结果落盘复现项目能不能稳定取决于日志设计。Fable 应该会对每道题记录初始 prompt、第一次生成的代码、执行结果、报错信息、第几次迭代通过、最终代码。这些日志既是调试依据也是复现报告的数据源。6.4 复现的边界在哪Fable 复现的是“评测闭环的可行性”不是“模型的数学能力”。它证明了如果你有一个足够强的模型再加上标准化的验证闭环是可以在 FrontierMath 这类任务上拿到结果的。但如果换成较弱的小模型同样的闭环也不一定能解出来。模型能力仍然是底座harness 只是把模型能力的上限尽量逼出来。7. 接口 API 与批量任务Codex CLI 本身是终端优先的应用但它的底层能力可以通过 OpenAI API 协议暴露出来。这也是 Fable 这类项目能快速跑流程的基础。7.1 通用 API 调用格式如果你想把 Codex 的解题能力接到自己的工具链里可以直接用 OpenAI 兼容接口。以下是一个通用模板import requests import json API_URL https://api.openai.com/v1/chat/completions API_KEY 你的API Key # 实际模型名以你的服务商为准 model_name 你的模型名 prompt 请用 python 解决下面这道数学题 给定正整数 n判断 n 是否能被 3 整除。 要求 1. 输出可直接运行的 python 代码。 2. 代码末尾打印最终结果。 3. 不要输出额外解释。 payload { model: model_name, messages: [ {role: user, content: prompt} ], max_tokens: 2048, temperature: 0.2 } headers { Authorization: fBearer {API_KEY}, Content-Type: application/json } resp requests.post(API_URL, headersheaders, jsonpayload, timeout120) data resp.json() if resp.status_code 200: content data[choices][0][message][content] print(模型输出) print(content) else: print(f请求失败{resp.status_code} {data})注意三点第一这个模板只是通用示例具体请求路径、模型名、参数名要以实际服务的文档为准。第二temperature 控制随机性数学题建议设低一点比如 0.1 到 0.3。第三max_tokens 不要太低否则模型可能写到一半被截断。7.2 批量任务设计如果手头有几十道题要做不建议手动一条条复制。推荐的做法是先建一个 JSONL 输入文件每一行是一道题{id: 1, problem: 求方程 2x 5 13 的解输出 x 的值。} {id: 2, problem: 判断 2025 是不是质数输出 True 或 False。} {id: 3, problem: 计算 1 到 100 所有奇数之和输出数字。}然后用 Python 脚本循环读取逐条调用 APIimport json import time import requests API_URL https://api.openai.com/v1/chat/completions API_KEY 你的API Key def solve_problem(problem_text, model_name, max_retry3): payload { model: model_name, messages: [ {role: user, content: problem_text} ], max_tokens: 2048, temperature: 0.2 } headers { Authorization: fBearer {API_KEY}, Content-Type: application/json } for attempt in range(max_retry): try: resp requests.post(API_URL, headersheaders, jsonpayload, timeout180) if resp.status_code 200: return resp.json()[choices][0][message][content] else: print(fattempt {attempt 1} failed: {resp.status_code}) except Exception as exc: print(fattempt {attempt 1} error: {exc}) time.sleep(3) return None with open(problems.jsonl, r, encodingutf-8) as fin: lines fin.readlines() outputs [] for line in lines: item json.loads(line) result solve_problem(item[problem], 你的模型名) outputs.append({ id: item[id], problem: item[problem], result: result }) print(f{item[id]} - {result}) time.sleep(1) # 控制请求频率避免触发限流 with open(outputs.jsonl, w, encodingutf-8) as fout: for out in outputs: fout.write(json.dumps(out, ensure_asciiFalse) \n) print(批量任务完成)批量任务最容易遇到三个问题请求限流、单条超时、结果截断。建议在脚本里加上请求频率控制、单条任务重试、以及输出字符串长度检查。7.3 和其他 API 协议的兼容问题社区里经常有人问 OpenAI API 协议和 Anthropic API 协议有什么区别。简单说OpenAI 的/v1/chat/completions接口使用messages数组而 Anthropic 的/v1/messages接口使用system字段单独传系统提示词。如果你内部有多个模型服务建议统一走一个网关层把不同的协议转换成统一格式否则上层应用每换一个模型就要改一遍调用逻辑。8. 资源占用与性能观察这次新闻里的“解数学题”任务资源占用差异非常大。8.1 走官方 API 时的资源占用如果直接调用 OpenAI 的 API本机只需要一个轻量 CLI 客户端和网络连接。CPU 占用很低内存占用通常在几百 MB 级别显存可以认为不占用。但要注意 API 请求耗时Agent 任务不是单次请求而是多次“生成 → 执行 → 迭代”一次完整解题可能产生十几个请求所以时间消耗和 token 消耗都比较高需要提前做好成本预算。8.2 本地模型推理时的资源占用如果 Fable 这类复现项目选择在本地跑开源模型那资源占用就完全不一样了。以 7B 参数模型为例4bit 量化模型显存占用大约 6GB 到 8GB。13B 参数模型显存要求提高到 10GB 以上。70B 参数模型即使量化也需要 40GB 以上显存或者用多卡并行。在没有材料支撑的情况下不能给出精确数字。更稳妥的判断是先看项目 README 推荐的模型规格再根据本机显存决定是选择小模型量化版本还是直接走 API。8.3 如何观察资源占用本地跑任务时用以下命令实时观察# 查看 GPU 显存使用 nvidia-smi -l 1 # 查看 CPU 和内存 htop # 查看某个进程的资源占用 ps aux | grep python如果显存接近上限优先做三件事降低并发数、换小尺寸模型、开启量化。8.4 影响性能的关键参数模型参数量直接决定显存占用和推理速度。输入长度数学题描述越长上下文处理时间越长。迭代次数Codex 类 agent 的性能瓶颈主要是迭代次数而不是单次推理速度。并发数并发太高可能导致 API 限流或显存溢出。输出长度max_tokens 设置过大会拖慢响应设置过小会导致答案截断。9. 常见问题与排查方法下面把最容易遇到的问题列成一张排查表。问题现象可能原因排查方式解决方案npm 安装 Codex CLI 失败网络问题、Node 版本过低查看 npm 报错日志执行 node -v 检查版本切换镜像源升级 Node.js 到 LTS 版本终端提示 codex 命令不存在Node 全局 bin 目录不在 PATH执行 which node 和 npm bin -g 查看路径把 bin 目录加入 PATH或改用 npx codex登录时报错API Key 不对、网络受限检查环境变量用 curl 测试接口连通性重新生成 API Key检查网络配置请求返回 401Key 无效或权限不足检查 Key 是否复制完整查看账户余额重新创建 Key确认账户有可用额度模型返回空内容请求格式错误、模型名不对打印完整响应 JSON核对 model 名称和 messages 格式数学题多次迭代仍然失败prompt 没有给出验证标准检查 prompt 是否把“怎么算对”说明白在提示词里增加示例、要求输出固定格式批量任务中途中断单条 API 请求超时、限流查看错误日志检查返回的状态码 429增加重试机制降低请求频率设单条超时本地模型推理卡死显存不足、模型加载失败运行 nvidia-smi 查看显存换小模型、开量化、降低并发数评测脚本突然报错依赖版本不一致、缺少库查看 traceback核对 requirements按官方 requirements 重建虚拟环境端口冲突应用占用了默认端口执行 lsof -i:端口号 查看占用换端口或关闭占用进程补充一点排查 agent 任务问题时先看日志再复现单条任务。agent 类任务最怕“黑盒式跑批”一旦失败找不到任何中间过程。所以无论用 Codex CLI 还是自己写脚本第一步永远是记录每轮生成的代码和反馈信息。10. 最佳实践与使用建议基于这次 Codex 和 Fable 的工程链路我给出几条可以直接落地的建议。10.1 先把“验证闭环”搭起来大部分 AI 任务失败的原因不是模型不够聪明而是缺少验证标准。你可以像 Fable 一样先不急着调模型而是把一个题目变成“生成代码 → 跑测试 → 返回错误”的最小闭环。闭环通了再换更强的模型。10.2 单条跑通再跑批量批量任务之前一定要用 3 到 5 条样本验证接口、prompt 和结果解析。批量跑的时候给每条任务加唯一 ID方便定位失败项。10.3 用日志和失败重试保护任务至少要做到每条任务保存完整输入输出。失败任务自动重试 2 到 3 次。重试仍失败的任务单独落盘不阻塞后面的任务。设置合理的超时时间比如单条 120 到 300 秒。10.4 API Key 和隐私安全不要提交 API Key 到代码仓库。内部代码和敏感数据不要直接发送到第三方服务。如果必须走外部 API建议在请求前做脱敏处理。10.5 场景正确的模型选择解数学题、跑代码优先选代码能力强的模型温度设置低。生成文案、润色文本可以选通用对话模型温度可以稍高。本地部署显存够用的情况下选 7B 模型会比较平衡追求效果再考虑更大模型量化版本。11. 总结与下一步OpenAI 这次最值得关注的点不是“10 道数学题”本身而是它把 agent 评测的 harness 开源了。Fable 在 24 小时内复现 5 道题说明这套“出题 → 生成 → 执行 → 验证 → 迭代”的闭环已经可以脱离 OpenAI 内部环境被外部团队复制。如果你对这块感兴趣下一步建议是先把 Codex CLI 安装跑通用一道简单编程题验证整个链路再挑一个你手头有客观验证标准的问题仿照 Fable 的思路把 prompt、验证脚本、重试机制搭起来最后再考虑接 API 和批量任务。最容易踩的坑是跳过验证闭环直接让模型“自由发挥”结果要么得不到标准答案要么出错了也找不到原因。这套东西一旦跑通你会发现它能直接复用到很多工作流里不只是数学题还有自动修 bug、批量处理数据、接口回归测试等。先跑通最小闭环再逐步扩大任务范围这是最稳的路线。