RunningTab：面向直接工作区交互的环境侧任务账本 RunningTab: Direct Workspace Interaction with Environment-Side Tabs
为终端直连工作区的LLM智能体配备环境侧账本，让读过的内容撑到交付
前置知识
LLM 智能体
以 LLM 为核心、通过工具调用循环完成任务的系统：模型在每一轮发出工具调用（如 read 打开文件、bash 执行 shell 命令），接收观察结果后再决策，直到不再调用工具（称为 stop）而结束。本文的智能体配备终端工具，在工作区内自主搜索和阅读文件，最终把交付物写入输出目录。
RunningTab 的账本正是挂在“环境”（运行模型与工具调用的循环）上，理解智能体循环是理解环境如何捕获读写行为的前提。
上下文窗口与信息冲刷
LLM 单次能处理的 token 上限。智能体多轮工作中，观察流不断增长，系统会对旧观察做截断或清除（本文用 runtime context management level 3 截断观察并清理历史），导致早期读到的内容虽然确实进入了模型视野，却在后续轮次中被新观察挤出、不再可用。
论文的核心失效模式“看过却丢失”就是上下文冲刷的直接后果，环境侧账本的全部意义在于把任务状态存放在窗口之外。
直接语料交互（DCI）
区别于在预建索引上做向量检索（如 DPR、RAG），DCI 把原始语料直接交给智能体：它用终端工具列目录、grep 关键词、打开文档，无索引、无预处理地到达任意文件。本文将其推广为直接工作区交互（DWI）：目标是把散落多文件的素材组装成交付物，而非回答一个短问题。
RunningTab 不改变文件到达方式，完全继承 DCI 的终端访问范式，只在旁边加了一本账，理解 DCI 才能看清两者的正交关系。
BM25 词面相关性排序
经典的稀疏检索算法，基于词频、逆文档频率和文档长度归一化计算查询与文档的词面（lexical）匹配得分。本文用它对候选文件的路径与任务、读日志摘录与要求分别做相关性排序，从而在评审时把每条 open 要求和最匹配的摘录、最值得打开的候选并排展示。
评审（review）机制和候选排序全靠 BM25，账本从“被动存储”变成“主动指路”的关键组件，也是后续讨论其词面局限的基础。
评分细则评测
Workspace-Bench 把每个交付物拆成约 18.5 条评分细则（共 100 任务、1850 条），用 LLM judge 逐条判定是否满足，报告细则通过率和 TCR@70（≥70% 细则满足的任务占比）。这种逐条评测能精确暴露交付物里“缺了哪条事实”，而非只给一个笼统分数。
RunningTab 的全部指标建立在逐条评测之上，其失效归因分析（把失败细则标注为提取/发现/格式化等类型）也依赖这种细粒度反馈。
研究动机
知识型工作的本质是把工作区里已有的文件变成新的交付物：招聘汇总来自简历与面试记录，预算审查来自一年的月度表格，项目提案来自会议纪要和旧合同。LLM 智能体通过直接工作区交互（DWI）可以在终端里自由列出、搜索并打开任意文件，但“到达文件”只是任务的一半。作者用 GPT-5.4 nano 在 Workspace-Bench 的 100 个任务上跑了三轮纯 DCI，并请 LLM 标注器给每条失败的评分细则归因（与人工标注的 Cohen's kappa 达 0.83），结果发现：提取类失败占丢分的 51.1%，其中“看过却丢失”（内容确实出现在已打开文件的输出里，却没进交付物）占 12.3%，“丢弃或失真”占 38.9%；发现类失败（从未打开正确文件，含列出但没打开）另占 17.6%。更直观的数字是：在 891 个细则期望、且智能体确实在观察中看到过的数值里，约 19.8% 最终没出现在交付物中。根源在于任务状态完全寄生于上下文窗口——读过什么、任务还欠什么、哪些文件列了没看，都被后续观察冲走，不留任何痕迹。
本文的目标是本文的目标是让直接工作区交互配上一本不依赖模型自觉、也不会被上下文冲掉的任务账本。具体而言，为每个任务维护一个由环境（运行模型和工具调用的循环）而非模型自己保管的环境侧账本 RunningTab：智能体在任务开始时用 add 把任务拆成一条条要求（每条事实、图表或交付物元素一条）；环境则自动把每次读文件记录为一条摘录加锚点（文件路径与产生它的命令）的读日志条目，把每个“列出但未打开”的文件记为候选并按 BM25 相关性排序；智能体可随时评审每条未完成要求及其最佳匹配摘录与未读候选，用真实证据把要求结案为 done 或说明原因置为 unavailable；若它试图带着未完成要求收工，环境通过 finish check 把它们退回一次。量化目标是：在 Workspace-Bench、TheAgentCompany、OfficeQA Pro 三个基准上、以 GPT-5.4 nano、DeepSeek V4 Flash、Gemini 3.8 Flash 三个 LLM 实例化时，全面超越纯 DWI 以及由模型自己记账的 TODO、Self-Refine、Self-Tracking 基线。
与已有工作不同的是，已有工作的诊断集中在“够不着文件”：Xu 等把 TheAgentCompany 的失败部分归因于文档理解能力不足，Tang 等点名异构文件理解与数据溯源是瓶颈——这些疗法都针对搜索与阅读环节。作者的失效分析则揭示了被忽视的另一半：内容已被打开、已出现在观察里，却在交付时丢失（占丢分 51.1% 的提取类失败）。与智能体记忆研究的区别更为本质：无论是跨会话记忆、任务内计划与笔记、每轮重写的压缩状态，还是 Magentic-One 式由编排器 LLM 书写的进度记录，账本都由某个模型自己书写、自己标记完成，既会被上下文冲刷，也可能漏记或粉饰。RunningTab 第一次提出由环境侧记账：环境直接从观察流中捕获读与列（无需模型配合、不依赖文件格式解析），要求项只能针对真实摘录结案，账本存放在上下文窗口和工作区之外。据作者所知，此前没有任何工作记录“任务哪条要求由哪个文件满足”。
核心方法
直觉上这像餐厅的跑菜单：客人点了什么、上了哪些菜、还有哪些没点，都记在环境保管的一张单子上，而不是靠服务员的记性。形式化地，任务 $t$ 的账本为 $\mathcal{T}_t = (\mathcal{R}, \mathcal{L}, \mathcal{C})$：要求集 $\mathcal{R}$（任务要的每条事实或元素，初始为 open）、读日志 $\mathcal{L}$（每次读文件追加一条原样摘录加锚点）、候选集 $\mathcal{C} \subseteq \mathcal{W}$（列出但未打开的文件，按 BM25 排序）。账本存于上下文窗口与工作区之外。技术上分三段：任务中记账——智能体开头用 add 写要求，环境从每条观察自动区分“读过”与“仅列出”并记录，观察后附加状态行；过程中取用——经 add、resolve、list、show 四个操作访问；交付前清算——评审把每条 open 要求与最佳匹配摘录、未读候选并排展示，resolve 需通过词面证据检查，首次 stop 触发一次性 finish check。框架只改系统提示与环境循环，跨三个基准零调参。
核心创新是“由环境而非模型记账”这一所有权重分配。此前的任务状态记录——TODO 列表、Self-Refine 复查、Self-Tracking、Magentic-One 的进度记录——都由模型自己书写并自行标记完成，存在两个致命缺陷：记录本身占用上下文窗口，会被后续观察冲掉；写入靠模型自觉，可能漏记或粉饰完成。RunningTab 反其道而行：环境观察每一条工具输出，自动区分读（内容出现）与列（只有路径），把读原样存为摘录加锚点，把列出的文件收进候选池；模型唯一要主动做的只是开头写要求。这带来三个连带好处：其一，账本不被冲掉，早读的事实直到交付都可用；其二，摘录原样保存、零格式依赖，任何文件类型都能记账；其三，结案必须引用真实读到的证据——resolve 拒绝路径与摘录都和要求无词面重叠的 done，杜绝空口标记完成。消融证实环境自动捕获贡献最大：去掉后 Pass Rate 从 44.73 掉到 41.36，几乎退回 DCI 的 41.63；而模型自记账基线最高仅 42.93，证明收益不是提示词工程带来的。
方法步骤详情
第一步，声明要求：系统提示附加短块，要求智能体开局用 add 把任务拆成一条条要求（如“2024 年新增发明专利数”）写入 $\mathcal{R}$，状态 open。第二步，自动捕获：环境解析每条观察，文件内容出现即记为读，向 $\mathcal{L}$ 追加条目（摘录=模型所见原样，锚点=文件路径与命令）；只出现路径则记入候选 $\mathcal{C}$，打开后移除，候选按路径与任务的 BM25 排序。第三步，状态回报：因账本在上下文之外，环境在每条观察后附加状态行，报告未完成要求数、读日志与候选规模、距上次账本操作的轮数。第四步，评审：提示智能体探索后、结案前用 list 拉取评审，返回每条 open 要求并排其最佳匹配读日志条目与未打开候选（均按 BM25 对该要求排序），69.9%–88.0% 的 open 要求旁能配到含其词面的摘录。第五步，证据结案：resolve 为 done 必须引用读日志条目，其路径与摘录须与要求共享词面，否则拒绝；unavailable 须给出理由（如需智能体自行计算）。第六步，finish check：首次 stop 时返回未完成要求与未打开文件；图 3 示例中智能体据此引用 L2（headcount=128）结案 r2 并完整交付。
技术新颖性
新颖性有四层。第一，问题设定新：提出直接工作区交互（DWI）——在组织真实工作区上多轮工作并交付产物的设定，区别于以短答案为目标的直接语料交互（DCI），并率先量化“看过却丢”这一失效模式（12.3% 的丢分、19.8% 的已见数值缺失）。第二，记录所有权新：账本由环境从观察流中自动维护，是首个不由任何模型书写、不受上下文冲刷、又能锚定到具体文件证据的任务状态记录；与 Dr-DCI（把检索结果拉进本地工作区）、GrepSeek（训练紧凑智能体）、终端搜索与向量检索对比研究等改进“如何到达语料”的工作完全正交。第三，机制设计新：读日志原样保存观察（零格式依赖）；要求-证据链接由 BM25 评审自动建立，评审把账本两端（要求与摘录/候选）显式连接；词面证据检查让每个 done 有据可查。第四，交互协议新：add/resolve/list/show 四操作加状态行与一次性 finish check，构成最小且模型无关的接口——同一配置跨三个基准、三个 LLM 无需调参，且账本操作调用会从评测轨迹中剔除，保证公平比较。
实验结果
在三个基准、三个 LLM（GPT-5.4 nano、DeepSeek V4 Flash、Gemini 3.8 Flash）上，RunningTab 在全部基准×指标组合上均为最佳。Workspace-Bench 的 Rubric Pass Rate 从 DCI 的 41.63/53.28/31.42 升至 44.73/59.99/46.91（Gemini +15.49），TCR@70 从 20.67/38.67/23.33 升至 25.67/41.00/36.33；模型自记账基线最高仅 42.93/26.19/45.00。TheAgentCompany 的 Score 从 32.09/37.47/26.35 升至 39.12/43.11/32.93，Success 从 17.86/21.43/19.05 升至 23.81/29.76/22.62。OfficeQA Pro（697 份财政部公报约 8.9 万页）上 Acc@0% 从 53.53/65.71/43.08 升至 60.58/68.59/55.77，Acc@1% 从 65.38/74.68/45.64 升至 71.15/77.56/62.82。账本每任务中位 4–5 条要求（74.0%/77.7%/50.7% 以 done 结案）、6–18 条读日志（12.1K–40.2K 字符摘录）、147–294 个未打开候选。DCI 丢掉的“看过却缺”数值 94.8% 被读日志捕获；LLM 无账本仅恢复 8.4%，给评审恢复 45.8%，整本日志恢复 78.1%。消融：去环境捕获 -3.37（退回 DCI 水平），去评审 -2.86（TCR@70 -5.34），去证据/收尾检查各 -1.84。收益随阅读量增长：最重阅读三分位的增益约为最轻两倍，而 DCI 在重阅读任务上 Pass Rate 掉了 16–27 个点。
查看结构化数据
| 任务 | 指标 | 本文 | 基线 | 提升 |
|---|---|---|---|---|
| Workspace-Bench 工作区交付物生成（5 种职业角色模拟工作区，100 任务 / 1850 条评分细则） | Rubric Pass Rate（细则通过率） | RunningTab：GPT-5.4 nano 44.73，DeepSeek V4 Flash 59.99，Gemini 3.8 Flash 46.91（三轮平均） | DCI：41.63 / 53.28 / 31.42；TODO、Self-Refine、Self-Tracking 等模型自记账基线均更低 | +3.10 / +6.71 / +15.49 个百分点，三种 LLM 全部第一 |
| Workspace-Bench 任务完成率 | TCR@70（≥70% 细则满足的任务占比） | 25.67 / 41.00 / 36.33 | DCI：20.67 / 38.67 / 23.33 | +5.00 / +2.33 / +13.00 个百分点 |
| TheAgentCompany 软件公司任务（仅需文件服务的 88 个检查点子集） | Score 与 Success（任务全检查点通过率） | Score 39.12 / 43.11 / 32.93；Success 23.81 / 29.76 / 22.62 | DCI：Score 32.09 / 37.47 / 26.35；Success 17.86 / 21.43 / 19.05 | Score +7.03 / +5.64 / +6.58；Success +5.95 / +8.33 / +3.57 个百分点 |
| OfficeQA Pro 企业档案问答（697 份美国财政部公报、约 8.9 万页，104 题子集） | Acc@0% 与 Acc@1%（允许绝对相对误差 0% / 1% 的准确率） | Acc@0% 60.58 / 68.59 / 55.77；Acc@1% 71.15 / 77.56 / 62.82 | DCI：Acc@0% 53.53 / 65.71 / 43.08；Acc@1% 65.38 / 74.68 / 45.64 | Acc@0% +7.05 / +2.88 / +12.69 个百分点；Acc@1% +5.77 / +2.88 / +17.18 个百分点 |
局限与改进
作者承认并声明的局限：账本会保存读过的摘录，真实工作区中可能包含敏感内容，部署时需要与工作区同级的访问控制并人工审查交付物；评测仅覆盖三个公开基准。我自己的观察还有几点。其一，发现类失败只被部分缓解：候选只是被动记录，实际打开候选文件的比例仅 22.7%/54.7%/19.0%，DeepSeek 和 Gemini 在 finish check 之后才动账本的比例只有 8.7% 和 5.1%，账本的实际利用程度高度依赖模型的使用习惯。其二，证据检查是词面级的——只要要求的词面与摘录或路径有重叠即放行——既无法防止语义错配，也无法覆盖智能体自行计算的值，脚注 2 明确说明读日志只存文件内容、不含计算结果。其三，评审的恢复率有上限：45.8% 对整本日志的 78.1%，BM25 基于路径的候选排序在异构文件名下可能失效。其四，候选规模庞大（中位 147–294 个未打开文件），状态行与评审的 token 开销和延迟成本未报告。其五，finish check 只返回一次，若模型在检查后再次强行收尾便没有二次拦截；且评测子集刻意排除了需要外部服务或外部数据源的任务，在更复杂环境中的表现尚未验证。
独立分析的弱点
独立分析出四个弱点并给出改进方向。第一，词面证据检查脆弱：要求与摘录共享词面即放行，同义改写（中文“员工数”与英文“headcount”）会被误拒，无关数字的巧合重叠会误放；改进方向是叠加轻量语义匹配（嵌入相似度阈值）或让小型 LLM 判官二次校验。第二，候选池只进不出、仅按路径 BM25 排序：147–294 个未打开文件里多数是噪音，异构命名（如 2023/archive/ 下的扫描件）让路径排序失效；改进方向是按内容做摘要级预览、按要求相关性增量剪枝。第三，读日志无去重与压缩：同一文件多次部分读取会重复入账，中位 40.2K 字符的摘录量在更长任务下会失控；可引入基于锚点的条目合并与分层索引。第四，发现类失败未根治：账本知道哪些文件没打开却不主动催促，三个模型打开候选的比例最高也只有 54.7%；改进方向是把与 open 要求相关的高分候选写进状态行，或在 finish check 里做定向提醒。此外，三个 LLM 使用账本的风格差异极大（Gemini 100% 先评审，GPT 72.6% 靠 finish check 倒逼），提示操作协议本身还可通过微调或提示工程进一步统一。
未来方向
作者方向的延伸：作者认为环境侧账本是直接访问的自然补充——终端负责“够得着”，账本负责“记得住”——并提出隐私保障（账本与工作区同权限、人工审查交付物）。在此基础上可延伸出五条路线。其一，把账本升级为语义化任务记忆：用嵌入索引替代 BM25，让评审跨语言、跨同义改写地匹配要求与摘录，并把智能体计算出的派生值（求和、汇率换算等）也纳入记账。其二，把一次性 finish check 泛化为进度感知的阶段性清算，在任务关键节点而非仅 stop 时触发，缓解 DeepSeek/Gemini 后程才动账本的问题。其三，从单任务扩展到跨任务：读日志与候选沉淀为组织级知识库，与智能体长期记忆研究（跨会话记忆、经验反思）对接，让“上次读过的年报”在本次任务直接复用。其四，训练侧：像 GrepSeek 训练紧凑搜索智能体那样，微调小模型学会主动、规范地操作 add/list/resolve/show，缩小三种 LLM 使用风格的差距并降低对商业大模型的依赖。其五，评测侧：构造包含外部数据源、多交付物、需要计算与图表重建的任务，检验账本在发现类失败占比更高场景下的上限。
复现评估
复现基础较好但仍有缺口。公开可得：三个基准全部公开（Workspace-Bench、TheAgentCompany、OfficeQA Pro）；智能体底座 DCI-Agent-Lite 基于开源 Pi harness（github.com/earendil-works/pi）；论文对账本构成、四个操作、BM25 排序、词面证据检查、finish check 触发条件都有完整描述，实现细节（300 轮预算、每任务 1 小时、runtime context management level 3）也给出。缺口：RunningTab 本身未提及开源，系统提示的具体措辞（要求声明短块、评审提示、状态行格式）只能凭正文推测复刻；评测需要三个商业 LLM API 加 GPT-5.4 mini 作 judge，主表每格三轮，100+88+104 个实例×5 方法×3 模型×3 轮，API 费用与每任务最长 1 小时的墙钟时间不低。总体难度中等：框架思想清晰、组件简单（BM25 加字符串重叠检查即可实现核心逻辑），最难对齐的是提示词细节与失效归因标注协议（Cohen's kappa 0.83 的 LLM 标注流程）。
论文图表
上图为 DCI 丢分的失效类型分解：提取类 51.1%（其中看过却丢失 12.3%、丢弃或失真 38.9%）、发现类 17.6%、格式化 10.3%、推理 4.8%、其他 16.1%。下图追踪 891 个智能体确实看到过的细则数值的去向：76.2% 进入交付物，19.8% 看过却缺失，4.0% 其他。
这张图是论文动机的定量证据：它首次把“内容已被智能体读过却没进交付物”这一失效模式量化，直接论证了为什么需要一本环境侧的账本。