TRACE AS STATE总览。(A) 因果处理器携带单一运行状态。(B) 最坏情况下，条件在前的处理只需跟踪实际状态路径；条件在后则可能需要在工作记忆中保留指数级更多的信息。(C) 推理轨迹T被视为任务状态的文本代理。(D) TRACE AS STATE在新的因果通道中将T置于长上下文之前，而TRACE APPEND则将T置于长上下文之后。
这些推理文本虽然不完美，可能包含错误，但本质上是一种可观测的“状态代理”。于是论文提出TRACE AS STATE方法：先把任务文本喂给模型让它自由发挥产生推理轨迹；把这些轨迹用固定格式串起来并截断到可接受的长度；在第二次重新阅读时，将这段轨迹放在长上下文之前，构造出“[T, x, q]”的提示结构。
先把问题拉回到最基本的地方：Transformer 是因果处理器，每个 token 只能看到自己左边的内容。这意味着，如果某条解题必需的信息出现在文档后面，模型在读到前面内容时，根本不知道要用什么“状态”去加工它们。论文把这个矛盾抽象成一种叫 条件状态更新任务（conditional state update task） 的模型。简单来说，这是一个顺序读取信息的处理器，每读一条新信息，就更新一次自己唯一的“任务状态”。形式上可以写成下面这条更新规则：其中 c_i 表示第 i 条输入信息，s_i 表示读完前 i 条后的任务状态，U 是固定的状态更新规则。整个任务就是：给定一个初始条件 z，处理器把它当成初始状态 s_0，然后依次读入 C = (c_1, ..., c_n)，最后返回 s_n。关键问题来了：条件 z 放在输入序列前面还是后面，对处理器的内存要求能差多少？论文给出了一个相当惊人的答案——在最坏情况下，差距是指数级的。如果条件 z 先出现，处理器只需要沿着“实际走到的状态”不断更新，任何时候只需要保存当前这一条状态路径。设状态空间大小为 |S| = 2^b，那么内存开销大约是 b 比特。如果条件 z 放到最后才出现，情况就完全不同了。处理器在读完整个 C 时还不知道当前该沿哪条状态路径走，因此它必须把“这个序列会对每个可能的初始状态产生什么最终结果”全部记住。每个可能的状态都对应一个最终结果，这相当于要保存一个从状态集合到自身的映射函数；最坏情况下，所有可能的合法序列会诱导出 |S|^|S| 种不同函数，所需内存下界为：也就是说，保存映射表需要约 b·2^b 比特，而条件在前只需要 b 比特。当状态数变大时，前者比后者高出一个指数量级。这个结论当然不是要描述真实大模型的内存分配，它的意义在于揭示一种结构性压力：任务状态出现的顺序，会影响因果处理器以多高的代价处理同样的信息。如果能把“后面才知道的状态”提前放到下一遍阅读之前，模型就能带着目标去重读长文。
TRACE AS STATE：把推理轨迹变成“任务状态”放在上下文之前
理论分析给了方向，但现实任务里，“任务状态”往往不是现成的文本。比如要在一份 30 万 token 的图边列表里做 BFS 遍历，起始节点可能藏在文档中段，模型读到前面时根本不知道目标。那该怎么办？论文给出的答案是：用模型自己生成的推理轨迹（reasoning trace）充当状态代理。现在很多前沿模型在给出可见答案之前，会先产出一段思维链文本，这段文本里往往记录了当前跟踪的目标节点、已经排除的选项、待探索的搜索前沿等信息。它可能不完整、有噪声，甚至包含错误，但作为可观测的文本，它已经携带了大量与任务状态有关的信息。作者把这种轨迹称为 文本状态代理（textual state proxy）。整个流程分三步。第一步，先用原始长任务跑若干次，拿到多条“推理轨迹 + 答案”：这里 M 是因果推理模型，x 是长上下文，r_j 是第 j 次运行得到的推理轨迹，a_j 是对应的可见答案，n_tr 表示一共收集多少条轨迹。第二步，把多条轨迹按固定格式拼接成一段序列化文本 T。序列化器 π 只加必要的分隔符和引导文字，不改变轨迹本身的文字顺序：第三步，开始第二遍阅读。这里论文做了一个非常干净的对比设计：把同一段 T 放到长上下文 x 之前，得到 [T, x, q]，称为 TRACE AS STATE；把同一段 T 放到长上下文 x 之后，得到 [x, T, q]，称为 TRACE APPEND。q 是问题，统一放在提示词末尾以保证模型聚焦。两种设置使用完全相同的长上下文 x、完全相同的轨迹文本 T，唯一差别就是 T 出现的位置。在 TRACE AS STATE 下，模型重新读 x 的每一个 token 时，都能通过因果注意力看到前面的轨迹；在 TRACE APPEND 下，轨迹只能在 x 已经被编码完之后才参与后续推理，无法回头改变 x 中已经形成的表示。这正好对应了前文理论分析中“条件在前”和“条件在后”两种模式。表中列出了理解方法所需要的核心记号：x 是长上下文，M 是因果推理模型，r_j / a_j 是第 j 次首遍运行得到的推理轨迹和答案，π 是固定的轨迹序列化器，T 是最终喂给第二轮提示的序列化轨迹文本。这种做法的妙处在于：它完全不需要训练、不需要改模型结构、不需要动 KV cache 的底层实现。只要模型愿意暴露推理轨迹，就能在推理阶段直接套用。本质上，这是一套“先让模型自己划重点，再带着重点重读原文”的通用推理扩展方案。
看到这里，很多人第一反应可能是：多读一遍当然有帮助，跟轨迹放哪里有什么关系？论文专门设计了一组对照消融来回应这种质疑。表 3 汇总了 DeepSeek V4 Pro Preview 在 GraphWalks 256K 上各种提示设置的成绩。逐个看这些条件，会发现论文想得很细。先看把问题提前的效果（Question First，[q, x, q]）。它把同一个问题在正文前和正文后各放一次。这确实提升了 Parents 的成绩，说明问题本身就是一种重要的任务状态；但它对 BFS 帮助不大，而且两个子任务都远低于 TRACE AS STATE。问题只是状态的一部分，轨迹里还包含更多在推理中逐步发现的中间状态。再看单纯重复阅读（Re2，[x, q, x, q]）。Re2 是之前已有的一种简单重读方法，它只是把原文和问题原封不动地重复一遍。它确实比单遍强不少，说明“多读一遍”本身有作用，但仍然明显低于 TRACE AS STATE。如果 TRACE AS STATE 的收益只是因为“第二遍更仔细”，那么 Re2 应该拉平差距，但事实并非如此。还有把首遍可见答案直接反馈到前面的设置（Answer Feedback，[a, x, q]）。它把 5 次首遍的最终答案放到正文前，效果比首遍略好，但仍远低于 TRACE AS STATE。这说明最终答案作为状态代理，信息量远远不如完整的推理轨迹。更有说服力的是 Random Trace（随机轨迹，[T_rand, x, q]）。它把同任务其他问题的轨迹拿来放在正文前。结果不仅没提升，反而比首遍还差：BFS EM 只有 22.4，Parents EM 只有 14.2。这一下就排除了“只要前面多垫一段推理样式文本就有用”的解释。随机轨迹兜售的是模板，不是状态，甚至可能干扰模型对真实状态的判断。只有包含本问题任务信息的轨迹，才能真正起到状态提示的作用。论文还比较了 Majority@5 和 Oracle@5。前者把 5 次首遍答案做多数投票，后者“事后诸葛亮”式地从 5 个首遍答案里挑成绩最好的一个。Parents 上 Oracle@5 也只有 50.0 EM，而 TRACE AS STATE 能到 81.8 EM，意味着二遍反馈不是在做简单的答案选择，而是真的基于轨迹状态重新生成了更可靠的答案。另外，Trace Only 条件只给轨迹不给正文，效果接近 TRACE APPEND 但远低于 TRACE AS STATE，说明原始长文依然承载着关键证据，两者需要配合。最后还有一个关于轨迹数量的消融，如图 2 所示。随着复用轨迹数量从 1 条增加到 5 条，两种方法的性能整体都在上升，而且 TRACE AS STATE 的曲线始终压在 TRACE APPEND 上方。这说明轨迹数量本身就是一个可以“堆算力”的扩展维度：每多一次首遍采样，就多得到一份关于任务状态的文本足迹。图 2A 展示 BFS 子任务的 F1 随 n_tr 变化的趋势。图 2B 展示 Parents 子任务上的对应结果，阴影区域是 95% 置信区间。整体来看，无论 n_tr 取多少，TRACE AS STATE 都保持在 TRACE APPEND 之上。
理论到实践：从条件状态更新到通用推理扩展方法
把理论分析和实验结果放在一起看，能提炼出一条很清晰的因果链。Transformer 是因果的，而推理任务中需要维护的状态往往不是因果顺序给出的。当状态出现在长文后面时，模型第一遍读前面的内容基本处于“盲走”状态。TRACE AS STATE 做的事情，就是打破单遍因果处理的封闭性：先盲走一遍，把过程中发现的“状态”以文本形式沉淀下来，再作为第二遍阅读的前缀放回去。从技术本质来看，这个方法其实是在“pass 之间”引入了反馈回路，而每个 pass 内部仍然保持严格的因果处理。它没有改变模型参数，没有修改注意力掩码，也没有引入任何训练目标。这种设计让它可以被零成本地应用到任何已经上线的大模型 API 上——只要该 API 暴露推理轨迹。这也是为什么论文把它称为一种通用的 推理扩展方法（inference scaling method）：你可以用增加首遍采样数量的方式“扩算力”，也可以用调整轨迹序列化方式的方式“扩状态表达”。论文在最后也给出了几个更进一步的扩展方向。一个是挑选或压缩轨迹：不是所有轨迹都同样有用，可以对多条轨迹做质量筛选，或用摘要模型把长轨迹压缩成更浓缩的状态文本。另一个是学习更好的文本状态接口：既然 T 的格式目前只是“固定分隔符+原文顺序”，那能不能训练一个小模型专门生成适合放在正文前的状态描述？更激进的设想是把“反馈接口”直接融入训练：让模型学会在首个 pass 中写出对第二个 pass 最有帮助的状态文本，同时保留 pass 内部的因果处理。这个方向一旦跑通，就不只是在已有模型上打补丁，而是从训练阶段就让模型意识到“我的草稿会被下一次阅读看到”。用一句不太严谨但容易记的话总结：长上下文推理的困难，有时不在“读不完”，而在“读的时候不知道重点”。 TRACE AS STATE 用推理轨迹把重点前置，等于给模型的第二遍阅读配了一张自己画的地图。
局限与展望：推理反馈的下一步在哪里
任何方法都有代价，TRACE AS STATE 的代价首先体现在推理开销上。它至少需要一次首遍推理和一次带着轨迹的第二遍推理。如果首遍还采样多条轨迹，token 消耗几乎是成倍增长。表 6 给出了各模型在主要实验里的供应商标记 token 用量，可以看到第二次 pass 会重新读入大量上下文。这里有个容易被忽略的细节：TRACE AS STATE 把 T 放在 x 前面，会改变长文本在提示中的前缀结构，因此第二遍很难直接复用第一遍长文部分的 KV cache；相比之下，TRACE APPEND 在缓存复用上更友好一些。因此，在延迟敏感或高频调用的场景里，直接套用 TRACE AS STATE 并不现实。它更适合一次性长文档问答、深度阅读辅助这类“多花一倍时间换显著准确率”的任务。另一个硬性前提是：模型必须暴露推理轨迹。当前实验里的 DeepSeek V4 Pro、GLM-5.2、Qwen 3.7 Max 都提供了可记录的推理内容，但很多 API 或产品只返回最终答案。论文也承认，如果只能拿到最终答案，就需要换一种状态接口，比如让模型先输出结构化摘要再重读，或者引入一个额外的“状态生成器”。评测覆盖也不够广泛。论文目前只测了三个模型、三种长文档任务族，没有覆盖多轮 Agent 交互、代码仓库理解、长视频上下文等更复杂的真实场景。此外，它把每条轨迹截断到前 50,000 个字符，虽然这是为了塞进上下文窗口的无奈之举，但也意味着后半段轨迹中的状态信息可能被直接丢弃，目前并没有量化这种截断带来的损失。实验使用的模型也都是厂商的预览版本或“Max”版本，API 背后的具体版本随时可能变化，这给第三方复现增加了难度。展望未来，最让人期待的方向是“把反馈接口训练进模型”。现在 TRACE AS STATE 像是一个外挂装置，用的是模型原本没想过会被重读的草稿。如果模型在训练时就知道自己的推理轨迹会被放在第二遍阅读前面，它完全可能学会生成更适合被重读的状态文本，甚至自动决定哪些中间变量值得写进轨迹。那样的话，状态代理就不再是“凑合能用”的近似，而是一个被显式优化的通信信道。结合当前各大厂商对推理模型和稀疏注意力的持续投入，这种跨 pass 反馈的推理范式还有相当大的探索空间。
龙迷三问
下面是龙哥对于大家可能的一些问题的解答：这篇论文到底在解决什么问题？清华与Z.ai提出TRACE AS STATE：将模型自己的推理轨迹作为状态代理，预先置于长上下文之前重新阅读。这篇工作最值得看的点是什么？TRACE AS STATE在27个模型-任务-指标组合中的26个上优于TRACE APPEND；在GraphWalks Parents任务上，DeepSeek V4 Pro的EM从29.2%(首轮)和43.0%(TRACE APPEND)提升至81.8%，GLM-5.2从66.4%和83.2%提升至100.0%这篇工作的边界或风险在哪里？优点：(1)理论分析清晰，通过条件状态更新任务形式化论证了条件位置对内存需求的指数级影响；(2)方法简单通用，无需修改模型架构或训练过程，适用于任何暴露推理轨迹的因果Transformer模型；(3)实验覆盖3个不同架构的模型和3个长上下文基准，验证了方法的泛化性；(4)消融实验设计全面，排除了多种替代解释。缺点：(1)需要额外推理次数，增加推理延迟和token成本；(2)依赖模型暴露原始推理轨迹，API只返回最终答案时无法使用；(3)轨迹截断到50K字符可能丢失重要信息；(4)未在交互式多轮Agent任务上验证。如果你还有哪些想要了解的，欢迎在评论区留言或者讨论~
龙哥点评
论文创新性分数：★★★★☆
提出TRACE AS STATE方法，将模型首轮生成的推理轨迹作为任务状态的文本代理，放置在长上下文之前进行二次因果前向处理，使任务状态在重新处理上下文时即可被利用。
实验合理度：★★★★☆
Exact Match(EM), Set F1, SequenceMatcher ratio, Accuracy
学术研究价值：★★★★☆
提出TRACE AS STATE方法，将模型首轮生成的推理轨迹作为任务状态的文本代理，放置在长上下文之前进行二次因果前向处理，使任务状态在重新处理上下文时即可被利用；更关键的是问题定义是否可复用到同类任务。
