Agent 知识库 Benchmark 调查：现状、缺口与 Notist Bench 设计

本文系统调查「Agent 操作文档知识库、或基于文档知识库完成任务」的现有 benchmark 生态，回答一个问题：在构建 Notist 的可量化对比 bench（同一内容语料 × Markdown/Notist × 无检索/向量检索 × 裸文件/CLI/MCP/LSP）之前，有哪些现成工作可以复用，哪些是真空白。

资料和判断截至 2026-07-25。调查分六路并行检索完成，每个条目都以一手来源（arXiv、官方 leaderboard、GitHub）核实，核实不了的标注为疑似不存在。经典 RAG 评测（BEIR、MTEB、KILT、ALCE、RAGAS、ARES、RAGChecker、RAGTruth、CRAG、MultiHop-RAG）已在 vault::ai::2026-07-21 notist agent mcp semantic retrieval and vector indexing 的评测方法一节覆盖，本文不重复，聚焦 agentic、任务级和写入侧，可以看作该节的展开与外部对标。

先给结论

• 「Agent 读写一个文档知识库（非代码、非 Office/GUI）完成任务」的现成 benchmark 不存在。最近邻是 Workspace-Bench（异构文件工作区，2026）、WorkArena 的知识库任务（企业表单系统内）、MCPMark 的 Notion/Filesystem 任务（CRUD 混合）。Obsidian/Notion/PKM 方向只有工具插件，没有任何评测集。

• 三条消融轴中，检索轴（无检索 vs 全文 vs 检索）有成熟先例：FRAMES 和 FanOutQA 的 closed-book/open-book/wiki 三档、LOFT 的「整个语料进 context vs RAG」、BrowseComp-Plus 的固定语料加可替换检索后端。语言轴（同一内容的 Markdown vs 结构化文档语言）和工具界面轴（grep/cat vs CLI vs MCP vs LSP）没有学术先例，只有方法学粗糙且结论互相矛盾的工业界实验。

• 引用质量评分有现成方案：Mind2Web 2 的 rubric 树 Agent-as-a-Judge、DeepResearch Bench 的 FACT、HELMET 的 Cite（即 ALCE）、KILT provenance、MCP-Atlas 的 claim-level rubric。

• 写入侧判分可以拼出来：MQuAKE 的多跳涟漪、ZsRE 的 Reliability/Generalization/Locality 三件套、LongMemEval 的 knowledge-update（新值生效、旧值失效）、SWE-bench 的 FAILTOPASS/PASSTOPASS 双层断言。Notist 的 check 天然就是回归测试套件。但「编辑后检索一致性」（read-your-write）没有现成 benchmark。

• 必须正面回应的反方先验：格式敏感性真实但方向不一致（FormatSpread、He et al.）；TOON 式「结构化更省 token」在独立验证和 agentic 场景多不成立（Notation Matters）；Chroma 的 Context Rot 报告甚至发现打乱结构的 haystack 一致优于有逻辑结构的 haystack。「结构化更好」只能靠自己的 bench 实测站住——这正是要建它的理由。

• 结论：Notist bench 必须自建，但它的每个组件（题型、判分、指标、harness）都有可复用的最佳实践；它的差异化贡献恰好落在三个空白上：语言轴、工具界面轴、read-your-write。先建 bench 再选模型/数据库的顺序，与既有路线判断一致。

调查方法

分六路并行调查，每路先核实候选名单再横向扩展：

1. Agentic 深度研究与网页问答：GAIA、BrowseComp、BrowseComp-ZH、BrowseComp-Plus、AssistantBench、Mind2Web 2、DeepResearch Bench、DeepResearchGym、xbench-DeepSearch、FRAMES、FanOutQA、InfoDeepSeek、WideSearch、HLE、WebWalker、SealQA。 2. 长上下文与记忆检索：RULER、NIAH 家族、Lost in the Middle、ZeroSCROLLS、LongBench v2、InfiniteBench、LOFT、HELMET、LongMemEval、LoCoMo、MemBench、PerLTQA 及 2025-2026 新工作。 3. 操作文件、文档与知识库的 Agent：OSWorld、WindowsAgentArena、TheAgentCompany、OfficeBench、AppWorld、WorkArena/++、Workspace-Bench、CRUD-RAG、FinanceBench、DocBench、DABstep、SpreadsheetBench、STORM/FreshWiki、SWE-bench 家族，另对 PKM/Obsidian/Notion 方向做专项搜索。 4. MCP 与工具调用：MCPMark、MCP-Universe、MCP-Bench、LiveMCPBench、MCPEval、MCPToolBench++、MCP-RADAR、MCP-Atlas、Toolathlon、τ-bench/τ²-bench、BFCL v3/v4、ToolSandbox、API-Bank、ToolACE、Seal-Tools、StableToolBench。 5. 表示形式与切块实证：FormatSpread、He et al. 格式实验、TOON 官方与独立验证、Notation Matters、Dense X Retrieval、LumberChunker/GutenQA、Meta-Chunking、Late Chunking、Contextual Retrieval、semantic chunking 成本研究、Context Rot。 6. 写入、维护与时效：KILT、FreshQA、RealTimeQA、EvoWiki、ZsRE、CounterFact、MQuAKE、HoH、EditEval、MemoryAgentBench、WikiGenBench、Wiki Live Challenge。

