我做电力智能巡检那几年，最耗人的不是调模型，是查「这个结论到底错在哪一级」。

误报率调不下去的时候，团队的第一反应总是换模型、调阈值。真正卡住我们的其实是另一件事：系统只告诉我们「这个结论是错的」，从来没告诉我们这个结论是在哪一级判出来的。后来把每一级判定单独留痕，误报才终于有了改进方向。

所以我读到智谱 GLM 那篇推理基建复盘时，注意力先被数字抓走，最后停在了另一句话上。

AI 在真实系统里干不动活，卡点通常不是它不够聪明，而是从「结果错了」到「哪一环错了」之间，没有一条它能读懂的链路。这是架构问题，不是模型问题。

GLM 的两周与三倍吞吐，功劳不在模型

先看事实。z.ai 在 9 月 17 日发布复盘，说 GLM-5.3-Flash 的全部生产推理跑在超过 10 万颗国产 AI 加速器的集群上。官方自述这是此前没人做到过的规模，过程中「生态不成熟、kernel 支持不完整、本应有文档的部分只能靠猜」。

他们的技术栈堆得相当密：

优化项作用
intra-node 张量并行用于 linear attention 与 LM Head
ReplaySSM序列状态复用
W8A8 量化权重与激活同时压到 8 bit
混合精度缓存量化INT8 / FP8 / BF16 混用
Layer Split层间切分
Encode-Prefill-Decode（EPD）分离架构把编码、预填充、解码三段拆成独立服务

结果是端到端服务性能提升约 3 倍，硬件利用效率与每 token 成本达到与主流 NVIDIA GPU「可比」的水平；从首次在新硬件上跑通到生产就绪不到两周。

顺便，同一天他们还确认了一件事：此前在 OpenCode 与 OpenRouter 上以匿名名 Ox-Alpha 测试的模型就是 GLM-5.3-Flash，一周内成为两个平台上使用量最高的模型，六天处理超过 62 万亿 token。这条从 9 月初就悬着的「匿名模型是谁」的问题，到这里由官方一手确认结案。

然后是关键的一句。他们把「两周、3 倍吞吐」这件事，归因给了一个由 GLM-5.3 自己驱动的 Infra Agent 的反馈回路，而不是模型更聪明。

这一点对我的意义比数字大。它意味着**「换硬件、换架构」的迁移成本正在被 agent 压缩，而压缩它的前提是反馈能被归因**——这两件事是有因果顺序的，不是并列的两件好事。

需要明确标注：以上全部是厂商自述、无第三方复现，而且「与主流 NVIDIA GPU 可比」没给具体口径，既没有单位 token 成本的绝对值，也没有吞吐的实测基线。数字先记着，但别拿去做采购决策。

端到端指标能告诉 AI「变差了」，但说不出为什么

GLM 那篇复盘里，有一句我反复看了几遍的诊断：

端到端指标能告诉 agent 结果变差了，但无法解释为什么。

他们的解释很具体。代码库只提供静态上下文，而一个推理系统里的数值偏差、性能回退、优化目标未达成，往往来自kernel 实现、并行策略、通信行为、内存管理、服务编排这几层的动态交互。

所以一次改动之后，agent 收到「精度测试失败」「首字延迟上升 30%」「输出吞吐下降 20%」，它依然不知道该怪哪一层，不知道自己的假设错在哪，也不知道下一步该测什么。

一个只会汇报终点的系统，喂不出会干活的 AI。

这话听着像抱怨模型，其实是抱怨系统。因为反馈能不能归因，是架构决定的，不是模型能力决定的。它可设计，也必须设计。

要让它真能干活，每一层吐出来的中间量至少得带三样东西：这是哪一层、相对基线是多少、这次变化了多少。再加上一个「下一步该测什么」的动作空间。缺了这三样，agent 就只能在一个越来越贵的循环里猜。

我那个巡检系统最后的做法就是这个形状。原来每一级判定只往上报一个最终结论，后来改成每一级单独留痕，并且记录它相对上一次的偏移。改动本身很小，收益却全在后面：有了可归因的链路，改进才有方向，调阈值和换模型才不再是赌。

