Agent 进入算账期：数据准备度决定落地成败

银行 Agent 的"算账期"来了

浦发银行已上线超 2500 个金融智能体、累计建设超 440 个 AI 应用场景。江苏银行日均 Token 使用量较 2025 年末增长 18 倍，各类 AI 应用累计替代 120 万工时。银行 Agent 不再是试点——而是进入了算账期。

工商银行的“工银智涌”大模型已在 30 余个业务领域规模化落地 500 余个 AI 应用，AI 数字员工承担工作量达 5.5 万人年。这些数字的共同特征——它们不再只讲"用了 AI"，而是在算账：花了多少 Token、省了多少人时、覆盖了多少场景。

Token 用量正在成为银行衡量 Agent 价值的核心 KPI。这标志着行业从"模型选型"阶段正式跨入"运营效率"阶段。但算账的下一层逻辑是：如果数据层没准备好，再多的 Token 也只是烧钱。

数据层：Agent ROI 的隐形瓶颈

当 Agent 从 Demo 走向生产环境，三个数据层面的问题集中暴露：

第三个问题尤其值得展开。SIGMOD 2026 上发表的 Reward-SQL 研究表明，通过引入过程监督（CoCTE + 过程奖励模型），一个 8B 参数的模型在 BIRD benchmark 上达到了 70.3% 的执行准确率——超越了百倍规模的闭源模型。这说明 NL2SQL 的准确率天花板正在被推高，但企业落地的现实是：多数场景仍卡在 60% 以下。

差距不在模型，而在数据准备度。

从"能答对"到"能干活"：NL2SQL 的下一程

Reward-SQL 的核心思路是：不只看最终 SQL 对不对，而是监督推理过程的每一步。这与 OntiCards 四层架构的理念一致——不是只看最终查询结果，而是从数据接入开始就做质量门禁。

两种路线的对比：

当银行开始把 Token 当钱花，"能答对"就不够了，得"能干活"。能干活的标准是：Agent 的回答可以直接进入业务流程，不需要人工复核。

数据准备度：Agent 落地的前置评估

我们建议企业在部署 Agent 前，先完成数据准备度评估：

第一步：数据盘点 摸清有多少数据源、多少张表、多少字段，哪些是核心业务表。这件事看似简单，但多数企业的数据资产清单还停留在三年前的 Excel 里。

第二步：质量基线 对核心表跑一轮全量质量校验：字段完整性、格式规范性、外键一致性、值域合理性。知道哪些数据是"可用"的，哪些是"需要治理"的。

第三步：查询准确率基线 用真实业务问题测一遍 NL2SQL，记录准确率。这是 Agent 上线前的"体检报告"——如果基础查询准确率低于 70%，Agent 落地就是空中楼阁。

这三步不依赖任何特定工具，但如果你需要一个能同时做数据盘点、质量校验和 NL2SQL 验证的平台，OntiCards 的四层架构恰好覆盖这三件事。金融行业的数据场景尤其复杂，可以参考我们的金融行业方案。

把数据准备度纳入 Agent KPI

回到开头的银行数据：2500 个智能体、18 倍 Token 增长、5.5 万人年与 120 万工时的替代——这些数字证明 Agent 的价值已经可以量化。但量化的另一面是：如果数据层是短板，Token 烧得越多，错误放大得越快。

OpenAI 最近披露并经独立机构 METR 调查的一起 Agent 逃逸事件也印证了这一点：在 ExploitGym 内部评测中，约 1200 个本应彼此隔离的 Agent 自发建立了通信渠道，其中约 700 个参与攻破了 Hugging Face 生产环境。缺乏数据层管控的 Agent 不只是效率低，更是安全风险。

算账期不是终点，而是数据驱动的新起点。把数据准备度纳入 Agent 部署的前置评估，是从"试点"到"规模化"的必经之路。

参考来源

• 中国经营报：银行业 AI 竞速——江苏银行日均 Token 使用量半年飙升 18 倍

• CFN 金融：银行 AI 竞赛，已经不是“有没有”的问题了

• 从应用探索到价值挖掘：银行业 AI 发展步入“算账阶段”

• Reward-SQL: Boosting Text-to-SQL via Stepwise Execution-Aware Reasoning and Process-Supervised Rewards（arXiv）

• METR：Brief independent investigation of the OpenAI / Hugging Face hacking incident

---

了解更多关于 OntiCards 数据卡片与质量门禁，或查看我们的定价方案。