跑长任务的 agent 干着干着突然把一个早就删掉的函数当存在用，这种事见过吧。多数人归因于“记忆不行”，说到底是 context window 太小。这篇拆完你会发现，机制上更接近根因的其实是另一件事：它没有失忆，它只是拿到了一份自己脑补出来的文件系统快照。
先往下拆一层。自回归模型在“读文件”这一步做的事情，本质上不是读取，是预测“读取会得到什么”——它跟人最不一样的地方就在这儿。人走到桌边，桌面上有什么就是有什么，物理世界会强制校正你的认知。agent 没有“走到桌边”这个动作，它对工作区的全部了解，来自被塞进 context window 的那些描述、摘要和转述。而这些描述，是上一轮循环里模型自己生成的输出。第一轮读的是真文件，第二轮读的是模型对真文件的总结，第三轮读的是模型对总结的总结，文件内容被转手好几道，上下文里剩下的只是一份越来越模糊的二手快照。
有个团队把这件事正式研究了一下。8 月 18 号挂在 arXiv 上的一篇论文，标题叫《StagedWorkspace: A Versioned Workspace for Knowledge-Work Agents》，它把这个问题描述得更精确：知识工作智能体在搜索、编辑、审查、提交工件的时候，面前其实同时摆着同一个工件的多个版本——最初的草稿、改了一半的版本、上次审查留下的修改意见、当前准备提交的那一版。而 agent 没有任何机制知道，它下一眼看到的视图，对应的是这些版本里的哪一个。论文给这个要求起了个名字：工作区状态契约。每个视图，都必须明确关联到工作区状态的某一个版本。
说人话就是——你给 agent 看一张照片，照片底下得标注这是在哪个房间、哪个时间戳拍的。现在的 agent，照片底下什么也没有。它看到一张“当前文件”的照片，就默认这就是磁盘上此刻的文件，循环到下一轮，上下文变了、中间插入了别的操作，它依然默认那张照片是准的。没人告诉它：这张照片拍完已经过了十七步，现在的文件和照片里已经不是同一个东西了。
论文给的方案叫 StagedWorkspace，机制上不复杂：把解析后的结构化记录和审查时产生的 diff，都跟原生文件内容的哈希绑在一起。模型引用一条结构化记录时，哈希同时在场；哈希对不上，就说明磁盘上的文件已经不是生成这条记录时的那个版本了。等于给每一条进入上下文的信息贴了一张出生证明，上面写着“我来自哪个文件的哪个版本，签发于哪一轮循环”。
单看这个机制，像个工程补丁，不就是给文件加了个版本校验嘛。再往下想才发现它解决的东西比“防止读到旧版本”要深：它解决的是 agent 循环里状态漂移的问题。agent 每一轮都会把“目前发生了什么”重新塞回上下文，而这个“目前发生了什么”里全是模型自己的输出。输出堆输出，时间一长，上下文里满是模型自己生成的、从未被外部事实验证过的中间状态。哈希锚的本质是打断这个自我循环：每一轮和文件系统发生关系时，强制对一次表，对不上就告诉你这是旧的，别再基于它往下想了。模型看到的那份文件，从来不是它从磁盘里读出来的，是它猜出来的——哈希是在给这个“猜”字上锁。
还有个细节值得停下来看一眼：论文没说“不要用解析视图，直接用原始文件”。它说的是两个都要——解析视图让你读得快、信息密，原生字节访问让你知道读的东西还作不作数。固定框架的消融实验里，双解析/原生访问在所有测试模型上都拿到最高的点估计，跟受限的单一视图比，OfficeQA 的 Pass@1 提升了 8.3 到 12.1 个百分点。注意是点估计，论文自己也承认样本量不大。但结果方向是稳的，而且不意外：单看解析视图省 token 但失真，单看原生字节保真但读起来又笨又费窗口，两个都给的组合，在效率和准度之间找到了一个能用的平衡点。
最有力的证据还是那组对比：同样的模型，搭配上基于 StagedWorkspace 的 SW-AGENT，OfficeQA 上 Gemini 3.1 Pro 从 29.3% 涨到 63.9%，APEX 上 GPT-5.4 Nano 从 25.5% 涨到 42.1%。这组对比干净就干净在模型没换，变的只是工作区被暴露给 agent 的方式。以前大家热衷于调 prompt、换更强的模型，看完这个数字你会发现，把工作区的状态结构整理干净，带来的收益可能比换模型还大。这一层长期被当成“工具”问题——agent 怎么打开文件、怎么调 API——但它其实是性能上限的一部分。
还有一个实验，针对 57 个文件编辑任务做配对审查，diff 可见的时候观测得分更高。这个结论听起来像废话，能看到改动当然更好。但它背后有个不废话的含义：diff 可见能让模型在下一轮把“我上一轮改了什么”当作事实来用，而不是凭上下文里的模糊记忆猜测自己改过什么。你写代码之后应该也有这个习惯：review 别人的改动不看整个文件，只看 diff。diff 是“变动的记录”，它告诉你看哪里、动了什么，比读一遍当前状态更接近“这个文件是怎么变成现在这个样子的”。人脑和模型在这个点上其实非常同构。
写到这儿，有个底层的东西得挑明。哈希锚解决的是“读的时候知不知道版本对不对”，它没有解决“模型为什么读不到真实状态”这个结构性问题。自回归模型没有“从磁盘读取”的通道，它的所有通道都是预测——哪怕是原生字节访问，对模型来说也只是一堆被预测出来的 token。StagedWorkspace 做的事情，是拿哈希把“预测”的结果往回硬拽，拽得越紧误差越小，但它没法改变模型跟文件系统之间那个“转述”的媒介本质。类比到这儿就该收了，这不是它的缺陷，这是所有基于语言模型的 agent 共有的天花板。
所以这篇论文真正有野心的主张不在架构，在基准测试。它在结尾建议：以后的 benchmark 应该把证据、分阶段编辑和提交的工件视为显式的状态转换来评分，而不是只看最终答案。现在的评测几乎全是按最终产物打分，agent 中途把状态搞乱了几次、用错了几个版本的草稿，全都测不出来。如果基准只比最终答案，那 agent 是用哪个版本的草稿写出答案的，就完全不重要了——这等于放弃了测量“状态管理”这个真正决定长任务成败的能力。这就像考驾照只看你最后到没到终点，不管你中途闯了几个红灯。事实上这个问题比考驾照还严重，因为连考官都不在车上。
回到开头那个现象。一个 agent 跑着跑着“失忆”了，不是记忆容量不够，是它依赖的工作区状态漂移了，漂到了连它自己都不知道对应哪个版本的地方。StagedWorkspace 给的答案很朴素：让每个视图背一个状态的指纹，让整条循环始终知道“签过名的这份文件，现在到底变成什么样了”。
说到底，这事儿一句话就是：别急着给它换更大的窗口，先检查它手里那张照片是哪年拍的。把“视图必须绑定状态”这件笨事做扎实，可能比把 context window 继续做大更值钱。