DataSpace 暴露了数据 Agent 的演示陷阱：创始人的完整结果验收闸门

一项名为 DataSpace 的新评测，要求数据 Agent 在混杂着 CSV、JSON、SQLite、Markdown、PDF 和视频的工作区里回答问题。任务听上去并不惊人：找到相关资料，把信息组合起来，再交付用户要求的完整表格。然而在 410 个任务上，论文报告的最佳受控结果只有 66.34% 任务准确率（Task Accuracy）；保持模型不变、只更换 Agent 运行框架（harness），成绩也会拉开 15.36 个百分点。

这些数字值得关注，但对创始人更有价值的是最强系统“最后失败在哪里”。作者审计了 136 次失败运行，其中 56.6% 的失败来自误解目标结果，或在生成最终表格时增删错了列。也就是说，Agent 可能已经找对证据、完成计算，却仍然交付了错误的业务对象。

这就是数据 Agent 的演示陷阱。流畅的解释、合理的图表，或五行完全正确的数据，都可能让 demo 显得成功；与此同时，一项续费、一个账户、一个地区、一条异常记录或一个必填字段已经消失。只要用户会据此采取行动，“部分正确”往往比明确报错更危险。

本文写给正在把 Agent 接入文档、表格、数据库、dashboard 或混合工作区的非技术创始人、AI app builder 用户和小型产品团队。你将得到一份完整结果契约、一个客户续费场景、六项验收测试、一张决策矩阵和一套 48 小时落地流程。核心判断是：验收业务交付物，不要验收答案有多会说服人。

DataSpace 实际测了什么

这项评测有三个特别实用的设计。

第一，题目不会提前告诉 Agent 应该读取哪个来源。工作区同时存在相关与无关文件，系统必须自行发现证据。第二，答案不是开放式报告，而是可以直接消费的表格。第三，评估是确定性的：在固定配置下，评估程序可以接受等价的列名、列顺序、数值精度、单位、空值和行排序表达，但不接受不完整或错误的结果。

DataSpace 还曾作为 KDD Cup 2026 Data Agents 竞赛的评测基准。这段使用历史说明任务形式具有现实研究价值，但不代表它与你的生产环境完全相同。

先定义结果，再评测 Agent

以下五个术语可以防止评测讨论不断漂移。

完整结果与优质解释之间的差异非常关键。微软的 RAG 评测指南把 completeness 定义为是否回答了问题的所有部分，并把它与 groundedness、relevance 分开衡量。对数据 Agent 产品，还应再向前一步：在运行前，把“所有部分”写成明确的行、列、类型、单位、排除规则和异常状态。

把评测当成产品警报，而不是模型排行榜

DataSpace 报告的最佳受控模型结果是 66.34%，同时有 76 个任务没有被六个受测模型中的任何一个解决。在固定同一模型时，五种运行框架的成绩从 30.98% 到 46.34% 不等。这些是作者特定配置下的评测结果，不是模型在所有产品里的可靠率。

比排行榜更重要的警报是：模型、工具、上下文管理、prompt、输出适配和停止逻辑共同组成最终系统。即使购买分数最高的模型，也无法弥补一个会丢列、改错行粒度、截断输出，或尚未保存最终文件就宣布完成的运行框架。

任务构成同样影响结果。在六个模型中，多模态任务比单一模态任务低 1.8 至 14.0 个百分点；需要 join 的任务则低 9.7 至 19.8 个百分点。作者明确把这些对比称为描述性观察，而非因果结论。创始人不应把这些差值直接套进自己的预测，但应该看见风险模式：每增加一种表达形式或一层关联关系，系统就多一个丢失、错配、重复或误读证据的机会。

因此，如果产品承诺同时分析发票、合同、CRM 导出、客服记录和通话视频，只拿十道干净的电子表格问题做模型对比远远不够。评测集必须接近真实业务路径，包括干扰文件、不一致的标签、缺失值、旧版本和跨来源 join。

