这两年金融圈聊AI已经很少再有人问“要不要上大模型”这种问题了问得更多的是“数据中台和大模型到底该怎么接”“Agent落地在哪里才有实际业务价值”。我去年到今年一直在做这块从底层数据打通到上层Agent应用都过了一遍踩了不少坑也沉淀了一套还算能用的打法。今天就把这套“数据中台大模型AI Agent”的组合实践完整拆开聊聊重点讲清楚每个环节为什么这么设计以及实际落地时那些常规文档里不会写的事。1. 为什么金融行业绕不开“数据中台大模型Agent”这个组合先交代一个背景。这几年金融机构并不缺数据真正缺的是把数据“用起来”的能力。很多银行、券商、保险公司早年都建了数仓、上了数据治理有的还搞了数据中台但中台建完之后高频使用的都是报表和固定口径查询业务部门想要一个灵活的分析结论往往还得排队提需求。数据资产堆在那里但离一线决策始终隔着一层“翻译”的成本。大模型出现之后大家的第一反应是“这东西能聊天、能写报告是不是可以直接问数据了”。但实际做下来你会发现把大模型直接对到数据库上有两个硬伤一是模型会一本正经地胡编金融场景里一个凭空捏造的金额是致命的二是大模型本身没有“行动能力”它能生成一段文本但不能自己去查库、调接口、触发流程。这时候AI Agent这个角色就变得很关键了——Agent负责拆解任务、调用工具、一步一步把事办完大模型负责其中的语义理解、推理和生成而数据中台则负责把底层的指标、标签、数据服务准备好。三者合在一起才真正构成一个能落地的工作流。说白了数据中台是“粮仓”大模型是“大脑”AI Agent是“手脚”。粮仓里的粮食再充足没有大脑和手脚前线还是饿肚子。而如果不接粮仓大脑和手脚再聪明也只是在空转。这里也顺带澄清一个误区。很多团队一上来就要把大模型微调成“业务专家”其实在金融场景里绝大多数业务知识是结构化存储的分布在数仓、指标库、知识库里模型根本不需要“背下来”它只需要知道去哪里取、怎么取。这也是为什么我一直主张金融大模型应用的第一优先级不是微调而是把“取数推理”的链路做扎实。2. 架构设计三层各司其职别指望一个模型全包干我在项目里通常会画一张非常朴素的三层架构图从上到下分别是应用编排层、模型服务层、数据资产层。很多团队把这三层混在一起什么都往Agent里面塞这是最要命的架构错误。2.1 数据资产层先解决“模型能拿到什么”的问题这一层就是数据中台要负责的事。但要注意金融数据中台服务大模型和传统服务BI是两套逻辑。传统BI要求口径固定、时效批次清晰而大模型和Agent的查询往往是动态的、组合式的。所以我做了两个改造第一是指标服务的API化。把原来散落在各业务系统的指标口径统一收口封装成一个个标准的指标查询接口比如“存款余额”“不良率”“客户AUM”这些Agent只需要调用一个接口名加参数就能拿数不需要知道底层表结构。第二是语义层的建设。这是很多人忽略的。大模型并不知道你的数据库里“cust_id”是什么意思也不知道“月日均”和“时点余额”有什么区别。我们专门做了一个语义映射层把自然语言里的词汇映射到指标、维度、过滤条件上。比如用户问“上海分行的存款规模怎么样”语义层会自动关联到机构维度里“上海分行”这个节点再关联到“各项存款”这个指标。没有这一层Agent的准确率基本靠猜。2.2 模型服务层一个底座多个模型别搞重复建设金融行业做大模型最忌讳各业务线各搞一套模型服务。我见过一个券商光客户服务一个场景就同时试了三家大模型的API内部审核的时候人都疯了。我们的做法是在模型服务层抽象出一个统一的模型网关底层接多个模型——通用对话用中等参数量的模型复杂分析用小参数量更大但推理能力更强的模型而涉及私有知识库的场景用经过领域增强的模型。上层业务全部通过网关屏蔽差异模型轮换的时候业务代码一行不用改。这一层还有一个很重要的点就是私有化部署与公有云API的混合路由。金融行业合规要求高客户信息、持仓数据绝对不能出域但一些通用知识类的问题可以走外部API以降低成本。模型网关里配了路由策略基于输入内容的分类结果自动决定走哪条链路。我们在网关层做了个轻量分级器先判定请求是否涉及敏感字段再做路由准确率做到99.5%以上才敢放开。2.3 Agent执行层别把Agent做成“高级对话机器人”Agent这一层在整个架构里最容易做歪。很多人理解的Agent就是个聊天框背后接了个大模型但真正的Agent核心是任务拆解、工具调用、状态管理和异常恢复。我们落地Agent用的是“计划-执行-验证”的循环模式。用户提一个请求Agent先做意图识别和任务规划把一个大任务拆成若干小步骤比如用户问“帮我对今年以来持仓收益率最差的十只基金做一个归因分析”Agent会拆成查持仓列表、算区间收益、排序取前十、拉取每只基金的持仓行业分布、做归因计算、生成报告。每一个步骤对应一次工具调用或一个子Agent。这里有一个很实用的设计工具调用必须做到可观测。我们在每一个Agent工具调用前后都打了日志并记录输入输出摘要。这样即便最后答案错了也能回溯到底是哪一步选的工具不对、哪个参数传错了还是模型本身幻觉了。金融场景出问题是必然的关键是出了问题能不能三分钟定位到根因。3. 应用场景实践我能讲清楚“跑通”的四个落地案例这个部分可能是大多数人最想看的。我挑四个已经跑起来的场景不画大饼直接讲业务效果和实现里最堵的地方。3.1 投研知识助手从“搜文档”到“给结论”第一个落地场景是投研知识助手。某基金公司原来研究员做个股研究要翻公告、研报、新闻一天下来可能只能覆盖三五家公司。现在通过大模型Agent自动把公告里的关键信息抽取出来结合行情数据和财务数据做交叉分析。实现上最麻烦的不是大模型生成而是把PDF、Word里格式杂乱的研报内容解析成结构化的markdown。我们在文档解析这一层下了很大功夫先做版面分析再做表格识别最后才是大模型的分段摘要。解析质量直接决定了后面RAG检索增强生成的效果。现在这套系统的公告覆盖率从原先人工的60%提到了98%研究员每天省出两三个小时做深度研究。3.2 智能信贷审批助手让“初筛”变成自动化工作流第二个场景在消费金融公司做信贷进件的初审助手。原来初审员要核对几十个字段、查黑名单、判断多头借贷风险一单大概要十五分钟。现在Agent自动从进件材料里抽字段并行调用风控模型、征信核验接口、内部黑名单库最后生成一张审批建议卡。这个场景最大的特点就是流程刚性每一步都是强约束的Agent不能自由发挥。所以我们没有用完全开放式的Agent而是用了“工作流Agent节点”的混合模式主流程是固化的但其中难度最大的“资料字段抽取”和“风险描述生成”两个节点用了大模型。这种半Agent化的设计既保住了效率和灵活性又守住了合规底线。目前初审单均耗时降到了5分钟而且每一步都有留痕监管审计完全不虚。3.3 客户经理展业助手把数据中台变成“随叫随到的分析师”第三个是银行对公客户经理展业场景。客户经理出去拜访客户前通常需要准备这家企业的基本档案、存量业务情况、上下游关联关系、近期风险动态。原来他需要自己在至少四个系统里来回切换查数据现在只要在企微里说一句“帮我准备明天拜访XX公司的材料”Agent就会自动从数据中台拉取结构化数据从资讯平台抓取舆情再生成一页纸的情报简报。这个场景的难点在于权限管控。客户经理不能看到超出自己管辖范围的数据Agent在取数时必须带上用户身份由数据中台统一做行级权限过滤。我们专门做了一个Agent身份注入模块所有数据查询都是“人的身份Agent行为”双重鉴权。落下来之后客户经理反馈很好但中间权限调试的坑真的不少后面我会单独讲。3.4 数据分析机器人让业务部门自己跑数据第四个是自然语言查询数据的BI机器人。业务人员直接问“华东区上个月客户流失率环比变化多少”系统自动翻译成SQL查询数据中台再返回一个带图表的回答。这里最核心的难点不是Text-to-SQL的准确率而是口径绑定。我们花了很大精力把语义层做好用户问到的每一个业务词汇都必须先映射到已经经过确认的指标上不允许大模型自己创造口径。违反这一条的查询一律拦截并提示用户重新表述。目前这个机器人在特定数据集上的SQL生成准确率大概在90%左右剩下的10%通过交互式追问来兜底实际可用性已经非常高了。4. 金融级落地安全、合规与系统稳定性的防线要怎么设金融行业做任何AI应用都有自己的规矩不是技术上跑得通就能上线。这一章我重点讲三件事权限与数据安全、模型输入控制、以及异常兜底机制。都是实践里真金白银换来的。4.1 行级权限和最小权限原则前面提到过Agent替用户操作时必须继承用户权限这一点怎么强调都不为过。我们在数据中台和Agent之间加了一层统一的安全代理每次Agent调取数据接口都会带上用户token由代理校验该用户是否有权限访问这个机构、这个客户、这个字段。这里有个细节要特别注意大模型生成的数据查询语句必须经过安全引擎做二次校验。比如Agent生成了一段代码要查询客户信息安全引擎会先解析代码里涉及的表、字段、过滤条件和当前用户权限做交集比对过滤条件不足的时候还会自动追加“机构用户管辖范围”这样的强制条件。这是防止水平越权的最后一道防线。4.2 提示词保护与注入防护Agent的威力来自于它能调工具但风险也在这里。如果恶意用户通过精心构造的输入让大模型执行一个“越权动作”后果不可想象。我们做了两道防线一道是对用户输入做「再描述」。用户说的话不会直接拼进系统提示词而是先经过一个专门的防线模型做意图重构把关键指令转成结构化参数再交给下游Agent执行。这一下就把绝大部分prompt injection的尝试挡在了外面。另一道是工具敏感操作确认机制。凡是涉及对外发送消息、资金操作、修改数据的工具Agent执行前必须弹出一个确认步骤由系统判断操作的风险等级。高风险操作直接拒绝中风险操作转人工确认。目前我们宁可用户体验差一点也要保住这条底线。4.3 稳定性与降级方案大模型的推理速度和稳定性都不如传统系统尤其高峰期GPU跑满的时候延迟能飙到十几秒业务根本等不起。我们做了三件事第一是超时熔断。Agent调用模型如果超过设定阈值比如15秒会自动切到轻量模型或者降低生成长度保证核心链路不被拖死。第二是降级预案。每个Agent服务都配套了规则引擎版本大模型出现故障或者回答置信度过低时自动切回规则决策。比如信贷初审Agent大模型抽取字段失败时就退回正则人工复核的老路虽然效率低但绝不让业务中断。第三是结果缓存。大量相似查询其实可以直接命中缓存我们把常见查询做成24小时有效缓存高峰期缓存命中率能到35%左右算力压力缓解不少。4.4 审计留痕完整的trace链金融机构用的系统每一条操作都要求能回溯。Agent应用更是如此因为它的行为模式比传统系统复杂得多。我们从一开始就要求每个Agent执行任务时生成一条完整的trace包含用户原始输入、意图识别结果、任务规划、每一步调用的工具与参数、模型返回内容、最终输出以及中间各个节点的耗时。这些trace全部落到日志平台保留一年以上。上线三个月后有一次监管调阅问到一个客户查询的来龙去脉我们五分钟内把整条链路拉出来当时确实松了口气。5. 工程落地中最容易踩的五个坑最后聊几个我实际踩过的坑希望看到这篇文章的同行能绕开。5.1 坑一数据质量问题在大模型时代被放大了以前数据质量差影响的是报表对不上数还能肉眼发现。现在数据质量差喂给大模型之后会被包装成一本正经的错误结论反而不容易察觉。我们上线初期就遇到过客户AUM口径的数据没更新Agent一本正经地给了一个好消息差点让客户经理直接发给客户。所以我的建议是Agent上线前一定要对核心指标做波动检测数据异动时宁可中断回答也不要硬着头皮给结果。5.2 坑二把RAG当成数据中台的全部很多人一听金融大模型就说要做知识库RAG把PDF都灌进向量数据库里。但金融场景里真正高频使用的其实是结构化数据客户数据、账务数据、指标数据这些存在数仓里的东西RAG根本搞不定。好的架构应该是结构化数据走API非结构化知识走RAG两者结合而不是互相替代。5.3 坑三Agent的工具越多越好工具调用一旦超过十五个Agent的规划失误率和延迟就会明显上升。我们的做法是给每个Agent配置的工具数量控制在5到10个多余的工具通过分层召回实现上层Agent只看到几个核心工具需要更深的能力时再派发给子Agent。这就像人不会每天背着全部门工具上班该去仓库拿的时候再拿。5.4 坑四只评估大模型本身不评估整套系统很多团队选大模型的时候只看排行榜上线之后却发现业务效果很一般。其实大模型在整套链路里只占一部分文档解析质量、检索召回质量、Agent规划能力往往对最终结果的影响更大。我们内部评估从来都是端到端评估从用户输入到最终答案人工打分然后反查是哪个环节拖了后腿。这种评估方式才真正能指导优化方向。5.5 坑五低估了运维成本Agent系统不是上线就完事的。大模型会漂移工具接口会变动数据口径会调整任何一个环节变了都可能让整个Agent“生病”。我们专门配了一个AI运维小组每天做三件事看trace里的失败样本、监测答案置信度分布、定期跑一批回归测试用例。没有这套运维体系系统会像温水煮青蛙一样慢慢变钝。6. 接下来的演进方向从“做得了”到“靠得住”我们这个阶段的项目目标其实已经从“大模型能不能做这个事”变成了“怎么让系统更加可靠、可控、可审计”。下一步有几个方向我在重点关注。一个是每类任务的置信度评估模型不只是让大模型回答还要让它知道“自己有多大把握答对”没把握的时候就主动转人工。一个是工具调用的自愈能力Agent执行某个接口失败时能自动发现异常原因并尝试换参、换路径、换数据源。还有一个是多Agent协作金融场景里很多任务其实涉及多个部门协同比如信贷审批就同时涉及风控、业务、合规三个角色未来一定会按角色拆成多个子Agent协同工作。数据中台、大模型、AI Agent这套组合本质上解决的是金融行业一个非常朴素的问题让正确的人在正确的时间拿到正确的信息并基于这些信息做出更好的决策。越做到后面越会发现真正的壁垒不是某一个大模型有多强而是你围绕业务把数据、模型、流程这条链揉得有多顺。这条路没有捷径但每一步都值得。