Workspace-Bench：面向大规模文件依赖的AI Agent工作空间学习评测基准

• Workspace-Bench：首个系统性评测 AI Agent 工作空间学习（Workspace Learning）能力的 Benchmark，由上海交通大学与 ByteDance 联合提出，聚焦大规模异构文件间的依赖推理
• 5 种用户画像、74 种文件类型、20,476 个文件（最大 20GB），构建高度真实、深度嵌套的数字工作空间环境
• 388 个依赖驱动任务、7,399 条细粒度 Rubric，覆盖 6 大协同能力维度，每个任务平均标注 5.1 条依赖边、跨 4.7 个不同文件
• 27 种组合（4 种 Agent Harness × 7 种 Backbone LLM）全面评测，最强组合仅 ~60%，平均仅 43.3%，远低于人类专家 + 工具辅助的 80.7%
• 额外提供 Workspace-Bench-Lite（100 任务子集），保持分布一致性，评估成本降低约 70%

Intro

近年来，Foundation Model 和 Agent Harness 的快速发展显著扩展了 AI Agent 的操作边界。从 OpenAI 的 ChatGPT Agent、Anthropic 的 Cowork/Claude Code，到开源框架 OpenClaw、Hermes——这些系统不仅提供模型推理能力，更集成了 MCP（Model Context Protocol）工具调用、持久化状态管理、长程任务编排、安全护栏和系统化评估机制等系统级能力。这使得 AI Agent 在减少日常乃至高级任务中的人力投入方面展现出越来越大的潜力。

然而，当前 Agent 在真实工作场景中的表现仍远未达到可靠水平。在 TheAgentCompany 上，表现最好的 Agent 也仅能完成 24–30% 的任务；在 OfficeBench 上，GPT-4 Omni 仅取得 47.0% 的成绩。更令人担忧的是，Anthropic 内部分析显示，虽然 Claude Code 在 2025 年 8 月至 12 月期间难度任务成功率翻倍，但每次会话中平均仍需 3.3 次人工干预——人类监督仍然不可或缺。在实际部署中，49% 的企业将推理成本列为扩展 AI Agent 的首要障碍，近半数企业将 76–100% 的 AI 预算仅用于推理。

论文作者对 ByteDance 内部 Lark 平台的 154 个真实任务场景进行了深入分析，揭示出核心瓶颈：真实工作空间中的任务要求 Agent 具备 Workspace Learning（工作空间学习）能力——即识别、推理、利用和更新异构文件之间显式与隐式依赖关系的能力。典型例子包括：

• 撰写高度定制化的销售提案需要协调非结构化的客户档案、历史沟通记录和结构化的行业知识库
• 更新项目预算需要交叉引用多个电子表格的原始数据、从看似无关的演示文稿中提取修订后的市场预估，并对照 CFO 的非正式邮件来验证最终数字

然而，现有的 Agent Benchmark 在评测工作空间学习能力方面存在严重不足。论文将现有 Benchmark 分为四类，并逐类分析其局限性：

1) Prompt-Driven Benchmarks（如 OneMillion-Bench、CL-Bench）：将所有任务信息完全嵌入自然语言指令中，完全不需要与外部环境或实际文件交互，从根本上绕过了办公工作流的核心操作媒介。虽然适合评测纯粹推理能力，但无法反映 Agent 在真实文件系统中的表现。

2) Open-Source/Environment-Driven Benchmarks（如 OSWorld、Odysseys Bench、WebArena、CRMArena-Pro）：要求 Agent 通过工具调用与动态环境（API、Web、操作系统）交互。这些 Benchmark 虽然引入了多步执行，但主要关注动作接地和 API 编排，忽略了日常知识工作的核心——在复杂的、关系型本地文件生态系统中进行导航、推理和管理。

