你有没有遇到过这种事：让AI助手帮你从一堆文件里整理一份报告，结果它明明打开了那份年度报告，你亲眼看着它在屏幕上读出了那个关键数字，可最后交出来的报告里,这个数字却不见了。
这不是幻觉问题,AI没有编造任何东西。它只是读过了,然后忘了。
这听起来有点离谱,但KAIST团队在2026年的一篇论文里,用数据把这件事讲得很清楚。他们找了GPT-5.4 nano这个模型,在一个叫Workspace-Bench的测试集上跑了三轮,专门盯着那些AI读到了但报告里没写的数字。结果是：在所有AI生成报告失败的原因里，有51.1%的扣分点来自"抽取失败",也就是文件找对了，但内容没进报告。而这51.1%里面，有将近四分之一（12.3%）是最让人意外的情况：内容明明出现在AI的观察记录里，报告里却彻底没有。
再换一个角度看这个数字：在所有交付了报告的尝试里,有891个具体数值是评分标准要求出现的,其中AI确实"看到"了这些数值,但有19.8%,差不多每五个里有一个,最终没有写进最终的报告。
**这意味着问题不在于AI找不到文件，而在于它没有一个机制记住自己找到过什么。**
### 问题出在上下文窗口这个"短期记忆"上
要理解这件事,得先搞清楚现在的AI智能体是怎么干活的。
大语言模型智能体*：指能够自主使用工具（比如读文件、执行命令）来完成任务的AI系统，不是简单问答,而是能在多个步骤里连续操作的程序。
这类智能体现在流行一种叫"直接语料交互"的工作方式。
直接语料交互（DCI）*：指AI不依赖预先建好的索引或检索系统，而是直接在终端里用ls、grep、cat这类命令操作原始文件，想读哪个读哪个，不需要提前整理。
这个设计思路本身很合理。传统的检索增强生成需要先把所有文件切片、建索引、放进向量数据库，这个过程本身就会丢信息，而且一旦文件更新，索引也得跟着重建。直接让AI拿着终端工具去翻文件夹,反而更灵活,什么格式的文件都能碰,不需要预处理。
但当任务从"回答一个问题"变成"写一份完整的报告"时，新的麻烦就来了。论文把这种新场景定义为"直接工作区交互"。
直接工作区交互（DWI）*：指AI在一个真实的工作区（比如公司共享盘里堆积多年的报告、表格、笔记）里，通过直接访问文件的方式，经过很多轮操作，最终产出一份综合性的交付物，比如总结报告或数据表格。
区别在哪？回答一个问题,通常几段话就能支撑答案,找到了就能用。但写一份报告，往往要翻几十个文件，跑几十上百个回合，最后才动笔。这中间拖得越久，前面读到的东西就越容易被挤出AI的"脑子"。
这个"脑子"就是上下文窗口,也就是AI在当前对话里能同时看到的所有文字内容。它是有容量上限的。随着AI不断执行新的命令、读新的文件，早期的观察记录会被截断、被清空、被新内容顶替掉。论文里举的例子特别形象：AI在第4轮读到了员工人数是128人,但到了第40轮才要写报告时,这个数字早就从它的"视野"里消失了,它甚至不会意识到自己曾经知道这件事。
这就好比你去超市买十样东西，没有写购物清单，全靠脑子记。走到第三个货架的时候，你可能已经忘了第一个货架前你决定不买的那瓶酱油是因为还有半瓶在家，还是因为嫌贵。如果不写清单，你最后结账的时候，大概率会漏掉几样东西，而且你甚至不知道自己漏了,因为那段记忆已经被购物过程中产生的新信息覆盖掉了。而AI面对的情况比这更极端，它要"逛"的不是十个货架，而是几百个文件，跑的不是十分钟，而是几十上百轮操作。
### RunningTab：给AI配一个环境端的记账本
搞清楚问题出在哪之后,解决思路其实挺直接：既然AI自己记不住，那就让环境帮它记。
这就是论文提出的RunningTab框架的核心思想。
环境侧标签（Environment-Side Tab）*：指一个由"环境"（也就是运行AI智能体的那套程序，负责执行命令、返回结果）而不是AI模型自己维护的、独立于上下文窗口之外的记录本，专门用来追踪一个任务还欠着什么。
关键的设计选择在于：这个记录本不是AI自己写日记，而是由外部系统帮它记。
为什么这个区别很重要？因为如果让AI自己在对话里写"我已经读过annual.pdf了，专利数是3"，这条记录本身也会被塞进上下文窗口，也一样会被挤掉。真正解决问题的办法是把记录存在上下文窗口之外，这样它就不会因为对话变长而消失。
这个标签由三部分组成，分工很清楚。
第一部分叫需求（Requirements）。
需求*：指任务要求的每一个具体事项，比如一个数字、一张图、报告里的一个章节，这部分内容需要AI自己在开始工作前先列出来，因为只有AI能理解任务到底要什么。
第二部分叫读取日志（Read Log）。
读取日志*：指环境自动记录的、AI每次打开或读取一个文件后留下的原文片段，连同这个片段的来源信息（文件路径和执行的命令）一起存起来，这部分完全不需要AI动手，环境自己就能观察到。
第三部分叫候选项（Candidates）。
候选项*：指那些AI在执行列目录、搜索之类命令时看到了文件名，但还没有打开看过内容的文件，环境会把它们记下来，按照和任务的相关程度排序，等AI打开了就从候选列表里移除。
这三块东西拼起来，就是一份完整的任务状态快照：要交付什么、已经读到了什么、还有哪些地方没去看过。
这里有个设计上挺巧妙的地方：需求部分必须靠AI自己写，因为任务要什么只有AI理解任务描述后才知道;但读取日志和候选项完全由环境自动捕获,不需要AI额外做任何事,也不会因为AI疏忽而漏记。这种分工避免了"记录本身也会被遗忘"这个死循环。
### 怎么分辨一个文件是"读过"还是"只是看到名字"
这里有个技术细节挺有意思。终端命令本身并不会明确告诉你一个文件是被"读"了还是只是"列"出来了。比如运行一个搜索命令,可能会把一个文件的内容打印出来,同时又列出了同目录下另外一百个文件的名字。
RunningTab的处理方式是看返回结果：如果某个文件的具体内容出现在了输出里，就算作"读过"，记进读取日志;如果只是文件路径出现了，就算"候选"，等着AI以后去翻开。因为候选项可能一下子冒出几百个,但真正有用的往往就那么几个,所以系统用BM25算法给候选项按照和任务的关联度打分排序。
BM25*：一种经典的信息检索算法，根据关键词在文本中的出现频率和稀有程度，给文档和查询之间的相关性打分，分数越高说明越可能相关。
### 写报告前，AI要先"对账"
光有记录还不够，更关键的是怎么让AI在动笔之前用好这些记录。RunningTab设计了三道关卡。
第一道叫审查。当AI调用list命令查看自己还有哪些需求没搞定时，系统会把每一条未完成的需求和最匹配的读取日志条目、最相关的未读文件并排显示出来。这就相当于有人在你交报告之前拍拍你肩膀说"你说要写营收数据，我这儿有一条记录看起来很像，你要不要核对一下"。
第二道叫证据校验。AI要把一条需求标记为"完成"，必须引用读取日志里的具体条目作为依据，系统还会检查这个引用和需求描述之间是不是真的有关联，如果引用的内容和需求完全对不上号，系统会拒绝这次标记。
第三道叫终局检查。
终局检查（Finish Check）*：指AI尝试结束任务、准备交付成果的那一刻，系统会拦一下，把还没处理完的需求和列出但没打开的文件清单再报一遍给AI，相当于交卷前的最后一次提醒。
这三道关卡加起来，很像你交税表之前会计师做的最后复核：这里有一笔收入你提到过但没填进表格，那边有张发票你扫描了但没算进成本。不是会计师帮你重新算一遍账，而是他对照着原始凭证，提醒你哪里对不上。如果没有这道复核，很多小遗漏会一路带到最终提交的文件里，而且往往是提交之后才会被发现。
### 测试结果：三个模型，三个基准，全面胜出
光讲道理不够，得看实际效果。研究团队在三个基准测试上做了验证，分别是模拟五种职业工作场景的Workspace-Bench、模拟软件公司真实任务的TheAgentCompany，还有基于近百年美国财政部公报的问答测试OfficeQA Pro。用了三个不同的大模型：GPT-5.4 nano、DeepSeek V4 Flash、Gemini 3.8 Flash。
对照组除了最朴素的DCI（完全不管理状态），还包括三种"让AI自己记"的方案：一种是让AI开头先列TODO清单，一种是让AI在交付前自己回头检查一遍（类似Self-Refine思路），还有一种是两者结合。
结果相当一致：RunningTab在所有benchmark、所有指标、所有模型组合上都是最好的。
拿Gemini 3.8 Flash在Workspace-Bench上的表现来说，纯DCI的任务完成率（TCR@70）只有23.33%，RunningTab直接拉到36.33%，提升超过13个百分点。更有意思的是，那些让AI自己维护TODO清单的方案，有时候反而比什么都不做还差，Gemini用TODO方式时完成率只有22.33%，比纯DCI还低。
**这说明问题不是"要不要提醒AI记事情"，而是"谁来负责记"。**
让模型自己在对话里写清单，清单本身照样会被挤出上下文窗口，等于没写。真正有效的是把记录挪到AI视野之外、挤不掉的地方。
### 标签里到底装了多少东西
研究团队进一步扒了Workspace-Bench上标签的具体内容。平均每个任务，标签里会积累4到5条需求，6到18条读取日志（覆盖5到11个不同文件，存下1.2万到4万个字符的原文片段），还有147到294个列出但没打开的文件。
更关键的数据是：当AI调用审查功能时，有69.9%到88.0%的未完成需求，身边正好摆着一条内容匹配的读取日志条目。
**这意味着多数情况下，答案其实早就被AI看到过了，只是没被用上，标签把它重新"捞"了回来。**
研究团队还做了个挺扎实的验证：针对那些AI看到了但报告里缺失的数值，检查这些值是不是真的被存进了读取日志。结果94.8%都在。接着又测试了一下这些存下来的内容实际有没有用：把需求里的数值遮起来，只给AI审查环节推荐的那几条匹配记录，AI能找回45.8%的答案；如果把整个读取日志（包含所有读过的内容）都给它，能找回78.1%。而完全不给任何标签信息，只能找回8.4%。
这组数字挺说明问题的。审查功能用一小部分文本（匹配的几条记录）就找回了完整日志将近六成的信息量，说明这个"排序+展示"的设计确实是把干活效率提上去了，不是简单地把所有东西一股脑塞给AI。
### 不同模型用标签的习惯不一样
有个挺有意思的观察：三个模型虽然都用了RunningTab，但用的方式各有偏好。
Gemini 3.8 Flash特别依赖审查功能，几乎每次都会在终局检查之前主动调用list查看需求状态，76.9%的"完成"标记都是靠审查推荐的条目直接引用的。GPT-5.4 nano反而更依赖最后那道终局检查，很多时候是被系统提醒了才回头去补内容，提醒之后有72.6%的情况会再次操作标签，17.1%会真的修改交付内容。DeepSeek V4 Flash则更喜欢靠候选项主动探索，它读的文件数量中位数达到11个，是三个模型里最多的，有54.7%的情况会主动打开一个此前被标记为"未读"的候选文件。
这种差异挺自然的,不同模型的"工作习惯"本来就不一样,但三种习惯殊途同归，都借助了标签给出的信息，没有一个模型是靠自己硬扛记忆压力完成任务的。
### 拆掉标签的一个零件会怎样
为了搞清楚标签里哪个部分最重要，研究团队做了消融实验，一次拿掉一个组件看效果掉多少。
结果最能说明问题：拿掉"环境自动捕获"这个功能（也就是不让环境自动记读取日志和候选项），任务完成率直接掉回和纯DCI差不多的水平（41.36对41.63）。这说明标签带来的收益，大头就来自环境自动帮AI记住了读过什么、列过什么，而不是别的什么锦上添花的设计。
其次是拿掉审查功能，掉分也很明显，说明光存着记录还不够，必须让AI能方便地把需求和已读内容对照着看。证据校验和终局检查的影响相对小一些，但也各自起作用，分别负责保证"完成"标记真实可靠，以及在交付前给AI最后一次机会。
### 读得越多，标签越值钱
还有一组数据挺直观。研究团队把Workspace-Bench的任务按照AI实际读取的文本量分成三档，低、中、高，然后看RunningTab相对纯DCI的提升幅度。
结果是提升幅度基本随着阅读量增加而增加。以DeepSeek V4 Flash为例，低阅读量任务上提升3.5分，高阅读量任务上提升到9.7分，接近翻倍。Gemini 3.8 Flash的差距更明显，从10.4分提升到18.4分。
**这个趋势背后的逻辑其实很直白：任务越复杂，需要翻的文件越多，AI要记住的东西就越多，上下文窗口被挤爆的风险也就越大，这时候一个外部记录本的价值自然就水涨船高。**
反过来看，纯DCI在阅读量最大的那一档任务上表现最差，完成率掉了16到27个百分点不等。这恰好印证了前面那个购物清单的比方：货架逛得越多，不写清单的代价就越大。
### 写在后面
读完这篇论文,最触动我的其实不是RunningTab这个框架本身有多精巧,而是它揭示的那个很容易被忽视的事实：我们一直在给AI加更大的上下文窗口,试图用"记忆容量"去解决"记不住"的问题,但这篇论文用扎实的数据证明,问题可能根本不在容量,而在于谁来负责维护这份记忆。
一个很朴素的细节让我印象很深：论文里统计发现,AI在整个任务过程中,真正需要自己主动写进标签的东西只有两类,开头列的需求清单,和结尾的"完成/无法完成"判定。中间所有的读取记录、文件候选列表、状态提醒,全都是环境自动完成的。这意味着给AI减负的关键思路不是让它更聪明地记事,而是从一开始就不要指望它记事,把这件事交给不会遗忘、不会被挤占的外部系统。
这让我想到一个更大的问题：现在很多"智能体记忆"方面的研究，默认的假设是让模型自己学会管理记忆，写反思、写笔记、做总结。但如果连记录这件事本身都要靠一个会遗忘的大脑去完成，那记忆系统的可靠性天花板，可能从一开始就被锁死了。谁来记，有时候比记多少更重要。
Q&A
Q1：RunningTab是什么？
A：RunningTab是KAIST团队提出的一个AI智能体框架，核心是给处理工作区任务的AI配一个独立于对话记忆之外的"环境端标签"，由环境自动记录AI读过的文件内容和列出但未读的文件，帮助AI不遗漏任务要求的信息。
Q2：为什么AI写报告总会漏掉已经读到的内容？
A：因为AI的对话记忆（上下文窗口）容量有限，任务跑的轮次一多，早期读到的内容就会被新的操作记录挤掉。论文测试发现，AI看到过的数值里，大约每五个就有一个最终没写进报告。
Q3：让AI自己列清单管理任务进度管用吗？
A：效果有限，甚至有时比不管理还差。因为AI自己写的清单依然存在对话记忆里，同样会被后续内容挤掉。真正有效的做法是把记录放在AI对话记忆之外，由环境系统自动维护，这正是RunningTab的核心设计。
