> ## Content Index > Fetch the complete content index at: https://www.hubwiz.com/blog/llms.txt > Use this file to discover other available public pages before exploring further. # 默认模型是没锁的依赖：15 天三变，评测怎么记 - URL: https://www.hubwiz.com/blog/agent-model-pinning-eval-drift/ - Published: 2026-10-18T17:48:36.000Z - Updated: 2026-10-18T17:52:46.000Z - Description: 9 月 29 日到 10 月 14 日，Codex 的默认模型变了三次，你的仓库 diff 一行没变。评测要能回答：这次结果到底是哪个模型跑出来的。 - Author: admin - Tags: AI Agent, 模型评测, Codex, 可复现性 **一句话结论**：如果你没有显式指定模型，那么"你的 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`。也就是说： ```text 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 结果的**最小记录**是四个字段： ```text model / reasoning_effort / account_type / commit ``` 缺任何一个，"前后对比"就是两个没有解释的数字。 ## 四、怎么固定：profile + 一行一条记录 日常使用，最干净的固定方式是 **profile**。按 Codex 的 advanced config 文档，profile 是 `~/.codex/` 下的一个文件，顶层键就是模型与推理强度： ```toml # ~/.codex/pinned.config.toml model = "gpt-6.1-sol" model_reasoning_effort = "medium" ``` 启动时显式带上： ```bash codex --profile pinned ``` PR #50013 保证显式 profile 启动会保持解析后的配置，所以即使是新 TUI 线程，profile 里的模型也不会被服务端默认值覆盖。 对**需要比较**的运行，把"固定"和"记录"放进同一个脚本。`codex exec` 支持 `-m` 指定模型，`-c` 设置任意配置键（文档说明：不是合法 TOML 的值按字符串处理）： ```bash #!/usr/bin/env bash # run-task.sh ""：一次固定运行，一行记录 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** - Gabriel Anhaia, *Codex Swapped Its Default Model and Retired GPT-5.5 in 15 Days. Did Your Evals Notice?*, dev.to, 2026-10-18：[https://dev.to/gabrielanhaia/codex-swapped-its-default-model-and-retired-gpt-55-in-15-days-did-your-evals-notice-df5](https://dev.to/gabrielanhaia/codex-swapped-its-default-model-and-retired-gpt-55-in-15-days-did-your-evals-notice-df5?ref=hubwiz.com) - Codex release / PR：#49318、#50013、#50727、#50913、#51235 - Claude Code 模型配置（别名与固定）：[https://code.claude.com/docs/en/model-config](https://code.claude.com/docs/en/model-config?ref=hubwiz.com) **相关阅读**：[AI 基建 / 评测 / 安全完全指南](https://www.hubwiz.com/blog/ai-infra-stack/) ｜ [AI 写的测试为什么和 bug 一致：变异测试与评委校准](https://www.hubwiz.com/blog/ai-tests-agree-with-bug-mutation-judge-calibration/) ｜ [Agent 交付验收：声明与 diff 对账](https://www.hubwiz.com/blog/agent-delivery-verification-gates/) 本文由汇智网编译整理，转载请注明出处。文中时间线与版本号以 2026-10-18 的公开资料为准，请按你自己的安装版本复核。 > **这是「AI 基建 / 评测 / 安全」专题的一部分。**完整地图见：[AI 基建 / 评测 / 安全完全指南](https://www.hubwiz.com/blog/ai-infra-stack/)