3) Task-File-Driven Benchmarks（如 OfficeQA-Pro、GDPVal、DataCross）：引入了实际文件处理，但将任务视为独立问题，直接提供预打包的任务特定文件给 Agent，更像"孤立文档 QA"而非真实办公。Agent 完全不需要从复杂文件生态中自主搜索、过滤和发现关键信息。

4) Workspace-Relevant Benchmarks（如 OfficeBench、TheAgentCompany、SWE-Bench）：是最接近真实的尝试，模拟了完整的工作结构并需要动态工具调用。但仍存在关键瓶颈：(i) 依赖单一的、单一风格的文件系统结构，缺乏角色多样性；(ii) 主要覆盖不到 10 种基本文件格式，缺少真实场景中 50+ 种多样化格式；(iii) 任务虽涉及多个文件，但将跨文件协同视为隐式副产品，而非显式评估任务到数据的依赖发现；(iv) 完全缺失文件血统关系（Lineage Relations）——即追踪版本历史和派生的能力。

⇒ 开发一个能够系统评测 Agent 工作空间学习能力的 Benchmark —— Workspace-Bench，填补从原子化技能到工作空间感知推理之间的评测鸿沟。

工作空间学习的五个阶段

论文提出了 Workspace Learning（工作空间学习）的概念——Agent 原生感知、推理和利用工作空间中异构实体之间结构化关系网络的能力。其核心洞察是：真实办公工作不是对独立数据对象的一系列原子操作，而是一个通过导航复杂关联关系图谱来持续转换信息的过程。作者将工作空间学习的演进分为五个阶段：

• L0：数据不敏感执行（Data Insensitive Execution） — Agent 作为被动顾问而非主动数据操作者。系统接收任务相关数据作为输入，仅向用户提供高层操作指导（如分析步骤和工作流程），实际的数据录入和交叉引用完全由用户完成。Agent 与数据和工作空间完全隔离，功能主要依赖 LLM 的基础能力，Harness 的支持微乎其微。例如，当用户需要执行财务审计时，Agent 可能告知用户所需的 Excel 公式或银行对账单与分类账之间的具体核对步骤，但实际的数据操作仍由人工完成。
• L1：用户指定文件执行（User-Specified File Execution） — Agent 作为被动执行器，完全依赖用户提供显式文件路径和操作序列。虽然能够处理特定数据，但将文件视为孤立实体，缺乏对文件间逻辑依赖的全局感知。如同现代 GUI Agent 所展现的，它们擅长局部的、单应用操作，但在高级意图与碎片化工作空间结构之间的桥接上挣扎——这导致 Task-File Omission（任务-文件遗漏）：Agent 无法从高级任务描述定位到正确的文件。例如，用户可能指示 Agent 从特定 CSV 文件生成柱状图并插入指定演示文稿幻灯片，Agent 能够基于提供的数据成功完成，但无法识别这些文件之间的协同关系。
• L2：文件间依赖推理（File-to-File Dependency Reasoning） — Agent 开始主动识别用户提供文件之间的显式和隐式依赖关系。通过映射依赖关系，Agent 理解不同文件如何共同运作。然而当前 Agent 在此阶段经常失败——例如错误选择命名中的"最终版"文件（如 report_final_v2.docx vs report_final.docx）而非真正的最新版本，因为它们缺乏区分命名约定与实际文件时效的时间感知能力。此阶段到达 编排奇点（Orchestration Singularity）：Harness 对任务执行的贡献开始超过 Foundation Model，因为多文件处理需要长程任务规划、中间状态管理和对不同文件应用不同技能等 Harness 级机制。
• L3：任务到文件的依赖发现（Task-to-File Dependency Discovery） — Agent 进化为主动探索者，能够根据高层任务意图在整个数字工作空间中自由探索。核心能力从分析显式提供的数据转变为自主发现相关数据及其底层结构。人类用户的角色退化为观察者，Agent 的贡献逐渐超过人类。此阶段到达 能力奇点（Capability Singularity）：Agent 具备端到端独立处理任务的能力。评测显示当前 Agent 在接近此阶段时性能单调下降——从 Easy 任务的 57.6% 骤降至 Hard 任务的 40.5%。例如，当用户请求"为某区域扩张准备审计报告"时，Agent 需要自主导航深层嵌套目录以查找最新的预算电子表格、法律合同和利益相关者邮件，映射其结构关系，过滤无关版本，无需用户指点具体文件位置。
• L4：工作空间原生自进化（Workspace-Native Self-Evolution） — Agent 成为与用户数字工作空间和历史上下文共同演化的"活体伙伴"。Agent 将每次任务执行和环境变化内化为隐式反馈，持续优化自身能力。例如，当本地工作空间安装了新软件时，Agent 应能高效检测到此修改并无缝将该应用集成到其可用工具库中以供未来调用。这是工作空间学习的终极阶段，代表着 Agent 从工具使用者到环境共演化者的质的飞跃。