最关键的故障发生在终点

论文的轨迹审计比总分更能指导产品设计。在最强受控模型的 136 次失败中，71 次主要发生在最终答案成形阶段，另有 31 次从任务定义或意图理解开始偏离。60 次结果成形（materialization）故障发生在内部已经得到所需结果之后：最终输出却增加或遗漏了列。还有 17 次意图故障误解了目标输出或行粒度。

两类合计 77 次，占受审计失败的 56.6%。相比之下，只有三次主要故障是因为选错证据源。找到相关文件，并不等于能正确提取、对齐、计算并交付用户需要的结果。

落到产品里，结果成形就是“内部工作如何变成用户拿到的文件或表格”。常见故障包括：

• 分析过程已经拿到正确 customer ID，导出的 CSV 却没有这一列；
• Agent 按每项订阅生成一行，用户实际要求每位客户一行；
• Markdown 预览显示 20 行，保存后的文件只有 17 行；
• null 被悄悄改成 0；
• 货币符号消失，USD 与 JPY 无法区分；
• 用户要求列出超过阈值的全部项目，Agent 却只给 top 10；
• 图表看起来合理，底层数据却因为错误 join 出现重复行。

为什么漂亮的局部答案容易通过弱验收

多数原型评审天然偏爱肉眼可见的成功。创始人问一个问题，Agent 搜索几个文件，说明推理过程，再返回一张看似可信的表。评审者抽查两行熟悉的数据，demo 就通过了。

这种流程测的是“像不像真的”，不是完整性。

局部结果通常不会露出明显 hallucination。屏幕上每一行都可能完全正确，真正的问题是没有显示出来的内容：状态拼写不同的已取消账户、遗留系统里的第二张发票、只出现在 PDF 附录中的客户，或本应显式出现的“该地区无结果”。一段自洽而自信的解释，反而会让遗漏更难被发现，因为它已经替评审者编好了完整故事。

NIST 关于 Agentic AI evaluation probe的工作，把 faithfulness、completeness 和 sufficiency 分开，并提出用机器可读的审计记录把结论映射回证据。这个模式很有价值，但业务结果还需要检查“总体是否闭合”。屏幕上每一行都有证据，不代表所有应出现的行都已经出现。

美国政府问责局的 数据可靠性指南也把准确性、完整性和对目标用途的适用性视为不同问题。产品验收应采取同样的纪律：“抽查到的值都正确”，不能替代“结果覆盖了全部范围内对象”。

使用完整结果契约

评测数据 Agent 之前，先为输出写一份小型契约。创始人不读代码也应看得懂，工程师或 app builder 则能把它直接变成断言。

result_contract:
  job: "列出需要人工介入的续费订阅"
  as_of: "2026-08-08T00:00:00Z"
  source_snapshot: "billing-v184 + crm-export-20260808 + contracts-index-v12"
  population:
    include: "未来 45 天内续费的有效年度订阅"
    exclude: "测试租户、已取消订阅、已批准不续费的订阅"
  row_grain: "每项订阅一行"
  required_columns:
    - subscription_id
    - customer_id
    - renewal_date
    - contract_value_usd
    - risk_reason
    - evidence_ids
  type_and_unit_rules:
    renewal_date: "ISO 8601 日期"
    contract_value_usd: "十进制 USD，不做货币转换"
    evidence_ids: "至少一个可解析的来源引用"
  uniqueness_key: [subscription_id]
  ordering: [renewal_date_ascending, subscription_id_ascending]
  precedence: "已签署修订 > 已签署订单 > 当前账单记录 > CRM 备注"
  empty_result: "返回只有合法表头的 CSV，以及 no_matches 回执"
  exceptions: "矛盾、缺失或无法读取的记录单独输出，绝不丢弃"
  reconciliation:
    source_population_count: required
    included_count: required
    excluded_count_by_reason: required
    unresolved_count: required
  delivery:
    artifact: "renewal_intervention.csv"
    preview_must_match_artifact: true

