--- title: "企业级Agent的多表面知识路由——北大WorkSurface基准评测及其对银行的启示" date: 2026-09-03 description: "深度解读北京大学DCAI团队开源的WorkSurface-Bench与WorkSurface-Build企业Agent评测基准：1,151个任务直面文档、表格、知识图谱三类数据入口，用Route/Evidence/Answer/Efficiency四维评分定位Agent失败环节，并探讨其对银行智能体工程落地的启示。" tags: ["企业Agent", "评测基准", "知识路由", "RAG", "知识图谱", "银行数字化", "大模型", "Agent落地"] schema_type: "Article" --- # 企业级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（总分） | 四维加权合成 | 横向比较不同模型与设置的统一口径 | 其中Aggregate的权重构成为0.35×Answer + 0.30×Evidence + 0.25×Route + 0.10×Efficiency。这一设计让失败不再被压成一个模糊的"模型不行"，而是可以精准定位到路由、证据或推理环节——这正是它作为工程诊断工具的独特价值。 同时，数据集保证**答案可验证（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 对银行工程落地的四点建议 基于上述分析，提出四点可操作的落地建议： 1. **建立银行自有的"表面路由"评测集**：抽取真实业务场景构造跨文档、跨表、跨图谱的评测题，作为Agent上线前的准入门槛，而非仅用通用问答准确率准入。 2. **区分路由层与证据层的能力优化**：五环节评分能指出瓶颈究竟在入口选择还是证据取用，据此分别优化检索召回、SQL生成或图谱遍历，避免一刀切地"换更大的模型"。 3. **用Build思路倒逼数据治理**：将"Agent能否从原始工作区构建出可复用数据环境"纳入数据工程团队KPI，推动制度库、数据湖、血缘图三张底座的协同建设。 4. **对高风险操作型Agent设冷静期**：在当前Answer准确率普遍仅56%-75%的现实下，涉及资金变动、客户授权等操作型Agent应先在证据链可追溯的沙箱中长时间验证，再考虑受控上线。 ## 六、结语 WorkSurface-Bench与WorkSurface-Build的价值，不在于又多了一个"刷榜"的测试集，而在于它把企业Agent的评测从"单次问答"拉回到"数据组织、证据检索与可复用工作环境"的真实工作流中。对银行而言，智能体的价值最终取决于它对机构内多形态、高复杂度数据资产的驾驭能力——这份基准给出了衡量该能力的第一把有刻度的尺子，也指明了从"能答对题"走向"能在真实数据流中干活"的工程路径。 ## 常见问题 Q: WorkSurface-Bench和现有RAG评测基准有什么区别？ A1：现有RAG基准主要看最终答案是否正确，把"选错入口"和"用错证据"两类失败混为一谈；WorkSurface-Bench把这两个能力拆开，用Route和Evidence两个独立维度分别打分，还能精确指出失败发生在路由、证据还是推理环节。 Q: 为什么模型路由选对了，答案还是错的？ A2：Route F1高达98.7-99.8，但Answer只有56.1-75.3，说明"选对入口"只是必要条件。入口对了之后，还可能因检索证据不全、SQL计算错误、图谱路径遍历失误或跨源合成偏差而答错，这四类原因需要依赖Evidence与Answer维度进一步区分。 Q: 这份基准对银行落地Agent有什么直接用处？ A3：银行数据天然横跨制度文档、业务表格与系统血缘图谱，跨表面任务正是银行真实业务的高频形态。银行可借鉴其四维评分构建自有验收体系，用Build思路推动数据就绪度改造，并对操作型Agent保持审慎的准入节奏。 Q: 开放多源工具到底能带来多大提升？ 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 *作者 Chao Pih，前沿人工智能探索者。本文仅代表作者个人观点，不构成任何机构立场。*