凌晨两点半我盯着终端里刷完的 Terminal Bench 4.0 评测结果脑子里只有一个念头这一代 Agent 的评测方式是真的要变天了。GPT-6 Astra 带着 Codex 智能体登顶 Terminal Bench 4.0 的消息这两天在开发者圈子里炸得很厉害有人欢呼Agent 终于能自己干活了也有人怀疑又是刷榜营销。作为一个把 Codex 当日常生产力工具用了快一年的人我试着把这件事实实在在地拆一遍Terminal Bench 4.0 到底在考什么、Astra 和 Codex 是怎么分工的、Codex 在本地怎么装怎么配、接第三方模型服务时会踩哪些坑。看完你就知道这个登顶含金量到底有多高以及你自己能不能复现一套类似的 Agent 工作流。1. Terminal Bench 4.0 考的不是会不会写代码是干不干得成事在读任何评测结果之前先得搞清楚题目本身长什么样。Terminal Bench 系列评测从诞生起就和其他代码榜单走完全不同的路线它不考给你一道算法题能不能做出来而是把 AI Agent 扔进一个接近真实的终端环境里让它像人类工程师一样完成一整串工作任务。1.1 一次完整的 Terminal Bench 任务长什么样我概括一下这类评测里的典型任务流程给你一个带有缺口的 Git 仓库让你定位一个偶现的并发 bug给你一套跑挂了的 CI 日志让你从几百行输出里找到真正的失败原因并修复给你一个待部署的服务让你改配置、跑迁移、重启并验证接口甚至让你在一个沙箱环境里处理数据管道中途还故意留了几个权限陷阱和隐藏依赖。这些任务有几个共同特点第一没有标准答案能跑通、能上线、能通过人工验收就是正确答案第二步骤极长往往需要几十次甚至上百次终端操作才能完成中间任何一步出错都可能让整个任务归零第三环境是真实存在的模型面对的可不是干净的评测 API而是要自己敲命令、读输出、改文件、跑测试的真实系统。1.2 从答对题到看得住摊子Terminal Bench 4.0 相比前代版本最核心的变化在于评测维度不再只看任务完成率而是加入了大量过程安全指标。说白了就是八个字能干活也看得住。过去很多 Agent 演示看起来很惊艳Model 能在两分钟内写出一段漂亮的代码但把它放进真实终端里就露馅了——它可能为了修一个 bug 直接把整个数据库删了可能在错误目录里反复横跳浪费二十多分钟可能在一个无限循环里疯狂请求 API 直到把额度烧光。Terminal Bench 4.0 把环境安全、命令执行效率、操作可逆性都纳入了评分Agent 不仅要完成任务还要在完成任务的过程中不闯祸、不绕路、关键时刻知道停下来问一句。我自己跑过几轮类似的评测脚本体感非常明显以往很多模型在给定需求直接输出代码的环节都表现不错但只要进入需要自己探索环境、自己调试错误的多轮终端任务表现就断崖式下跌。这正是 Terminal Bench 4.0 和普通榜单拉开差距的地方也是它越来越被各大模型团队当成「硬指标」的原因。对比维度传统代码评测Terminal Bench 4.0任务形态单点题目输入输出明确多步骤开放任务真实终端环境评测方式比对代码输出结果人工/脚本验收任务最终状态是否执行命令否是且会真实改动文件系统过程安全监控无有破坏性操作会被扣分甚至终止上下文长度要求短极长需维持几十轮操作状态结果代表性代表会做题代表能干活、看得住2. GPT-6 Astra 与 Codex 的双核分工模型负责聪明智能体负责稳搞明白评测本身之后再来看这次登顶的两个主角GPT-6 Astra 和 Codex 智能体。很多人把这两者当成一码事其实它们是两个完全不同层级的组件只是组合在一起形成了一个完整系统。理解这层关系才是理解这次成绩的关键。2.1 Astra 是大脑Codex 是手脚和躯干GPT-6 Astra 是模型层负责的是理解、推理、生成。它接收终端回传的各种输出——编译报错、日志堆栈、测试结果、文件列表——然后判断当前处于什么状态、下一步该执行什么命令。Codex 则是智能体层它的正式名称是 Codex harness套件/外壳相当于一个包在模型外面的工程框架负责调度模型、执行工具调用、管理上下文、截取终端输出、维护任务状态。我习惯用一个人来打比方Astra 是那个坐在驾驶座上的大脑Codex 是整辆车——变速箱、方向盘、油门刹车、仪表盘都是它。没有 CodexAstra 再聪明也只是停在纸面上无法真正去操作终端没有 AstraCodex 就是一辆没有司机的空车每个动作都毫无方向。2.2 Codex harness 凭什么能稳住复杂任务在这次登顶成绩里我最关注的其实是 Codex 在工程层面做的几个关键机制这也是社区里大量讨论的焦点命令执行与输出截获。Codex 每次执行命令都会把完整输出截取回来喂给模型模型判断后再决定下一步。这个过程看似简单实际非常考验工程细节——输出太长了怎么办命令卡住了怎么办返回码有异常怎么办这些都要在 harness 层面处理好否则模型再聪明也会被脏数据带偏。上下文管理。几十轮终端操作意味着大量历史输出如果把所有内容全部塞给模型上下文会迅速膨胀既浪费 token 又干扰判断。Codex 的做法是只保留和当前任务最相关的段落类似人工作记忆里的焦点切换。这种上下文压缩策略直接决定了 Agent 能不能在长任务里保持稳定的推理质量。权限与安全控制。Terminal Bench 4.0 强调看得住本质上是要求 Agent 的操作可约束、可回滚。Codex 在这个方向上做了不少设计对危险命令进行拦截或二次确认、操作前记录环境快照、任务失败时可恢复初始状态。这在真实生产环境里尤其重要——没人敢让一个什么都敢跑的 Agent 直接操作生产服务器。2.3 数学难题与内测离谱口碑推理能力的实锤预告里提到的一天攻破 5 道数学难题以及首批内测用户口中结果离谱的评价反映的都是 Astra 在推理能力上的实质提升。数学题尤其是那些需要多步推导、不断回溯修正思路的题目对模型的规划能力要求极高而这类能力恰好是 Terminal Bench 这类长程任务的基础。我注意到不少内测反馈提到Astra 在任务进行到一半时如果发现方向错了会主动回退到之前的某个正确状态重新规划而不是硬着头皮往下走。这种敢于推翻自己的特性在纯代码生成年代几乎看不到但在真实工程环境里恰恰是最值钱的能力。因为真实的调试过程本来就是反复试错、不断回退而不是一路顺风地写完。3. Codex 本地部署实录从 CLI 到桌面版把智能体搬进自己的终端聊完概念进入实操环节。Codex 作为一个智能体工具目前最常用的形态是 CLID命令行工具和桌面版应用两类配合 VS Code 插件使用。我两套都实际跑过下面把安装、登录、配置的完整流程和坑点都整理出来。3.1 用一行命令把 Codex CLI 装起来如果你和我一样平时大部分时间都泡在终端里CLI 版本是最优先的选择。它轻量、可脚本化、能直接嵌进 tmux 和编辑器几乎不占额外资源。安装前先确认环境里有 Node.js建议 18 以上版本然后一条命令搞定npm install -g openai/codex装完之后可以先看一眼版本确认安装成功codex --version首次运行会进入登录流程两种方式任选一是用 ChatGPT 账号走浏览器授权二是在环境变量里设置OPENAI_API_KEY。前者适合个人体验后者适合需要脚本化调用或接 API 计费的情况。3.2 配置文件里最容易被忽略的两个字段Codex 安装好之后配置集中在~/.codex/config.toml。我第一次配置的时候跳过了很多字段结果跑了半天都是默认行为效率并不理想。后来仔细研究才发现这几个字段的含水率# 指定默认模型按自己账号权限来 model gpt-6-astra # 开启审批模式危险命令需二次确认 approval_policy on-failure # 允许执行的命令白名单 allowed_tools [shell, file-read, file-write, web-fetch]approval_policy是看得住的关键建议从on-failure或never起步。如果设成untrusted模式遇到危险操作会弹出确认提示适合初次接触 Agent 的新手确认信任当前环境后再改成on-failure减少打断频率。还有一个隐藏参数值得提experimental_use_ollama之类的开关不要去随便乱试稳定优先。尤其是刚上手阶段默认配置足够用了折腾花活反而容易把自己搞晕。3.3 桌面版与 VS Code 插件的互补用法桌面版是我后来才装上的坦白说可视化界面对新手理解 Agent 的运行过程帮助很大——你能直观看到它每步在执行什么命令、读取了什么文件、自己脑内推理到了哪一步。安装过程在 Windows 上也非常顺滑直接去官网下载对应安装包双击安装然后用同一个账号登录即可。如果你平时用 VS Code 写代码插件也建议装一个。它和 CLI 共享同一套后端逻辑但能在编辑器里直接选中代码片段让 Codex 解释或重构省去来回复制粘贴。我最常用的组合是VS Code 插件做代码段的快速修改CLI 跑长任务桌面版偶尔用来观察 Agent 思考过程。三者的底层会话状态是独立维护的使用时要留意当前会话用的哪套配置。4. 接入第三方模型接口的正确姿势与常见报错排查Codex 真正被国内开发者和研究者玩出花来的是它能够接入第三方模型 API 的能力。默认情况下它走 OpenAI 官方端点但通过配置model_providers字段你可以让它调用任何 OpenAI 兼容接口的模型服务——包括 DeepSeek 等国产模型。这个特性给预算有限或需要特定模型能力的人提供了很大自由度。4.1 一个能跑的 OpenAI 兼容接口配置示例以接入 DeepSeek 为例配置思路就是在config.toml里自定义一个 provider然后在启动 Codex 时指定这个 provider。大致结构如下[model_providers.deepseek] name DeepSeek base_url https://api.deepseek.com/v1 env_key DEEPSEEK_API_KEY wire_api chat配置好之后启动 Codex 时加上环境变量和模型参数DEEPSEEK_API_KEYsk-xxxx codex --model-provider deepseek这里有两个细节容易栽跟头。第一个是base_url要不要带/v1后缀取决于服务商接口的实现带错了通常会在请求阶段直接报 404 或者路由错误。第二个是wire_api字段不同服务商可能要求chat或responses两种协议格式配置前最好去服务商文档里确认一下对 OpenAI 协议的兼容程度。4.2 换个模型就报错chatgpt 账号与模型不匹配的真相我实际使用中遇到最多的报错是这条The gpt-5.6-sol model is not supported when using codex with a chatgpt account.这句话的意思很直白你用 ChatGPT 账号登录 Codex 时模型选择范围被严格限制在了账号套餐允许的模型集合内。你手动去配一个当前账号没权限的模型名比如gpt-5.6-sol或者某些内部实验模型Codex 会在启动阶段直接拒绝。解决办法也很简单要么把登录方式换成 API Key在OPENAI_API_KEY环境下指定有权调用目标模型的密钥要么把配置文件里的模型名改回套餐支持的模型。这个报错经常被误认为是 Codex 本身坏了其实只是权限边界没搞清楚。4.3 cc switch 切换工具与本地代理转发失败的排查链路社区里很多人会用 ccswitch 这类多服务商切换工具来管理 Codex 的配置一个工具就能在多个 provider 之间来回切。好用是好用但我也确实在切换过程中遇到过一条很经典的报错cc switch local proxy failed while handling codex endpoint /responses.从头到尾排查一遍你会发现它通常不是 Codex 本身出问题而是切换工具启动的本地转发服务挂了。一般按下面这个顺序检查本地服务是否在运行切换工具需要在本地起一个转发进程如果它没起来所有请求都会失败。检查任务管理器或ps aux确认相关进程存在。端口是否被占用本地转发服务默认监听某个端口一旦被其他软件占掉转发链路就断了。配置里的目标地址是否正确切换工具生成的临时配置片段如果 base_url 写错转发请求会打到不存在的地址上。看看是不是刚才切换配置后没重启改了 provider 之后旧会话可能还握着旧的转发配置重启 Codex 会话就能解决。这种工具壳子报错和核心功能报错一定要分清楚。遇到问题先问自己一句是 Codex 本身干不了活还是它身边的人没转起来排查思路对了解决问题通常只要几分钟。4.4 接入第三方服务时需要记住的三个原则以我接第三方模型接口半年多的经验有三条原则值得分享尽量选官方适配过的服务商能少踩很多兼容性坑。把密钥放在环境变量里绝对不要硬编码进config.toml并提交到 Git 仓库。首次接入时先用一条简单命令验证连通性比如codex exec echo hello跑通基础链路再上复杂任务不要一上来就跑长流程否则报错时根本分不清是配置问题还是任务问题。5. 让 Codex 真正看得住Skills、上下文管理与多 Agent 协作实践看到了这里装备已经齐了但如果你想让 Codex 在自己真实的项目里稳定发挥还需要做一轮看得住层面的精细化调教。我理解的看得住不只是评测分数里的安全指标更是日常使用中 Agent 是否可控、可预期、可复制。5.1 用 Skills 把团队的私有流程固化给 AgentCodex 的 Skills 机制是我最喜欢的一个设计。简单说你可以在.codex/skills目录下给 Agent 定义一组能力包每个 skill 是一个带说明文档的操作手册告诉 Agent 在特定场景下应当如何行动。举例来说我所在的团队有一套自己封装的部署命令脚本命名和参数规范和开源工具有差异。如果没有 skillAgent 每次执行部署时都会像个新员工一样瞎猜有了 skill 之后它遇到部署测试环境这个指令时会自动读取对应的 skill 文档然后严格按照团队规范执行。创建一个 skill 的入口很简单通常是一个带名字的目录加一份描述文件.codex/skills/deploy-test/skill.mdskil.md 里写清楚适用场景、执行步骤、必备命令、危险提示。这个机制看起来不起眼却是把 Agent 从通用工具变成团队专属生产力的关键一步。因为你真正需要的不是它懂所有事情而是它在你自己的环境里不犯错。5.2 AGENTS.md 上下文与多 Agent 分工除了 skill项目根目录的 AGENTS.md 也是一个管理 Agent 行为的高效手段。它作用和 README 类似但专门写给 Agent 看的——写上项目结构说明、常用命令、代码风格约束、安全红线。Codex 在启动会话时会自动读取这类文件从而在进入具体任务前就带上项目的背景知识。我在一个稍微复杂点的项目里实践过双 Agent 分工一个 Codex 实例专门做代码修改和测试另一个实例负责审查前者的 diff模拟写代码的人不审核自己的代码这个工程原则。两个实例通过共享仓库和 issue 进行任务交接效果意外地好尤其是处理多文件改动时审查 Agent 能明显抓到一些实现上的疏漏。5.3 和 Claude Code 的对比不同取舍圈子里总是拿 Codex 和 Claude Code 对比这很正常。两者我都长期用过想要各自的核心差异维度CodexClaude Code底层模型体系OpenAI GPT 系列新模型迭代更快Anthropic Claude 系列开源程度CLI 部分组件有开源版本更早开源社区插件生态更丰富定制灵活性支持 provider 接入和 skills 扩展工具函数定义强大偏好长上下文上手门槛配置切到第三方服务时稍复杂开箱即用体验较顺滑我的选择标准很简单如果任务是深度集成 OpenAI 生态的、或者需要接第三方模型省钱用 Codex如果更看重工具扩展性和社区现成玩法Claude Code 也完全值得试。工具之间没必要站队能满足场景就是好工具。5.4 我的日常工作流Codex 到底替我扛了什么最后分享一下我用 Codex 最频繁的几个场景给大家一个具体的参考。故障排查类任务。生产环境报个奇怪的错我会把日志丢给 Codex 让它去定位它会自己去看配置文件、查服务状态、复现问题最后把结论整理给我全程不用我亲手敲一条命令但每一步都在审批权限下执行——这就是能干活也看得住在日常里的样子。批量重构。比如把一个旧项目的所有接口从回调改成异步这种脏活虽然无聊但对一致性要求高。Codex 在这种任务上比人细心一次跑完几十个文件的改动最后让我逐个 review diff。写测试覆盖。它跑测试、看覆盖报告、找出没覆盖的分支、自动补测试用例循环往复直到覆盖率达标。以前这个流程至少要占我半天时间现在基本是泡杯茶的功夫。长会议之后的跟进整理。让它根据会议纪要实现一个简单的数据看板原型这种从模糊到具体的需求正好是它近几代版本进步最明显的地方。说句公道话现在的智能体远没到全自动研发的程度你让它完全独立负责一个模块从设计到上线仍然会翻车。但如果你把它当成一个能力很强但需要盯着的初级工程师它能在很多环节帮你省下大量时间。而这个盯着其实就是看得住——评测分数背后真正值得关注的东西是 Agent 在多大程度上能让我们放心地把终端交给它。用能干活的模型加看得住的工程外壳这套思路将来只会越来越普及现在开始把自己的工作流和它磨合好你会比大多数人更早体会到智能体协作的红利。