这份契约完成六件事：固定时间点、范围和来源版本；定义行粒度与 schema；声明来源冲突时谁优先；禁止随意改写 null、日期、货币和单位；让空结果与未解决项都显式出现；最后通过对账，证明来源总体里的每条记录都有去向。

如果任务只是“总结这份笔记”，通常不需要如此严密；如果遗漏会改变客户联系、金钱、库存、人员安排、合规结论或用户决策，就值得使用。

用一个客户续费 Agent 走完整流程

假设一家五人 SaaS 公司 Northstar Metrics 想让 Agent 找出 45 天内续费、需要人工介入的年度订阅。相关证据分散在账单 CSV、CRM JSON 导出、已签署订单 PDF、Markdown 定价政策和客服记录中。

demo 问题是：“哪些续费存在风险，原因是什么，我们应该怎么做？”一个很有吸引力的原型返回了十二位客户，并为每一位给出简洁解释。其中三位确实有风险，所有引用的客服记录也都准确。团队正准备把结果连接到自动触达流程。

完整结果契约会改变这场评审。

首先，团队把粒度定义为“每项订阅一行”，而不是“每位客户一行”，因为同一客户可能购买了两个条款不同的产品。其次，总体是未来 45 天内续费的全部有效年度订阅，而不是 CRM 搜索碰巧找到的账户。第三，已签署订单与修订条款和默认定价政策冲突时，应以前者为准。第四，“风险未知”是一种合法状态，不能因为 PDF 解析失败就让这条订阅消失。

团队制作了 24 条合成但接近真实的订阅样例，其中包含重名客户、两种货币、一份修订版 PDF、一条缺失的客服记录、一项仍留在 CRM 里的已取消订阅，以及一个拥有两项订阅的账户。Agent 返回 22 行，每一行看起来都没错。

对账很快暴露问题：一项订阅在按客户分组时被吞掉，另一项因为修订版 PDF 使用了不同合同编号而被过滤。界面预览还对合同金额做了四舍五入，而 CSV 保留了小数。这些故障都不会从那段流畅解释中自然显现。

Northstar 不必因此放弃产品，而应缩小第一版承诺。Agent 负责生成续费审核表和未解决队列，不自动触发客户联系。确定性校验器检查 schema、唯一性、日期、数量、排除原因、总额和预览/文件一致性；人类只复核未解决合同和高金额续费。团队能明确说出信任边界后，这项能力才真正有用。

上线前运行六项验收测试

建立一个小型、有版本号的测试工作区，并把标准结果放在 Agent 无法读取的位置。

1. 总体闭合测试

同时放入应该纳入、应按不同原因排除，以及必须标记为未解决的记录。要求数量满足：

即使返回的每一行都正确，只要有记录在某个阶段无声消失，就判定失败。

2. 行粒度碰撞测试

加入两个共享客户、名称、日期或类别，但必须保持独立的对象，以发现错误分组与错误唯一键。再加入一条应按声明键合并的真实重复记录，检查另一方向的处理。

3. 跨来源 join 测试

把标识符放在一个文件、状态放在另一个文件、覆盖性条款放在文档里，同时加入名称相似的干扰项。只有最终行使用了正确实体、优先级规则和证据引用才算通过。

4. 类型、单位、空值与顺序保真测试

混合日期、小数、百分比、货币、null 和贴近阈值的数值，明确转换与舍入规则。检查保存后的文件，而不只是 UI 预览。

5. 空结果与未解决结果测试

一组数据应合法地产生空结果，另一组则包含无法读取或相互矛盾的证据。前者应返回格式合法的空文件，后者应显式返回未解决项。两者都不能变成编造记录，也不能只显示一句笼统的“任务成功”。

6. 重复运行、预览与导出一致性测试

