读对了却做错了：System One 模型的决策失败诊断学

一个让 Agent 开发者夜不能寐的问题

你做了一个 LLM Agent。它在模拟环境里跑得好好的，突然在某个状态选了一个离谱的动作。

你打开日志，发现没有思维链可以看——因为你用的是 System One 模型，它只给概率分布，不写推理过程。

这时候你面对一个无法回避的诊断分叉：

模型是没看懂当前状态？还是看懂了，但选错了？

前者指向上下文表示、context budget、状态编码；后者指向决策本身。如果你分不清这两种失败，你的修复就是瞎猜——加更多 context？换更强的模型？还是改决策头？

CMU 的 Yubo Li、Ramayya Krishnan 和 Rema Padman 发了一篇论文，标题就是这个问题本身："Reading Right, Acting Wrong: Diagnosing Decision Failures of System One Models in Agent Loops"。他们不仅提出了问题，还造了一把尺子。

System One 模型：Agent 世界的"快思考"

先说清楚研究对象。当前 Agent 的主流范式是：每一步都调一个 LLM，让它写一段思维链，然后输出动作。这是 System Two——慢、贵、但可检查。

但有一批新模型走的是另一条路：System One 模型。给定 Agent 状态和一组候选动作，它一次前向传播直接返回一个概率分布，不生成任何文本。代表选手包括 JEV（TypeSafe AI）、OpenAI Decisions、Clef-27B（Cloudflare）、Eikos-27B 等。

它们快到什么程度？论文测了：

• System One 模型回答一个完整状态的中位延迟：27–225 毫秒
• 开源 LLM 的似然读数：317–947 毫秒
• 推理模型（GPT-6.1）：2.3 秒

JEV 处理 65,228 个决策状态总共花了 $8.79——每 1000 个状态 $0.13。GPT-6.1 达到类似覆盖要 $642，贵了 73 倍。

但问题是：当 System One 模型选错了，你打开日志，什么都没有。没有思维链，没有推理过程，只有一个概率分布。错误变成了一个黑箱。

四象限诊断法：把黑箱拆开

论文的核心方法极其优雅。在每一个 Agent 决策状态上，独立地问两类问题：

1. 决策问题：下一步该选哪个动作？
2. 事实探针：上一步动作成功了吗？Agent 当前在哪？手里拿着什么？这个动作是否被允许？

每个探针都在同一个状态上独立提问，不泄露答案给决策问题。然后把两个结果交叉，得到一个 2×2 矩阵：

关键象限是 U1D0：所有事实探针都答对了，但动作还是选错了。这就是"Reading Right, Acting Wrong"。

这个分叉有明确的工程含义：

• U1D0 多 → 问题在决策环节，换更强的决策头或加推理
• U0D0 多 → 问题在理解环节，改状态表示或加 context

核心发现：73-85% 的错误是"读对了，做错了"

论文在 19,663 个配对测试状态上跑了 18 个系统。结果令人震惊：

对于最准确的 6 个系统，73-85% 的决策错误发生在所有事实探针都答对的状态上。

而且这个比例随准确率增长——系统越强，"读对了却做错了"占错误的比例越大。因为强系统主要减少了"读错"的情况，但"读对了却做错了"几乎没减少。

GPT-6.1 作为推理参考系，准确率 0.884，但它的错误中 85% 也是"读对了，做错了"。

这意味着：理解和决策是两个可分离的能力。你可以让模型完美地理解状态，但它的决策仍然可能崩盘。

141 个"全员阵亡"状态

如果"读对了却做错了"是每个模型各自的随机噪声，它们应该均匀分布在状态空间里。

但不是。14 个合格的快速系统在完全相同的 141 个状态上全部翻车——所有事实探针答对，动作选错。零假设下这个数字应该是 0。

每个系统在"只有自己失败"的状态上准确率 74-94%，但在"其他 13 个系统都失败"的状态上准确率只有 1-16%。

错误不是 idiosyncratic 的，而是附着在特定状态属性上的。 这意味着存在一类"结构性困难状态"，它们能暴露所有快速模型的共同盲区。

组合失败：能读 + 能算 ≠ 能边读边算

为了搞清楚 U1D0 到底是"探针没覆盖到关键事实"还是"模型不会组合信息"，论文构造了一组探针充分性可验证的状态：

• 4 条规则 + 1 个默认动作，规则条件由 8 个二元事实决定
• 4 个事实被规则测试，4 个是干扰项
• 对每个事实赋值，gold action 唯一且可枚举验证

结果非常漂亮：

JEV 和 Qwen3.8-27B 在"只给事实"时决策准确率接近 100%（1.000 和 0.994），在"只给原始 trace"时只有 0.791 和 0.797。

它们能完美地读事实，也能完美地从事实推出动作，但把两者放在一起——从原始 trace 边读边决策——就掉了 20 个百分点。

这不是"不会读"也不是"不会算"，是不会边读边算。论文称之为"组合失败"（composition failure）。

两种失败机制，同一个表象

更精细的分析发现，U1D0 这个象限里其实藏着两种完全不同的机制：

