去年我们机构启动智能财务Agent选型时我以为最难的环节会是AI模型能力的PK或者财务流程自动化的效果验证。真到执行层面才发现所有问题绕了一圈全都回到一个原点——信创。你说Agent聪明不聪明演示环境里确实聪明可一旦放到鲲鹏芯片加麒麟系统加达梦数据库的环境里能跑、跑得稳、跑得合规这三点能同时满足的供应商掰着手指头都能数过来。银行和证券行业的财务本身就是业务复杂度最高的财务场景之一再叠加信创这个硬约束选型的难度直接翻倍。这篇文章不聊虚的把我实际选型过程中的思考逻辑、评估维度、踩过的坑按实操顺序整理出来。不管你是正准备立项还是已经在选型中途被信创适配搞得头疼应该都能用上。1. 先搞明白信创环境下的智能财务Agent到底难在哪1.1 智能财务Agent和传统RPA不是一回事很多项目组上来就讨论“Agent”和“RPA”的区别这个还真得先掰扯清楚。RPA是规则驱动的脚本机器人每一步都是提前写死的Agent是目标驱动的智能体它能把一个大的任务拆解成多个子任务自己判断该调用哪个工具、该读取哪张表、该跟谁确认。在财务场景里前者只能“照着流程走”后者可以“看着目标自己找路”。但这恰恰是信创环境里最大的难点一个越智能的Agent背后依赖的技术栈就越复杂——大模型推理、知识库检索、工具调用、工作流引擎每一层都要跑在信创底座上。传统的财务软件迁到信创环境已经够折腾的了Agent这种高度依赖生态的新物种适配难度只会指数级上升。1.2 信创不是换个操作系统那么简单我在选型前做过一次内部摸底当时列了这么一串问题Agent要跑在什么芯片架构上什么操作系统什么数据库什么中间件大模型用哪家的能不能私有化部署算力资源在哪里每个问题背后都对应一个生态位每个生态位都有好几个国产选项在排列组合。单拿数据库来说达梦、人大金仓、openGauss、GaussDB语法细节、存储过程写法、事务隔离级别都有差异。供应商跟你说“支持国产数据库”跟“在所有国产数据库上都经过深度优化”是两个完全不同的故事。我们遇到过一个案例某供应商在Oracle上跑得好好的系统改用达梦之后报表模块的存储过程直接报错一片最后研发赶工了一个多月才补齐。1.3 金融行业的财务Agent监管和安全要求天然更重银行和证券的财务数据涉敏级别高数据不能随便出域系统操作必须可审计。这就带来两个直接影响一是Agent背后的大模型必须能私有化部署不能依赖云端API。二是Agent的每一个决策和操作都要有日志可追溯。听起来是基本要求实际上能做到的供应商不多。很多Agent产品是从互联网行业迁移过来的默认跑在公有云上数据加密、日志体系、权限模型都是按互联网标准做的拿到金融行业来根本不达标。2. 智能财务Agent的核心能力按这个维度去拆解2.1 财务业务的“纵深度”决定Agent的真实价值银行和证券的财务科目体系、核算逻辑、业务场景跟普通企业差很多。银行有吸存放贷、同业往来、表外业务、减值计提证券有自营投资、资管业务、两融业务、经纪业务每一类业务的财务处理逻辑都不一样。选型时如果只听供应商讲“我们支持智能报销、智能审单”那是远远不够的。我建议做一个“真实业务摸底测试”把你们机构最近一个季度的高频财务场景整理成测试集比如员工报销、供应商付款、费用分摊、预算控制、凭证生成、报表编制让供应商用这套测试集实际跑一遍。这个动作一来能看出Agent对金融财务业务的理解深度二来能识别出哪些供应商只会做“通用财务自动化”的外包装。2.2 AI能力与国产大模型的适配三件事必须问清楚第一推理引擎能不能跑在国产算力上。很多Agent产品在NVIDIA GPU上跑得飞快但金融信创环境里往往只能调用国产GPU或者NPU资源。供应商是否针对国产算力做过算子适配和性能优化差别非常大。同样是发票识别任务适配过的可能1.2秒返回结果没适配的要等五六秒。第二专业场景有没有做模型微调。财务领域充斥着专业术语——权益法核算、递延所得税、商誉减值、公允价值变动。通用大模型对这些概念的理解往往流于表面。成熟的供应商通常会用脱敏后的财务语料做一轮领域微调让模型真正“懂行”。第三模型层和应用层是否解耦。这一点很多人忽视了。Agent号称支持多家大模型切换但实际代码里可能跟某一家的API深度绑定。一旦那家模型服务升级或者出问题整个Agent直接瘫掉。选型时让供应商演示一下“模型切换”的过程是骡子是马当场就能看出来。2.3 业财融合与生态集成能力是信创环境最大的隐形杀手财务Agent不可能孤立存在。它要跟报销系统、核算系统、预算系统、影像系统、核心业务系统、甚至监管报送平台做交互。在传统架构下这些集成工作已经够繁琐在信创环境下更是如此——因为上下游系统本身的信创改造进度还不一致有的已经切到国产数据库有的还在Oracle上跑双轨。我特别提醒一点一定要让供应商提供详细的“接口适配清单”包括对接过的系统类型、接口协议、数据传输方式和前置依赖条件。见过太多供应商嘴上说“集成能力很强”真到联调阶段才发现连对方系统的基础接口文档都没看过。当年我们为了让Agent对接新一代信贷系统的RESTful接口光联调就花了两个星期这段经历至今记忆犹新。2.4 供应商的“信创基因”是否深入内核问一个很直接的问题你们的研发团队日常是在哪个环境里开发测试的如果研发团队主力仍然在Windows加传统数据库环境里写代码只是发布时打一个适配信创的包那这个产品的信创质量大概率是靠“打补丁”撑起来的。反之如果研发主力环境就是国产化技术栈产品从设计之初就考虑了兼容性问题后续出问题的概率会小很多。3. 实操层面选型步骤与关键评估方法3.1 第一步把你们自己的信创家底摸清楚选型前先组织一次内部盘点至少搞明白四件事现有IT系统的信创改造进度哪些系统已经在生产环境跑信创哪些还在测试哪些完全没动。目标部署环境Agent将来跑在哪个机房、哪个云平台、哪一类型的算力资源上。上下游系统兼容Agent要对接的系统里哪些已经信创化哪些还是传统架构哪些正处于过渡期。数据安全边界财务数据是否允许出域现有的敏感数据管理要求是什么级别。这四项不清楚后面跟供应商谈全是模糊账。我们当时最开始的失误就是没做这步结果前面三轮沟通供应商一直在问“你们环境到底是怎么个情况”我们答得七零八落白白浪费了两周的交流时间。3.2 第二步画一张“信创适配矩阵”评估表把通过初筛的供应商拉进来务必做一张结构化的适配评估表。我列一下当时表格里的关键字段评估维度具体检查项重要程度芯片架构x86海光、兆芯、ARM鲲鹏、飞腾、LoongArch等支持情况高操作系统银河麒麟、统信UOS、欧拉等是否含具体版本高数据库达梦、人大金仓、openGauss、GaussDB、OceanBase高中间件东方通、宝兰德以及版本兼容性中大模型部署私有化部署、国产算力适配、模型可替换性高客户端兼容是否支持统信/麒麟下的浏览器、办公插件中信创认证是否持有相关国产化适配互认证书低这张表一出来第一轮能筛掉一半以上的供应商。我们当初有三家候选其中一家直接说ARM架构还在适配中问什么时候能好给不出时间表当时就被否了。3.3 第三步PoC场景一定要“量身定制”PoC是选型里最花时间也最能看到真相的环节。我给自己的团队定了几条原则第一PoC必须在你们自己的信创测试环境里做。供应商提出“在云端开个环境演示”的我一律拒绝。因为只有真实跑在你们未来的生产环境同类底座上测出来的性能才有参考价值。第二PoC要设计三层场景。第一层是高频场景例如差旅发票自动识别、费用凭证自动生成第二层是复杂业务场景例如一笔费用涉及多个成本中心、多张发票混合报销、跨部门分摊第三层是对抗性场景例如输入重复报销单据、涂改发票、超标酒店房价看Agent能不能正确识别并拦截。三层场景都过了Agent才算基本靠谱。第三PoC结束后的性能报告要对比信创环境和非信创环境的差异。如果响应延迟、吞吐量差异过大一定要搞清楚瓶颈在哪一层——是数据库、中间件还是大模型推理。3.4 第四步技术尽调必须看“软件成分”和“日志体系”商务谈判之前技术尽调是我最看重的环节。这里有一个不太常规的建议向供应商索取软件成分清单SBOM。目的是搞清楚他们的产品里到底引用了哪些开源组件、有没有潜在许可证风险、遇到安全漏洞有没有能力自行修复。这个问题问出去之后几种供应商的反应很能说明问题一种是痛快拿得出来一种是支支吾吾说“需要回去找”还有一种直接反问“这是什么东西”。另外务必确认Agent的日志体系。财务场景对追溯性要求极高Agent每一步的推理、操作、工具调用都必须有可以导出的审计日志。我见过一个产品日志只记录了“做了什么”不记录“为什么这么做”也就是缺少决策依据字段。这在金融审计场景里几乎等于没有日志。4. 安全合规与模型风险这几个关口绕不过去4.1 金融级安全合规是硬门槛不是加分项银行和证券行业在安全合规上有一整套自己的要求。选型时至少要确认以下几点数据链路是否全链路加密包括客户端到服务端、服务端到数据库、数据库到备份体系。模型训练数据的来源是否合规是否使用过未经脱敏的财务数据。系统部署架构是否满足“数据不出域”也就是说推理引擎、知识库、模型参数全部都要落在机构内部的信创环境里。系统日志能否满足审计要求是否支持端到端的操作追溯。这里我特别想提醒很多供应商的产品在互联网环境里打磨得很好但金融行业的合规要求对它们来说完全是新的领域。你以为他在跟你聊合规实际上他可能连等保三级是什么都不太清楚。遇到这种情况直接淘汰不必浪费时间。4.2 Agent的权限边界必须从设计层面卡死Agent能做事情不代表它应该被赋予所有权限。财务场景里一个能自动审批、自动生成凭证、自动发付款指令的Agent必须被限制在严格的操作边界内。我当时给团队定下三个原则额度控制Agent自动触发的付款类操作单笔和累计金额都要设上限超限必须转人工。人工闸口Agent生成的财务凭证必须经过财务人员一键复核确认后才能入账不允许完全无人值守。最小权限Agent本身的系统账号权限不能高于一个普通财务人员最好采用“临时授权”机制每次操作时按需授权操作完即回收。这些要求在合同里就要写清楚别指望靠供应商“自觉”。当时我们跟一家供应商谈到权限模型时对方反复强调“我们很安全”但拿不出具体的权限管理文档这让我非常警惕。4.3 模型幻觉在财务场景里是“一票否决”大模型的幻觉问题在闲聊场景里是笑话在财务场景里就是事故。一个发票识别Agent如果金额识别靠大模型生成而不是靠结构化抽取很可能偶发光字符错乱。一个费用咨询Agent如果它“一本正经”地告诉你某某支出可以税前扣除结果依据是错的那后续税务风险谁来担所以我在选型谈判里提出过一个硬性要求凡是涉及金额、日期、税额、科目代码这类确定性数据必须走结构化识别引擎或规则引擎不允许直接让大模型输出。大模型只负责理解用户意图、拆解任务、生成解释性文案这类“开放性”工作。结构化输出和生成式输出之间必须有明确的架构边界。5. 常见问题与避坑实录5.1 数据库迁移的兼容性远比你想象的复杂供应商说“支持达梦”和系统在达梦里稳定运行完全是两回事。我们在PoC阶段就翻过一次车某模块从Oracle迁移到达梦存储过程报错十几个原因很典型——代码里用了Oracle特有的函数和语法写法换个数据库就得逐条改。避坑建议有两条一是要求供应商提供一份数据库兼容性差异说明把不兼容的点明确列出来二是PoC里必须包含全量报表回归测试用你们真实的数据量跑一遍别只测几个功能点就当过关。5.2 信创环境下的性能衰减要有心理准备信创硬件和传统服务器的性能差距是一个客观存在的事实。但问题不在于这个差距本身而在于供应商能不能提前告诉你、并主动做性能调优。当时有一家供应商演示时顺滑无比我问了一句“鲲鹏环境下跑过压测吗”对方沉默了一下说“还没有”。这种态度就很说明问题他根本没把信创当作主战场。金融行业的月末结账、季末报表系统负载是平时的数倍。Agent如果扛不住高峰并发整个财务关账进度都会跟着遭殃。所以选型时一定要让供应商提供在国产芯片、国产数据库条件下的性能压测报告并重点关注两个指标并发吞吐量和高峰延迟。5.3 小心“信创包装”型产品市场上有一类产品让我警惕核心代码在传统技术栈上开发信创适配靠的是外挂兼容层。比如在Linux上套个Windows兼容层或者改一下数据库驱动配置就敢宣称是“信创产品”。这类产品选进去短期好像没问题长期维护、安全更新、性能优化都会是大麻烦。怎么识别一句话问他核心代码是不是跑在国产化环境里。如果遇到信创环境下的bug研发是要修改核心代码解决还是只能绕过去、搞一些配置上的workaround如果只能绕那这个产品的信创基因基本为零。5.4 服务运维的SLA写不写进合同差别很大信创环境的排障链路比传统环境复杂得多。Agent出了问题可能是大模型推理的问题可能是数据库兼容问题可能是底层芯片驱动问题也可能是多个因素叠加。供应商如果没有信创环境的实施经验出了问题很容易陷入“网络层推操作系统、操作系统推数据库、数据库推上层应用”的踢皮球循环。所以商务环节务必把信创环境现场支持写进SLA明确响应时限、支持范围、责任人。宁可合同谈慢一点也不要给自己留一个“出了问题没人管”的隐患。5.5 Agent上线后的“影子流程”不能失控Agent上线了不代表项目管理结束。很多Agent产品在一开始会有“学习期”处理问题的行为逻辑跟人工习惯不一致容易在边缘场景里走偏。我建议上线后保留一个并行验证机制同一批业务让Agent跑一套再让人工走一遍两边对比持续一到两个财务月度周期。差异项要逐条分析确认是Agent的问题还是流程本身的问题。这个过程虽然费人力但能避免Agent在无人察觉的情况下养成“坏习惯”。6. 最后说几句实在话整个选型流程走下来我最深的感触是信创环境下的智能财务Agent本质上是在一个“还不够成熟”的生态里去做一个“足够前沿”的产品选型。这意味着你不可能指望找到一个完美答案你能做的是在多个维度之间寻找一个风险可控的最优解。我个人的体会是选型团队里一定要有懂技术架构的人最好是熟悉信创技术栈的那种。否则供应商随便甩几个“信创适配证书”团队很容易被唬住。同时我真心建议把“信创适配深度”这一项在评标权重里放得高一些因为功能可以迭代适配的坑却是跟着产品一直存在的。智能财务Agent是好东西但它必须长在合适的土地里。选型选的不只是Agent本身而是选择了它背后整个技术生态的适配深度和可持续服务能力。想清楚这一点选型表格怎么写、权重怎么设、问题怎么问自然就有答案了。