从 L2 开始，Harness 的贡献持续大于 Foundation Model。在 L3/L4 阶段，所需的工作空间学习能力与当前 Agent 孤立文件处理范式之间的失配不断扩大，形成 数据关联鸿沟（Data Association Gap）——这是当前 AI Agent 尚未能跨越的根本性瓶颈。跨越这一鸿沟需要重新思考 Agent Harness 如何发现、表示和利用跨文件依赖关系。

Benchmark 构建

Workspace-Bench 的设计遵循四大核心原则，使其与现有 Agent 和文档 Benchmark 有本质区别：

(1) 高保真关系型工作空间（High-Fidelity Relational Workspaces）：现有 Benchmark 通常将数据放置在干净、独立的文件中，而真实工作场景要求 Agent 在混乱的数字工作空间中导航。Workspace-Bench 构建了包含数千个相互关联工件的工作空间，Agent 必须处理隐式约定、角色特定文件组织和嘈杂的工作空间结构。这与静态 Benchmark 有本质区别——它迫使 Agent 像"团队成员"一样理解组织的"谁、做什么、在哪里"。

(2) 依赖驱动的推理（Dependency-Driven Reasoning）：许多跨文件 Benchmark 仅测试表面级聚合。而真实工作空间任务通常需要从不同位置检索上下文相关文件并对其依赖关系进行推理——包括显式引用、语义关系、模态转换、版本血统。Workspace-Bench 的 388 个任务被设计为不能通过简单关键词搜索解决，需要追踪项目生命周期中决策的血统，协调跨异构源的证据。

(3) 真实任务标注（Authentic Task Annotation）：LLM 生成的任务虽然可规模化，但往往遗漏真实专业工作流的结构复杂性和隐式约束，尤其是在需要导航多模态、相互依赖的工作空间时。Workspace-Bench 从真实办公场景中整理任务，由领域专家手工标注，LLM 仅作为辅助工具用于验证和 Rubric 优化，任务逻辑、依赖规范和参考输出保持人工管理。

(4) 过程感知的细粒度评估（Process-Aware Fine-Grained Evaluation）：单一成功率分数不足以诊断 Agent 在工作空间任务中的行为。Agent 可能生成看似合理的最终摘要，却依赖了过时的文件版本或忽略了所需的支持文档。Workspace-Bench 不仅评分最终输出，还评估关键中间决策——是否识别了正确的文件、是否遵守了依赖约束、是否使用了正确的文件版本。

工作空间构建

构建了五种代表性职业角色的工作空间：运营经理（Operations Manager）、物流经理（Logistics Manager）、产品经理（Product Manager）、后端开发者（Backend Developer）和研究员（Researcher），覆盖互联网公司中不同的工作流和文件组织结构。每个工作空间配备了显式的组织结构，编码了报告关系、团队成员和项目职责，使得需要角色约束和隐式知识的任务成为可能。

采用自顶向下的两阶段混合构建流水线（Top-Down Two-Stage Hybrid Construction Pipeline），模拟真实工作空间自然演化的三个属性：深度嵌套的目录结构、语义噪声文件（过时草稿和历史修订）、隐式跨文件依赖：

