把轨迹当状态：推理时间 Scaling 的一个新维度

同一份推理轨迹、同一个模型、同一次额外前向，只因为放的位置不同，分数差了一倍：

只给轨迹、不给原文     [T, q]       43.8
原文 + 轨迹，轨迹在后   [x, T, q]    43.0
原文 + 轨迹，轨迹在前   [T, x, q]    81.8

前两个几乎一样：材料给全了，反而没比只给一半强。直到位置对了，才跳到 81.8。

2026-09 这是 Z.ai 与清华唐杰的论文 Trace as State: Reasoning Traces as Conditional States for Long-Context Transformers（arXiv:2609.02702，2026-09-02）的结论。本文把它放在推理时间 Scaling 的谱系里讲。文中数字均已比对论文原文的 Table 2 / Table 3 / Table 6。

一、Scaling 的第三条轴

训练侧的 Scaling Laws 走过三代：Kaplan 定律说参数优先，Chinchilla 修正为参数与数据同比例增长，MoE 打破了「参数量等于激活量」的等式。这条线的问题在另一篇里展开过，这里只说它的结局：数据快用完了。

Chinchilla 预言 10T 参数模型需要约 200T token，而互联网高质量文本总量估计只有 100T–300T。与其继续在训练侧堆料，不如换一条轴：不 Scale 训练，Scale 推理。o1 之后，这条轴成了主线。

它已经长出了好几类做法：

类别 代表 多花的是什么
采样 self-consistency、best-of-n 并行跑几份
长度 reasoning effort、budget forcing 思维链写多长
搜索 Tree-of-Thought、MCTS 搜索树多大
迭代 self-refine、Re2 反馈几轮

四类做法的共同点是：都在「多算」上加码。多采几份、多想一会、多搜几枝、多改几遍。

这篇论文问的是另一个问题。

二、算力花出去了，产出用足了吗

前四类方法都在增加算力的投入量。但算力投进去之后会产生中间产出：推理轨迹。这份产出到目前为止只有一个用途，被读一遍，当作上下文的一部分。

论文指出的是：长上下文推理里有一个结构性的错配。

因果注意力下，靠后出现的信息无法影响同一次前向传播中已经形成的、靠前的表示。而长上下文任务往往需要维护某种「任务状态」：正在找的目标、待查队列、已排除的假设。麻烦在于，这些状态常常是读完材料、开始推理之后才浮现的。

打个比方：读完 50 万字小说的最后一章，才被告知「请找出坏人」。前面每一页都是不带目标读完的。

论文的做法是把这件事反过来：第一遍按正常顺序读完、正常推理；把推理轨迹收起来，放到第二遍的上下文前面。

于是第二遍读同一份材料时，模型已经知道要找什么了。

三、Trace as State

3.1 流程

论文把它概括成 read → compute → feedback → reread 四步：

第一遍   (r_j, a_j) ~ M(· | x)         跑 n_tr 次，各得一条轨迹和一个答案
序列化   T = π(r_1, …, r_ntr)          只加分隔符和一句引导语
第二遍   (r', a') ~ M(· | [T, x, q])   带着 T 重读原文

序列化本身几乎不做加工：保留源顺序，加 <trace_start> / <trace_end> 之类的分隔符，再补一句「轨迹可能有错、请对照原文」的提示。过长的轨迹截断到前 50,000 字符。

论文对轨迹的定位很克制：「任务状态的可观测文本代理」，并明确说它「可能不完整、有损、或有错」，不等同于模型内部状态，也不等于形式化的任务条件。这个定位后面还会用到。

3.2 严格对照

这篇的实验设计干净到值得单独说。它设了一个对照组 Trace Append：同样一份 T，放在上下文后面。

TRACE AS STATE   M(· | [T, x, q])     轨迹在前
TRACE APPEND     M(· | [x, T, q])     轨迹在后

同一个 x、同一个 T、同一个模型，唯一的变量是顺序。

