GPT-6 Astra 要的是另一台电脑，Opus 5 要的是一次重启

🔴 七次部署崩溃。内核日志里十二次段错误。每一次都指向同一个 CPU 核心。运行 GPT-6 Astra 的 Codex 读了日志，写下“是假设，不是证明”，然后问我要一个 GitHub Actions 运行器。五十八分钟后，运行 Opus 5 的 Claude Code 检查了同一台机器，执行了四天里谁都没想到要跑的两条命令，然后让我输入 sudo apt install intel-microcode。从此，“受阻”这两个字不能再随便用了。🧭

⚙️ 一个翻转的比特，七种故障面貌

一颗运行过时微码的 CPU，把 CPython 内联缓存里的比特翻转了。四天里每一种看似“不同”的崩溃，都是同一个故障让程序读错了内存位置。⚙️ 一旦看清，整份日志就能归结成一句话。

从外面看，事情是这样的。我的网站先部署到预发布环境，再正式发布到生产环境。预检门禁没有全绿，内容就不会交给托管平台：构建、验证、几百项 Python 测试、几百项浏览器检查。从 T+3m 到 T+1h30m，一共尝试了六次预览部署。一次整数减法过程中报出了 malloc 空闲链表损坏错误，退出码 134；一次 TypeError 说字符串变成了整数，随后垃圾回收器内部发生段错误；一次嵌套构建失败，标准错误输出却没被显示出来；Conda Python 3.12.2 与 Homebrew Python 3.14.4 在同一个 YAML 读取器里发生段错误；还有一个真正的 argparse 缺陷，以及编排者自己造成的 spawn uv ENOENT：它构造了一份“受控”PATH，却漏掉了 uv 所在的目录。

同一会话从 T−4 天起就一直遇到退出码 139，已经五次了。它也早就试过换一个 Python。⚠️

fig 01 上传前多次崩溃的日志：当天七次部署失败，从 T−4 天起已有五次崩溃；原始日志保留英文

故障本身是这样发生的。PyYAML 的 Reader 把字符串 buffer 和整数 pointer 放在相邻位置。每次失败都说 buffer 是整数。Python 代码本身不可能造成这种情况。从 3.11 开始，CPython 的特化解释器（PEP 659）把特化 LOAD_ATTR 的内联缓存放在紧跟指令之后的条目里；只要一个比特翻转，读取就会落到旁边的位置。Claude 会话一开始，CPython 就已经给出了自己的诊断名称：Fatal Python error: Executing a cache。3.12 和 3.14 都有内联缓存，所以换解释器没有用。

fig 02 相邻属性误读与 LOAD_ATTR 内联缓存损坏的证据；原始日志保留英文

🚨 答案就在 Codex 屏幕上，它却把它归档为“尚未证实”

Codex 找到了 CPU 8 的规律和 0x10f 微码，随后它自己的流程吞掉了这个发现，吐出来的却是换台电脑的请求。🔍 如果你在生产环境运行智能体，这一幕应该会刺痛你。

从 T 开始，也就是第一次预览部署尝试开始时，编排者是 Codex CLI 0.153.4，使用 gpt-6-astra，推理强度为 high，子智能体分别使用 gpt-5.6-sol、gpt-5.6-terra 和 gpt-5.6-luna。下文所有时间都以 T 为基准。这里每个模型名称都来自对话记录，不是凭记忆写的。T+1h41m，原记录写道：“几天内记录到的八次 Python 段错误，都指向逻辑 CPU 8。这台机器是 i9-13900KF，BIOS 较旧，微码为 0x10f；Intel 目前建议使用 BIOS 微码 0x12F 或更高版本。”它甚至链接了 Intel 的支持公告，其中建议使用含有 0x12F 或更新微码的 BIOS。

然后，流程吞掉了这个发现：

一个子智能体被派去对比 CPU 8 与 CPU 16，却被提供方的安全检查拦了两次。没有结果，如实报告，也如实放弃。
一小时前写下的“这不是硬件故障的证据”，始终没有撤回。新线索只是作为一个“值得重视的假设”附在后面。
归档报告只想到了一个解决办法：刷 BIOS，并且明确拒绝提供操作：“这里不提供刷写指令。”
于是请求转向基础设施：我可以改用哪台机器？我可以创建 GitHub Actions 工作流吗？到 T+2h26m，目标被标记为受阻。