核实标准：只收录在一手来源确认的条目。FileBench（LLM 向）、WikiNewpages、SheetAgentBench 经多角度搜索判定疑似不存在；DeepResearch Bench（USTC，2506.11763）与 Deep Research Bench（FutureSearch，2506.06287）同名不同物，引用时注意区分；ResearchGym 是科研实验 agent 的 bench，方向不符已剔除。文中 2026 年的新条目均核实过 arXiv 页面存在，个别未逐一深读，使用时建议再核对版本。

方向一：Agentic 深度研究与网页问答

横切结论：这类 bench 的语料几乎都是 live web（黑盒搜索 API），不可复现也不可控；只有四个例外使用固定文档集合——BrowseComp-Plus（约 10 万篇人工核验文档）、DeepResearchGym（ClueWeb22/FineWeb 快照加自带检索 API）、FRAMES/FanOutQA（Wikipedia 固定快照）、SealQA 的 LongSeal 子集（固定文档堆捞针）。真正评引用质量的只有 Mind2Web 2、DeepResearch Bench、DeepResearchGym、BrowseComp-Plus 四个。

• GAIA（2023，Meta/HuggingFace）：466 道真实世界问题，三级难度，exact match。短答案可自动验证加难度分层的模式值得学；语料是 live web 加附件文件，无引用评分。

• BrowseComp（2025，OpenAI）：1,266 题，「逆向构造」——从难找的答案反推问题，答案短且易验证、定位极难。这个造题法可直接用于知识库 QA 造题，保证不能靠模型记忆作答。

• BrowseComp-Plus（2025，Waterloo/CMU 等）：从 BrowseComp 筛出 830 题加固定语料，每题带人工核验的 gold 文档和 hard negatives；指标含 accuracy、Recall@5/nDCG@10、citation accuracy、搜索调用次数；检索器可替换（GPT-5 加 BM25 55.9%，换 Qwen3-Embedding-8B 升到 70.1%）。「固定文档库 + 可换检索后端 + 引用评分」三需求同时满足的唯一样板，已有跨语言扩展 XBCP。

• Mind2Web 2（2025，Ohio State）：130 个长程 agentic search 任务，Agent-as-a-Judge 为每题生成树状 rubric，同时评答案正确性与来源归属（source attribution），报 partial completion。是目前最成熟的引用质量自动评分方案，可改造为对 Notist source range/wiki reference 的评分器。

• DeepResearch Bench（2025，USTC）：100 个 PhD 级任务；RACE 评报告质量、FACT 评引用（citation accuracy + effective citation count），是少数把引用做成一维指标的方案。

• DeepResearchGym（2025，CMU 等）：开源沙盒等于可复现 search API 加评测协议，设计目标就是换掉商业搜索 API。直接示范了 harness 形态：把检索后端整体换成自有知识库，其余评测协议照搬。

• FRAMES（2024，Google）：824 道多跳题，每题整合 2-15 篇 Wikipedia 文章，标注推理类型；论文对比无检索约 40% vs 多步检索约 66%。「固定文档集合 + 同一套题跑多档检索条件」正是检索轴的现成实验设计。

• FanOutQA（2024，UPenn）：1,034 道 fan-out 题（先枚举实体再逐实体查文档聚合），closed-book/open-book/wiki 三档设定，可按子问题分解评分。题型对应 wiki reference 批量反查场景。

• InfoDeepSeek（2025，SJTU/华为）：指标体系最细——ACC、IA@k（证据充分性）、EEU（证据利用率）、IC（信息紧凑度），把检索质量从答案正确率中解耦。

• WideSearch（2025，ByteDance）：广度收集题，原子事实逐条可验证，item-F1 适合「列出所有满足 X 的条目」的完整性度量。

• AssistantBench（2024）：accuracy 与 answer rate 双指标，不答不罚，惩罚幻觉而不惩罚拒答——适合知识库问答的拒答轴。

• xbench-DeepSearch（2025，红杉中国）：正确率与每任务成本/耗时并列为榜单维度，题库季更加闭源集防刷榜。

• HLE（2025）：防检索泄漏的题目设计原则可参考；「HLE w/ tools」是各家自报口径不是独立 benchmark，scaffold 不统一、不可横向复现。

• WebWalker（2025，阿里）：按信息埋藏深度/跨源数分级难度，可映射到 vault 层级与跨模块引用深度；只给链接需自爬，可复现性弱。

• SealQA（2025）：专攻搜索结果冲突/有噪场景；LongSeal 子集是固定文档堆设定。

方向二：长上下文与记忆检索

