Argo-Bench：企业数据Agent真实能力评估

大多数 Text-to-SQL 基准测试只考查 Agent 能否生成一条 SELECT 语句。Argo-Bench 问了一个更难的问题：Agent 能否在 235 张表之间导航、重建隐藏的业务事实、运行统计分析，并执行那些会改变模拟企业状态的操作？

答案是：不能。最强的模型只有在 34.8% 的任务上得分超过 95 分，平均得分仅 59.5 分。这个差距揭示了从查询生成转向多阶段数据工作流时什么东西会崩溃。

现有基准测试的问题

Spider 和 BIRD 这类 Text-to-SQL 基准测试将查询生成作为独立任务来评估。输入是自然语言问题、schema 和数据库，Agent 编写 SQL，评分系统将输出与参考答案进行比对。

这种设置存在三个结构性问题：

答案键经常是错的。对流行基准测试的审计发现了大量不正确的 Ground Truth，导致无法判断一个失败的 Agent 究竟是坏了还是正确的。

单表偏见。公开数据集将业务事件塞进一张表。真实的企业数据仓库会将一笔交易分散到数十张规范化表中。

没有动作执行。Agent 生成查询但从不基于结果采取行动。真实的工作流需要根据查询结果来封禁账户、分配预算或发起退款。

Argo-Bench 通过在模拟器中而不是用 SQL 字符串对照答案键来评分动作，从而解决了这三个问题。

架构：模拟世界 + 隐藏的 Ground Truth

Argo-Bench 模拟了纽约市的一个外卖平台，2024 年有 8100 万笔订单。模拟包含：

扎实的经济模型（定价、费用、折扣）

欺诈模式（账户盗取、优惠滥用）

市场激励机制（骑手奖金、餐厅推广活动）

模拟器将数据导出到一个 235 张表的 ERP 数据仓库，模拟 Oracle E-Business Suite。该仓库包含 75 亿行数据。

关键设计选择：模拟器的 Ground Truth 状态对 Agent 看到的仓库是隐藏的。任务要求 Agent 通过在不完整或反规范化的数据中导航来重建事实，然后才能行动。

例如，识别欺诈账户需要跨多张表连接订单历史、支付方式、设备指纹和地理位置日志。Agent 必须推断欺诈模式，而不仅仅是查询一个 fraud_flag 列。

任务结构与评分

210 个任务中的每一个都遵循以下流程：

1. 自然语言任务描述（例如："封禁在 24 小时内从不同邮编地区下单超过 10 次的账户"）
2. Agent 探索仓库（查询、统计分析、跨表推理）
3. Agent 提交动作（封禁列表、预算分配、退款批次）
4. 评分系统根据模拟器中动作的后果打分

评分系统不比较 SQL。它评估 Agent 的动作是否在隐藏的模拟状态中产生了正确的结果。

每个任务都包含一个可执行的参考解决方案，演示仅使用仓库的可解性。这证明任务不是不可能的，并提供了正确性基线。

什么在多表工作流中会崩溃

该基准测试揭示了四种失败模式：

最强模型在最需要状态重建的任务上失败得最多。它们将仓库当作权威来源，而实际上仓库只是模拟器隐藏状态的一个不完整、反规范化的视图。

可观测性与调试

由于评分系统在模拟器中对动作打分，你得到的是确定性的反馈。如果 Agent 封禁了错误的账户，你可以重放模拟、检查 Agent 的查询，并追踪推理在何处偏离了 Ground Truth。

传统的基准测试更难做到这一点。如果 Agent 的 SQL 输出与答案键不匹配，不经过人工审查就无法判断是 Agent 错了还是答案键错了。

• 每条 Agent 执行过的查询的执行日志
• 显示 Agent 每一步知道什么的中介状态快照
• 将 Agent 的动作与参考解决方案的动作进行比较的模拟器差异

这使得调试多步推理失败成为可能，而不仅仅是查询语法错误。

状态管理要求

Agent 需要在多次查询和分析中维护上下文。一个典型任务需要：