它从未运行 dpkg -l intel-microcode。Ubuntu 把 Intel 的修复作为软件包提供，启动时即可加载。不用刷 BIOS，重启一次就行。Codex 手里已经有 CPU 型号、当前微码、推荐微码，以及故障集中在同一个核心的规律，却把这四条线索变成了换电脑的请求。随后它把 Claude Code 作为子进程启动，还在任务说明里写上“不得改动 BIOS/微码/电压/频率，不得重启”，最终得到了同样的结论，因为它的要求就是如此。T+5h22m，第七次尝试，退出码 139，Codex 提出的还是同样的请求。

fig 03 Codex 在 T+1h41m 查到微码线索，随后请求第二台机器；原始记录保留英文

🔍 Opus 5，58 分钟，两条命令

**Claude 接过 Codex 的发现，用四条命令排除软件问题，再运行 dpkg，**找到了四天的笔记都遗漏的事实：微码软件包曾经安装过，后来又被卸载了。🎯

T+5h25m，我打开一个没有额外配置的 Claude Code 会话，输入“把网站部署到预发布环境”。最开始的三个准备步骤，包括发起首次部署，使用的是 claude-sonnet-5；从第一次失败开始，后续每一步都使用 claude-opus-5。第一次尝试撞上了一个多余的 zip 文件。第二次遇到了缓存异常终止。同一轮中，重跑出现了 'int' 错误，第三次运行却通过了。模型说：“这是缺陷，不是我应该掩盖的偶发失败。”

开始十四分钟后，它在磁盘上找到并阅读了 Codex 的会话日志，明确说：“前面的会话已经跟这个同样的崩溃斗了两天。让我检查它们指出的 CPU/微码证据。”功劳必须分清，因为这篇文章的论点就建立在这里：CPU 8 的规律和 0x10f 微码是 Codex 找到的。Claude 接过这个发现，问了下一个问题。📌

然后，它像凌晨 2 点值班的优秀工程师一样，先排除软件。没有 C 加载器。标准 GIL 构建，没有 JIT。空闲内存 50 GB，没有 OOM。没有运行时补丁（monkeypatching）。接着是这两条命令：

$ grep -m1 microcode /proc/cpuinfo
microcode  : 0x10f
$ dpkg -l intel-microcode
rc  intel-microcode  ...   ← removed, config-files only

rc，也就是曾经安装，后来卸载，只剩配置文件。CPU 跑的是几年前的原始固件，早于 Intel 为修复其所说的空闲和轻载活动期间核心电压偏高导致 Vmin 偏移而推出的整条修复链。这条修复链包括 2024 年的 0x12B，以及面向连续几天处于轻载状态机器的 2025 年 0x12F。这说的正是我的工作站：上面挂着两个空闲智能体。🎯

第三轮部署尝试在另一个测试文件里崩了。模型指出了特征：读取 Reader.buffer，返回的却是 Reader.pointer。随后它停了下来：“我不想继续替你一次次花 25 分钟掷硬币碰运气。”

fig 04 Claude Code 排除软件因素，并检查 CPU 微码与 intel-microcode 软件包状态；原始日志保留英文

🛠️ 两个智能体都没法亲手修好，只有一个知道接下来该怎么办

修复需要 root 权限、重启和我的密码，而任何智能体都不该拿到这个密码。两套运行框架的全部区别，就在于各自遇到这堵墙后做了什么。🤝

获取 root 权限需要我的密码，它不该出现在任何对话记录里。重启会杀掉智能体自己的会话，以及机器上的所有其他进程，其中包括已经跑了一天的两个 Codex 实例。这从一开始就应当由人决定，我很高兴两套运行框架都这样处理。

Codex 寻找绕过去的办法。Claude 则把交接做得很省事：给出三个选项及其代价，尝试 sudo -n 并报告结果，在重启前写好会话日志和记忆备注，接着提供两条命令、一条验证指令、回滚办法，以及一句我自己也会写的限定：“微码更新是一次实验，还不是已经确认的修复。”当我试图在会话里运行 sudo，却因缺少 TTY 而失败时，它解释了原因，也拒绝建议我通过标准输入管道传递密码。