横切结论：这个方向几乎全是单轮 prompt 评测，没有 agentic 多步工具形态（2025 年后的记忆类工作才开始评增量写入）；没有一个评结构化文档语义（标题层级、wiki 链接、source range），HELMET 的 Cite 任务评段落 ID 引用是最接近的。RULER、NIAH 原版、Lost in the Middle 的协议允许整体替换语料，是做 Markdown vs Notist 对照的低成本起点。

• RULER（2024，NVIDIA）：13 个合成任务四类（多针/多值/多查询/干扰、variable tracking、聚合、QA 插干扰），长度 4K-128K 可配，全自动字符串判分，无需 judge；haystack 是本地文件可直接替换。提出「有效上下文长度」——性能跌破阈值的临界长度，可推广为「有效库规模」。

• NIAH 家族：协议极简、完全语料无关（BABILong 到 10M token、NoLiMa 用语义推断针）；天花板低，前沿模型接近满分，只适合做 sanity check。

• Lost in the Middle（2023）：gold 文档位置扫描产生 U 型曲线。假设：Notist 的 outline/search 结构导航能否消除 U 型曲线，是一个便宜且直接的实验。

• LOFT（2024，Google DeepMind）：把 128K/1M 整个语料放进 context 与专门检索/RAG 系统对比，含 SQL-like 结构化查询任务。「全文进 context vs 检索」的对比轴设计直接可抄。

• HELMET（2024，Princeton）：七类任务含 RAG（SubEM）与 Cite（ALCE 的 citation precision/recall），长度可控，框架支持添加新任务。其「NIAH 分数不能预测下游表现」的结论支持 bench 必须含真实任务。

• LongMemEval（2024，UCSB 等）：500 题五类记忆能力，含 knowledge-update 题型（早前事实被改写，须答新值）；indexing/retrieval/reading 三阶段归因框架正好对应检索轴与工具轴的归因。

• LoCoMo（2024，UNC）：多 session 对话 QA，含时序与对抗性题型；2025 年起多篇工作指出其标注噪声，引用需谨慎。

• MemBench（2025，华为）：把效率与容量纳入记忆评测指标，对应成本轴。

• 2025-2026 新进展（arXiv 页面已核实、未逐一深读）：MemoryAgentBench（少见的 agentic 增量多轮协议，评准确检索、test-time 学习、长程理解、冲突消解四能力，是目前唯一 agentic 的写入/更新/冲突消解 harness）；LongMemEval-V2、MemoryArena、LoCoMo-Plus、ConvoMem、LMEB。

• ZeroSCROLLS、LongBench v2、InfiniteBench：固定语料不可注入自定义库，复用价值低；InfiniteBench「检索少量片段不足以解题」的设计哲学对任务分层有用。

方向三：操作文件、文档与知识库的 Agent

横切结论：不存在「Agent 读写个人文档知识库（非代码、Wiki/Vault 式）完成任务」的主流 benchmark。对 PKM/Obsidian/Notion/second brain 的专项搜索命中的全部是工具与插件（各类 Obsidian MCP、vault builder 等），无一评测集。这个空白本身就是 Notist bench 的正当性证明。最近邻按距离排序：Workspace-Bench（通用文件工作区）、WorkArena 知识库任务（企业表单系统）、MCPMark 的 Notion/Filesystem（见方向四）、SWE-bench 家族（结构化语料但是代码）。

• Workspace-Bench（2026，清华/Ant 等）：真实感「打工人工作区」，5 角色画像、74 种文件类型、20,476 个文件（20GB）、388 任务、7,399 条 rubric，每任务带文件依赖图；另评了 4 种 agent harness——与「同一任务不同工具界面」的对照最近。最佳 agent 约 60%，人类 80.7%。

• WorkArena/WorkArena++（2024，ServiceNow）：唯一把「知识库检索/使用」列为正式任务类别的 agentic bench（在 ServiceNow 实例内）；模板乘 seed 实例化出 23,150 个任务实例的规模化方法、L1/L2/L3 组合式难度分级可学。

• SWE-bench（2023，Princeton）及 Verified（2024，OpenAI）、Multimodal（2024）：issue 到 patch，FAILTOPASS 加 PASSTOPASS 双测试集判分，每实例独立环境，Verified 用 93 名开发者人工筛除 68.3% 问题样本。Notist 的 check（语法/类型/引用校验）天然等价于单元测试，「issue 前 check 红、编辑后 check 绿」的 F2P 模式可平移；人工筛题流程是自建 bench 的必修课。

• LocAgent/Loc-Bench（2025，USC）：把「定位」单独做成 benchmark（issue 到文件/类/函数，Acc@k），训练截止后采样防泄漏；graph-guided 检索 vs 裸 grep 的对比设计正是检索轴与工具轴的雏形。

• SWE-agent ACI（2024）：agent-computer interface 设计（命令集、错误反馈格式）对性能影响显著——工具界面轴必须控制变量的直接证据，虽然只在代码域。