第一阶段：结构生成（Structure Generation）。不同职业角色按照不同的工作流组织文件。例如，开发者通常维护 src/、tests/、docs/ 等目录，而研究员可能围绕 literature/、experiments/、results/ 组织文件。为捕捉这种多样性，首先为每种角色定义详细画像——包括职责、典型工作流、文件使用模式和领域特定术语。然后基于这些画像，利用 Agent 生成反映角色特定工作空间组织的树状目录层次结构。同时引入受控结构噪声——冗余文件夹、歧义名称（如 report_final、report_final_edited）、归档目录等——以更好地匹配真实文件系统。

第二阶段：内容填充（Content Population）。采用混合策略，结合真实世界数据检索和扎根式生成。首先部署语义驱动的 Agentic Crawler，遍历生成的目录树并根据文件路径的语义上下文自主抓取相关公开资源——如 arXiv 论文、GitHub 仓库、技术文档、报告、电子表格和演示文稿材料。然后利用 LLM 基于收集到的文件合成相关工件——如讨论某篇论文的邮件、引用设计文档的会议记录、基于电子表格派生的分析报告等。这一过程在丰富工作空间的同时有效缓解了纯合成语料的同质化问题，成功在整个文件系统中注入了深层文件关系。

最终由领域专家审核模拟文件系统，验证其合理性和结构一致性——重点关注目录层次是否与目标画像匹配、文件内容是否与其位置保持一致、注入的文件关系是否能够支撑有意义的工作空间任务。构建完成的工作空间包含三大核心挑战：

• 任务相关文件检索：Agent 需要在嵌套目录结构中导航，从噪声候选中识别相关文件
• 版本追溯（Lineage Understanding）：Agent 需要区分同一工件的多次修订——如 report_v1、report_reviewed、report_final——理解版本演化关系
• 异构源推理（Heterogeneous-Source Reasoning）：Agent 需要跨模态连接信息——如将幻灯片中的图表与其源电子表格关联，或将讨论邮件与对应的设计文档连接

任务构建

基于构建的工作空间，人工构建了 388 个任务。每个任务以自然语言请求的形式编写，且故意欠指定（Intentionally Under-specified）——Agent 必须检查工作空间结构并恢复相关文件依赖才能完成任务。任务覆盖从常规操作（表单填写、文件组织）到复杂多步请求（通过协调先前文档、近期代码变更和项目状态更新来准备周报）的广泛范围。为确保真实性和可评估性，论文避免了 LLM 全自动生成，而是采用问题驱动的人工整理流水线：

1) 真实工作流收集（Sourcing Authentic Workflows）。首先通过内部问卷收集真实工作场景中的工作流——参与者提供任务描述、预期输入和期望输出。领域专家随后筛选收集到的工作流，去除琐碎或欠指定的案例，保留需要非平凡工作空间探索和跨文件推理的任务。选定的工作流被标准化为 154 个代表性任务场景——例如综合客户档案、购买历史和交互日志来生成客户评分和个性化推荐。

2) 多维度任务标注（Multi-dimensional Task Annotation）。25 名标注者根据五种工作空间角色从代表性场景出发创建具体任务。对于每个任务，标注者需完成：编写自然语言指令、识别所需输入文件、生成参考答案、设计评估 Rubric。标注者进一步为每个任务构建文件依赖图谱（File Dependency Graph）——定义 Agent 为正确解决任务所必须访问或使用的最小关键文件路径集合。这一标注使得过程感知评估成为可能——判断 Agent 是否发现了正确的证据、使用了正确的文件版本、遵循了所需的依赖结构。标注者还为每个任务标记所需的能力维度和三个难度级别：仅需工作空间探索和结果提供文件的为 Easy（14%）、主要需要语义内容关系理解和任务支撑文件的为 Medium（53%）、涉及异构文件理解和血统追溯的为 Hard（33%）。

