★ FEATURED ARTICLE 外面在为财务智能助手做供应商预审。对方展示的Demo能把报销单、发票识别、自动记账串成一条漂亮的流水线页面也做得很有金融范儿。但当我问‘你们的Agent在鲲鹏ARM架构上真实跑过吗接的是达梦还是Oracle国密改造怎么对接’的时候对方明显犹豫了。这种场景我遇到不止两三回了。在信创环境下给银行或证券公司选智能财务Agent本质上不是在买一个AI而是在买一个能跟现有财务系统共生、能被审计认可的整栈工程。这篇东西就是把我这些年做选型、做POC、被供应商画饼后踩坑攒下来的要点写清楚给真正要拍板的人一个抓手。1. 不可绕开的前提为什么财务Agent要把信创兼容放在第一位1.1 财务业务在银行/证券的特殊性银行和证券的财务系统跟我以前做过的零售、电商财务完全不是一个量级。这里说的财务Agent不是简单帮你写个报销单的聊天机器人而是要和总账、费用、固定资产、税务、监管报送等模块联动自动完成单据识别、科目判断、凭证生成、预算检查、异常提醒甚至初步审批建议。这类场景有三个非常硬的要求精度要求极高金额差一分钱都不行科目挂错更是事故。普通客服Agent回答错了可以再答一次财务Agent入账错了是要调账的。审计追溯极强每一笔自动生成的凭证要能说清楚为什么这么记。模型推理过程、数据来源、操作人、审批链都要留痕。系统交互极深Agent不只是对话它要读取核心系统数据、调用记账接口、触发审批流甚至操纵报表引擎。这三个要求叠加在一起导致一个结论财务Agent的选型核心不在模型跑分而在它能不能在你们真实的信创技术栈里稳定、合规、可解释地跑起来。1.2 信创不是装个国产系统就行我见过很多甲方把信创要求写成操作系统麒麟、数据库达梦觉得列上去就行了。实际上财务Agent涉及到的信创改造远比想象中复杂。一套完整的Agent系统从上到下包括层级涉及组件信创关注点硬件层CPU鲲鹏/海光/飞腾、服务器、存储ARM vs x86架构的兼容性操作系统麒麟、统信UOS、欧拉进程调度、内核特性、GPU驱动中间件东方通、宝兰德或Tomcat等开源中间件的国产化适配JVM版本、servlet容器行为差异数据库达梦、人大金仓、GaussDB、OceanBase、TDSQLSQL方言、存储过程、事务隔离大模型国产大模型开源私有化或商业API部署形态、显存依赖、推理框架如vLLM、MindIE密码体系国密SM2/SM3/SM4传输加密、存储加密、签名验签应用层Agent编排框架、OCR识别、规则引擎、RPA组件各组件是否已适配全信创链路任何一个层级掉链子Agent都上不了线。更麻烦的是很多供应商的信创支持是片面的——模型能在昇腾上跑但OCR组件是闭源的绑定了特定GPU驱动或者数据库对接只做了查询没做写入。选型时一定要把整个链路抠出来逐个验证。2. 一张能直接拿去打分的国产化兼容清单2.1 芯片与服务器先分清ARM和x86的路线差异银行/证券目前最常见的是两条路线。一条是鲲鹏ARM架构一条是海光x86架构。两者对Agent的影响差异非常大。鲲鹏ARM路线数据处理底座多为鲲鹏AI加速卡通常是昇腾。要注意很多开源的Python推理库、OCR模型、向量数据库在ARM上的表现和x86不完全一致有些依赖你没有源码根本编译不过去。供应商如果在项目现场没有真实部署过ARM环境至少要留足适配周期。海光x86路线和传统Intel生态兼容性好很多软件直接拿来就能跑AI卡也相对自由一些。但同样要注意信创清单对部件的认证要求不是能跑就行还要看适配证书和稳定性记录。我的建议是在招标前先确认你们数据中心存量到底是哪条路然后强制要求供应商在相同架构的测试环境做POC。别让供应商用一台带NVIDIA显卡的Intel服务器做演示你们采购的是鲲鹏节点那不是同一个东西。2.2 操作系统与中间件隐藏的小问题最多操作系统层面银行最常遇到的是麒麟V10和统信UOS。Agent涉及到的Python环境、GPU驱动、容器化部署K8s/Docker、Java运行环境都要在国产OS上重新验证。我踩过的一个典型问题是某开源OCR库依赖的底层图像处理库在指定国产OS的glibc版本上编译不过去最后只能换一个老版本。中间件也要提前问清楚Agent对外提供接口是走统一网关还是独立服务如果走的是东方通TongWeb或宝兰德这类中间件能否正常部署Spring Boot应用很多财务Agent会以微服务形式拆分出数个服务中间件的session管理、连接池行为、超时配置都可能和Tomcat不同。这些细节POC不测上线后就是事故。2.3 数据库对接达梦/金仓/GaussDB/OceanBase上的SQL方言陷阱财务Agent一个核心能力是通过自然语言或规则动态生成SQL查询比如查一下上个月差旅费前十的部门。听起来很酷但这里有个极其容易被忽视的坑Agent自动生成的SQL很可能带上了模型训练时熟悉的数据库方言。模型见惯了MySQL、PostgreSQL的写法而你们实际用的是达梦、人大金仓或者GaussDB语法兼容性就可能出问题。比如达梦有Oracle兼容模式和MySQL兼容模式初始化时的参数设置直接决定limit/rownum、序列、存储过程的写法。人大金仓KingbaseES语法上偏向PostgreSQL但部分函数名称、类型转换也有差异。GaussDB在分布式部署的情况下对跨节点事务、查询并行度有严格要求Agent生成的复杂关联查询可能直接被拒绝或超时。因此选型清单里必须包含一条财务Agent的数据库访问层要能在你们的数据库方言下通过压力测试。最好在POC期间把Agent生成的SQL记录下来让DBA逐条检查是否有低效或危险写法。2.4 密码改造国密SM2/SM3/SM4在财务Agent里的落地位置信创环境里密码改造是必答题不是选择题。财务Agent涉及的数据很敏感包括发票影像、科目余额、客户信息等。按等级保护的要求至少要做到传输加密、存储加密和审计数据防篡改。具体落地上SM2非对称、SM3哈希、SM4对称各就各位SM4用于数据库表字段级加密。比如身份证号、银行卡号、客户名称等敏感字段存库时必须用SM4加密。Agent在读这些字段时要有解密权限控制。SM2用于Agent与外部系统之间的接口签名。比如Agent调用记账接口、审批接口时请求体要用SM2做签名防止报文被篡改。SM3用于审计日志的完整性校验。每一条审计记录要生成SM3摘要形成哈希链事后能验证日志是否被修改过。选型时你要问供应商三个问题第一加密在哪个层做的是应用层还是数据库层第二密钥怎么管理是和现有KMS对接还是自己存配置文件第三Agent推理过程中的临时数据比如模型输入输出落入磁盘时会不会经过加密很多供应商第一第二个问题能答上第三个问题就直接卡住。3. 模型选型不是跑分最高就好而是私有化部署后的财务能力3.1 金融场景为什么坚持私有化部署银行/证券的财务数据基本是不可能出域的。就算很多国产大模型API声称数据安全、不做训练用监管和内部合规部门那一关就过不去。所以财务Agent选型事实上只有一条路私有化部署。这意味着模型权重要在你们自己的机房里跑推理服务要安装在信创服务器上。私有化部署带来的直接连锁反应是模型参数量不能只按效果选还得看硬件扛不扛得住。一个百亿参数的模型如果用FP16跑显存就得200GB以上普通一台Harness服务器根本塞不下。很多银行实际预算只买了单机8卡或者4卡昇腾能跑起来的模型就有限了。所以模型选型的第一个步骤不是看榜单而是算账你们能接受多少张AI加速卡是单机部署还是多机集群期望并发是多少比如同时20个财务人员使用峰值时延容忍度是多少比如每个请求5秒内返回算完再反过来筛模型。当前信创环境下比较常见的私有化基座是Qwen系列、DeepSeek系列、GLM系列及其各行业微调版本。小参数版本7B~14B部署轻量、响应快适合单点财务问答大参数版本70B理解能力更强但资源消耗也大需要权衡。如果硬件资源紧张一个比较现实的做法是用大模型做理解和规划用确定性代码做计算和记账这样对模型能力的要求会降一档。3.2 开源基座与商业API的真实差距很多人觉得开源基座能力不行商业API才是终极答案。但如果是在信创金融场景商业API通常不等于商业私有化部署第三方大模型API普遍被排除在外。真正能对比的是两件事开源基座自己私有化调优 vs 商业大模型的一体机方案。一体机的优势是开箱即用厂商把模型、推理框架、运维监控都打包好了和昇腾等硬件做了适配省心。劣势是价格贵、模型更新受限于厂商节奏而且容易绑定。开源基座自己运维队伍的方式灵活性最高但要求内部有懂大模型部署的人才。财务Agent这种场景我的经验是行业微调模型比通用基座更重要。通用模型知道借和贷但不知道你们企业的科目表、费用类型、审批矩阵。真正落地的Agent往往要在基座之上用财务语料做指令微调或者至少做一层知识库的检索增强RAG把企业财务制度、历史凭证样例喂进去。选型时要重点考察三件事供应商能否提供财务领域的微调能力和语料积累而不是只包装一个开源模型就说支持财务。模型更新/迭代时回归测试怎么做金融场景最忌讳模型行为漂移上次对了这次错了。推理框架是否已适配你们指定的AI加速卡和操作系统比如昇腾平台的MindIE、CANN版本是否有明确支持。3.3 财务数字精确性Agent幻觉是最大风险点大模型在财务数字上出现幻觉这不是可能而是一定会。我做过测试让几个领先模型算一个含多级折扣的报销金额十个问题里错两三个是很常见的。模型对自然语言理解很好但算术不总是那么精确。所以在架构上我强烈建议一个原则凡是涉及金额计算、科目判断、借贷平衡的地方绝不能依赖大模型直接输出结果而要让模型输出结构和参数然后调用确定性的计算模块来执行。具体来说财务Agent可以这样做模型负责理解用户意图比如识别出这笔2月4日上海到北京的差旅费应该计入哪个部门。模型抽取结构化参数金额、日期、票据号码、部门编码。计算模块做实际处理调科目映射规则、跑金额校验、检查预算余额。模型再把计算结果组织成自然语言回应或者触发下一步流程。只有这样才能把幻觉率降到可接受范围。选型的时候不要只听供应商吹我们的模型数学能力很强而是要看他们的系统架构里到底有没有把计算与生成分离。没有这层架构的财务Agent再好的模型也迟早出事。4. 财务Agent的手单据识别、工具调用和规则引擎的结合4.1 票据/回单识别的准确率要按字段验收财务Agent处理报销和入账必须从票据OCR开始。银行里涉及发票、回单、结算单证券还有交割单类型五花八门。OCR识别不能只看整体准确率要看字段级别的精度。我一般要求POC里放一批真实脱敏单据重点考核这些字段发票代码、发票号码数字错一位就是假发票风险金额大写金额和小写金额要cross-check日期、购销方名称、税号多张发票混扫时的切分能力选型时要注意OCR引擎的信创兼容性。很多OCR供应商的模型是在特定GPU上训练的部署到昇腾芯片需要转换模型格式。转换后的精度损失有多大必须实测不能只看对方报告。另外财务场景OCR还有个特殊问题印章遮挡、模糊发票、手工填写字段。这些边缘case的比例可能不到5%但恰恰是人工介入最耗时的地方。一个成熟的财务Agent应该能在OCR置信度低时主动转人工而不是硬着头皮给出一个可能是错的识别结果。4.2 工具调用Agent连接RPA也要考虑信创RPAAgent不是只靠一张嘴做财务的它还要调用系统。银行证券的老财务系统很多是存量系统没有对外开放的API这时候就要靠RPA来操作界面或者靠中间件收发报文。这就引出一个问题Agent要能调用RPA而RPA本身也要信创适配。目前国内主流RPA厂商基本都有信创版本比如来也UiBot、艺赛旗、云扩等能跑在麒麟/UOS上也能控制WPS、国产浏览器环境。但要注意Agent和RPA之间的编排方式是简单的触发一个脚本还是动态传入参数并获取结果很多供应商的Demo里Agent和RPA各做各的中间靠人copy paste这就不叫智能财务Agent了。比较实际的架构是Agent生成任务清单每个任务对应一个RPA流程Agent把结构化参数传给RPARPA执行完把结果回传Agent再做结果校验。这套链路在POC里必须完整走通包括异常分支RPA执行失败、超时、找不到元素。4.3 规则引擎兜底不要把风控判断全交给大模型即使有大模型财务场景里仍然有很多规则是确定的。比如超标差旅标准一线城市住宿上限超了就要走特批。发票校验增值税专票和普票的税率映射。预算控制部门预算余额不足时单据不能自动通过。这些规则如果写在模型提示词里会出现两种情况模型有时候记不住全部条件或者不同表述触发不一致的结果。正确的做法是用规则引擎比如Drools或国产规则引擎把财务制度落成确定性规则Agent负责从自然语言里抽取信息然后给规则引擎去判断。换句话说大模型管理解和交互规则引擎管判断和执行。这一层设计直接决定了Agent上线后会不会被财务经理和审计打死。选型时一定要看供应商有没有规则引擎组件以及规则是否可视化、可版本化管理。5. 银行和证券的财务Agent选型侧重点其实很不同5.1 银行总账、内部资金、拨备逻辑需要强流程编排银行的财务体系复杂度远超一般企业。不说别的光是内部资金转移定价FTP带来的内部账户往来就有一堆清算、计息、分摊的账务逻辑。再加上拨备计提、税务调整、旬报月报每一步都有严格的时点和顺序要求。所以在银行场景财务Agent最重要的不是聪明而是流程编排能力。一个Agent任务可能牵出十几个子任务先抓取当日总账流水再做科目汇总再按FTP规则计算转移利息然后生成内部往来凭证最后归集到报表系统。中间任何一步失败都要有重跑机制和断点续跑能力。选型时我会特别看重供应商的Agent框架是否支持有向无环图式的工作流编排而不是简单的单轮问答。任务间参数传递和状态管理。子任务失败时的重试、补偿和告警。人工审批节点的自由插入。如果供应商拿来的东西只是一个聊天机器人那不管模型多强在银行财务场景都走不远。5.2 证券结算、佣金、行情相关财务处理追求时效性证券公司的财务处理节奏和银行很不一样。最典型的是日终结算收盘之后大量交易数据涌进来要在规定时间内完成资金清算、佣金计算、费用归集、盈亏核算。这个窗口通常只有两三个小时过了就有监管考核问题。所以在证券场景财务Agent选型更看重性能指标和批量并发能力。比如日终处理能不能在时间窗口内完成10万笔交易数据进来Agent的资源调度和工具调用会不会崩模型推理的时延会不会拖慢整体流程证券还有一个特点金融产品的创新快新业务不断出现新品类、新交易模式财务规则需要快速调整。Agent系统如果每次改规则都要重新训练模型那根本跟不上。所以规则引擎加模型分离的架构在证券公司尤其好用。财务规则变了改规则引擎就行不用动模型。5.3 一个通用的需求评估框架不管银行还是证券我习惯在选型前先做一次场景优先级排序。别上来就希望Agent全流程覆盖那是给自己挖坑。我的建议是按四个维度打分业务价值这个场景自动化后能省多少人天数据条件需要的数据系统里有没有质量如何规则清晰度流程规则是明确的还是依赖经验判断容错空间出错后影响多大有没有人工复核环节优先选择业务价值高、数据齐、规则清晰、容错空间大的场景先做。一般我会推荐从费用报销、发票校验这类高频场景切入跑通一个再逐步扩展。上来就想做全自动总账处理风险极高。6. 安全、审计与运维财务Agent上线后的三件麻烦事6.1 审计日志和操作留痕要做到可解释银行/证券的财务操作每一笔都要能回答谁在什么时候做了什么、为什么这么做。传统系统里这是靠操作日志实现的但Agent系统的问题在于模型决策的输入不仅是数据库数据还有提示词、历史会话、检索到的知识片段。如果审计只记录了Agent调用了生成凭证接口事后根本没法复盘。我建议在选型要求里明确写入审计日志的字段标准输入内容用户原始提问、附件信息Agent解析后的结构化参数调用的工具/模型/规则引擎模型返回的原始输出和最终执行结果置信度分数和是否触发人工复核时间戳、操作人、会话ID此外日志完整性要用SM3哈希链保护防止被篡改。这不仅是合规要求也是出事之后证明系统操作合规的唯一手段。6.2 权限隔离与数据不出域财务Agent如果服务全行多个部门权限模型就很重要。比如分公司财务只能访问自己公司的费用数据不能看到全行成本数据。Agent在检索知识库和数据库时必须继承当前用户的权限不能因为模型什么都知道就绕过了权限。很多系统在这个环节偷懒一个Agent服务一个大模型账号所有数据都裸给模型这是安全事故。另一个实际问题是数据不出域Agent在调用大模型推理时提示词里可能会带上具体的企业信息。如果推理服务和其他系统部署在一起要确保严格的网络隔离和访问控制。最好的做法是Agent的所有组件全部部署在财务系统的安全域内与外网物理隔离模型走内网调用。6.3 模型迭代与财务数据漂移的监控这是大部分选型容易忽略的点。财务Agent不是上线就完事了模型会迭代财务数据也会变。典型的问题是供应商升级模型版本本来识别正确的科目升级后突然换了个科目。年初财务制度调整比如差旅标准变化规则引擎改了但模型的训练数据还停留在旧场景。新旧业务类型涌入票据样式变化OCR识别率悄悄下降。所以选型时就要供应商承诺一套监控方案定期用固定测试集回归评测模型准确率检测Agent输出分布有没有明显漂移对OCR识别失败的票据数量做趋势监控以及一套回滚机制能在模型出问题后一键切回上一版本。没有这套体系的Agent用久了就是一颗定时炸弹。7. 选型测试方案POC这么设计才不踩坑7.1 用真实财务数据评测而不是用通用考试题很多供应商POC的时候用的是自己准备的标准样例比如几张干净的增值税发票、几个常见报销单。真正上了生产环境面临的全是脏数据扫描歪了的发票、PDF转出来的乱码、Excel表里带批注的金额、历史老系统导出的编码错位数据。所以我坚持让供应商在POC阶段使用脱敏后的真实财务数据。至少准备这样一批测试数据500张真实发票含电子发票、纸质扫描件、模糊件、重复件200条历史记账凭证涵盖高频科目和冷门科目50个复杂场景跨部门分摊、差旅超标、预算不足、多币种部分故意构造的错误数据金额不匹配、发票重复报销拿这套数据来测才能测出供应商真正的功力。如果对方说你们的发票格式我们不支持趁早换人。7.2 多轮模拟从票据到做账再到审批的全链路POC不能只测识别发票并提取字段那是OCR的事不是Agent的事。真正的测试要从用户输入一张发票图片开始一直到生成凭证草稿、触发审批流程、写入系统结束。我会设计10个完整场景要求供应商现场演示差旅报销多张发票混合计算总额判断超标生成报销单。对公付款合同关键信息提取关联供应商检查预算。费用分摊一张发票多成本中心分摊按比例生成多张凭证。异常检测重复发票、连号发票、金额阈值触发审批。审批后修改审批人退回Agent根据意见自动调整。跨系统联动从费控系统读取数据调用财务系统生成凭证。每个场景都要记录Agent独立完成率、人工介入次数、修改的必要性。最终要拿到一个量化指标端到端的自动化通过率。我见过做得好的供应商简单场景能到90%以上做得差的演示很完美但一换真实场景就掉到50%。7.3 性能与压测别在高并发面前翻车财务Agent的并发模型和普通客服不一样。平时可能没几个人用但月底结账、年末关账这几天财务人员集中操作事务量和并发都会突然上来。我建议POC期间做一轮简单的压测模拟20个并发用户同时提交单据。单条单据从提交到返回结果的最长时延是多少批量导入1万张发票Agent系统的吞吐量和失败率是多少在CPU、内存资源受限的情况下系统是否会降级或超时特别要注意的是大模型推理的时延通常比普通接口高一个数量级。如果财务Agent串联了多个模型调用识别、理解、生成单笔请求可能超过10秒这在实际体验里是不可接受的。供应商需要在架构上做并发缓存、排队、异步处理等优化选型时务必实测。8. 我见过的失败案例和供应商打单陷阱8.1 失败案例A模型升级分录规则全乱某券商采购了一款智能财务Agent上线一个月内运行良好。后来供应商在未经充分回归的情况下远程升级了大模型版本结果第二天开始原先把差旅费计到业务招待费的分类行为突然全部变形。财务团队没注意等到月底对账才发现一大批凭证科目错误整理返工花了整整一周。这件事告诉我们两条教训。第一Agent系统的模型升级权限必须锁死在甲方手里供应商不能远程自行操作。第二任何模型升级都必须先在镜像环境跑完整回归测试集通过后在生产环境做灰度发布并配一键回滚。把这两条写进合同和SLA比什么都重要。8.2 失败案例B支持国产数据库只是接口存在另一家银行选型时供应商演示了在达梦数据库上查询凭证数据速度很快效果很好。但等到集成测试阶段DBA发现Agent要往达梦里写入凭证时用的是JDBC底层批量插入性能和事务控制都有问题。更离谱的是Agent生成的部分SQL用了达梦不支持的窗口函数写法一执行就直接报错。所谓的支持达梦实际上只是测过几条select语句。这个坑非常典型。选型时一定要求供应商在POC阶段完成至少三种数据库操作查询、插入、更新/删除并且要覆盖事务回滚场景。别只看查询演示一定要看写入和事务的一致性。金融财务系统里写操作才是真正的主战场。8.3 供应商沟通的红线财务结果零容忍最后这点是我多年选型的底线。和供应商谈需求时我会直接说明财务场景的特殊性并把这些要求写进合同金额计算错误率必须为零。Agent如果计算出错的金额绝不能静默写入必须拦截并转人工。所有自动操作的最终审核权在人Agent只能提供建议和执行确定性任务不能全自动完成关账。产生任何审计疑问时Agent的全部操作链路必须可分批次导出。凡是听到这些要求就含糊其辞的供应商不管演示多漂亮我都会直接降权。做金融财务Agent最重要的不是功能炫不炫而是底线守不守得住。一套连失败兜底都没想清楚的系统不值得用真实账目去试错。我个人实际操作的体会是信创环境下的智能财务Agent选型本质是一个系统性工程决策。模型能力、信创栈适配、财务领域规则、安全审计缺一环都不行。与其被供应商的Demo牵着走不如先把上面这些清单和测试场景沉淀成你们自己的选型标准用统一标尺去量所有产品。这样不管市场宣传吹得多响你看到的就是真实适配度。后续如果有条件也可以从费用报销这一个高频场景起步用3到6个月把一个Agent真正跑进生产跑熟之后再想扩展的事。饭一口口吃Agent一个场景一个场景落这条路最稳。
阅读完成 · 觉得有帮助？
