戳破企业Agent “全能助手” 幻象！北大开源1151项任务新基准

智猩猩AI整理

北京大学 DCAI 团队 投稿

Agent 正在大规模进入企业内部。

很多团队会先给它接 RAG 知识库或者数据库，试图让 Agent 盘活过往的数据资产，成为企业内一个有问必答的 “全能助手”，通晓销售、交付、财务、人事、项目管理等不同部门的问题，也让管理者可以从一个入口拿到答案。

麻烦也从这里开始，不同部门的数据资产与问题，天然长在不同的数据格式上，因此大模型的查询方向便不同。

更复杂的问题会把这些混在一起。先看制度确认费用口径，再查表算金额，最后找受影响项目。

用户看到的是同一个聊天入口，Agent 下面要调动的却是RAG、Table 和 Graph三类数据。

工具接上了，模型未必知道该去哪类数据里找。入口选错了，后面模型再会推理，也可能沿着错误证据一路走偏。

这就是 WorkSurface-Bench 想测的能力。北京大学 DCAI 团队发布了一个包含 1,151 个任务的基准测试 WorkSurface-Bench，旨在评估 Agent 是否能够从文档、结构化表格以及知识图谱中选取、检索并整合相关证据。

此外它还配套了一个 WorkSurface-Build，把问题往前推了一步，很多企业最初并没有干净的文档、表和图，只有一堆原始文件，WorkSurface-Build 则可以测出 Agent 能不能先把这些原始工作资产整理成后续可用的数据环境。

两个部分合在一起，可以给企业 Agent 做一次更接近真实工作的测试。

01

WorkSurface-Bench：

测 Agent 会不会用已有数据环境

WorkSurface-Bench 首先建立了一个统一共享的 workspace ，并把同一个 workspace 里的资料整理成三类 surface，分别是RAG、表格、依赖图。

这一步的价值，首先是保留了企业数据原本的差异。文档、表格和关系链放在同一个工作区里，又分别用适合自己的方式被查询。

模型面对问题时，必须先判断该打开哪类入口，不能默认把所有问题都塞进文档检索。

第二个好处是评测结果更容易解释。

Agent 答错以后，WorkSurface-Bench 可以继续看它有没有选对 surface，有没有拿到对应证据，最后有没有把证据用对。

这样一来，错误不会全部堆到“模型能力不够”这个笼统结论上。

第三是能测量 surface 的任务。

共享 workspace 让 RAG、Table 和 Graph 之间有共同业务背景，模型需要在同一件事里组合多种证据，这比单独测三套工具更接近企业 Agent 的使用方式。

02

数据集：多环节可验证

在一次完整回答里，企业 Agent 要先判断需要哪些知识资源，再收集对应证据，最后生成答案。

WorkSurface-Bench 的数据集就是围绕这条过程来设计的。

除了问题和标准答案，它还把路由、证据和回答这几个环节都留成可检查对象。

对应到每道题上，数据集会标出需要访问的 surface，也会配上可验证的 gold evidence。不同类型任务的证据要求并不一样：

Table 任务需要有执行过的 SQL 或可验证的数据视图来支撑答案；RAG 任务需要能够定位到文档中的具体片段；Graph 任务需要能够验证路径或终点节点；Cross-surface 任务则需要明确哪些 surface 共同参与了最终答案。

数据集的构建分为五步。

先从 Workspace-Bench-Lite 固定 100 个 source task 和源文件版本，再把同一批材料整理成 RAG、Table、Graph 三类可查询 surface；

随后生成带 gold evidence 的 atomic task，经过确定性检查和多模型筛选，最后由人工抽样审核。

这样留下来的题目既能回答，也能追到背后的 SQL、文档片段或图路径。

数据集最终收录了 1,151 个 atomic task。这些任务经过自动检查、多模型筛选和人工审核，保留下来的重点是可回答、证据正确、问题自然，并且确实需要对应的 surface。

对企业 Agent 来说，这类数据集的意义在于，它给出总分，也能暴露模型在路由、证据和推理上的具体问题。

03

评估与审核：

针对性解决问题

数据集做出来以后，还要回答两个问题：模型跑完怎么评分？题目本身怎么保证可靠？WorkSurface-Bench 把这两件事分开处理。

评分部分主要看 Agent 的完整执行过程，一共包含 5 个环节：

Route看它选择了哪些 surface；Evidence看它有没有获取题目要求的证据；Answer看最终回答是否正确；Efficiency则评估工具调用次数和资源消耗；最后再将这些指标合成为Aggregate，让不同模型、不同设置能够放在同一张表里进行横向比较。

基于这个设计，失败不会被压成一个模糊的错误，可以针对性选择解决方案。