3) 客观可评估性保证（Ensuring Objective Evaluability）。开放性任务常引入人工编写 Rubric 的模糊性。为提高客观性，论文使用辅助 Agent Pipeline将模糊标准转化为数据锚定的断言——例如将"计算是否正确？"转化为"最终值是否等于 [具体值]？"。人类专家随后交叉验证所有任务、依赖图谱、参考答案和 Rubric，确保标注一致性和评估可靠性。每个任务平均由专家耗时 超过 3 小时进行标注和验证。

每个任务平均需要解析 5.1 条依赖边（跨 4.7 个不同文件），通过平均 19.1 条 Rubric 进行评估（范围 6–30，总计 7,399 条）。Rubric 分为三类：

• 结果导向（Result-oriented）— 54.8%：验证最终输出的正确性和完整性，如摘要是否包含所需的项目风险、最终计算值是否正确
• 基础（Foundation）— 25.0%：检查基本任务合规性，如文件命名、格式、存储位置是否符合要求
• 过程导向（Process-oriented）— 20.2%：评估 Agent 是否遵循了合理的推理和执行过程，如是否使用了正确的中间文件、是否按正确顺序处理了依赖

评估框架

在工作空间锚定的环境中评估 Agent 面临三个核心技术挑战，Workspace-Bench 设计了专门的自动化评估系统逐一解决：

挑战1：严格的状态隔离与高效环境恢复。由于 Agent 在工作空间内执行读写操作，防止跨任务污染并实现低延迟的文件系统状态重置是可靠评估的基础。解决方案：采用独立 Sandbox 机制——每个任务在隔离的工作空间沙盒中执行。任务完成后，运行并行 BFS 工作空间回滚算法：从根节点开始逐层比较当前工作空间与基准快照的目录树差异，复制缺失节点、强制删除多余节点、用基准副本覆盖二进制哈希不匹配的修改节点。沙盒释放回池中以供后续任务复用。

挑战2：开放工作空间中的精确结果抽取。Agent 生成的输出文件通常存储在不可预测的非固定路径中，从海量噪声文件中精确提取目标结果是重大挑战。解决方案：三路并行检索策略（Multi-strategy File Extraction）：(i) 指令约束路径提取：在任务分配阶段通过 Prompt 强制 Agent 在最终回复中显式声明结果文件的确切路径；(ii) 统一副本集中检索：强制 Agent 在全局指定目录中保存结果的额外副本，评估框架直接扫描提取；(iii) 基于元数据的全局模糊匹配：利用任务元数据中定义的目标文件特征（如预期文件名），在沙盒文件系统中执行全面的遍历和模糊搜索。最终系统聚合去重后通过三种并发策略获取的文件列表。

挑战3：长程任务的评估效率瓶颈。Workspace-Bench 中每个任务的平均执行时间超过 5 分钟，跨大量测试集会带来巨大的时间成本。解决方案：双级并行加速机制——工作空间级并行：利用五个独立的用户画像工作空间并发调度和执行不同任务，实现 5 倍评估吞吐量；任务级并行：预克隆同一工作空间的多个镜像副本并集成到 Sandbox Pool 进行动态管理，新任务被调度时自动分配空闲沙盒环境执行，实现更显著的加速效果。

评估过程中，所有 Agent 配置统一采用 Seed-2.0-Lite 作为 Agent-as-a-Judge 的 Backbone LLM，标准化的执行和评估 Prompt 统一应用于所有测试配置，确保公平评估。

Benchmark 统计

Workspace-Bench 包含 388 个任务，分布在 5 个独立的专业工作空间中。与每个任务仅提供少量孤立文件的传统 Benchmark 不同，Workspace-Bench 中每个工作空间都是一个大规模、自包含的数字环境——单个工作空间最多包含 11,020 个文件，平均每个工作空间超过 4,000 个文件。核心统计数据：