• TheAgentCompany（2024，CMU）：模拟软件公司，ownCloud 文档任务是最接近「文档库」的部分；partial credit 与 checkpoint 式中间态判分可学。

• AppWorld（2024）：9 个模拟 app，TGC/SGC 指标；SGC「链式任务不破坏已有状态」非常适合知识库编辑任务的回归断言（编辑 A 不能弄坏 B）。

• OfficeBench、OSWorld、WindowsAgentArena：办公/OS GUI 环境，与文档语言轴关系远，仅 execution-based 终态校验的思路可参考。

• CRUD-RAG（2024）：Create/Read/Update/Delete 四分类法适合做知识库任务分类学；注意它的 Update/Delete 是生成任务（纠错/摘要），不是对 KB 的真实增删改。

• FinanceBench（2023）：evidence string 作为判分维度；DocBench（2024）：把「系统」而非裸模型作为被测对象；DABstep（2025）：factoid 化答案加自动校验，使 agentic 任务可大规模客观判分。

• SpreadsheetBench（2024）：「一条指令 × 多个测试文件」的 OJ 式判分，比单终态更鲁棒，知识库编辑任务可照搬。

• STORM/FreshWiki（2024，Stanford）：citation recall/precision 的自动度量是引用轴现成方法；「cutoff 后的新鲜主题防泄漏」思路可学。

方向四：MCP 与工具调用

横切结论：MCP 原生 bench 在 2025 年爆发，任务构造与判分方法已成熟（state-based 是主流）；但没有任何工作在*同一任务集*上对比 CLI/API/MCP/LSP 四种工具界面，只有方法学粗糙、结论互相矛盾的工业界实验——这是最大的空白机会。

• MCPMark（2025，NUS 等）：127 个任务覆盖 Notion/GitHub/Filesystem/PostgreSQL/Playwright 五个真实 server，CRUD 混合的深交互；curated initial state 加程序化验证脚本逐条 pass/fail；指标 pass@1 与 pass^4（可靠性）；报告 turns 与 tool calls（平均 16.2 turns、17.4 tool calls）；最强模型仅 52.56% pass@1。任务范式与成本报告方式可直接复用，harness 极简易改，可把 Notist MCP server 直接挂进去跑。

• τ-bench/τ²-bench（2024/2025，Sierra）：纯 state-based 确定性判分，pass^k 专测一致性；τ² 的 compositional task generator 从原子组件程序化生成可验证任务、可控复杂度。判分与规模化方法可复用度最高。

• BFCL v3/v4（2024-2025，Berkeley）：事实标准；multi-turn 四个 split（base/缺参数/缺工具/长上下文）的扰动设计天然对应「同一能力不同暴露方式」的消融条件；判分混合 AST 匹配、可执行性与终态状态校验。

• MCP-Universe（2025，Salesforce）：231 任务，format/static/dynamic 三类 evaluator；dynamic evaluator 运行时拉取实时 ground truth，是处理「文档库内容会变化」的干净方案；明确分析 input token 随步数膨胀。

• MCP-Bench（2025，Accenture）：fuzzy prompt（不指明工具）考工具发现与跨工具编排；发现 schema 合规等低层能力已收敛，瓶颈在跨 server 编排。适合测 Notist CLI 的 search/outline/query 可发现性。

• LiveMCPBench（2025，中科院）：95 任务，answer-based LLM judge（与人工 81% 一致），70 server/527 tools 一键 Docker 复现。

• MCPEval（2025，Salesforce）：自动化任务生成加验证框架，成功轨迹即 ground truth——批量产出知识库任务并控制成本的思路。

• MCP-Atlas（2026，Scale AI）：1,000 个人工撰写任务（500 公开加 500 私有榜），claim-level rubric 判分——最终答案对照原子事实 claim 打分，允许不同合法轨迹；11 类失败诊断（63.3% 失败是认知性而非工具性）。claim-level 是「引用质量/答案事实性」最成熟的现成方案。

• ToolSandbox（2024，Apple）：milestones/minefields 对任意轨迹做中间加终态动态评估，附录专做 turn-count 效率对比。

• StableToolBench（2024，THUNLP）：缓存加模拟失效 API 保证评测可复现——依赖外部服务的 bench 的关键纪律。

• MCPToolBench++（2025）：覆盖面最大（4k+ server）但深度浅；其「真实 server 本身不稳定」的教训支持用本地可控 server。

• MCP-RADAR（2025）：CRE 指标少数显式量化计算资源消耗；MCPAgentBench（2025）带干扰工具测工具甄别；MCPEvol-Bench（2026-07）测工具集动态演化，可跟进。

• API-Bank、ToolACE、Seal-Tools：历史意义或数据合成管线，范式已被 BFCL 吸收。

工具界面消融的现有碎片证据（均为工业界实验，互相矛盾，仅作动机）：

• Scalekit（2026）：同任务下 MCP 比 CLI 多耗 4-32 倍 token（schema dump 进上下文），可靠性 CLI 100% vs MCP 72%；样本小、偏成熟 CLI。

