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 數據卡片與質素門禁，或查看我們的定價方案。