银行Data Agent落地实战：哪些场景能上，哪些先别急？（文末领取自评卡）

原创已于 2026-07-21 00:01:12 修改 · 447 阅读

本内容遵循CC 4.0 BY-SA版权协议

于 2026-07-20 17:45:02 首次发布

这两年去银行聊 Data Agent 项目，几乎每家客户都会先问同一件事：能不能用大白话提问，让它把数据和报表直接调出来。

这个能力当然重要，也是很多人对 Data Agent 的第一印象。但聊得深一点就会发现，客户真正的焦虑常常不在"查数"这一层——报表银行从来不缺，缺的是有人能从这堆数字里看出门道：这个指标为什么变、接下来大概率往哪走、手里该先动哪一步。

把数据调到人面前，是问数；而回答"为什么、会怎样、该怎么办"，已经是在帮人做决策了。从智能问数到智能决策，这一步跨越，正是白泽这两年在银行领域反复打磨的东西。

下面想聊的，就是我们和客户一起摸出来的几条判断：在银行，哪些事该交给智能体、哪些先别急，以及一个真正能支撑决策的智能分析，该是什么样子。

决策不能靠拍脑袋

先把智能体的能力边界划清楚

想让智能体参与决策，第一步反而是承认它"不该做什么"。这两年的项目经验反复提醒我们：边界划得准不准，很大程度上决定了项目走得顺不顺。有四类需求，越急着上越亏。

追"大而全"的统一 AI 中台，不如先把"应用门禁与编排"搭起来。银行采购追求稳态，没错。但大模型技术栈眼下还在剧烈变化，架构、框架、评估体系几乎每月都不一样。采购流程动辄大半年，等中台建好，模型可能已经迭代了好几轮。我们更主张把大模型当"原子能力"嵌进现有架构，先搭好调度和编排，既快速见效，又不被某一代技术锁死。

别让科技部门去做取数的活。科技的价值是"生产"数据资产，不是替业务"消费"数据。科技人员是懂 SQL 的——看到大模型生成的 SQL，他们会本能地逐行审查逻辑对不对、关联有没有漏、口径符不符合业务定义，这份审查的成本，往往比自己从头写一遍还高。正确的做法是把自助分析的能力直接交到业务人员手里，让他们自己解决那些高频、灵活、不值得开发成固定报表的取数需求——科技团队从取数工单里抽身，去干数据治理和模型开发这些更值钱的事。一个动作，两头受益。

行领导的管理驾驶舱，别急着用对话框替代。驾驶舱的价值是数据 100% 可信、全局一目了然。智能体在这里更该做"旁白"——补一句归因、提前推一个异常预警，而不是把直观的仪表盘，拆成需要反复追问才能拼出全貌的聊天记录。

风控和尽调的核心决策，交给成熟方案，大模型只做"增强"和"初稿"。反欺诈、信用评分必须可解释，尽调报告签字即代表尽职核实。这些地方，成熟的小模型精度、稳定、成本都已经做到极致。大模型真正的位置，是从非结构化数据里提取特征去喂小模型，或者生成尽调初稿、辅助审核。做增强，别做替代。

这四条不是给 AI 泼冷水，恰恰相反：把该守的守住，智能体才敢往"决策"这一步真正迈进去。

一个场景值不值得上

我们先搞清楚这五件事

划清边界，接下来就是正面判断：哪些场景值得果断投入。

在五问之前，我们习惯先看两件事：这个需求是科技部门主导，还是业务部门深度参与？是真实痛点长出来的，还是为立项而立项？经验反复证明，业务部门在场、由痛点驱动的需求，成功率天然高一截；反过来，痛点讲不清楚的需求，后面每一步都会还债。

在此基础上，这些年我们和客户磨出了一把共用的"尺子"，五个问题问下来，心里基本就有数了。

一问定位。智能体是辅助人做判断，还是要替人负全责？辅助的活可以大胆上；可一旦要对结果负全责，比如放进监管、合规、财务对账的闭环，现有的技术和法律框架都还托不住，就得慎之又慎。

二问需求。客户要的，是提效、辅助决策、生成初稿，还是"替代某个岗位、端到端自动出结论"？前者是大模型的甜区，后者往往先得打个问号。

三问容错。万一它做得不完美，后果扛得住吗？我们看两点：一是风险可不可控，出了错会不会捅大篓子；二是组织容不容错，纠错的代价高不高。低风险、高容错的场景，才适合让智能体先跑起来。

四问 ROI。收益能不能算成一笔明白账。尽调辅助就是个好例子：一份报告从 4 小时压到 1 小时，全行一年 5000 份，一年就省出 15000 个小时、约 1900 人天——这种账算得清，客户才肯真金白银地投。

五问地基。数据质量、指标体系到位了吗？这一条最常被跳过，却几乎决定了上面四条能不能落地。地基不稳，再好的场景也是空中楼阁。

这把尺子不是用来挑客户的刺，而是让双方在项目启动前，就把"能不能成、值不值得成"说透。想清楚，永远比做得快更重要。我们把这五问做成了一份可以直接打分的《AI 场景评分卡》，文末可以领。

SmartBI白泽在银行业的决策级应用场景

判断标准聊完了，看几个真的跑通的场景。它们有个共同点——回答的都不是"是多少"，而是"为什么、会怎样、该怎么办"。这就是决策级和问答级的分水岭。

