DocOps：自主智能体复杂文档操作的确定性可验证基准

首个对文档原生操作做确定性验证的智能体基准，暴露长程状态跟踪与破坏性编辑两大短板。

前置知识

智能体框架（Agent Harness）

封装 LLM 执行循环的基础设施，提供上下文管理、工具注册与状态维护。本文对比了四种：DocTools（结构化文档 API、无 shell）、Terminus-2（带文件系统的 Bash 框架）、Codex（CLI 开放脚本执行）、Claude Code（带文件系统反馈的交互式编码框架）。还区分了是否注入官方 Anthropic 文档技能（w/ skill 与 w/o skill）。

本文的核心发现之一是模型能力不能单独决定成败，框架选择同样关键。理解这四种框架的区别及其成本差异，是看懂 Table 2、Figure 6、Table 3 实验结果的基础。

文档原生状态（Native Document State）

指文档格式内部的结构化表示，而非渲染后的可见外观。例如 Excel 的可执行公式与单元格引用、Word 的标题样式层级与原生表格对象、PPT 中真实的 shape.has_table 对象、PDF 的书签大纲树。这些状态藏在压缩 XML / 二进制内部，仅读取可见文本无法触及。

本文坚持把文档当作'一等公民'的有状态计算对象。能否正确读写这些原生状态，是区分合格文档智能体与'表面贴图'的关键，也是三类验证谓词和破坏性编辑失败模式分析的内核。

确定性验证器（Deterministic Verifier）

在容器内直接通过文档原生库（如 openpyxl、python-docx、python-pptx、PyPDF2）检查最终产物是否满足任务契约的程序化检查器，与 LLM-as-a-judge 主观打分相对。它使用三类谓词：结构谓词（查底层原生状态）、语言锚点（用任务特定关键词验证所需文本）、保留谓词（确保被保护的越界元素完好）。

这是 DocOps 区别于以往基准的根本所在——可确定性地、离线地、可复现地判定任务是否真正完成，从而能识别'看起来对但内部已坏'的破坏性编辑，并支持细粒度失败模式归因。

LLM-as-a-judge（模型充当裁判）

用一个 LLM 对另一个模型的输出进行打分或判定的评估方式，灵活但有偏差、成本高、结果不可复现。在文档编辑任务中，裁判容易被'看起来合理的输出'欺骗。

DocOps 明确反对用 LLM-as-judge 评估文档操作。Table 1 的对照正是通过与依赖间接验证或裁判式评估的基准对比，凸显确定性验证的优势，读者需理解这种区别才能领会方法贡献。

研究动机

现有针对文档的基准被两种范式卡住。第一种是静态只读框架（如 DocBench、DUDE），把文档降级为只读知识库，只评测信息抽取或在固定文本上的问答；第二种是面向工作流的评测（如 OfficeBench、OdysseyBench），关注的是跨软件的导航编排，文档只被当成在不同应用之间传递的临时、被动的数据载荷。两者都没有把文档当作一等公民的计算对象——一种智能体必须在整个复杂工作流中持续、主动地操作的复杂数字制品。在真实办公场景里，智能体需要直接合成并修改多种文档的内容与格式，并保证修改后的文件结构有效、功能完整。更棘手的是，以往基准往往依赖间接验证目标和粗粒度的任务级成功信号，例如往返重建或模型裁判打分，因而难以判断智能体是否真的产出了有效且非破坏性的 Office 制品。一个悬而未决的问题是：当前智能体能否可靠地完成端到端的文档中心任务，同时维持全局文档状态一致、且不引入破坏性修改。

本文的目标是本文的目标是构建一个严格可验证的评测框架 DocOps，系统评估 LLM 智能体在端到端文档操作上的真实能力。它要回答的核心问题是：当前智能体能否可靠地修改原生格式 Office 制品、同时保持文档原生状态一致，并在达成用户目标时不引入破坏性改动。为此，DocOps 提出了一套有原则的双轴分类法，把文档操作这个黑箱系统性拆解为原子维度与递增的工作流复杂度，使研究者能精确定位智能体的失败究竟源于局部结构破坏，还是长程状态跟踪的崩溃。同时通过直接检查原生文档制品，提供可复现、确定性的评测契约，减少过度宽松的评估，进而暴露以往依赖表面验证或任务级成功判定都无法捕捉的文档原生失败模式。