顺带一句，这套思路跟可预测的活先别交给模型是接得上的（见 Sourcegraph 让编排层先写脚本）。那篇讲的是把确定性的活留在脚本层；这篇讲的是再往下走一层，你得先让系统能被查，agent 才可能被信任。

更贵的失败是它连「变差了」都不报

上面那种情况至少还报了错。更麻烦的是第二阶段：系统连「变差了」都没告诉你。

同一天，anthropics/claude-code 发布 v2.1.275（9 月 17 日），修复清单里有这么一条：

修复 Linux 沙箱内 zsh 下失败的 Bash 命令被报为 exit code 0。

这是静默失效最纯粹的形态。agent 是依赖退出码做判断的，它看到 0，就认为命令成功了，然后在这个「成功」之上继续往下叠。错误不是被漏掉，是被当成了地基。

同一版还修了另一个同类问题：配置的遥测导出 helper 失败时，整条链路静默为空，之前没有任何提示。

「没有数据」和「数据坏了」，在监控面板上长得一模一样。 这是它最阴的地方：不是指标难看，是根本没有指标，而你分不出来。

我对这类问题有天然敏感，因为在生产领域的智能安监里做过阈值设计。误报和漏报的代价从来不对等，所以真正难的不是选哪个数，而是让系统能说清它现在站在哪一边、以及它有多确定。

那次让我记牢一条规矩：说不清的那部分，不能塞进成功或失败里。 它得自己有个位置，也自己有个数字。

回到 claude-code 这两条修复，能直接搬走的检查项有三条：

问题检查动作
沙箱 + shell 组合可能把失败报成成功用一条注定失败的命令验证退出码，别只看文档
遥测导出失败不报错在启动时就校验导出链路，不要等到查日志时才发现没有日志
错误分类混淆（403 权限不足被报成 401 登录过期）让每类失败有自己的名字和自己的处置路径

第三类其实 v2.1.274 也修了：被 403 insufficient_scope 拒绝的 MCP 工具调用，之前被误报成「登录过期」，现在会指出缺失的权限并指向重新认证。权限不足和凭证过期要人做的事完全不同，混在一起就会让人去重新登录一个根本不用重新登录的账号。

把这两版连起来看，它们几乎构成一份静默失效的检查表。可观测性不是加日志，是让每一层能回答一句：这次和上次有什么不同。

从这两件事能搬走的三个动作

第一，挑一个你已经在用 AI 干的活，把它的判定链路按层写下来，每层旁边标一句：这一层的中间量，现在存在吗。标不出来的层，就是 AI 只能靠猜的层。

第二，把你 agent 依赖的每一个「成功信号」拿去验证一遍。用一条注定失败的命令或一次注定报错的调用，看它到底会不会报错。那个 exit 0 的坑，就是没验证过的代价。

第三，给「说不清」留一个位置。别把它塞进成功或失败的某一类，让它单独成一个状态，并且在监控上给它一个数字。

数据说明

  • 事实来源：GLM 部分来自 z.ai 官方博客《Toward Recursive Self-Improvement: How GLM Built Its Own Inference Infrastructure》（2026-09-17）。claude-code 部分来自 anthropics/claude-code 的 GitHub Releases（v2.1.274 发布于 2026-09-17T00:12:02Z，v2.1.275 发布于 2026-09-17T22:33:17Z），release notes 全文读取。
  • 未独立复现：GLM 自述的「3 倍端到端吞吐」「每 token 成本与主流 NVIDIA GPU 可比」「不到两周从跑通到生产」「六天处理超过 62 万亿 token」均为厂商口径，未提供测量方法、绝对值或吞吐基线，无第三方复现。
  • 事件状态：GLM 推理基建复盘与 Ox-Alpha 归属确认，均为官方发布的既成事实。claude-code v2.1.275 / v2.1.274 为已发布的 stable 版本，修复项来自官方 changelog。
  • 对照参考：本日另有 UC Berkeley 与 Arena 合作的 HarnessTax 研究（harnesstax.github.io），在 SWE-bench Lite 与 Terminal-Bench 2.0 上评测 21 个 model–harness 组合，结论是 harness 选择对成功率影响很小、对成本影响最高可达 5 倍，且极简 harness 具竞争力。该研究与本文判断相邻但不同源，其 harness 成本差异属论文自述、未见独立复现，故本文只作旁证引用，不展开。