• 探索 10-15 张表以理解 schema 关系
• 运行 3-5 个探索性查询来验证假设
• 执行统计聚合（百分位数、移动平均、队列分析）
• 基于结果制定动作
• 持久化内存来追踪已探索过的表
• 中间结果存储用于多步计算
• 假设追踪以避免重复查询相同数据
• 动作暂存用于在提交前验证动作

论文中测试的大多数 Agent 使用无状态的提示工程，配合完整的对话历史。这对简单任务有效，但当推理深度超出上下文窗口限制时就会失败。

安全与隔离边界

基准测试让 Agent 对只读仓库执行操作。Agent 不能修改数据，只能通过受控 API 提交动作。

这种分离对生产部署至关重要。企业数据 Agent 不应该拥有仓库的写访问权。相反，它们应该：

• 对仓库只读查询
• 通过暂存 API 提议动作
• 等待人工或自动审批
• 在独立的事务层执行动作

Argo-Bench 通过设计强制执行这个边界。Agent 看到仓库，但通过模拟器的 API 行动，该 API 验证并对每个动作打分。

代码示例：参考解决方案模式

以下是一个欺诈检测任务的简化参考解决方案：

# Step 1: Identify accounts with suspicious order patterns
suspicious_accounts = db.query("""
    SELECT customer_id, COUNT(DISTINCT zip_code) as zip_count
    FROM orders
    WHERE order_date >= CURRENT_DATE - INTERVAL '24 hours'
    GROUP BY customer_id
    HAVING COUNT(DISTINCT zip_code) > 10
""")

# Step 2: Cross-reference with payment anomalies
fraud_candidates = db.query("""
    SELECT DISTINCT o.customer_id
    FROM orders o
    JOIN payment_methods pm ON o.payment_id = pm.id
    WHERE o.customer_id IN ({})
    AND pm.card_country != o.delivery_country
""".format(','.join(str(id) for id in suspicious_accounts['customer_id'])))

# Step 3: File ban action
action = {
    "type": "ban_accounts",
    "account_ids": fraud_candidates['customer_id'].tolist(),
    "reason": "Multi-zip + cross-border payment anomaly"
}
submit_action(action)

参考解决方案演示了这个工作流：探索、推理、行动。评分系统根据被封禁的账户是否与模拟器的 Ground Truth 欺诈名单匹配来打分。

部署注意事项

运行 Argo-Bench 需要：

• 仓库基础设施（235 张表，75 亿行数据）
• 模拟器运行时（对动作打分并提供 Ground Truth）
• Agent 执行环境（与生产数据隔离）
• 仓库的 Parquet 导出（可下载）
• 模拟器代码（开源）
• 评分工具（确定性评分）

对于生产使用，你需要用实际的 ERP schema 替换模拟的仓库，并构建一个自定义评分器，根据业务规则而不是模拟器来验证动作。

Agent 在生产中会失败的情况：

• Schema 漂移改变了表关系但没有更新 Agent 的 schema 知识
• 数据质量问题引入了空值或重复，破坏了统计假设
• 动作 API 变了但 Agent 继续使用已弃用的端点
• 人工审批延迟导致 Agent 的分析在动作执行前变得过时

Argo-Bench 没有对这些失败模式建模。它假设一个静态 schema、干净的数据和立即的动作执行。真实部署需要监控 schema 变更、数据质量检查和过时检测。

适用场景

在以下情况下你应该使用 Argo-Bench：

• 你在构建必须导航复杂 ERP schema 的数据 Agent
• 你需要评估多步推理，而不仅仅是查询生成
• 你想要基于动作结果而不是 SQL 字符串匹配进行确定性评分
• 你在为企业管理自动化工作流设计评估工具

在以下情况下应该避免 Argo-Bench：

• 你只需要测试单查询 Text-to-SQL 生成
• 你的数据只涉及少数几张表，不需要多步推理
• 你无法在本地或 CI 中运行 750 亿行的仓库
• 你需要的基准测试能模拟 schema 漂移、数据质量问题或审批工作流

该基准测试对构建编排多阶段分析流水线的 Agent 的团队最有价值。它揭示了生成 SQL 与在企业规模上执行数据驱动动作之间的差距。

Argo-Bench 论文（ArXiv）

代码仓库（见论文链接）

数据集下载（见论文链接）

如需进一步行动，你可以考虑屏蔽此人或举报滥用行为