与已有工作不同的是，DocOps 的独特切入点在于：它把文档定义为有状态的计算对象，每一次操作都被视为一次状态转移——必须到达所请求的状态，同时保留原生格式有效性以及跨异构格式的相关越界状态。这与以往工作有本质区别：以往要么只看可见输出、要么只判任务级成败、要么用模型裁判。DocOps 为每个任务配备确定性验证器，用三类谓词（结构、语言锚点、保留）捕捉连表面验证都无法发现的文档原生失败模式，如公式被替换成静态值、原生表格被文本框伪装、书签大纲被忽略。这种制品级、保留感知的视角，使 DocOps 既能做能力诊断又能识别破坏性编辑，并支持跨格式的耦合度分析，填补了文档中心 AI 评测的关键空白。

核心方法

DocOps 的整体思路是：先用一个双轴分类法把文档操作空间说清楚，再用受控流程构造任务，最后用确定性验证器判分。直觉上，作者认为文档操作的难度来自两个正交维度：一是操作哪些层（内容、格式、结构），二是状态跟踪有多深（L1 原子到 L4 跨文档）。技术上，操作轴把原子编辑原语分为三族：内容族（抽取 C1、编辑 C2、生成 C3、计算 C4、推理 C5）、格式族（样式一致 F1、高亮 F2、布局 F3、主题转移 F4）、结构族（增删 S1、重排 S2、层级编辑 S3、表格表单操作 S4）；难度轴四档：L1 单次原子编辑测局部执行，L2 在一个制品内组合多次操作测短程规划与局部依赖，L3 单文档工作流测全局一致性，L4 跨文档对齐测跨文档状态跟踪。配合四阶段任务构造和三类谓词验证器，整个框架既能细粒度诊断操作能力，又能给出可靠的端到端工作流评分。

核心创新在于把文档操作重新定义为保留感知的状态转移。这与以往方法本质不同：以往把文档当只读知识库（只读不写）或当被动数据载荷（写完即弃、只看任务是否完成）。DocOps 坚持每一次操作都必须用原生文档库直接检查最终制品是否到达请求状态、是否保留了被保护的越界元素、是否破坏了隐藏结构（可执行公式、原生表格、书签大纲、样式层级）。三类谓词正是为此设计：结构谓词查底层原生状态以发现渲染不可见的结构腐蚀；语言锚点用任务特定关键词验证所需文本同时容忍合法语言变体；保留谓词确保被声明的越界元素完好。这种制品级、原生库直接验证的契约，是 DocOps 能识别破坏性编辑、做确定性判分、并允许多条合法执行路径的根本所在。

方法步骤详情

第一步，分类法设计：定义操作三族（内容 C1-C5、格式 F1-F4、结构 S1-S4）与难度四档（L1 原子、L2 复合、L3 工作流、L4 跨文档）。第二步，四阶段任务构造。阶段一从 600 个候选源（472 条社区需求、125 个公开工作流、3 个自动化模板）筛选，剔除 118 条（19.7%，因需外部服务或范围不清等），保留 482 个候选。阶段二用标准化提示把每条种子形式化为 task_metadata.json，记录分类标签、输入输出路径、所需操作、编辑范围与保留要求。阶段三据此合成紧凑的原生格式源制品（含表格记录与公式、Word 节、幻灯片对象、PDF 页面）。阶段四由一位 PhD 研究者迭代人工评审指令清晰度、范围完整性、分类对齐与原生完整性，不合格则回炉或丢弃。最终得到 210 个任务（50 L1、40 L2、60 L3、60 L4），每个打包为自包含 Harbor bundle。验证器在容器内直接检查提交产物，主指标为通过率 $\mathrm{PassRate}(m,h)=\frac{1}{|T|}\sum_t\mathbf{1}\{V(m,h,t){=}1\}$。

技术新颖性