• 5 个工作空间（5 种职业角色），总计 20,476 个文件，3,299 个目录，最大目录深度 8 层，平均文件深度 3.7 层
• 覆盖 74 种文件类型：文档（.docx, .pdf, .md）、电子表格（.xlsx, .csv）——两者合计占 37.5% 和 35.3%，反映其在专业办公场景中的普遍性；演示文稿（.pptx）、代码（.java, .py, .js, .ts）——代码和配置文件贡献了额外的 12.7%，主要由后端开发者工作空间驱动；配置（.yaml, .json）、邮件（.eml）、统计数据集（.dat, .sav, .xpt）、图像（.png, .jpg）等
• 388 个任务，每个任务平均 19.1 条 Rubric（范围 6–30），总计 7,399 条
• 任务输出涵盖 16+ 种不同文件格式，包括分析报告、电子表格、演示文稿和脚本
• 任务难度分布：Easy 14%、Medium 53%、Hard 33%
• 依赖边密度分布：低密度（0–2 边）33.8%、中密度（3–5 边）36.9%、高密度（≥6 边）29.4%
• 各工作空间任务数：运营经理 122（31%）、物流经理 115（30%）、研究员 67（17%）、后端开发者 43（11%）、产品经理 41（11%）
• 6 大能力维度覆盖（多标签）：工作空间探索 67.5%、任务支撑文件利用 61.3%、结果提供文件利用 54.4%、内容关系理解 43.8%、语义异构文件理解 36.1%、版本追溯 35.1%
• 额外提供 Workspace-Bench-Lite：100 个任务的精简子集，跨所有工作空间、难度级别和能力维度严格保持分布一致性，评估成本降低约 70%

五个工作空间的文件组成差异显著。研究员工作空间是最大的，包含 11,020 个文件分布在 2,059 个目录中；产品经理工作空间最紧凑，包含 1,379 个文件组织在 309 个目录中。为模拟真实工作空间的时态演化，部分文件具有多个历史版本（如 v1、v2、final），要求 Agent 进行血统追溯。此外，文件深度嵌套在层次化目录结构中（最大深度 8 层），迫使 Agent 主动导航和发现信息，而非依赖扁平检索。

实验

实验设置

评估了 4 种 Agent Harness 搭配 7 种 Foundation Model，共 15 种配置。所有评估在 Workspace-Bench-Lite 上运行：

三种 Agent Harness 基线：

• OpenClaw：开源基线，采用解耦双循环执行架构——将高层认知规划与低层工具调用隔离，有效防止长程任务中的死锁。为缓解上下文遗忘，用结构化知识存储和语义路由层替代传统滑动窗口策略，实现跨会话共享记忆。
• LangChain DeepAgent：高度可控的白盒 Harness 基线，基于 LangGraph 的持久化有向无环图（DAG）架构。通过将核心 Agent 能力抽象为独立中间件序列（如任务分解和显式文件 I/O），将控制流逻辑与底层 LLM 解耦。通过强制内置规划工具（如 write_todos），将 LLM 内部决策树序列化，确保完全透明和可追踪的执行路径。
• Hermes：前曕性开源基线，代表配备内置学习循环的 Agent。无缝集成本地交互环境与多通道消息网关，原生利用 MCP 实现高可扩展的工具调用和子 Agent 编排。采用四层解耦记忆引擎——严格隔离静态身份指令与有界动态状态文件和 SQLite 支持的 FTS5 全文搜索归档，使用主动提取和按需注入策略显著降低 Token 消耗和认知噪声。其独特的自学习机制将试错洞察持久化到标准化本地技能库，有效跨瞬时会话保留工程经验。

七种 Backbone LLM：GLM-5.1、GPT-5.4、Gemini-3.1-Pro、Kimi-2.5、MiniMax-M2.7、Grok-4.3、Qwen-3.6-Plus。覆盖从顶级闭源模型到开源模型的完整谱系。

主要结果