对同一冻结任务运行多次。非确定性推理可以走不同路径，但通过验收的业务交付物必须满足同一契约。对比 UI 预览、下载文件、API response 和下游交付；只要某个接触面发生有实质影响的截断、格式变换或重排，就判定失败。

分层给产品打分

单一的通过/失败指标会隐藏真正需要修复的位置。更好的方式是保留分层评分表。

这套分层借用了论文对意图、发现、提取、归属、计算、结果成形和终止阶段的区分，再为生产使用补上来源谱系与交付层。它能帮助小团队选对修复方式：检索不到来源，可能需要改善元数据；内部表格正确、导出文件错误，则应修输出层，而不是换更大的模型。

W3C 的 PROV 概览把来源谱系（provenance）定义为生产一项数据时涉及的实体、活动和人员，并覆盖派生关系、验证、版本与可复现性。你不必完整实现整套标准，也可以采用核心思想。至少保留来源 ID 与版本、转换或 query 版本、Agent/运行框架版本、run ID、时间，以及 reviewer 或审批状态。

根据后果决定上线方式

不要因为评测很新就扩大自动化范围，应根据结果后果选择运行模式。

英国政府的 AI-ready 数据集指南强调，readiness 取决于具体数据集与具体用途，而不是一个通用标签。指南也要求追踪 schema 与版本、来源谱系、已知质量问题、稳定 ID、来源可追溯性和明确责任人。对输出是否“ready”，同样应该采用这种场景化标准。

明确 DataSpace 不能证明什么

DataSpace 是有价值的评测基准，不是生产认证。

它的任务来自临床与金融 Text-to-SQL 数据源，再被转换成异构工作区。这样做让作者拥有可执行的标准答案逻辑，也能够确定性评估，但它不会复刻每家公司的历史包袱、权限模型、实时 API 或带攻击性的文档。任务多数来自金融领域，医疗任务所占比例较小。

公开发布中只有 60 份完整标准答案包可用于本地端到端评估，其余标准答案由官方完整评测控制。论文里的模型与运行框架结果依赖特定版本、工具、资源限制和 2026 年 7 月的接口，不能被当成永久排行榜，更不能变成你自己用户的成功概率。

Task accuracy 有意采用严格标准：只要表格不完整，整个任务就算错。如果产品承诺“完整结果”，这种标准很合理；但真实产品还可能需要衡量逐行 precision/recall、经过校准的不确定性、延迟、成本、隐私、权限隔离、可访问性和人工恢复。严格表格验收是一道闸门，不是完整产品评估。

最后，只有问题足够明确时，标准表格才可能存在。真实用户经常提出含糊问题。如果范围、行粒度、单位、时间或来源优先级不清，正确行为是追问，或先生成一份待确认的结果契约。产品定义清楚成功是什么之后，确定性评估才真正开始。

避免五种常见误读

创始人的 48 小时落地流程

DataSpace 真正值得长期记住的，不是“数据 Agent 只有 66.34% 好用”。更重要的是：系统可以完成大量令人印象深刻的工作，却在形成最终交付物时失败。创始人今天就能控制这类风险：先定义结果，再对总体做账，验证真正交付的文件，保留来源谱系，并让 Agent 的权限始终不超过证据所支持的范围。

参考资料

• DataSpace 作者，DataSpace: Benchmarking Data Agents for Verifiable Analytics over Heterogeneous Workspaces，2026 年 8 月。
• HKUSTDial，DataSpace 官方代码仓库与评估程序。
• HKUSTDial，DataSpace 数据集与公开发布说明。
• KDD Cup 2026，Data Agents for Complex Data Analysis。
• NIST，Building Evaluation Probes into Agentic AI。
• 美国政府问责局，Assessing Data Reliability。
• Microsoft Azure Architecture Center，Large Language Model End-to-End Evaluation Phase。
• 英国政府，Guidelines and best practices for making government datasets ready for AI。
• W3C，PROV Overview。