Route 低，问题可能出在入口选择；Evidence 低，问题可能出在检索、表查询或图遍历；Answer 低，问题更可能出在计算、推理或答案组织；Efficiency 低，则说明 Agent 为了得到答案绕了太多路。

题目质量则交给人工审核再过一遍。研究团队抽取 200 个分层样本，让 3 位 annotator 独立检查，覆盖不同 surface 组合。

审核内容包括题目能不能回答、证据是否正确、答案是否可靠，以及标注的 surface 是否真的必要。

最终，这 200 项样本全部通过多数票，其中 192 项三人完全一致通过。

04

对照实验：评测结果

可作为工程诊断参考

实验部分用 4 个 backbone 和 6 种 agent setting 跑出了27,624 条 released trajectories。

这个数字来自 4 个模型、6 种设置和 1,151 个任务的组合。

模型当时选了什么 surface，调用了什么工具，拿到了什么证据，最后怎么回答，都能回到轨迹里看。

六种设置可以理解成一组逐步放开的对照实验。

实验结果很清楚。

相比固定只走单一入口的基线，开放 RAG、Table 和 Graph 组合使用以后，整体表现提升了 14.4 到 29.5 分。

企业 Agent 面对复杂问题时，多源工具确实有价值。只靠一类入口，会把很多问题提前限制住。

Route F1 和 Answer accuracy 的 Spearman 相关系数是 0.62，二者明显相关，但没有完全绑定。

即使在 gold constrained 设置下，Route F1 已经达到 98.7 到 99.8，答案准确率仍然只有 56.1 到 75.3。

模型找对入口以后，还要读对证据、算对数字、沿着图关系走对路径。

任务类型上的差异也很明显。单一 surface 任务相对容易，cross-surface 任务最容易暴露问题。

Always RAG 在 RAG 问题上还能工作，一到 Table、Graph 和 Cross 任务就掉得很厉害。

Naive router 比 Always RAG 稳一些，但遇到需要组合多个 surface 的问题，仍然容易卡住。

所以 WorkSurface-Bench 的结果也非常适合拿来做工程诊断。

这个 Agent 适合接什么数据，遇到什么任务会失手，应该先改路由、检索、表格计算，还是图关系遍历，都能看得更具体。

05

WorkSurface-Build：

测 Agent 会不会自己整理数据环境

WorkSurface-Bench 部分默认 RAG、Table 和 Graph 已经准备好了，Agent 要做的是选择、查询和组合。

可是在真实企业场景中，很多团队一开始拿到的往往是一批原始工作文件。里面有文档、表格、方案、历史版本、交付物和目录关系等，这些数据资产并没有经过索引、显示建图等处理，处于相较原始的状态。

所以 WorkSurface-Bench 还配套了一个前置评测——WorkSurface-Build。

测试开始时，Agent 先看不到后面要回答的问题，只会拿到一个原始 workspace、角色说明和构建预算。

它可以自行创建可复用的成果，比如 RAG 索引、SQL 数据库、图结构，也可以做混合表示。

构建完成后，这些成果会被冻结，再交给固定的 Worker 去回答对应的 WorkSurface-Bench 问题。

其中关键的一个设计是：Build 没有预设唯一正确的数据整理方式。

一个构建结果好不好，最后看下游回答质量、证据能不能回到原始来源、查询是否高效，以及前期构建成本能不能被后续任务摊薄。

这个设计贴近企业知识工程的真实状态。

企业想要的是一套可以反复使用的数据环境。今天销售问 SKU 毛利，明天交付问验收细节，后天项目经理查下游影响，如果 Agent 每次都从原始文件里临时翻一遍，成本和稳定性都很难控制。

Build 评估的，就是 Agent 有没有能力先把工作区整理成以后能继续用的知识资产。

具体实验上，WorkSurface-Build 复用了 1,151 个经过审核的 WorkSurface-Bench 问题，并且不需要在任务级别进行额外的回答注释处理。

这样一来，Bench 和 Build 形成了前后两段测试。

前者看 Agent 会不会用已有数据环境，后者看 Agent 能不能自己把原始工作区整理成可用的数据环境。

06

结语

当 Agent 进入企业内部，数据检索的准确性会直接影响回答质量的上限。

WorkSurface-Bench 和 WorkSurface-Build 把评测对象放回真实的数据工作流程中，分别检验 Agent 对已有多源数据环境的使用能力，以及对原始工作区的整理能力。

这也是 DCAI 团队 DataCentric AI 方向的一部分，让模型能力评估从单次问答走向数据组织、证据检索和可复用工作环境。

关注+星标，获取AI前沿进展与开源一线动态