对公"访前一页纸"，从 1 周到 10 分钟。客户经理拜访前原本要翻 5 到 8 个系统。白泽把工商信息、结算流水、关联方图谱、外部舆情整合到一起，一键生成客户画像、产业画像、推荐话题、推荐产品和风险提示。它给的不是一堆数据，而是"这个客户该聊什么、推什么、防什么"的行动建议。

对公尽职调查报告初稿，从 2 周到 20 分钟。自动完成股权穿透、关联图谱、财务趋势、流水特征、司法涉诉、行业对标，产出一份结构完整、要素齐全的高完成度初稿——客户经理复核确认后再进入送审流程。这正是第一部分说的"做初稿、不替代"：签字的责任仍在人，但人从两周的粘贴排版里解放了出来，报告完整性反而更高，返工更少，也更稳地满足监管"了解你的客户"（KYC）的要求。

风险迁徙预测，从"知道现在"到"看见下一步"。白泽构建风险迁徙矩阵，预测各逾期阶段（M0 到 M4+）的滚动逾期率和不良转化概率，支持假设分析和 Vintage 账龄分析（按放款月份分批追踪逾期表现）。它回答的是"下个月不良会怎么走、拨备该提多少"——这已是决策问题，不是查询问题。同一条能力线上，贷后风险巡检报告也能自动生成初稿，交风险经理复核。

零售财富管理，从"任务驱动"到"需求驱动"。产品矩阵复杂到客户经理难以全部掌握，交叉销售常退化成"促销任务摊派"。白泽基于客户画像做"客户—产品"匹配：有房贷推家财险、代发工资推薪金理财、有子女推教育金保险，每条推荐都附可解释的理由。理财经理拿到的不是名单，而是"跟这位客户开口的理由"；客户感到"银行懂我"，转化率和客单价才会跟着起来。

客户流失预警，从"被动等待"到"主动干预"。小微客群年流失率高达 20%–30%，常在流失后才被感知——白泽从结算、产品、交互行为里捕捉前兆，提前 30 天生成名单、自动派发挽留任务。信用卡客户销卡前则有"沉默期"：交易连续下滑、他行新开卡都是信号，白泽给出流失概率和核心原因（如"持有他行高权益卡、近两月无我行消费"），并自动匹配挽留动作，把策略从"一刀切送积分"做成"千人千面"。它回答的始终是：谁要走、为什么走、该怎么留。

财务分析，从"算得出"到"讲得清"。资产负债分析涉及期限缺口、利率敏感性、流动性覆盖率（LCR）等复杂指标，过去导数、算缺口要 1 周——白泽压缩到 10 分钟，还能直接回答"LCR 距离监管红线还有多少"。ROE 下降了，系统自动做杜邦分解、逐层下钻，归因瀑布图讲清各因素贡献，异常监测从月频提到日频。这些答案最终摆上资产负债管理委员会（ALCO）的桌面，支撑真金白银的配置决策。

以上只是切片。到今天，白泽在银行业沉淀的场景，已经覆盖经营管理、对公、零售、普惠、信用卡、国际业务、金融市场、财务管理、运营合规、渠道营销等十余个条线、四十多个场景：监管报表报送从 5 天到 2 小时，资产负债分析从 1 周到 10 分钟，网点效能诊断从 2 天到 3 分钟，金融市场组合风险诊断从 2 小时到 5 分钟。这些不是概念演示——其中多个场景已在西南、华南多家城商行落地运行。

决策敢不敢信

全看指标口径对不对

场景越往"决策"走，对一件事就越较真：数字到底可不可信。

一个"会问数"的产品，答错了顶多重问一次。但当它的结论要拿去支撑拨备计提、授信审批，口径错一点，代价就完全不是一个量级。同一个"不良率""中收"，在银行不同系统里口径可能天差地别；账龄分析里，分母用放款本金还是贷款余额、账龄从哪个月起算，任何一处含糊，结论就失之毫厘、谬以千里。

这份较真不是姿态。说一个我们自己踩过的坑：在华南某城商行的 POC 里，客户要做 Vintage 账龄分析，我们第一版智能体的输出很不稳定——分母错用了贷款余额而不是放款本金，账龄月（MOB，即放款后的第几个月）的起止边界频频算错，同一个问题每次跑出来的答案都不一样。

我们没有靠"多调几次提示词"把它糊弄过去，而是借鉴 Harness Engineering（驾驭工程）的思路，把整个分析能力重构了一遍：输入数据强制校验，指标口径写成硬规则而不是靠模型理解，输出结果自动验证、不通过就重算，小样本批次强制标注警告，每次分析的参数和结果都留存哈希审计记录。重构之后，输出稳定、可复核、可追溯。这件事给我们的教训只有一句话：决策级分析的可靠性，不是模型"聪明"出来的，是工程"管"出来的。

而这套工程化能力，长在思迈特深耕多年的指标管理根基上。统一的指标口径、严格的工程化校验、可追溯的审计存证，让每一个数字都经得起追问。这不是锦上添花，而是决策级智能分析的入场券。

再往上，是能不能啃下归因、预测、尽调这类真正有业务纵深的复杂场景，以及有没有把银行的行业规则和经验沉淀进产品里。这些不是靠一次对话堆出来的，是一个个真实项目磨出来的。