技术新颖性体现在三方面。其一，状态转移视角：把文档操作建模为必须到达请求状态并保留原生有效性与越界状态的转移，而非单步脚本匹配，从而允许多条合法执行路径。其二，确定性原生验证：直接用 openpyxl、python-docx、python-pptx、PyPDF2 等库检查最终制品，离线、可复现，避开 LLM-as-judge 的偏差与不可复现性。其三，验证器保真度经双重验证：128 个人工审计判例中验证器一致 122 例（95.31%，3 假阳 3 假阴）；对 36 个产出注入 180 处受控变异（改内容、腐蚀结构、违反保留、删产物、同名损坏），检出 174 处（96.67%）。代表性 Excel 验证器既检查公式存在（值以等号开头）又重算期望总额并拒绝静态值；PPT 验证器拒绝文本框伪装表格，坚持真实 has_table 对象；PDF 验证器联合检查页序与书签大纲树。这种粒度在以往基准中前所未有。

**Figure 1**: The overview framework of DocOps.

**Figure 8**: DocOps benchmark statistics.

实验结果

核心发现如下。其一，最强配置（GPT-5.5 + Codex + skill）整体通过率仅 0.671，近三分之一任务失败；Claude Sonnet 4.6 在 Claude Code 无 skill 为 0.552。其二，模型不单独决定成败，框架同样关键，同一模型在不同 harness 下波动明显（Qwen3.6-27B 在 Terminus-2 达 0.476）。其三，难度进入工作流级即崩盘，GPT-5.5 从 L1 的 0.725 跌到 L4 的 0.237，瓶颈在维持状态与跨步依赖而非局部操作。其四，退化高度不均：强耦合的 Excel 从 L1 最高跌到 L3 近乎归零，PDF 最稳健；FormatCV 从 0.120 升到 0.436，说明耦合度而非操作数量主导难度。其五，原子操作中抽取、重排、增删较可靠，层级编辑、主题转移、计算、样式一致最难。其六，三大失败模式中语义验证缺口占主导，状态跟踪与破坏性编辑也占相当比例。其七，skill 注入不一致，对中等开源模型显著增益（Qwen3.5-27B +7.1pp、Gemma4-31B +6.7pp），对前沿模型边际甚至有害。

**Table 1**: Comparison with representative document-understanding, document-editing, and office-workflow benchmarks.

**Table 2**: Overall task pass rates across models and execution harnesses.

**Table 3**: Average harness cost statistics.

**Table 4**: Average pass rates by document type and difficulty level with 95% bootstrap confidence intervals.

**Figure 2**: Pass rates across difficulty levels for representative models averaged over their available harness and skill settings.

**Figure 4**: Atomic operation accuracy for representative models on L1 tasks.

**Figure 6**: Harness-level pass-rate ranges over open-source models with complete harness coverage.

**Figure 7**: Overall pass-rate change from skill injection on open-source models.

查看结构化数据

任务	指标	本文	基线	提升
210 任务整体通过率	PassRate	0.671（GPT-5.5 + Codex + skill）	无统一先验基线，以最强配置为参照	即便最强也仅过 2/3，远未饱和，证明任务具有区分度
GPT-5.5 难度梯度通过率	PassRate（跨可用 harness 均值）	L1 0.725 → L2 0.551 → L3 0.203 → L4 0.237	L1 = 0.725	L4 相对 L1 绝对下降约 0.488，工作流级能力崩盘
Excel 跨难度通过率	PassRate（95% bootstrap CI）	[0.566,0.773] → [0.247,0.623] → [0.031,0.085]（L1→L2→L3）	L1 Excel	到 L3 近乎归零，强耦合格式最易崩溃
跨格式性能差异 FormatCV	FormatCV = Std/Mean（跨 Excel/Word/PPT/PDF）	L1 0.120 → L3 0.436	0.120（L1）	增长约 3.6 倍，耦合度而非操作数主导难度
验证器保真度	一致率 / 变异检出率	人工审计 95.31%（122/128）；变异压力测试 96.67%（174/180）	—	确定性验证器本身可靠，评测结论可信
技能注入增益（Claude Code）	ΔAcc（百分点，10000 次配对 bootstrap）	Qwen3.5-27B +7.1pp、Gemma4-31B +6.7pp（CI 全在零上）	w/o skill	对中等开源模型显著正向，但非普适

局限与改进