整体结果：所有 15 种配置的 Rubric 通过率分布在 27%–60% 之间，平均仅为 45.1%，严重低于人类专家 + 工具辅助水平（红色参考线，80.7%）。排名前三的组合是：DeepAgent + GLM-5.1、Hermes + GLM-5.1、OpenClaw + GLM-5.1。GLM-5.1 搭配多个 Harness 均占据领先位置，表明 Foundation Model 的规划与推理能力是决定上限的关键因素。

与此同时，在相同 Backbone LLM 下，Harness 的选择也产生显著影响。例如，当使用 Gemini-3.1-Pro 时，不同 Harness 之间的性能差异可达 10 个百分点以上。这表明 Harness 的编排策略、记忆管理和错误恢复机制对最终性能有实质性影响——尤其是当底层模型的能力不足以独立弥补 Harness 的缺陷时。

此外，论文还对依赖图谱识别率进行了分析。节点 F1 分数（识别任务相关文件的能力）显著高于边 F1 分数（理解文件间关系的能力），说明理解文件间的关系比仅仅识别任务相关文件更具挑战性。Hermes 在节点 F1 上表现最优，归因于其对工作空间探索的更稳健支持。而普遍偏低的边 F1 分数突显了当前 Agent 在推导跨文件依赖方面的关键缺陷。

深入分析

发现1：Agent 在执行更高级工作空间任务时性能持续显著下降

从 Easy (51.4%) 到 Medium (46.0%) 再到 Hard (35.7%)，通过率呈阶梯式下降，验证了难度分层的合理性。在 Easy 任务中，Agent 主要执行涉及简单异构输入和较少推理步骤的原子操作（如多文件摘要或单文件编辑），即使最低配置也能维持 40%–60% 的基线。此级别的性能主要由基础 LLM 的固有能力决定，而非 Harness——共享同一 Backbone LLM 的配置之间差异很小。

然而当任务复杂度增加时，性能差距急剧扩大。Hard 任务引入了高动态性，要求 Agent 具备：文件关系发现（通过任务到文件和文件到文件的依赖识别相关文件）、长程规划（将复杂执行步骤映射到用户意图）、状态跟踪（管理中间过程）和错误恢复（在意外结果后进行重试）。性能下降是基础 LLM 推理局限性与 Harness 编排约束双重作用的结果。例如，Hermes + Gemini-3.1-Pro 在 Hard 任务上跌至 30% 以下，而 GLM-5.1 搭配三种 Harness 均展现出强大的韧性，维持在接近 60% 的通过率且仅轻微下降。

发现2：6 大工作空间任务维度中，异构文件理解和版本追溯构成当前 Agent 的主要瓶颈

大多数配置在工作空间探索和结果提供文件利用上表现相对较好。前者的熟练度源于当前 Agent 强大的工具调用能力（如执行终端命令进行文件系统导航），后者则重度依赖 LLM 的推理能力。异构文件理解（Heterogeneous File Understanding）和版本追溯（Lineage Tracing）在所有 Agent 中持续排名垫底——解析跨格式内容和对深度跨文件依赖进行推理是所有当前 Agent 系统共同面临的通用工作空间学习瓶颈。

更强的基础模型在不同维度上表现出显著方差。例如，DeepAgent + GLM-5.1 在工作空间探索上接近 50%，但在异构文件理解上降至约 30%。而较弱配置（如使用 Gemini-3.1-Pro 的组合）在各维度的任务完成率密集聚集在约 10%。这暗示不足的底层推理能力无法赋予 Harness 提升整体任务执行的能力。横向比较四种 Harness 发现：以 GLM-5.1 为例，在 DeepAgent 下其各维度表现高度聚集（集中在 30%–50%），但在 Hermes 下同一模型的能力分布变得更加分散——表明 Harness 的编排能够重塑同一 Backbone LLM 的能力分布。

发现3：不同 Harness 和基础 LLM 在不同用户画像上表现各异