这就把问题问得很清楚了：轨迹放前面，到底比放后面强在哪？

差别在因果注意力上。放后面，T 只能影响它之后的推理和最终回答，改不了模型已经对 x 形成的理解；放前面，模型是在「知道要找什么」的前提下重读 x 的。

3.3 为什么前面比后面好

论文给了一个形式化论证。把处理器抽象成因果状态更新器：

s_i = U(s_{i-1}, c_i)        i = 1, …, n

任务条件 z 决定初始状态 s₀ = z。同样的序列 C、同样的条件 z，只有顺序不同：

顺序 处理器何时知道该走哪条路径 需要的工作内存
[z, C] 条件在先 读完 z 就知道 ⌈b⌉ 比特（b = log₂|S|，只存当前状态）
[C, z] 条件在后 读完整段序列才知道 ⌈b·2ᵇ⌉ 比特

第二行是这么来的：条件在后时，处理器读完了 C，还不知道该把哪个初始状态传播进去，于是必须为每一个可能的 z 保留一份完整的响应档案。S 到自身的函数共有 |S|^|S| 个，取对数就是 |S|·log₂|S| = b·2^b。

最坏情况下，两种顺序的工作内存差一个指数。

由此得到一条排序原则：任务条件在它所指导处理的信息之前就可用，会好用得多。

需要说明的是，这是关于抽象处理器的结论，不是关于 Transformer 的。论文摘要自己限定得很清楚：”for deterministic processors that read the input once”；正文也写明条件状态更新任务”are not literal models of real world long context tasks”。它提供的是排序原则的直觉，真正的证据在实验里。

3.4 实验

三个模型，来自三家不同厂商，架构也各不相同：

模型 论文披露的架构 推理档位 输入预算
DeepSeek V4 Pro Preview CSA + HCA + mHC max 1,048,576
Qwen 3.7 Max GDN + GA xhigh 提示 983,616
GLM-5.2 DSA + IndexCache max 1,048,576

三个基准：GraphWalks 256K（长边表上的图状态维护）、MRCRv2 8-needle（把最终请求绑定到正确的历史问答实例）、NUB-1M（40–70 万 token 长篇小说的阅读理解）。每题 5 次重复，第二遍带上全部 5 条轨迹。

主结果（Table 2，全部为 5 次重复的平均值，单位 %）：

模型 条件 BFS EM / F1 Parents EM / F1 MRCR 256K EM / Seq MRCR 512K EM / Seq NUB Acc
DeepSeek V4 Pro 首遍 31.6 / 36.4 29.2 / 46.5 53.8 / 78.5 45.4 / 63.6 60.0
  Trace Append 41.8 / 48.3 43.0 / 65.3 66.6 / 79.6 49.4 / 66.9 71.0
  Trace as State 58.8 / 65.9 81.8 / 91.3 76.8 / 88.7 52.6 / 73.3 73.0
Qwen 3.7 Max 首遍 60.0 / 68.1 60.8 / 87.2 79.8 / 83.1 36.2 / 43.7 37.0
  Trace Append 60.4 / 70.4 71.0 / 91.7 84.0 / 87.1 40.4 / 47.4 49.0
  Trace as State 63.8 / 71.7 96.4 / 99.1 88.4 / 91.3 46.8 / 52.5 51.0
GLM-5.2 首遍 55.8 / 70.7 66.4 / 88.5 40.2 / 48.2 42.6 / 52.0 43.0
  Trace Append 60.0 / 75.8 83.2 / 92.7 40.0 / 58.3 44.6 / 59.9 65.0
  Trace as State 63.4 / 75.0 100.0 / 100.0 61.2 / 71.9 55.4 / 70.1 66.0

横向 9 个指标 × 3 个模型 = 27 个组合，Trace as State 赢下 26 个。

唯一的例外是 GLM-5.2 的 BFS F1：75.0 对 75.8，差 0.8 个点（同一个子任务的 EM 仍是前者高）。DeepSeek V4 Pro 与 Qwen 3.7 Max 则在每一个指标上都偏好前置。