• Smithery（756 次测试）：Native MCP 成功率 91.7% vs CLI 83.3%，中位 token 28.8k vs 82.9k——MCP 返回结构化 JSON 反而省 token；结论是「界面之争不如 harness 用法之争」。

• Port of Context：12 个 Stripe 任务乘三种界面，token 差 2.4 倍。

• SUMO-MCP（学术，交通仿真域）：MCP 工具调用比直接 CLI 脚本参数错误更少。

• 结论：没有学术 harness 做过同内容、同任务、多界面的受控对比，现有结果无人能引。Notist bench 可以做第一个。

方向五：表示形式与切块的实证

横切结论：格式敏感性真实且大（可达几十个点），但方向不一致、随模型变强而减弱；「结构化/省 token」的主张在独立验证和 agentic 场景多不成立。这些反方证据决定了 bench 的方法论纪律：跨模型、报区间、以端到端任务成功率为准。

• FormatSpread（2023，UW/AI2，ICLR 2024）：同一内容做保义格式变换，LLaMA-2-13B 上性能区间最高达 76 个点；提出「报区间而非单点」的评测范式。没有它，Markdown vs Notist 的任何单点差都无法排除格式噪声。

• He et al.（2024）：同一 context 序列化为 plain/Markdown/JSON/YAML，GPT-3.5 上差距最高约 40% 且方向不一致（代码翻译 JSON 差、MMLU JSON 好），GPT-4 显著更鲁棒。结论强依赖模型代际，bench 需跨模型跑。

• TOON（2025）：官方称省约 40% token 且准确率不降；但多家独立验证偏负面（Improving Agents 复测中 TOON 从未最优；Matveev 2026 指出优势常被缩减）。

• Notation Matters（2026）：在 BFCL、MCPToolBench++、MCP-Universe、StableToolBench 四个 agentic bench 上乘 5 个开源模型测 TOON/TRON 编码工具 schema：TOON 省约 18% token 但掉约 9 个百分点准确率，多轮解析失败会级联、并行 tool-call 输出坍缩。关键警示：单轮格式收益不能外推到 agentic 多轮，CLI/MCP 轴必须用端到端成功率验收。

• Dense X Retrieval（2023，Microsoft）：passage/sentence/proposition 三种检索粒度消融，proposition 在 dense retriever 上平均最优。粒度消融的干净范式；Notist 元素天然带边界，可做「notist 元素 vs 固定块 vs proposition」三方对比。

• LumberChunker/GutenQA（2024）：100 本公版书加 3,000 条「答案段落已知」的 QA，DCG@20 加下游 RAG 准确率。「长文档内定位已知段落」是天然的检索评测模板，公版书语料无版权问题。

• Meta-Chunking（2024）：无标注低成本切块基线，适合做对照组；Late Chunking（2024，Jina）示范了「切块边界」与「上下文注入」两个变量的解耦。

• Is Semantic Chunking Worth the Computational Cost?（2024，负面结果）：semantic chunking 收益不一致、配不上计算成本。提醒：结构切块主张必须过「vs 固定切块」这道最朴素的对照。

• Anthropic Contextual Retrieval（2024）：top-20 检索失败率 5.7% 降到 1.9%（加 contextual BM25 与 rerank）；头条数字流传广，但测的是检索失败率不是端到端正确率，且评测集未完整开放，只能引用不能复现。

• Beyond Chunk-Then-Embed（2026）：切块策略 taxonomy 加复现，发现 contextualized chunking 对 in-corpus 检索提升 15-27%，但一致损害 in-document 检索 30-53%——「vault 内检索」与「跨库检索」结论相反，是 vault 检索设计的关键先验。

• Lost in the Middle（2023）：位置扫描应进 bench 设计；Chroma Context Rot 技术报告（2025）：18 个模型四组实验，性能随输入变长普遍退化；反直觉发现 shuffled（无结构）haystack 一致优于有逻辑结构的 haystack；focused（检索后约 300 token）vs full（113K 全文）对比正好对应「检索 vs 全文」轴。「结构化上下文未必更好」是 Notist 必须正面回应的先验。

• TQA-Bench（2024）、SUC（2023）：表格序列化格式对比，Markdown/CSV/JSON/HTML 各有偏置，「结构化不等于更好」。

方向六：写入、维护与时效

横切结论：写入侧判分只有四种成熟做法（diff 比对、编辑后 QA 反推、局部性回归、引用校验），可组合使用；「agent 持续维护整个文档库（写入加重组加回归）」的 benchmark 不存在，read-your-write 没有专门评测——最近的组合是 MQuAKE 涟漪加 LongMemEval 更新传播加 MemoryAgentBench 冲突消解。

• KILT（2021，Facebook）：统一 Wikipedia 快照加 provenance 标注，答案对不算分、引用的 source 也必须命中（R-precision 联合分）。Wiki Reference 引用质量的现成判分模板。

