AI Agent

默认模型是没锁的依赖：15 天三变，评测怎么记

9 月 29 日到 10 月 14 日，Codex 的默认模型变了三次，你的仓库 diff 一行没变。评测要能回答：这次结果到底是哪个模型跑出来的。

admin

— 阅读时间 10 分钟
分享
默认模型是没锁的依赖：15 天三变，评测怎么记

一句话结论：如果你没有显式指定模型，那么"你的 Agent 用什么模型"就是供应商决定的。2026 年 9 月 29 日到 10 月 14 日，Codex 三次改动默认模型、一次退役旧模型，而这一切不会出现在你仓库的 diff 里。于是所有"上周还行、这周不行"的判断都失去前提——你测的可能根本不是同一个东西。最低限度的补救是四个字段：模型、推理强度、账号类型、提交。

披露：本文编译自 Gabriel Anhaia 的技术文（dev.to，2026-10-18）。作者是 Hermes IDE 的作者，文中含产品介绍；版本号、PR 编号与退役时间均来自 OpenAI 的 release notes、changelog 与公开 PR，建议按你自己安装的版本复核。

一、15 天里发生了什么

作者按 OpenAI 自己的发布记录把时间线排了出来：

日期（2026） 变更 影响谁
9 月 29 日 Codex CLI 0.159.1：GPT-6.1 Sol 在随包 catalog 里获得最高优先级，成为默认 从没设置过模型的 CLI 用户
10 月 7 日 0.161.0：再次列入默认（随包与 Amazon Bedrock catalog） 同上，外加 Bedrock 用户
10 月 8 日 0.162.0：新的 TUI 线程遵循服务端的模型默认值 启动时不带模型参数的 TUI 用户
10 月 14 日 GPT-5.5 从 Codex 退役（ChatGPT 登录），太平洋时间中午 12 点（19:00 UTC） 显式选了 gpt-5.5 且用 ChatGPT 登录的人

10 月 8 日那次最安静。release note 的原话是：Codex 会"尊重服务端的模型与推理摘要默认值，同时保留显式启动覆盖"。背后的 PR #50013 说得更直白："新的 TUI 线程应使用 app server 的模型设置，除非启动时显式覆盖。" 这里的 app server 是 TUI 连接的那个本地或远程守护进程。同一个版本还去掉了模型选择器里的"(default)"后缀（#51235）。

10 月 14 日则打到另一群人：显式固定了模型的人。OpenAI 的模型页写得很清楚——退役只影响 ChatGPT 登录，API key 会话不受影响；Plus / Pro / Business / Enterprise / Edu 被指向 GPT-6.1 Sol，Free / Go 指向桌面端的 GPT-6 Luna，都是"在有货时"。

公平地说，这些变更都不隐蔽：release note、changelog 都写了，退役还给了精确时间和替代型号。OpenAI 也说 GPT-6.1 Sol 在约 1/5 的 Astra token 价格下接近 Astra 的表现（这是厂商自己的数字，来自 Unite.AI 与 The Batch 的转述）。但问题不在"有没有告知"，而在告知之后，你的历史结果还算不算数。

二、"默认"是谁选的？一个 catalog 文件

看 PR #49318 里"默认"的含义：没有人"选择"GPT-6.1 Sol。它在 CLI 随包的一个 catalog 文件里拿到了最高优先级，于是赢了。

这不是 Codex 的特例。Claude Code 的模型文档写着，opus / sonnet / haiku 这些别名"指向你的供应商推荐的版本，并随时间更新"；要固定版本，得用完整名称，例如 claude-opus-5-5。也就是说：

claude --model opus            # 移动靶：按设计会漂移
claude --model claude-opus-5-5 # 固定

移动靶对聊天没问题——你晚上 11 点提问，当然想要最新模型。对任何需要测量、比较、对同事承诺的东西，它都是问题。

这也是本文最值钱的一句：你没有选的模型，就是你没有固定的依赖。

三、评测测的是模型，所以必须写模型名

Agent 评测不一定是正式的测试套件，更常见的是团队聊天里的一句话：

  • "Codex 做迁移比 Claude Code 差。"
  • "改了 AGENTS.md 之后 Agent 变好了。"
  • "这个任务上周要 40 分钟，这周 12 分钟。"

每一句都是关于某个模型的断言。 如果那个模型是默认值，你就不知道它是谁。于是三种解释无法区分：

观察到的变化 可能的原因 你能不能区分
同样任务变快/变慢 模型换了、推理强度换了、账号换了、代码变了 只有记录了才知道
提示词改动"变好" 新模型更吃这套提示词 同上
某任务"退化" 默认 catalog 变了，或新线程取了服务端默认值 同上

模型也不是唯一的隐藏变量。推理强度（reasoning effort）同样会改结果，而 PR #50013 把它和模型同等对待：启动时不设置，新线程就取服务端默认值。账号类型也算：GPT-5.5 的退役只影响 ChatGPT 登录，API key 会话照旧——同一个 gpt-5.5 设置，在两种登录方式下意味着两件事。

所以任何一条 Agent 结果的最小记录是四个字段：

