长上下文不等于会记事：StateBench 四层状态追踪清单

2026 年 11 月 3 日，Ai2 发布 StateBench；同日，Hugging Face 的 allenai 组织博客刊出同一篇介绍——两处页面日期均为 11 月 3 日（采集元数据把 Ai2 记成 11-02，以页面为准），这是官方账号的同题发布，不是第三方转述。它值得现在关注，是因为大模型正在被用于读代码、跟踪任务和处理超长对话，但“能读进去多少文字”并不等于“能持续记住事情怎样变化”。StateBench 把这种容易被长上下文能力掩盖的能力拆成了四层。

下文把官方材料明确写出的内容称为“官方结论”；根据资料做出的比较和适用边界判断，会明确标为“我的判断”。文中的简化代码只是帮助理解评测逻辑的复现框架，不是官方实现。

真正测的不是记忆长度，而是状态链

StateBench 测的是长文档中的状态追踪：实体在文中不断变化后，模型能否回答出当前状态。官方给出的代码例子是变量赋值：先执行 x = 4，后来又执行 x = 2，模型应返回最后一次赋值；小说里的等价情况则是物品转交给另一人。

这与普通长上下文测试有本质区别。后者常把答案线索分散在全文中，模型只要找到相关段落再归纳即可；状态追踪要求模型按顺序执行一系列更新。官方用一个物品转交的例子说明难度差异：如果刀先由 Edward 放进 John 的背包，随后 John 又把背包里的物品交给 Mary，漏掉任何一步，最终归属都可能答错。

官方还特别指出，过去的测试往往集中于最难的状态追踪。随着 Gated DeltaNet 这类可携带运行记忆的递归或混合架构受到关注，研究者需要区分模型究竟能否处理“找到最新值”与“沿依赖链连续更新”这两类差异很大的任务。

因此，“上下文窗口足够长”不能单独证明模型适合处理长期状态。更有意义的问题是：它能处理哪一种更新方式，长度增加后又会在哪一层失效。

四层难度，相当于四种记事规则

StateBench 将任务分成四个层级。每一层都使用相同数量的变量、不同取值以及相同位置的赋值事件，区别只在赋值类型。这样设计，是为了尽量公平地比较模型，而不是让题目长度或信息量顺便成为干扰因素。

R-trivial 一词可以直白理解为“状态不变”：变量第一次被赋予什么值，后面就一直是什么值。Aperiodic 表示更新没有固定周期，只需认准最后一次变化。Soluble 更接近记分，每次得分都建立在当前总分上。General finite 则包含跨变量依赖，是官方所说最困难的一层。

官方用五个杯子的交换动作解释最后一类：球最初藏在某个杯下，之后杯子不断互换位置。要回答球在哪里，模型必须依次处理每次交换，而不能只寻找离问题最近的那个杯子描述。

这四层并非随意排列。官方说明，它们与 Krohn–Rhodes 理论有关：这是一门研究有限状态问题如何分解为基本原语的代数理论。普通用户不必先掌握数学定义，但需要记住一个实用判断——越往右，越不能靠“搜索最新一句”蒙对。

一个简化复现框架

如果要在自己的任务中复刻 StateBench 的思路，可以先不比较模型，而把每条更新规范化。下面这段伪代码不是官方代码，而是依据官方给出的四类赋值规则整理出的最小框架：

state = initialize()

for event in document:
    if event.type == "immutable":
        state[event.variable] = event.value

    elif event.type == "reassign":
        state[event.variable] = event.value

    elif event.type == "self_referential":
        state[event.variable] = (
            state[event.variable] + event.value
        )

    elif event.type == "assign_by_reference":
        state[event.variable] = state[event.source]

answer = state[question.variable]

真正困难的不是这四行逻辑，而是把长文档中的事件正确地识别、排序，并区分初始状态与后续更新。若评测程序先替模型完成了更新，最终答案自然容易得到；StateBench 的关键恰恰在于这些中间步骤需要模型自行完成。

官方介绍还提供了一个便于构造题目的思路：先生成一段通用的有限状态赋值序列，再从同一序列导出另外三种较容易版本。这样，四种题目在变量数量、取值数量和赋值位置上保持一致。

架构差异，不等于实际任务可靠

官方材料给出的结论包含两个层次。理论上，Transformer 在 R-trivial 上可以较为稳定地工作，在 Soluble 与 Aperiodic 上也能处理到一定程度，但预计难以应对 General finite 问题；相比之下，拥有更灵活记忆更新的 Gated DeltaNet，原则上可以处理四层。

实际训练结果则更具体。官方称，递归和混合模型在直接针对这些任务训练后，能够泛化到远得多的位置；但包括 Gemini 3.8 Flash、Claude Opus 5.5，以及 GPT-6 Sol 和 Luna 在内的前沿模型，在输入继续变长后，仍会在困难状态追踪形式上失效。

这里需要避免一个误读：这是官方基准中的结果，不是对所有真实应用的判决。StateBench 使用人工构造的赋值事件，考察的是受控状态更新；真实项目中的状态还可能来自多个文件、工具调用、权限变化和相互矛盾的信息。因而，这是我的边界推导：基准分数更适合用来选择专项评测或定向训练模型，不能直接替代代码执行、数据库查询和业务规则校验。

同名基准不是一回事

检索 StateBench 时，还会遇到 Parslee 项目的 StateBench 数据集说明及其 GitHub 仓库。它同样使用 StateBench 这个名称，但研究对象不同：后者关注多轮会话中的状态正确性，例如旧地址被新地址替换后，模型是否仍引用旧信息。

Parslee 的说明列出了多种错误，例如引用已经失效的事实、越过信息边界，以及没有真正应用用户此前的更正。这与 Ai2 的 StateBench 有交叉，却不是同一套任务。两者可以互补：Ai2 更像“模型能否执行赋值链”的能力测试，Parslee 更接近“真实会话状态管理是否可靠”的应用测试。

跨源对比后的结论是：名字相似不等于评测口径相同。如果团队选择 StateBench 做模型验收，应先确认指的是 Ai2 的长文档四级基准，还是 Parslee 的多轮状态数据集。前者适合比较架构与训练方法，后者更适合发现客服、订单和工作流中的状态污染问题。混用名称和结论，会让模型选型建立在错误前提上。

用四层清单设计自己的验收

对普通 AI 技术用户，最实用的做法不是先猜哪款模型“最强”，而是拿真实任务做一张四层验收表。先准备一组容易发现旧状态的样本，再准备一组必须累计变化的样本，最后加入涉及对象引用和交换的样本。

验收时至少记录三个信号：模型能否指出当前状态、能否解释最近一次有效更新、能否在中间步骤缺失时承认无法确定。只有最终答案正确而过程已经错乱，在长任务中仍值得警惕，因为后续问题可能把错误继续放大。

官方完整介绍可见 Hugging Face 上的 StateBench 文章，Ai2 的发布页则提供了同一研究的入口：StateBench: Testing how language models track state changes over long documents。Hugging Face 的 数据集页面也可用于查找后续发布的数据版本。

StateBench 真正带来的提醒不是“长上下文又落后了”，而是长上下文能力至少要拆成三层看：能否容纳信息、能否找到相关片段、能否连续执行状态变化。只有第三层可靠，模型才真正具备处理长期任务的基础。