• MQuAKE（2023，Princeton）：编辑一批事实后问 2-4 跳问题（「首相换了，首相配偶是谁」须连带变化），测涟漪一致性。把编辑对象从模型参数换成 Notist apply_edit 即可整体移植，是最接近 read-your-write 的现成判分。

• ZsRE/CounterFact（经 MEND/ROME/MEMIT 系列）：Reliability（编辑命中）、Generalization（改写问法仍命中）、Locality（无关条目不破坏）三件套是编辑评测的通用语言，可直接平移到文档编辑；CounterFact 的反事实编辑即「库里写了错事实，agent 要改掉」的 propose_edit 场景。

• LongMemEval knowledge-update：新值生效、旧值必须失效——可直接写成 apply_edit 后的回归断言。

• MemoryAgentBench（2025）：唯一 agentic 的「写入加更新加冲突消解」评测 harness（准确检索、test-time 学习、长程理解、冲突消解/选择性遗忘四能力）；数据是合成记忆而非文档，是局限，协议可改造为 vault 维护任务。

• HoH（2025，ACL）：用 token-level diff 加 LLM 流水线从 Wikipedia 真实版本差异批量合成 QA，量化「旧版本文档残留」对检索的误导率。它的数据合成流水线就是现成的编辑任务生成器：版本 diff 变成编辑指令加 gold diff。

• EditEval（2022，Meta）：指令式文本改进，SARI/EM 与 gold 修订文本比对（diff 式判分）；其 updating 子任务（基于 Wikipedia 过期段落改新）几乎就是现成的任务定义。SARI 比 EM 更容忍部分正确的编辑。

• FreshQA/FreshLLMs（2023）：「时效分层（never/slow/fast-changing）加答案过期即幻觉」的标注框架，可搬到版本化知识库问答。

• RealTimeQA（2022）：每周自动出题的动态机制比静态题库更适合防污染。

• EvoWiki（2024）：知识分 stable/evolved/uncharted 三态——直接映射编辑影响面：改一条事实，问 stable（回归）、evolved（涟漪）、uncharted（新增）三类题。

• STORM/FreshWiki、WikiGenBench、Wiki Live Challenge（2026）：写作侧引用忠实度与 rubric 判分参考；它们是从零写新条目，不是维护既有库。

• 语义纠偏：DocEdit 是视觉文档版面编辑（Adobe），不是文本知识库编辑；WikiBench 是 HCI 数据集共建系统，不是 wiki 写作榜。

与 Notist 三个消融轴的对照

缺口清单，按硬度排序：

1. 语言轴：同一内容平行语料（Markdown vs 结构化文档语言）的任务级对比，无人做过。最接近的只是格式敏感性研究（非 agentic、非知识库任务）。 2. 工具轴：裸文件读写 vs CLI vs MCP vs LSP 的受控对比，无人做过；ACI 研究只在代码域证明界面设计影响显著。 3. read-your-write 与文档库维护闭环：只有记忆域近似（MemoryAgentBench）和可拼接组件（MQuAKE 加 LongMemEval 加 locality），文档级（而非记忆/参数级）的一致性评测不存在。 4. 软空白：结构化文档语义（标题层级、wiki 引用、source range）的收益无人评分。 5. 软空白：token/步数成本作为一阶指标，多数 bench 不报。

Notist Bench 设计建议

总体形态

一个任务实例等于：初始 vault 快照 + 自然语言指令 + 程序化判分脚本。判分优先级：状态断言（diff/check/QA 反推）优于短答案 exact match，优于 rubric judge。

harness 参考 DeepResearchGym 的「检索 API 抽象加评测协议分离」与 MCPMark 的极简 tool-calling loop：被测对象可换（裸文件工具、notist CLI、notist MCP，未来 LSP），检索后端可换（无、全文、BM25、向量、hybrid），其余协议不动。每实例用 vault 快照打包/解包做隔离，比 SWE-bench 的 Docker 轻得多。

现状可行性：本仓库 CLI 已提供 search、outline、references、query、edit、check、mcp、lsp、daemon，harness 今天就能驱动 CLI 与 MCP 两档；LSP 是编辑器会话协议，给 agent 用需要包一层适配，建议后补。

语料：平行双语言是最大成本项

• 同一内容同时维护 Markdown 与 .not 两个版本。候选来源：英文 Wikipedia 固定快照（FRAMES/FanOutQA/BrowseComp-Plus 的做法，规模可控、无时效漂移）、公版书（GutenQA，无版权问题）、以及本仓库 docs/（冷启动首选，0721 文档已提议 100-300 条人工标注 query）。

• Markdown 侧必须是公平强基线：front matter、wiki-link 插件、标题层级、合理 chunker 都配上。否则对比会被质疑为打稻草人，结论也无法对外引用。

• 规模分档：小库（全文可进 context）、中库、大库，测「有效库规模」曲线（RULER 有效长度概念的推广）——哪个条件下性能先崩，是比单点分数更有信息量的结果。