多数 Agent 配置在后端开发者和研究员画像上表现更好——这些画像强调代码执行和结构化数据处理。例如，Hermes + GLM-5.1 在 Researcher 维度上接近 65%，归因于 Hermes 对代码开发和研究任务的原生编排优化。相反，在产品经理和运营经理等偏业务型画像上，平均性能基线出现相对下降——后者需要战略规划、资源分配和模糊语义理解。

由于当前 Harness 框架普遍缺乏解决工作空间任务的高级能力，Agent 的任务性能仍主要由 Backbone LLM 的固有能力决定。例如，GLM-5.1 在几乎所有画像上都形成了最外层包络，展现出异常稳健和平衡的跨领域泛化能力。而领域特定模型如 Seed-2.0-Code 在后端开发者维度上保持尚可表现，但在物流和运营管理画像上出现急剧下降。

发现4：高交互轮次和高计算成本并不保证优质表现，优秀系统展现出卓越的"推理效率"

虽然更多交互轮次通常意味着更全面的推理链和更多试错机会，但结果显示了显著的反例：Hermes + GLM-5.1 位于图表的左上象限，以极低交互轮次（< 30）和最小 Token 消耗实现了超过 55% 的平均准确率，展现出卓越的"推理效率"——优秀框架搭配顶级基础模型可以依赖强大的推理质量和精确的意图识别来快速、准确地完成任务。

而 DeepAgent + GLM-5.1 位于图表最右侧，取得了近 60% 的顶级准确率，但以极大的气泡和极高的交互轮次为代价——表明 DeepAgent 框架倾向于采用广泛探索策略，以极其高昂的经济和时间成本换取可嘉的任务成果。配置聚集在右下区域的组合（如 DA+Gemini、HM+Gemini）产生 40–60 轮交互、消耗海量 Token，准确率却停滞在 30%–45%。当底层 LLM 缺乏足够复杂的推理和自我反思能力时，Agent 极易陷入无意义的重复循环——反复调用无效工具或在遇到错误后沿错误路径越走越远。

发现5：人类专家与 Agent 协作仍然显著优于全自主 Agent

20 名领域专家在仅提供任务指令和对应工作空间文件、可使用 Agent 作为辅助工具的条件下，Rubric 通过率达到 80.7%（图中红色参考线），远超所有全自主 Agent 配置。跨任务难度比较显示：人类基线的通过率不随任务复杂度增加而显著下降——这归因于专家天生具备辨别异构文件间潜在关系并灵活利用这些联系解决问题的能力。从认知和规划角度看，人类专家的能力天然满足复杂开放任务的阈值要求。

这一发现表明：虽然 Agent 可以在真实场景中大幅提升操作效率，但人机协同（Human-in-the-Loop）仍然是确保复杂任务高质量输出的不可或缺的组成部分。核心 Agent 能力仍处于向更高级工作空间任务演进的阶段。

错误分析

为系统分析 Rubric 失败原因，论文将错误分为五类：

• 约束错误（Constraint Error）：违反文件命名约定或目标路径等规范
• 内容缺失（Missing Content）：核心信息的遗漏——这是占比最大的错误类型
• 推理错误（Reasoning Error）：统计、聚合、排序、关联或数学计算不准确——这是第二大错误类型
• 过程错误（Process Error）：Agent 执行轨迹中的缺陷
• 格式错误（Format Error）：输出结构与请求格式不符

各 Agent 配置的错误分布高度一致：内容缺失和推理错误构成绝大多数失败原因。这表明当前 Agent 在复杂文件系统中的主要瓶颈在于深度嵌入信息的全面召回和跨文件数据聚合与理解能力。相比之下，格式错误和过程错误占比极少，说明现有模型在执行基础工作流和遵循格式化输出指令方面已相对成熟——真正的差距不在于"知道该怎么做"，而在于"在复杂工作空间中正确地做对"。

Reference

[1] Workspace-Bench 1.0: Benchmarking AI Agents on Workspace Tasks with Large-Scale File Dependencies

Contact