fig 05 Claude Code 说明重启代价、密码限制、操作命令与回滚方式；原始记录保留英文

📊 重启之后

安装一个软件包，换来了这场拉锯开始以来第一次完整门禁通过；但启动后高负载期间的一次复发，让我不能把它叫作证明。✅

内核显示，微码从 0x10f 升到了 0x133，加载自 Ubuntu 的 intel-microcode 软件包版本 3.20260210。第一次门禁运行失败，因为重启停掉了测试数据库。第二次运行时，重启后的系统负载达到 15，'int' 特征又出现了一次；同一个文件随后五次运行全部通过。第三次运行，系统恢复平静：退出码 0，没有异常回溯，也没有段错误。随后预发布部署拒绝继续，因为我的本地提交还没推送，这是保护措施在正常工作。

会话自己也说清楚了：面对间歇性故障，一次全绿是证据，但计算出错的主机既可能明显崩溃，也可能悄悄翻转一个字节。不过，这是四天里唯一改变了结果的实验，代价只是安装一个软件包。

fig 06 重启后微码变为 0x133，第三次完整检查通过，期间曾复现一次故障；原始日志保留英文

📊 没解决问题的一方，花了多少

没有找到缺陷的一方用了约 30 倍的 token，其中大部分花在 Codex 审查 Codex 上。📉

两边用的都是订阅，所以这里没有实际现金支出。这些数字根据原始用量记录，按公开标价折算成 API 等价成本。Codex 从 T 时刻的首次预览尝试，到 T+5h25m 我放弃它为止，仅统计有公开定价的模型：

模型	API 调用次数	未缓存输入	缓存输入	输出	成本
gpt-6-astra	786	2.66M	90.6M	341k	$134.24
gpt-5.6-sol	114	0.60M	9.9M	51k	$7.37
gpt-5.6-terra	125	0.39M	11.6M	77k	$4.03
gpt-5.6-luna	77	0.15M	4.6M	32k	$0.16
合计	1,102	3.80M	116.7M	501k	$145.80

fig 07 Codex 各模型的调用量、token 用量与 API 等价费用，总计 1,102 次调用、$145.80

此外，还有记录为 codex-auto-review 的审批审查器产生的 588 次调用和 6600 万个输入 token。OpenAI 没有为它公布价格，我也就不替它定价。费率来自 OpenAI 定价页。

使用 Opus 5 的 Claude Code，从首次尝试到给出诊断，20 分钟：47 条消息、5.34M 缓存读取、121k 缓存写入、27k 输出，$4.57。到 58 分钟完成交接，合计 $5.31。费率来自 Anthropic 定价页；用同一套费率计算 Codex 启动的那次 Claude Code 审查，结果与 Claude Code 自身遥测报告的 $5.46 一致。

公平地说，到 T+2h26m 出具自己的根因报告时，Codex 的费用是 $71.13，而且它当天交付了三个经过审查的提交。只不过，没有一个触及我遇到的问题。

🧭 流程换来了归档，判断力带来了修复

两个模型都知道 Raptor Lake 不稳定性是什么；差距在于如何处理证据的三个决策，而再多的审查流程也替代不了它们。🧭

GPT-6 Astra 是顶尖的编程模型，Opus 5 是 Anthropic 当前的 Opus 级模型，也没有什么魔法。当症状不可能由软件造成时，就别再在软件里找了。开口要更多硬件之前，先问那个成本最低、最能作出判断的问题。遇到只有人能做的那一步时，把交接变成两条命令，而不是一份工作流提案。

fig 08 从 T−4d 到 T+6h47m 的排障时间线：Codex、Claude Code 与 William 的操作

fig 09 双格漫画：对比 Codex 的五小时、$146 与 Claude 的二十分钟、$4.57

我曾说过，真正的 AI 编程竞赛，比的是编码后的判断力，以及编码后的判断力才是护城河。Codex 负责发现，Claude 负责决定。这周，我亲眼看见一套比我用过的任何系统都更讲流程的运行框架——发现者、对抗审查者、裁判、审批审查器、证据归档——产出了 6600 万个审查 token 和一张受阻工单。而判断力给出的，是 dpkg -l。