model / reasoning_effort / account_type / commit

缺任何一个，"前后对比"就是两个没有解释的数字。

四、怎么固定：profile + 一行一条记录

日常使用，最干净的固定方式是 profile。按 Codex 的 advanced config 文档，profile 是 ~/.codex/ 下的一个文件，顶层键就是模型与推理强度：

# ~/.codex/pinned.config.toml
model = "gpt-6.1-sol"
model_reasoning_effort = "medium"

启动时显式带上：

codex --profile pinned

PR #50013 保证显式 profile 启动会保持解析后的配置，所以即使是新 TUI 线程，profile 里的模型也不会被服务端默认值覆盖。

对需要比较的运行，把"固定"和"记录"放进同一个脚本。codex exec 支持 -m 指定模型，-c 设置任意配置键（文档说明：不是合法 TOML 的值按字符串处理）：

#!/usr/bin/env bash
# run-task.sh "<task>"：一次固定运行，一行记录
set -u
task="$1"
model="gpt-6.1-sol"
effort="medium"
account="chatgpt"   # 或 "apikey"：这次运行怎么登录

codex exec -m "$model" \
  --sandbox workspace-write \
  -c model_reasoning_effort="$effort" \
  "$task" > last-run.log
agent=$?
npm test > test.log 2>&1
tests=$?

printf '%s\t%s\t%s\t%s\t%s\t%s\t%s\n' \
  "$(date -u +%FT%TZ)" "$(git rev-parse --short HEAD)" \
  "$model" "$effort" "$account" "$agent" "$tests" >> runs.tsv

两个细节值得解释：

  • codex exec 默认在只读沙箱里跑，所以要显式 --sandbox workspace-write，Agent 才能改工作区、测试才有意义。
  • agent 列保留 Codex 自己的退出码，这样"Agent 步骤失败"会出现在行里，而不是被"测试在未修改的代码上通过"掩盖。

每条 runs.tsv 记录因此包含了：哪个模型、什么推理强度、什么账号，在哪个 commit 上，得到什么测试结果。

五、固定的代价，和被退役时的正确姿势

固定不是免费的，10 月 14 日就演示了一次：所有用 ChatGPT 登录、把模型钉在 gpt-5.5 上的人，都必须改配置。OpenAI 的清单列了要更新的位置——工作区默认值、保存的模型设置、托管配置、自定义 Agent、定时任务，以及仍然选择 gpt-5.5 的脚本。

作者的评价很到位：这是"好的那种断裂"。你改 diff 里的一行，重跑任务，拿新行和旧行对比。相反，"默认值悄悄漂移"是坏的那种断裂——没有 diff、没有重跑、没有对比，只有一句"最近好像不太行"。

具体到操作，模型退役时应该做四件事：

  1. 先冻结旧结果：把 runs.tsv、测试日志、commit 一起归档，不要覆盖。
  2. 改一处配置，不要改多处：模型名只在一个 profile / 一个环境变量里出现。
  3. 重跑同一组任务：用同一份任务清单、同一个评测集，不要只跑"感觉会变"的那几个。
  4. 把差异写成结论：如果新模型在某类任务上退化，写明"哪类任务、退化多少、样本多少"，而不是"变差了"。

六、一张表决定：别名还是固定

场景 建议 理由
日常问答、一次性脚本 用默认/别名 你要的是最新的能力，不值得维护版本
团队共享的评测集 固定完整模型名 结果要能跨时间比较
上线前的回归测试 固定 + 记录四字段 失败要能复现、能归因
成本敏感的生产路由 固定 + 定期评测后升级 升级是一次有据可查的变更，不是后台静默替换
教学、演示、截图 记录当时版本 读者半年后复现时要能对上

再加一条经验：把"升级模型"当成一次代码变更来管理——有变更单、有评测、有回滚方案。模型升级往往比代码升级影响更大，因为它改的是"同样的输入会得到什么输出"。

七、边界

  • 文中所有版本号、PR 编号、时间点均来自 2026 年 10 月中旬的公开记录；供应商随时可能再改。
  • "GPT-6.1 Sol 接近 Astra、价格约 1/5"是厂商口径，作者也明确标注了这一点；不要当成独立测评。
  • 四字段记录能解决"归因"，不能解决"评测集本身没测到关键能力"的问题；后者要靠任务设计与人工抽检。
  • 作者是 Hermes IDE 的作者，文中产品段落请按广告阅读；方法论部分与产品无关。

一句话收尾：你可以让模型漂移，但不能让记录漂移。 在写下任何一个"Agent 变好了/变差了"的结论之前，先回答那个问题——这个结果，是哪个模型跑出来的？

Sources

相关阅读：AI 基建 / 评测 / 安全完全指南 ｜ AI 写的测试为什么和 bug 一致：变异测试与评委校准 ｜ Agent 交付验收：声明与 diff 对账

本文由汇智网编译整理，转载请注明出处。文中时间线与版本号以 2026-10-18 的公开资料为准，请按你自己的安装版本复核。

这是「AI 基建 / 评测 / 安全」专题的一部分。完整地图见：AI 基建 / 评测 / 安全完全指南

阅读更多