作者坦承三方面局限。其一，DocOps 只覆盖确定性、离线的文档编辑任务，不涉及需要实时外部服务、协同编辑或交互式用户澄清的工作流。其二，因为复杂文档任务需要结构有效的制品、明确的编辑范围以及人工评审指令和生成文件，扩展基准的人工成本远高于采集只读样例，目前仅 210 个任务。其三，跨 harness 的 token 成本比较需谨慎，因为不同运行时以不同保真度暴露用量统计，部分 Codex/DocTools 数值是标定估计（Table 3 中标†）。我额外观察到几点：210 个任务对四大格式做细分（如 L4 每格式仅 15 个工作流）时统计功效有限、置信区间较宽；任务是人工合成而非完全真实抓取，可能低估真实世界的噪声与歧义；skill 只评了 Anthropic 一家的文档技能，关于 skill 普适性的结论外推需谨慎；三类失败模式的占比来自作者对验证器断言与轨迹的归类，存在一定的主观标注成分。

独立分析的弱点

第一，破坏性编辑几乎无缓解机制。当前验证器只能事后判失败、不能在轨迹中拦截，改进方向是引入操作前后差异保护——对受保护对象（公式、原生表、书签）做快照并在每步比对，发现腐蚀即自动回滚。第二，长程状态跟踪在 Excel 尤其脆弱（L3/L4 近乎归零），暴露的是全局状态表征缺失，建议给智能体外挂显式的文档状态图（公式依赖图、单元格引用拓扑、表单关系），每步主动维护而非仅依赖上下文记忆。第三，语义验证缺口占主导，说明智能体缺乏可执行性自检，建议在提交前用原生库回读并自验（重算公式、检查 has_table、核对大纲层级），形成 verify-then-submit 闭环。第四，skill 注入对前沿模型边际甚至有害，说明静态流程会限制零样本编排，建议改用可被模型选择性调用的动态技能，或学习何时遵循流程。第五，任务规模 210 偏小且人工合成，建议结合真实协同编辑日志并配合自动化变异扩增以扩充规模与真实性。

未来方向

作者明确计划继续扩展基准：增加更多文档域、更大的工作流包以及更多格式特定操作，同时保留确定性验证与人工质检。基于本文成果可延伸的方向包括：其一，把三类失败模式作为训练信号，构造非破坏性、状态感知智能体的微调数据或奖励函数。其二，将确定性验证器发展为在线护栏，从离线评测走向实时执行保护。其三，把分类法推广到协作编辑（多智能体并发改同一文档）以及带外部服务依赖（邮件、数据库、审批系统）的真实工作流。其四，研究跨 harness 的统一 token 计量协议，使成本与效率对比更公平。其五，针对文档操作中的记忆与长上下文管理（公式依赖链、跨表引用）做专门设计，缓解 Excel 这类强耦合场景的崩溃。其六，针对破坏性编辑设计可逆操作与文档版本化机制，把每次编辑纳入可审计的事务。

复现评估

复现性整体良好。作者公开了代码与数据（github.com/icip-cas/DocOps），每个任务以自包含 Harbor bundle 发布，含源制品、自然语言指令、可选文档技能与确定性验证器；Harbor 统一管理任务容器、智能体执行与验证器调用，运行离线、确定性、可复现，且任务文件、智能体运行时与验证器相互隔离。附录给出模型服务细节（API 访问与本地 vLLM 配置：单 A800 节点 8×80GB、tensor parallel 8、bfloat16）、各 harness 配置与 w/o skill 的确定性去除脚本。难点在于：评测依赖大量当时版本的前沿与开源模型（GPT-5.5、Claude Sonnet 4.6、Qwen3.6 系列、Gemma4 等），第三方未必随时可得且会随时间漂移；任务构造高度依赖 PhD 级人工评审与结构有效制品合成，扩展新任务门槛高；部分 token 成本为标定估计。算力上本地开源模型需 8×A800-80GB。综合复现难度中等偏上：框架与数据可复现，但完整复现全部实验需相当 API 预算与算力。

DocOps：自主智能体复杂文档操作的确定性可验证基准 DocOps: A Verifiable Benchmark for Autonomous Agents in Complex Document Operations