收益最大的是 GraphWalks Parents。这个子任务要求模型在解读图的过程中始终维护「前驱节点」这个状态，正好是「任务状态前置」最能帮上忙的场景。

3.5 消融：五个对照逐一堵死

主结果之外的替代解释，论文用一组对照逐个排除（DeepSeek V4 Pro / GraphWalks 256K）：

对照 Prompt BFS EM Parents EM 排除了什么
首遍 [x, q] 31.6 29.2 —
Majority@5 首遍 5 次投票 35.0 31.0 —
Oracle@5 首遍事后择优 50.0 50.0 —
Question First [q, x, q] 33.4 53.0 问题本身就是任务状态
Re2 [x, q, x, q] 49.0 50.0 单纯重读有用，但不够
Answer Feedback [a, x, q] 35.4 45.4 只给答案不如给轨迹
Random Trace [T_rand, x, q] 22.4 14.2 格式脚手架不成立
Trace Only [T, q] 46.2 43.8 原文仍然必要
Trace Append [x, T, q] 41.8 43.0 —
Trace as State [T, x, q] 58.8 81.8 —

几条值得单独看：

Random Trace 比不放还差（Parents EM 14.2 对首遍 29.2）。换成别的问题的轨迹，性能直接崩掉，收益必须来自同一个问题的轨迹，排除了「格式对了就行」的解释。

Question First 一个纯 prompt 重排就拿到 53.0。这说明问题本身也是一种任务状态，只对 Parents 这种「目标明确」的子任务有效（BFS 上只有 33.4，几乎没动）。

Trace as State 超过了 Oracle@5（Parents EM 81.8 对 50.0）。事后从 5 个首遍答案里挑最好的，还不如带上轨迹重读一遍。

还有 Trace Only 与 Trace Append 几乎打平（43.8 对 43.0）：一个连原文都没有，一个材料齐全，分数却一样。这条最能说明问题，收益不来自材料多少，来自材料的顺序。

轨迹条数本身也是一个旋钮：n_tr 从 1 增到 5，性能总体上升（论文原话是 generally rises），且 Trace as State 的排序优势全程保持。

四、收益的构成

前面那张消融表里藏着一个需要拆开看的事实。

DeepSeek V4 Pro 在 GraphWalks Parents 上的首遍只有 29.2% EM。一个纯粹的 prompt 重排（Question First）就把它拉到 53.0。这一段增益跟推理轨迹没关系，是「让模型知道自己在找什么」本身的价值。

真正属于「把轨迹当作状态」的增量，是 53.0 → 81.8。

这个拆解论文没有做，但读的时候心里应该有一杆秤。

另一半是收益与任务类型的相关性：

基准 任务状态形态 DeepSeek V4 Pro 的增益
GraphWalks Parents 当前节点 + 前驱集合，可枚举 +52.6
MRCRv2 256K 待绑定的问答实例，较紧凑 +23.0
NUB-1M 对情节的弥散理解，不可枚举 +13.0

状态越紧凑、越可枚举，这个方法的收益越大。 图任务需要一个能写下来的「当前走到哪」，推理轨迹恰好承载得住；小说理解的状态是弥散的，几条轨迹写不全。

五、代价与边界

成本结构值得拆开看。

DeepSeek V4 Pro / GraphWalks 256K 首遍 Trace as State（总计）
输入（cached + missed） 257.9M 597.4M
输出（含推理 token） 62.5M 90.5M

输入涨约 2.3 倍，输出涨约 1.45 倍。两遍加起来一定更贵，多出来的输入抵不掉。

但单独看第二遍，有个地方值得注意：它只产出 28.0M 输出，不到首遍 62.5M 的一半。带着状态重读之后，模型想得更少。也就是说，这个方法不是靠「想更多」换质量，恰好相反：它用一次额外的阅读，换掉了模型本来要花的长篇推理。