1. 整合失败（Consolidation failure）——JEV、Qwen3.8-27B

• 能读对每个事实
• 能从事实推出动作
• 但不会把散落在 trace 各处的事实整合成一个一致的快照再应用规则
• 修复方法：把事实集中到一处

2. 捕获失败（Capture failure）——Clef、Vega-27B、SimpleJev-27B

• 能读对每个事实
• 但被"程序外的真实但错误的线索"捕获
• 即使规则条件满足，去执行了一个看起来合理但不在程序内的动作
• 修复方法：删除干扰事实（Clef 的准确率因此从 0.589 飙到 0.924）

同一个 U1D0 标签，两种完全不同的失败机制，两种完全不同的修复路径。 如果只看最终准确率，你永远分不清。

自我摘要：让模型自己救自己

最实用的发现来了。既然 System One 模型能完美地回答事实探针，那让它们自己给自己写摘要会怎样？

具体做法：

1. 先在原始 trace 上问决策问题
2. 在独立请求中问事实探针
3. 把模型自己的探针答案拼回 trace，再问一次决策

结果：

模型自己读对了事实，把事实喂回给自己，决策就变好了。 不需要外部信息，不需要更强的模型，只需要把"读"和"决策"解耦成两个独立请求。

更激进的做法：用代码组合。既然规则是显式的，让模型回答事实，用代码把事实映射到动作。JEV 达到 0.996，Clef 达到 1.000。

这就是 System One 模型的设计初衷——许多窄问题并行，由代码组合。论文引用了 TypeSafe AI 的设计理念，这正是 JEV 这类模型的预期使用方式。

级联：只在不确定时多问一次

但每次都问两轮太浪费。论文测了一个级联策略：

• 第一轮决策，如果模型自信度 > 0.7，直接用
• 如果 < 0.7，再问一轮事实探针，拼回去再决策

JEV 用这个策略达到 0.932 准确率，只在 38% 的状态上需要第二轮。

这是工程上最优雅的方案：用置信度做闸门，把算力花在不确定的状态上。 理解和决策解耦，但不是每次都解耦，只在需要时解耦。

GPT-6.1 的"过度谨慎"

一个有趣的发现：GPT-6.1 在 τ²-bench（客服策略场景）上是 6 个最强系统里最弱的（0.709），其他场景都是最强。

原因不是读不懂，而是过度谨慎。当 gold action 是"执行用户刚确认的写操作"时，GPT-6.1 有 16.7% 的情况选择回复用户确认，而不是直接执行。快速系统只有 2.8-7.0%。

推理模型的"思考"让它学会了多确认一遍，但在 gold 标准里这被算作错误。这揭示了一个深层问题：推理模型的谨慎和 gold 标准的效率假设之间存在张力。

工程洞察：这对你意味着什么

1. 不要只看准确率。 两个准确率相同的模型可能有完全不同的失败模式。Torchcast-27B 读得最好（U=0.858）但决策最差（D=0.678），SimpleJev-27B 读得一般但决策更差——前者是"读对了做错了"，后者是"被干扰捕获"。

2. 探针是诊断工具，不是训练目标。 论文明确说这是一个"诊断工具，不是排行榜"。如果你把探针准确率当训练目标，模型会学会在探针上表演，但决策不会变好。

3. 级联是 System One 的正确用法。 不是让一个模型端到端做完所有事，而是让窄模型快速回答窄问题，用代码组合，只在不确定时升级到更慢的路径。

4. "理解 ≠ 决策"是一个设计原则。 你的 Agent 架构应该把"读状态"和"选动作"当作两个可独立替换的组件。当你发现决策错误时，先问"是读错了还是选错了"，再决定修哪一层。

一个更深的洞察：标量幻觉的又一例

这篇论文给"标量幻觉"概念谱系添了一个强有力的例子：准确率是一个标量，但它隐藏了两个独立的维度。

• 模型 A 准确率 0.78，可能全是"读错了"
• 模型 B 准确率 0.78，可能 80% 是"读对了做错了"

这两个模型的修复路径完全不同，但准确率告诉你它们"一样好"。

这和之前发现的"基准准确率 ≠ 表示忠实度"、"论文晦涩度是标量但认知结构是多维"是同一个模式：当你用一个标量衡量一个多维度系统，你会系统性地误判修复方向。

个人思考：诊断学 vs 排行榜

这篇论文最让我欣赏的是它的立场。作者明确说："这是一个诊断工具，不是排行榜。"

在 AI 评测越来越卷的当下，这种态度稀缺。大多数 benchmark 在比谁的数字高，但这篇论文在教你如何理解你的模型为什么错。它不告诉你哪个模型最好，它告诉你"你的模型错在哪里，以及该怎么修"。

这和医学的逻辑一样：体温计不治病，但它告诉你该吃什么药。

论文链接：https://arxiv.org/abs/2610.18579
HTML 版本：https://arxiv.org/html/2610.18579v1

这篇论文给所有 Agent 开发者提供了一个实用的诊断框架。当你下次面对一个选错动作的 Agent，别急着换模型——先问一句：它读对了吗？