欢迎关注公众号：爱学习的妮妮qiang
-
最近在研究长上下文大模型的时候，看到一篇很有意思的论文：《Trace as State: Reasoning Traces as Conditional States for Long-Context Transformers》，这篇论文研究的问题其实很简单：如果模型已经针对一个问题认真思考过一次，那么第二次再做这个问题时，能不能把第一次的"思考过程"利用起来？
-
作者并没有单纯让模型"再思考一次"，而是研究了一个非常细节的问题：同样一段 Reasoning Trace，放在上下文前面和后面，为什么效果会差这么多？
-
我自己也把这篇论文的实验跑了一遍，所以这次不单纯做论文介绍，而是结合论文实验和自己的复现，聊聊这个方法到底是什么、为什么有效，以及我觉得更值得讨论的一个问题：Trace as State 到底是在增强模型推理，还是把之前已经获得的答案信息重新利用了一遍？
1. 背景：长上下文越来越长，但"看到了"不等于"利用好了"
- 现在的大模型上下文窗口已经越来越大。 几十万 Token、百万 Token 的上下文，逐渐成为很多模型的基础能力。但实际使用过程中，一个非常明显的问题是：上下文越长，模型并不一定越容易完成复杂推理。
- 特别是在一些需要长距离信息检索、多步关系推理的任务中，模型经常会出现这样的情况：信息都在上下文里，但第一次推理没有找到正确的路径。
- 那么，一个很自然的思路就是：既然第一次已经思考过了，为什么不把第一次的思考结果保留下来，再让模型重新做一遍？。 于是就有了第二次推理。
- 但这里马上又出现一个问题：第一次生成的 Trace，到底应该放在哪里？ 传统方式可以理解为：
原始上下文 → Trace → 问题，而 Trace as State 使用的是：Trace → 原始上下文 → 问题，也就是把 Trace 从上下文后面移动到了前面。看起来只是调整了一下顺序，但实验结果却非常明显。
2. Trace as State：到底提出了什么？
- 理解这个方法，可以先把 Trace 简单理解成：模型第一次处理任务以后留下来的"任务状态"。 比如模型第一次面对一个复杂问题，可能已经完成了一些搜索和推理：找到了部分关键实体；排除了几种错误路径；形成了几个候选结论；记录了中间推理过程等。这些内容虽然不一定完全正确，但已经包含了大量和当前任务相关的信息。所以第二次推理的时候，与其让模型完全从零开始，不如把这段 Trace 当成一种"已有状态"。
- 论文比较的核心就是下面两个输入形式：
| 方法 | 输入形式 | 含义 |
|---|---|---|
| First Pass | [x,q] |
第一次直接回答 |
| Trace Append | [x,T,q] |
Trace 放在原始上下文之后 |
| Trace as State | [T,x,q] |
Trace 放在原始上下文之前 |
-
其中，
x是原始上下文，q是问题，T是之前生成的 Reasoning Trace。 -
所以这篇论文真正关注的并不是：多给模型一些 Token 有没有用？ 而是： 过去的推理结果，应该以什么方式进入下一轮推理？ 这其实已经开始从传统的 Prompt Engineering，走向一种更接近 Reasoning State Management 的思路。
3. 为什么 Trace 放到前面？
- 假设我们面对一个非常长的上下文。第一次推理结束后，模型已经形成了一段 Trace。如果采用：
[x,T,q]，那么模型首先需要重新处理完整的上下文，最后才能看到自己之前产生的 Trace。而如果采用：[T,x,q]，模型一开始就能看到之前的推理结果。这意味着 Trace 在第二次推理中不再只是"附加信息"，而更像是：告诉模型当前这个任务已经思考到了什么阶段。 - 可以把两种方式简单理解成：
| 方式 | 更像什么 |
|---|---|
| Trace Append | 事后补充一段之前的思考 |
| Trace as State | 带着之前的思考状态重新进入任务 |
- 这也是作者为什么使用 State 这个词。当然，这里有一个很重要的细节：Trace 并不是某种神秘的内部神经状态。 它本质上还是一段文本，只不过作者把这段文本当成了当前任务的一种"外显状态"。
4. 实验设计与结果：这个想法到底有没有效果？
- 论文主要在三个任务上进行了验证，同时测试了 Qwen 3.7 Max、DeepSeek V4 Pro Preview、GLM-5.2 等模型。
| 数据集 | 主要任务 | 指标 |
|---|---|---|
| GraphWalks | 长上下文关系推理 | EM、F1 |
| MRCRv2 8-needle | 长上下文信息检索 | EM、SequenceMatcher |
| NUB-1M | 百万级上下文任务 | Accuracy |
- 作者还专门设计了一系列控制实验，用来区分：到底是 Trace 本身有效，还是只是因为"上下文变长了"？ 其中几个实验非常关键。
Random Trace
- 把真实 Trace 换成无关 Trace。 如果只是在前面放一段文本就能提升效果，那么 Random Trace 也应该有效。 但实验结果并不是这样。 这说明提升主要来自： Trace 中携带的任务相关信息。
Trace Only
- 只给模型 Trace 和问题，不再提供原始上下文。 这个实验说明了一件事： Trace 本身确实保存了大量和答案有关的信息，但它又不能完全替代原始上下文。 所以 Trace 更接近一种：压缩后的任务状态。
Oracle@5
- 第一次让模型生成 5 个结果，然后直接选择其中最好的一个。 这个实验用来回答：Trace as State 是不是只是在"挑一个之前已经做对的答案"？ 如果只是这样，那么它的表现应该不会明显超过 Oracle@5。 但论文实验显示，Trace as State 仍然可以超过 Oracle@5。所以作者据此认为： Trace as State 不只是简单利用某一次正确答案，还可能让第二次推理重新获得修正和推理的机会。
最直观的结果：GraphWalks
- 论文统计了 27 个模型、任务、指标组合。其中 26 个组合中 Trace as State 优于 Trace Append，只有 GraphWalks BFS 的 F1 出现了约 0.8 个点的反向结果。
- 所以从实验现象来看：Trace 放在前面，并不是简单的格式变化，而确实可能影响第二轮推理的效果。
5. 论文复现
- 这次我也按照论文的核心逻辑做了复现。采用MiniMax-M3模型，跑了GraphWalks的Parents中的150条数据。结论和论文结论一致。
| 条件 | 输入形式 | 目的 | EM | Precision | Recall | F1 |
|---|---|---|---|---|---|---|
| First Pass | [x,q] |
基线 | 0.3067 | 0.5353 | 0.4242 | 0.5405 |
| Trace Append | [x,T,q] |
Trace 放后面 | 0.4760 | 0.6584 | 0.5713 | 0.6855 |
| Trace as State | [T,x,q] |
Trace 放前面 | 0.7393 | 0.7433 | 0.7145 | 0.8249 |
- 源码和跑的结果数据也同步放在github，喜欢自取：https://github.com/mengrennwpu/trace-as-state
6. 一个值得讨论的问题：这到底算推理增强，还是答案信息注入？
- 这是我看完论文以后比较在意的问题。因为我们仔细想一下：Trace 本身，很可能已经包含了答案信息。 举个非常简单的例子。第一次推理过程中，模型可能已经写出了：通过节点 A、B、C 的关系，可以判断最终答案应该是......，那么第二轮再把这段 Trace 放进去，本质上就已经不是："一个不知道答案的模型重新做一次题。" 而是："一个已经获得部分答案线索的模型，再做一次题。" 所以从严格意义上来说，Trace as State 并没有证明：模型自身的基础推理能力突然提升了。 它证明的是另外一件事情：模型可以通过额外的 inference-time computation 产生一个中间状态，并在下一轮推理中继续利用这个状态。
- 我觉得这是两个不同的概念。可以把它理解成：第一次推理：生成任务状态 → 第二次推理：利用任务状态继续求解。 因此，这种方法更适合描述成：Inference-Time Scaling + Reasoning State Reuse
7. 这篇论文真正说明了什么？
- 如果只看论文标题，很容易把它理解成一个"Trace 摆放位置优化"。但我觉得它真正有价值的地方，要比"位置优化"更大一点。以前我们通常把模型推理理解成：输入 → 推理 → 输出。推理结束以后，过程就结束了。
- 而 Trace as State 提供了一种完全不同的思路： 推理过程本身也可以成为下一轮推理的输入状态。 于是就可以形成一种新的工作模式： Reasoning → State → New Reasoning → Updated State。
- 这个思路其实很容易进一步扩展到 Agent。 未来一个复杂 Agent 任务，很可能不再只是简单地：Prompt → Answer ，而是：Agent → Task State → Context → Reasoning → Updated State ，这样一来，Trace 就不再只是一次推理产生的"副产品"，而有可能变成： 连接长上下文、多轮推理和 Agent 执行过程的中间状态。
- 当然，这条路还有几个明显的问题：第一是成本。 多做几轮推理，就意味着更多 Token、更高延迟和更高推理成本。 第二是状态压缩。如果 Trace 越积越长，那么最终又会重新遇到长上下文问题，所以未来还需要研究：如何把大量 Reasoning Trace 压缩成高质量 State。 第三是状态质量。第一次推理本身可能就是错的。如果第二次推理盲目继承错误状态，就可能形成：错误状态 → 错误推理 → 更强的错误状态。 所以未来一个很重要的研究方向，很可能不是："怎么保存 Trace？"而是：> "怎么判断、压缩、更新和纠正 Trace State？"
8. 总结
-
一句话足矣~
-
本文针对 Trace as State 进行了论文研读与代码复现，核心就一件事：把推理轨迹当作任务状态的文本代理，放到长上下文之前，让模型"带着状态重读"------不改模型、不微调，仅仅调换顺序，就能在长上下文推理上拿到接近换模型的收益。
-
要真正落地，卡点不在方法而在接口 ------你的模型愿不愿意把 reasoning trace 交出来。另外，这个"顺序很重要"的洞察，其实可以迁移到更多地方：RAG 里把查询意图放在文档之前、Agent 里把历史决策摘要放在新观测之前，本质上都是同一件事------先给状态，再给信息。
9. 参考
- Trace as State 论文地址: https://arxiv.org/abs/2609.02702
- 本文复现代码: https://github.com/mengrennwpu/trace-as-state
- alphaxiv 讨论页: https://alphaxiv.org/abs/2609.02702