（Table 6 的 Total tokens 列给出的是两遍的合计；只比较第二遍与首遍会被误读成总量对比。）

但有一项代价论文只提了一句，没有量化：把新生成的轨迹插到上下文最前面，会让整个 prompt 的前缀缓存失效。

  • 单轮任务里这无所谓，反正只跑一次
  • 多轮 Agent 里每一次都要重排，前缀复用颗粒无收

而多轮 Agent 恰恰是前缀缓存价值最高的场景。论文在局限里承认了这一点（”can also reduce key–value cache reuse in multi-round settings”），也明确说没测多轮任务。所以这篇展示的是收益侧，代价侧是欠测的。

另外三处值得留意：

  • 理论与实验之间的桥很窄。 指数级内存分离是关于抽象处理器单次读取的最坏情况结论，论文用它「引出」方法（原文用词是 motivate），而不是「解释」实验结果。两者是呼应关系。
  • 消融只覆盖一个格子。 上面那张对照表全部来自 DeepSeek V4 Pro / GraphWalks 256K。另外两个模型、另外两个数据集没有做同类对照。
  • GLM-5.2 在 MRCRv2 256K 上，Trace Append 比首遍还低（40.0 对 40.2 EM）。论文的表述是「Trace Append 在许多设置上优于首遍」，用词准确，但容易被读成「大多数」。

六、它捅破的是什么

把这篇文章放回 Scaling 的语境里，它的位置很特别。

采样、长度、搜索、迭代这四类，都在回答「再多花多少算力」。这篇问的是「已经花掉的算力，产出该怎么放」。它不是在既有维度上加码，而是打开了另一个维度。

而且这个维度背后有一个更普遍的观察：模型内部的状态是绑在位置上的，文本不是。

hidden state、KV cache 都锚死在特定的 token 位置上，你没法把「读到第 10 万个 token 时才形成的理解」搬到第 1 个 token 前面去。但推理轨迹是文本，它可以被复制、截断、重排，搬到任何位置。

一旦承认「轨迹即状态」，随之而来的能力就不止于重排：

  • 状态可以跨会话传递
  • 可以跨进程传递
  • 甚至可以跨模型传递，不需要共享 KV cache，也不需要同一份权重

在多智能体系统里，这就是一个天然的交接协议。

结语

论文的对照设计是它最扎实的地方：同一个 x、同一个 T、同一个模型，只改顺序。正是这个设计让结论无法用「格式」「材料多少」「模型差异」来解释。

回到开头那三个数字：

只给轨迹、不给原文     [T, q]       43.8
原文 + 轨迹，轨迹在后   [x, T, q]    43.0
原文 + 轨迹，轨迹在前   [T, x, q]    81.8

材料更全，分数却没变；顺序一换，翻了一倍。

推理时间 Scaling 到目前为止都在优化「算力投多少」，这篇提示了另一件事：同样的算力产出，还没有被用尽。

源文件索引

本文的「源码」是论文原文与其中的表格。

来源 关键内容 引用点
Trace as State 论文 因果关系错配的问题陈述、read→compute→feedback→reread §1、§3.3
同上 条件状态更新、指数级内存分离、排序原则 §3.1（Eq. 1、Eq. 2）
同上 轨迹作为「任务状态的文本代理」的定位、序列化规则 §3.2
同上 模型配置、数据集与评分、5 万字符截断 Table 1-1、Table 1-2
同上 主结果（27 个组合） Table 2
同上 对照消融（Question First / Re2 / Answer Feedback / Random Trace / Trace Only / Oracle@5） Table 3
同上 轨迹条数消融（n_tr = 1…5） Figure 2
同上 配对 bootstrap 置信区间 Figure 5、Figure 6
同上 Token 用量（总计输入 2.3×、第二遍输出不足首遍一半） Table 6
同上 局限声明（接口依赖、延迟与成本、KV 复用、未测多轮） Limitations

版本：arXiv:2609.02702v1，2026-09-02。所有实验数字为该论文口径，未做独立复现。

参考资料