图找到了，报告里却没放：agent 的需求遗忘有治了

coding agent 有种失败特别气人：过程全对，交付缺角。图表明明提取了，最终报告里偏偏没有；需求里写了三条，交上来只剩两条。KAIST 团队 10 月 7 日放榜的 RunningTab（arXiv 2610.10444，作者 Jinheon Baek、Sung Ju Hwang 等）给这类需求遗忘下了诊断：病根在直接工作区交互（DWI）这种流行工作方式本身。

病症：悄然遗失

直接工作区交互指 agent 不建索引、直接在终端里搜索和读文件，目前很多 agent 产品默认就这么干。问题在于任务要求只存在模型的上下文里：文件列出来却从未打开，这件事不留任何痕迹；翻了几十个文件后，早期读到的关键值被挤出注意力。等 agent 组装交付物时，需求清单已经残缺，而它自己毫无察觉。把记录维护交给模型内部的方案（让模型自己维护待办）也有同样软肋：记录和任务共用同一份上下文，一起被挤掉。

药方：清单放环境里

RunningTab 的做法是把任务清单搬到环境侧，由环境为每个任务维护一张随动的表。流程五步：agent 先注册交付物需要满足的需求；环境把每次文件读取记成带出处的摘录，把列而未开的文件记为候选；每条需求旁边自动摆上最佳匹配的摘录与头号未开候选；agent 逐条对着内容闭合，暂时解决不了就挂起并注明理由；最后有完工检查兜底，agent 想交差时，仍未闭合的需求会被全数翻出来。设计的妙处在责任分离：环境负责记，模型负责判断，清单物理上不受上下文挤压，模型想忘也忘不掉，而挂起必须给理由，遗忘从静默漏洞变成显式决策。

效果与边界

在三个基准、三个模型上，RunningTab 一致超过朴素 DWI，也胜过把记录放在模型内部的基线，清单上通常能留住所需要的关键值。边界同样清楚：摘要未给具体分差，代码也没有随论文放出，工程化要等开源。对我们的读者，这条思路几乎可以立刻白嫖：给自己的 agent harness 加一张外部任务清单，读过的文件留摘录、列过的文件留候选、交差前跑一次对账，半小时的实现就能堵住最常见的一类交付缺陷。把它与前几天的 SWE-Game 对照着读更有意思：那边基准测出需求漏做是构建类任务的头号失败模式，这边就给出了对症的环境侧解法，研究与实践正在同一处会师。