AI写报告漏数字：KAIST研究称51.1%扣分源于抽取失败

让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不用额外做任何事，也不会因为疏忽而漏记。这么一分工，就避开了“记录本身也会被遗忘”的死循环。

###

有个技术细节值得一说。终端命令并不会明明白白告诉你，某个文件是被“读”了还是只被“列”了出来。比如跑一条搜索命令，可能把某个文件的内容打印出来，同时又列出同目录下另外一百个文件的名字。

RunningTab的做法是看返回结果：某个文件的具体内容若出现在输出里，就视为“读过”，记进读取日志；若只有文件路径露面，则算“候选”，等AI以后去翻开。候选项有时一下冒出几百个，真正有用的往往没几个，所以系统用BM25算法按与任务的关联度给它们打分排序。

BM25*：一种经典的信息检索算法，依据关键词在文本中出现的频率和稀有程度，为文档与查询之间的相关性打分，分数越高说明越可能相关。

###

记录下来还不够，更关键的是让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思路），还有一种是两者结合。

结果相当一致：无论哪个benchmark、哪项指标、哪种模型组合，RunningTab都是最好的。

以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，它能找回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最后一次机会。

###

还有一组数据很直观。团队按AI实际读取的文本量把Workspace-Bench的任务分成低、中、高三档，再看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见过的数值中，差不多每5个就有1个最后没被写进报告。

Q3：让AI自己列清单管理任务进度管用吗？

A：效果很有限，有些时候甚至还不如不做管理。问题出在AI自己列的清单同样存放在对话记忆里，后面进来的内容照样会把它挤走。管用的办法是把记录放到AI对话记忆之外，让环境系统自己去维护，RunningTab的核心设计走的正是这条路。