企业级Agent的多表面知识路由——北大WorkSurface基准评测及其对银行的启示
核心摘要
- 企业Agent入口选错，再强推理也会一路跑偏
- 路由正确但答案未必正确，中间隔着证据鸿沟
- 开放多源工具组合，整体表现提升14.4至29.5分
- 银行数据天然多形态，跨文档跨表跨链路检索成刚需
企业级Agent的多表面知识路由——北大WorkSurface基准评测及其对银行的启示
企业Agent入口选错，再强推理也会一路跑偏
路由正确但答案未必正确，中间隔着证据鸿沟
开放多源工具组合，整体表现提升14.4至29.5分
银行数据天然多形态，跨文档跨表跨链路检索成刚需
2026年7月28日，北京大学DCAI（Data-Centric AI，数据为中心人工智能）团队联合中关村研究院、中国科学院大学，在arXiv上发布了企业级多表面知识路由基准数据集WorkSurface-Bench（论文编号2607.25765），并同步开源了配套的前置评测WorkSurface-Build。这一成果直指当前企业Agent评测的一个关键盲区：大多数基准只看"最终答案对不对"，却无法回答"Agent到底是在哪一步走偏的"。
对于正在把智能体引入信贷、风控、运营、合规等场景的银行业而言，这份基准的价值远超一篇学术论文本身。它提供了把Agent能力从"单次问答"拉回"数据组织、证据检索与可复用工作环境"的真实工作流评测方法，也为银行建立自己的Agent验收体系提供了可直接借鉴的工程范式。
一、为什么"全能助手"会破灭：入口之错的一票否决
企业Agent落地的典型路径，是先给模型接上RAG知识库或数据库，让它"有问必答"。但麻烦恰恰从这里开始：企业数据天然散落在不同格式中——制度流程藏在非结构化文档里，金额口径沉淀在结构化表格中，系统依赖关系则盘踞在知识图谱里。面对"先查制度确认费用口径，再查表算金额，最后找出受影响的关联项目"这类真实问题，Agent必须跨格式协调证据。
WorkSurface-Bench想测的，正是模型有没有能力"选对入口"。研究将其定义为表面路由（Surface Routing）：面对一个问题，Agent需要先判断该访问文档（RAG）、表格（Table）还是依赖图（Graph），再决定如何检索与组合。入口一旦选错——该查表的去翻了文档——后续推理能力再强，也会沿着错误证据一路跑偏。
二、数据集与评分：把一次回答拆成五个可诊断的环节
WorkSurface-Bench共包含1,151个原子任务，全部源自5个角色限定的Workspace-Bench-Lite工作区，并投影到RAG、表格、依赖图三类可路由知识表面。其中跨表面任务488个、纯表格279个、纯RAG 213个、纯图谱171个——跨表面任务占比最高，正是企业真实工作中最棘手也最常见的形态。
与"只报总分"的传统基准不同，WorkSurface-Bench对每个任务给出四维过程分，再合成总分：
| 评分环节 | 考察内容 | 分数低说明什么 |
|---|---|---|
| Route（路由） | Agent选择了哪些数据入口 | 找错了知识形态，问题出在"入口选择" |
| Evidence（证据） | 是否获取了题目要求的证据 | 入口对了但没拿全证据，检索/查询/图遍历有缺口 |
| Answer（回答） | 最终答案是否正确 | 证据齐备但计算、推理或合成出错 |
| Efficiency（效率） | 工具调用次数与资源消耗 | 绕了太多路，成本不可控 |
| Aggregate（总分） | 四维加权合成 | 横向比较不同模型与设置的统一口径 |
同时，数据集保证答案可验证（Auditable）：表格类答案由执行DuckDB查询复现，文档类答案锚定到验证过的文本片段，图谱类答案追溯到源依赖标注，全程可审计、可复现。质量控制上，团队抽取200个分层样本由3位标注者独立审核，全部以多数票通过六项质量标准，其中192项三人在全部标准上完全一致。
三、实验发现：路由正确≠答案正确
研究使用GPT-4o-mini、DeepSeek-V4-Pro、Gemini-3.1-Pro、GPT-5.5四个模型主干，在六种受控设置下跑出27,624条无协议错误的完整轨迹。六种设置可视为一组逐步放开的对照实验：
| 设置 | 语义 |
|---|---|
| S1 Closed book | 闭卷：不暴露任何知识表面工具 |
| S2 Always RAG | 只暴露文档检索这一条入口 |
| S3 Single-surface routing | 回答前先选一个表面 |
| S4 All tools | 同时暴露RAG、表格、图谱三类工具给ReAct智能体 |
| S5 Gold-constrained | 提供黄金表面标注，仅暴露必要工具 |
| S6 Gold-hint/all | 提供黄金标注但保留全部工具，隔离"信息提示"与"工具裁减" |
其一，多源组合价值显著。相比固定只走单一入口的基线，开放RAG、Table、Graph组合使用后，整体表现提升了14.4到29.5分。只靠一类入口，会把大量真实问题提前限制住。
其二，路由不等于答案。即使在黄金标注受限（S5）条件下，Agent的Route F1已达98.7-99.8，最终答案准确率却仍只有56.1-75.3。Route与Answer的Spearman相关系数为0.62——强相关但远未绑定。这说明"找对地方"只是必要不充分条件，Model在拿对证据、算对数字、走对图路径上仍存在巨大鸿沟，而这一点恰恰是传统端到端评测永远看不到的。
其三，跨表面任务最容易暴露短板。Always RAG在纯RAG问题上尚能工作，一旦遇到Table、Graph与Cross任务就大幅掉点；即便是更稳健的Naive router，面对需要组合多个表面的复杂问题仍容易卡住。跨表面合成是当前企业Agent明确的能力洼地。
四、WorkSurface-Build：把评测窗口前移到"原始数据"
WorkSurface-Bench默认数据环境已就绪。但真实企业往往只有一堆未索引、未建图的原始文件。为此团队配套了前置评测WorkSurface-Build：测试开始时Agent看不到后续问题，只拿到一个原始工作区、角色说明与构建预算，需自行整理出可复用的数据环境——无论是RAG索引、SQL数据库、图结构还是混合表示。
构建成果会被冻结，再交给固定Worker去回答WorkSurface-Bench的1,151个问题。其关键设计在于不预设唯一正确的整理方式：成果好坏靠下游回答质量、证据能否回溯原始来源、查询效率以及构建成本能否被后续任务摊薄来检验。
这构成了"先建后用"的前后两段测试：WorkSurface-Bench检验Agent"会不会用已有数据环境"，WorkSurface-Build检验Agent"能不能把原始工作区整理成可用数据环境"，二者合起来贴近企业知识工程的真实生命周期。
五、对银行的意义：从"能答对题"到"能在真实数据流中干活"
对银行业而言，这一基准的启示可以概括为三层。
5.1 直击银行数据"多形态"的真实命门
银行是所有行业中数据形态最庞杂的机构之一：制度办法、监管口径、产品条款沉积在非结构化文档中；客户信息、交易流水、利率参数、风险计量结果存储在结构化表库中；而"核心系统—渠道系统—风控系统"之间的调用关系、数据血缘与依赖链路，本质上是一张巨大的知识图谱。
以一条真实的信贷审批场景为例："查询某对公客户近三个季度的现金流，结合贷后检查报告中的风险信号，确认其是否在集团关联企业中跨担保"。这道题同时需要表格查询（现金流）、文档检索（贷后报告）与图谱遍历（关联关系与担保链路）——正是WorkSurface-Bench定义的跨表面任务。当前许多银行试点Agent在这类任务上掉点，并非模型推理能力不足，而往往是从"查错入口"开始系统性跑偏。WorkSurface-Bench把这种失真的根本原因第一次变成了可量化、可定位的诊断指标。
5.2 为银行Agent验收建立"四维归因"标准
银行对AI应用的验收历来偏重"最终结果正确率"，这导致两个问题：一是错误无法归因，部门间相互推诿（模型问题、数据问题还是Prompt问题说不清）；二是迭代缺乏方向。WorkSurface-Bench的Route/Evidence/Answer/Efficiency四维评分，恰好提供了银行可以照搬的验收框架：
- 路由维度对应"知识调度是否走对"——适合评估Agent对制度库、数据仓库、系统血缘的入口选择能力；
- 证据维度对应"数据取用是否完整、可追溯"——直接呼应银行监管对数据溯源与留痕的要求；
- 回答维度对应"计算结果与业务推理是否正确"；
- 效率维度对应"查询成本与资源消耗是否可控"，对涉及核心系统查询的银行场景尤为重要。
5.3 "先建后用"观点映射银行的存量数据治理
WorkSurface-Build提出的"原始工作区→可复用数据环境"命题，与银行数据治理的现实高度同构。多数银行的数据资产停留在"原始可用但不可问答"的状态——报表堆积、口径不一、血缘不明。Build评测给出的启发是：银行若要规模化部署Agent，必须先完成面向Agent的"数据就绪度"改造——建立可供RAG检索的规范制度库、可供SQL计算的口径统一数据湖、可供图谱查询的系统依赖血缘图，并让这三者共享同一业务语义。否则，Agent永远只能在临时翻找原始文件的高成本、低稳定模式下运行。
5.4 对银行工程落地的四点建议
基于上述分析，提出四点可操作的落地建议：
- 建立银行自有的"表面路由"评测集：抽取真实业务场景构造跨文档、跨表、跨图谱的评测题，作为Agent上线前的准入门槛，而非仅用通用问答准确率准入。
- 区分路由层与证据层的能力优化：五环节评分能指出瓶颈究竟在入口选择还是证据取用，据此分别优化检索召回、SQL生成或图谱遍历，避免一刀切地"换更大的模型"。
- 用Build思路倒逼数据治理：将"Agent能否从原始工作区构建出可复用数据环境"纳入数据工程团队KPI，推动制度库、数据湖、血缘图三张底座的协同建设。
- 对高风险操作型Agent设冷静期：在当前Answer准确率普遍仅56%-75%的现实下，涉及资金变动、客户授权等操作型Agent应先在证据链可追溯的沙箱中长时间验证，再考虑受控上线。
六、结语
WorkSurface-Bench与WorkSurface-Build的价值，不在于又多了一个"刷榜"的测试集，而在于它把企业Agent的评测从"单次问答"拉回到"数据组织、证据检索与可复用工作环境"的真实工作流中。对银行而言，智能体的价值最终取决于它对机构内多形态、高复杂度数据资产的驾驭能力——这份基准给出了衡量该能力的第一把有刻度的尺子，也指明了从"能答对题"走向"能在真实数据流中干活"的工程路径。
常见问题（FAQ）
Q1：WorkSurface-Bench和现有RAG评测基准有什么区别？
A1：现有RAG基准主要看最终答案是否正确，把"选错入口"和"用错证据"两类失败混为一谈；WorkSurface-Bench把这两个能力拆开，用Route和Evidence两个独立维度分别打分，还能精确指出失败发生在路由、证据还是推理环节。
Q2：为什么模型路由选对了，答案还是错的？
A2：Route F1高达98.7-99.8，但Answer只有56.1-75.3，说明"选对入口"只是必要条件。入口对了之后，还可能因检索证据不全、SQL计算错误、图谱路径遍历失误或跨源合成偏差而答错，这四类原因需要依赖Evidence与Answer维度进一步区分。
Q3：这份基准对银行落地Agent有什么直接用处？
A3：银行数据天然横跨制度文档、业务表格与系统血缘图谱，跨表面任务正是银行真实业务的高频形态。银行可借鉴其四维评分构建自有验收体系，用Build思路推动数据就绪度改造，并对操作型Agent保持审慎的准入节奏。
Q4：开放多源工具到底能带来多大提升？
A4：论文实验显示，相比固定单一入口（如只用RAG），开放RAG、Table、Graph组合使用后整体表现提升14.4到29.5分，印证了多源组合对企业Agent复杂问题的价值。
参考资料
- WorkSurface-Bench论文（arXiv:2607.25765）：北京大学DCAI团队，2026年7月28日
- 数据集与评测代码：github.com/haolpku/WorkSurface-Bench
- 数据集：Hugging Face lhpku20010120/WorkSurface-Bench
作者毕超，金融行业风险管理从业者。本文仅代表作者个人观点，不构成任何机构立场。