• 位置扫描：同一证据放在 vault 不同位置/不同层级深度（Lost in the Middle 协议），检验 outline/search 结构导航能否消除 U 型曲线。

任务族

按 CRUD 加维护分六族，判分方式随族定：

1. 事实 QA（读）：BrowseComp 逆向构造短答案题，exact match；多跳题沿显式 wiki reference 链（FRAMES 式 2-15 篇文档）；fan-out 枚举题用 item-F1（WideSearch）。 2. 定位与引用（查）：GutenQA/LocAgent 式「答案位置已知」题，要求回答带 module/element/range 引用；指标 Acc@k 加 citation precision/recall（ALCE/KILT）。 3. 长文综合（读）：Mind2Web 2 式 rubric 树 judge，同时评正确性与来源归属；用于回答「结构导航是否有可测量收益」。 4. 编辑（写）：HoH 式从版本 diff 自动合成编辑指令（gold diff 加 SARI/EM 文本判分，EditEval）；CounterFact 式纠错；rename/move/restructure 结构操作，判分等于目标状态 diff 加 check 绿。 5. 维护（演进）：知识更新（新值生效、旧值失效）；多跳涟漪（MQuAKE）；冲突消解（MemoryAgentBench）；回归（locality 加 PASSTOPASS——无关模块 check 保持绿、无关 QA 不变差，AppWorld SGC 思路）。 6. 拒答与时效：answerable/unanswerable 各半，accuracy 与 answer rate 双指标（AssistantBench）；stale index 与冲突事实场景沿用 0721 文档评测方法一节的设计。

消融矩阵与控制变量

三个轴不是完全正交的：检索轴依附于工具轴——裸文件档的「检索」就是 grep，CLI 档是 notist search/query，MCP 档由 server 内部做 hybrid。因此实际设计是两层的：

语言轴:   Markdown(强基线) vs Notist          —— 同一内容、同一 chunk 策略
工具轴:   裸文件(grep/cat/直接改) vs CLI vs MCP —— LSP 档后补
检索轴:   每个(语言×工具) cell 内部的可配置档位:
          closed-book / 全文进 context / 词项 / 向量 / hybrid

硬控制：同一模型、同一 harness、同一 token 与步数预算；至少跨两个模型代际（He et al. 证明结论随代际反转）；用 FormatSpread 式格式扰动报区间而非单点。全矩阵很大，按轴贪心推进：先固定工具等于 CLI 跑语言乘检索，再固定最优检索配置跑工具轴。

判分必须看端到端任务成功率，不能只看单轮格式准确率——Notation Matters 的教训是单轮收益在 agentic loop 里会反转。

指标分层

判分器与标定

• 程序化优先：状态断言（编辑后快照 diff 加 notist check 加 QA 反推）应覆盖写入族全部与读族大半；SpreadsheetBench 式「一指令 × 多测试文件」提高鲁棒性。

• LLM judge 只用于长文综合族：Mind2Web 2 rubric 树或 MCP-Atlas claim-level；judge 模型与被测模型分开，报告 judge 版本，并用人工标注子集校准。

• 每次 run 存 trajectory、成本、判分明细，支持 leaderboard 化（xbench 把成本列为榜单维度的做法）。

任务生成与防污染

• 批量造题：HoH 版本 diff 流水线（编辑族）加 τ²-bench 组合式生成器（读族）加 MCPEval「成功轨迹即 ground truth」（降人工成本）。

• 人工筛题：SWE-bench Verified 流程（剔除描述欠定、判分过严样本），这是必修不是可选。

• 防污染：BrowseComp 逆向构造保证不能靠记忆作答；私有 held-out 集（HLE/xbench）；版本 diff 滚动翻新题库（RealTimeQA）。

分阶段路线

• v0.1 冷启动：语料用本仓库 docs/；只跑 Notist × CLI × {closed-book、search、query}；任务为事实 QA 加定位，100-300 条人工标注；判分为 exact match 加引用检查加 check。目标是跑通闭环，先回答「结构化查询是否比 grep 好」这一个问题。

• v0.2：加 Markdown 平行语料与裸文件工具档，产出语言轴第一组数据（报区间、跨两个模型）。

• v0.3：加写入族与维护族，落地 read-your-write 三断言。

• v0.4：加 MCP 档、多模型、成本报告；视需要补 LSP 适配层。

• 之后：规模分档与有效库规模曲线；动态语料滚动翻新；对外 leaderboard 化。

风险与纪律

• 单格式单点结果不可信（FormatSpread）：所有对比报区间、跨模型。

• 结构化收益必须实测（Context Rot 的反例、TOON 独立验证失败、Notation Matters 的 agentic 反转）：若 Notist 在定位族不优于强 Markdown 基线，先修产品再修 bench。

• 公平基线纪律：Markdown 侧用最佳实践配置；检索轴每档调优到各自最优再比。

• 不评「哪个模型好」，只评「同一模型在不同条件下的差」；模型是控制变量不是主角。

• 任何 LLM judge 用人工标注校准；judge 结论与被测模型隔离。

参考资料

深度研究与网页问答

• GAIA（2023）：https:

• BrowseComp（2025）：https:

• BrowseComp-ZH（2025）：https:

• BrowseComp-Plus（2025）：https:

• AssistantBench（2024）：https:

• Mind2Web 2（2025）：https:

• DeepResearch Bench（USTC，2025）：https:

• DeepResearchGym（2025）：https:

• xbench-DeepSearch（2025）：https:

• FRAMES（2024）：https:

• FanOutQA（2024）：https:

• InfoDeepSeek（2025）：https:

• WideSearch（2025）：https:

• HLE（2025）：https:

• WebWalker（2025）：https:

• SealQA（2025）：https:

长上下文与记忆

• RULER（2024）：https:

• Needle-in-a-Haystack 原版（2023）：https:

• BABILong（2024）：https:

• NoLiMa（2025）：https:

• Lost in the Middle（2023）：https:

• ZeroSCROLLS（2023）：https:

• LongBench v2（2024）：https:

• InfiniteBench（2024）：https:

• LOFT（2024）：https:

• HELMET（2024）：https:

• LongMemEval（2024）：https:

• LoCoMo（2024）：https:

• MemBench（2025）：https:

• PerLTQA（2024）：https:

• MemoryAgentBench（2025）：https:

文件、文档与知识库 Agent

• OSWorld（2024）：https:

• WindowsAgentArena（2024）：https:

• TheAgentCompany（2024）：https:

• OfficeBench（2024）：https:

• AppWorld（2024）：https:

• WorkArena（2024）：https:

• Workspace-Bench（2026）：https:

• CRUD-RAG（2024）：https:

• FinanceBench（2023）：https:

• DocBench（2024）：https:

• DABstep（2025）：https:

• SpreadsheetBench（2024）：https:

• STORM/FreshWiki（2024）：https:

• SWE-bench（2023）：https:

• LocAgent/Loc-Bench（2025）：https:

• SWE-agent ACI（2024）：https:

MCP 与工具调用

• MCPMark（2025）：https:

• MCP-Universe（2025）：https:

• MCP-Bench（Accenture，2025）：https:

• LiveMCPBench（2025）：https:

• MCPEval（2025）：https:

• MCPToolBench++（2025）：https:

• MCP-RADAR（2025）：https:

• MCP-Atlas（2026）：https:

• MCPAgentBench（2025）：https:

• MCPEvol-Bench（2026-07）：https:

• Toolathlon（2025）：https:

• τ-bench（2024）：https:

• BFCL v3/v4（Berkeley）：https:

• ToolSandbox（2024）：https:

• API-Bank（2023）：https:

• ToolACE（2024）：https:

• Seal-Tools（2024）：https:

• StableToolBench（2024）：https:

• Scalekit MCP vs CLI（工业实验，转述）：https:

• Smithery MCP vs CLI（工业实验）：https:

• Port of Context CLI vs MCP vs Code Mode（工业实验）：https:

• SUMO-MCP（2025）：https:

表示形式与切块

• FormatSpread（2023）：https:

• He et al. 格式实验（2024）：https:

• TOON 官方（2025）：https:

• Notation Matters（2026）：https:

• TQA-Bench（2024）：https:

• SUC 表格结构理解（2023）：https:

• Dense X Retrieval（2023）：https:

• LumberChunker/GutenQA（2024）：https:

• Meta-Chunking（2024）：https:

• Late Chunking（2024）：https:

• Is Semantic Chunking Worth the Computational Cost?（2024）：https:

• Anthropic Contextual Retrieval（2024）：https:

• Beyond Chunk-Then-Embed（2026）：https:

• Chroma Context Rot（2025）：https:

写入、维护与时效

• KILT（2021）：https:

• MQuAKE（2023）：https:

• ZsRE/CounterFact 评测入口 EasyEdit：https:

• HoH（2025）：https:

• EditEval（2022）：https:

• FreshQA/FreshLLMs（2023）：https:

• RealTimeQA（2022）：https:

• EvoWiki（2024）：https:

• WikiGenBench（2024）：https:

• Wiki Live Challenge（2026）：https:

本仓库相关

• vault::ai::2026-07-21 notist agent mcp semantic retrieval and vector indexing：检索技术地图与评测方法节，本文是其外部对标与展开。

结语

调查支持「先建 bench」这个判断：外部生态把检索轴的实验设计、引用质量的评分器、写入侧的判分原语都准备好了，但语言轴、工具界面轴和 read-your-write 是三个无人占据的空白，恰好对应 Notist 的核心主张（结构化语言、结构化工具界面、可验证编辑）。自建 bench 不只是内部选型工具，本身就是这个方向上第一个可引用的对照实验。第一版要克制：只跑通「docs/ 语料 × CLI × 检索档 × 读族任务」的闭环，把判分器和成本记录的纪律立住，再逐轴扩张。