1. 从一次真实的选型翻车说起
去年下半年，我参与了一家城商行的智能财务Agent选型评估。当时行里已经跑了两年的信创改造，办公终端、数据库、中间件基本都换成了国产栈，财务共享中心那边提了个需求：想上一套能自动处理报销单据、做费用稽核、生成凭证草稿的智能Agent，把财务人员从重复劳动里解放出来。
项目组一开始的思路很直接——找市面上做财务RPA和AI Agent最成熟的几家厂商来POC。结果第一轮演示就出了问题：某家头部厂商的产品在演示环境跑得行云流水，一搬到行里的信创测试环境，OCR识别模块直接报错，原因是它依赖的某个图像处理库在国产ARM架构的服务器上根本没有编译好的版本。另一家的Agent倒是能跑起来，但它的推理服务默认要连公网调用云端大模型，这在银行内网环境里是绝对过不去的合规红线。
这两次翻车让我意识到一件事：在信创环境下选智能财务Agent，和在普通企业环境里选，完全是两套逻辑。普通环境里你主要看功能、看准确率、看价格；信创环境里，功能只是入场券，真正的胜负手在于——这套东西能不能在你的国产软硬件底座上稳定跑起来，能不能满足金融行业的合规要求，能不能在不出内网的前提下完成推理。
这篇文章就是把这套选型逻辑拆开讲清楚。不管你是银行、证券、保险的科技条线负责人，还是正在做信创改造的财务信息化从业者，下面这些内容应该都能帮你少走几个月的弯路。
2. 信创环境给智能财务Agent套上的三层约束
2.1 硬件层：ARM与x86的架构鸿沟
很多人对信创的理解还停留在"换个国产CPU"的层面，觉得只要操作系统能跑，上层应用就都能跑。这个认知在传统业务系统上勉强成立，但在AI Agent这类重度依赖计算库的应用上，会摔得很惨。
目前主流的信创服务器CPU以ARM架构为主，比如鲲鹏、飞腾系列，也有部分海光、兆芯的x86兼容路线。问题在于，智能财务Agent的核心能力——文档OCR、NLP语义理解、大模型推理——底层都依赖大量的数学计算库和深度学习框架。这些框架在x86+英伟达GPU的生态里打磨了十几年，各种预编译包、加速库一应俱全；但到了ARM架构上，很多库要么没有官方支持，要么性能打了对折。
我实测过一组数据：同一个票据识别模型，在x86服务器配一张推理卡的环境下，单张发票的识别耗时约180毫秒；换到ARM服务器纯CPU推理，耗时直接飙到1.2秒。如果财务共享中心每天要处理几万张单据，这个差距就是能不能按时出账的问题。
所以选型时第一个要问厂商的问题不是"你们支持信创吗"，而是**"你们在ARM架构上的推理性能实测数据是多少，用的什么加速方案"**。如果对方支支吾吾说不清楚，基本可以判断他们只是在x86上跑通了然后宣称"兼容信创"。
2.2 软件层：国产OS与中间件的适配深度
操作系统层面，麒麟和统信UOS是两大主流选择。这两套系统虽然都基于Linux内核，但在系统调用、依赖库版本、安全策略上各有各的脾气。一个在CentOS上跑得好好的Agent服务，搬到麒麟上可能因为glibc版本差异直接起不来。
更隐蔽的坑在中间件层。银行的信创改造通常会配套替换数据库和消息队列，比如从Oracle换到达梦或OceanBase，从Kafka换到国产消息中间件。智能财务Agent需要频繁读写业务数据、缓存推理结果、做任务调度，这些环节全都跟中间件打交道。如果Agent厂商只做过MySQL适配，没碰过达梦，那数据读写这一层就得重新开发。
我的经验是，在POC阶段一定要让厂商在真实的信创环境里部署，而不是他们自己搭一个"模拟环境"。真实环境里的坑，模拟环境里一个都遇不到。
2.3 合规层：数据不出域与模型本地化
这是金融行业最硬的一条红线。银行的财务数据涉及大量敏感信息——供应商账户、员工薪酬、交易流水——这些东西绝对不能出内网。但市面上很多智能Agent产品是SaaS形态，或者虽然支持私有化部署，但大模型推理仍然要调用外部API。
证券行业的要求同样严格。根据行业监管要求，客户信息和交易数据必须在内网闭环处理。这意味着智能财务Agent如果要用到大模型能力，必须支持本地化部署的国产大模型，比如部署在行内GPU服务器上的开源模型，或者厂商提供的私有化推理方案。
这里有个容易被忽略的细节：本地化部署的大模型，参数量通常比云端模型小很多，推理能力会有折扣。选型时要重点评估厂商有没有针对财务场景做模型微调，有没有蒸馏出适合本地部署的小模型。一个7B参数的通用模型直接拿来处理财务单据，准确率大概率不如一个经过财务语料精调的3B模型。
3. 拆解智能财务Agent的核心能力模块
3.1 单据识别：不只是OCR那么简单
很多人把智能财务Agent的单据处理能力等同于OCR，这是个很大的误解。OCR只负责把图片上的文字提取出来，但财务场景真正难的是理解这些文字的含义。
举个例子，一张增值税发票上有几十个字段，OCR能把所有文字都识别出来，但Agent需要判断：这张票是专票还是普票？税率是多少？购买方和销售方的税号是否匹配？发票金额和报销单金额是否一致？这些判断需要的是结构化抽取和业务规则引擎，不是单纯的文字识别。
在信创环境下，这个环节的挑战在于：很多高精度的OCR模型依赖GPU加速，而信创服务器上可能没有可用的GPU。厂商如果只提供GPU版本的识别服务，到了纯CPU环境就得降级使用传统OCR引擎，准确率会明显下降。
选型时要重点考察厂商有没有CPU优化版的识别模型，以及在国产CPU上的实测准确率。我见过一家厂商的方案，在x86+GPU环境下发票识别准确率98.5%，到了ARM+CPU环境降到91.2%，这个差距在财务场景里是不可接受的——每100张票就有近9张需要人工复核，自动化就失去了意义。
3.2 规则引擎：财务稽核的"大脑"
单据识别出来之后，下一步是稽核。财务稽核的规则非常复杂，而且每家银行、每家券商的规定都不一样。比如差旅报销，有的单位规定住宿标准是每晚不超过500元，有的规定一线城市可以上浮20%，有的还区分职级。
智能财务Agent需要有一个灵活的规则引擎，让财务人员能够自己配置这些规则，而不是每改一条规则就要找厂商开发。这个规则引擎要支持条件判断、数值计算、逻辑组合，最好还能支持自然语言配置——财务人员用大白话写"住宿费超过500元且没有审批单的，标记为异常"，系统就能自动生成规则。
在信创环境下，规则引擎的挑战在于性能。一家大型银行每天产生的报销单据可能上万笔，每笔单据要跑几十条稽核规则，如果规则引擎的执行效率不够，整个流程就会卡住。选型时要问清楚规则引擎的并发处理能力，最好能在POC环境里做压力测试。
3.3 凭证生成：与财务系统的对接能力
稽核通过之后，Agent要自动生成会计凭证，并推送到财务系统。这个环节的关键不是Agent本身有多智能，而是它能不能跟行里现有的财务系统无缝对接。
银行的财务系统通常是SAP、Oracle EBS或者国产的用友、金蝶，这些系统的接口标准各不相同。有的提供标准API，有的只能用数据库直连，有的甚至只能通过文件导入导出。智能财务Agent如果只支持某一种对接方式，到了实际环境里就可能卡住。
更麻烦的是信创改造带来的系统替换。很多银行正在把SAP换成国产ERP，把Oracle数据库换成达梦。如果Agent厂商的对接方案是基于旧系统的接口开发的，新系统一上线就得重新适配。选型时要优先考虑那些对接层做了抽象设计的厂商，换系统时只需要改配置，不需要改代码。
3.4 大模型推理：本地化部署的取舍
前面提到，金融行业要求数据不出域，所以大模型必须本地化部署。但本地化部署面临一个现实问题：算力从哪来。
信创服务器通常不配英伟达GPU，国产GPU（如昇腾、寒武纪）虽然在进步，但生态成熟度还有差距。如果行里没有专门的GPU服务器，大模型只能跑在CPU上，推理速度会非常慢。一个7B参数的模型在CPU上生成一段200字的稽核说明，可能需要十几秒，用户体验很差。
这时候就要做取舍：是用小模型牺牲一点准确率换速度，还是用大模型接受慢速但更准的结果？我的建议是分场景选择。对于标准化程度高的单据识别和规则稽核，用传统模型+规则引擎就够了，不需要大模型；对于需要理解复杂语义的场景，比如从合同文本里提取付款条款，再用大模型，而且可以接受异步处理——用户提交后先去做别的事，处理完了再通知。
4. 选型评估的五个硬指标
4.1 信创兼容性：要的是"认证"还是"实测"
现在市面上几乎每家厂商都会说自己"支持信创"，但你仔细一问，有的是真适配，有的是"兼容"。区别在哪？
真适配的厂商，会针对主流的信创组合（比如鲲鹏+麒麟、飞腾+统信）做专门的优化和测试，能拿出具体的性能数据，甚至有针对性的加速方案。兼容的厂商，通常只是在信创环境里跑通了基本功能，性能没优化，遇到问题只能临时排查。
选型时不要只看厂商提供的"信创兼容性认证"证书，那个东西的含金量参差不齐。更靠谱的做法是要求厂商在行里的信创测试环境做一次完整的POC，用真实的业务数据跑一遍全流程，记录每个环节的耗时和准确率。这个数据比任何证书都有说服力。
4.2 推理性能：CPU环境下的真实表现
前面反复提到性能问题，这里给一个具体的评估框架。对于智能财务Agent，重点看三个指标：
| 指标 | 含义 | 可接受范围（参考） |
|---|---|---|
| 单张单据识别耗时 | 从图片输入到结构化字段输出 | CPU环境≤500ms |
| 单笔稽核规则执行耗时 | 跑完所有规则并输出结果 | ≤200ms |
| 大模型生成响应时间 | 生成一段稽核说明或凭证摘要 | ≤5s（可异步） |
这些数字不是绝对的，要根据业务量来定。如果每天只有几百笔单据，慢一点也能接受；如果是几万笔，就必须卡死性能指标。
测试时要注意并发场景。单张单据跑得快不代表并发也快，很多Agent在单线程下表现不错，一上并发就崩。POC时一定要模拟业务高峰期的并发量，看看系统能不能扛住。
4.3 规则可配置性：财务人员能不能自己改
这个指标经常被忽略，但实际使用中极其重要。财务政策是经常变的——税率调整、报销标准更新、审批流程优化——如果每次改规则都要找厂商，响应周期太长，财务部门会很不满意。
评估时可以让财务人员直接上手试：给一条新的稽核规则，看他们能不能在不需要技术人员帮助的情况下配置进去。如果厂商的规则引擎需要写代码或者用复杂的表达式，那就不合格。好的规则引擎应该支持表格化配置或者自然语言配置，让财务人员像填Excel一样简单。
4.4 系统对接的灵活性：换系统时要不要改代码
前面讲过对接层抽象设计的重要性，这里补充一个评估方法：问厂商"如果我们明年把财务系统从A换成B，你们的Agent需要做哪些改动"。如果对方的回答是"只需要改配置"，那说明对接层设计得不错；如果回答是"需要重新开发接口适配"，那就要慎重考虑了。
信创改造是一个持续的过程，今天换数据库，明天换ERP，后天可能换中间件。智能财务Agent作为上层应用，必须能够适应底层的持续变化。选型时要看厂商的架构设计能力，而不是只看当前的功能清单。
4.5 厂商的信创服务能力：出了问题谁来扛
这一点很现实。信创环境里的问题往往比较偏门——某个依赖库在ARM上编译不过、某个中间件的版本不兼容、某个安全策略导致服务起不来——这些问题需要厂商有足够的技术支持能力来快速定位和解决。
评估厂商的服务能力，可以看几个方面：有没有专门的信创支持团队？有没有积累常见问题的知识库？能不能提供驻场支持？响应时间是多少？这些信息在售前阶段可能问不出来，可以通过侧面了解——比如问问他们现有的金融行业客户，在信创环境里遇到过什么问题，厂商是怎么解决的。
5. 一个可复用的POC测试方案
5.1 测试环境搭建：尽量贴近生产
POC环境不要用厂商提供的"演示环境"，也不要用行里随便找的测试机。最好的做法是从生产环境里划出一套与生产配置一致的信创资源，包括同型号的CPU、同版本的操作系统、同款的数据库和中间件。
如果资源有限，至少要做到CPU架构和操作系统版本与生产一致。我见过一个案例，POC用的是x86测试机，生产是ARM服务器，结果上线后性能差了5倍，不得不紧急扩容。
测试数据也要用真实的业务数据，至少是脱敏后的真实数据。用厂商自带的样例数据测出来的结果没有参考价值，因为样例数据通常是精心挑选的"好数据"，真实数据里的各种异常情况才是考验。
5.2 测试用例设计：覆盖典型场景和边界情况
测试用例要覆盖财务共享中心的典型业务场景，同时也要设计一些边界情况。以下是一个参考清单：
- 标准场景：正常的增值税发票报销、差旅报销、费用分摊
- 异常场景：模糊的发票图片、手写单据、多张发票合并报销
- 边界场景：金额刚好等于审批阈值、税率处于政策过渡期、供应商名称有别名
- 并发场景：模拟月末结账高峰期，同时提交大量单据
每个场景都要记录Agent的处理结果和耗时，跟人工处理的结果做对比。重点关注准确率和召回率——准确率是识别出来的单据里有多少是对的，召回率是所有该识别的单据里有多少被识别出来了。财务场景对准确率要求极高，因为一个错误的凭证可能导致账务混乱。
5.3 评估打分：量化对比不同厂商
POC结束后，需要一个量化的评估框架来对比不同厂商。建议从以下几个维度打分：
| 维度 | 权重 | 评分要点 |
|---|---|---|
| 信创兼容性 | 25% | 在真实信创环境的部署成功率、性能表现 |
| 功能准确率 | 25% | 单据识别、稽核、凭证生成的准确率 |
| 性能表现 | 20% | 单笔耗时、并发处理能力 |
| 规则可配置性 | 15% | 财务人员自主配置的便捷程度 |
| 服务能力 | 15% | 技术支持响应速度、问题解决能力 |
权重可以根据行里的实际情况调整。比如如果行里的信创改造已经完成，兼容性风险较低，可以适当降低这个维度的权重，把更多权重给功能准确率。
6. 那些厂商不会主动告诉你的坑
6.1 "支持信创"和"信创优化"是两回事
很多厂商的宣传材料上写着"全面支持信创"，但你仔细看小字，会发现写的是"已完成与XX操作系统、XX数据库的兼容性认证"。兼容性认证的意思是"能跑"，不是"跑得好"。
真正做过信创优化的厂商，会针对国产CPU的指令集做加速，会针对国产操作系统的内核参数做调优，会针对国产数据库的SQL方言做适配。这些工作不会写在宣传材料上，但会在实际使用中体现出来。
选型时可以直接问厂商："你们在信创环境上做了哪些性能优化？"如果对方能说出具体的优化手段和效果数据，说明是真做过；如果说不出，那大概率只是做了兼容性测试。
6.2 大模型本地化部署的隐性成本
本地化部署大模型听起来很美好——数据不出域、自主可控——但隐性成本很高。首先是硬件成本，要跑一个像样的大模型，至少需要一张推理卡，而信创环境下的国产推理卡价格不菲。其次是运维成本，大模型需要持续调优、更新、监控，这些都需要专门的AI运维人员。
还有一个容易被忽略的成本是电力。GPU服务器的功耗远高于普通服务器，如果行里的机房供电和散热没有提前规划，可能会遇到意想不到的问题。
所以在选型时，要算清楚总拥有成本，不要只看软件授权费。如果行里已经有GPU资源，可以复用；如果没有，要把硬件采购和运维成本算进去。
6.3 规则引擎的"最后一公里"问题
规则引擎的配置界面做得再友好，财务人员第一次用的时候还是会遇到问题。比如"且"和"或"的逻辑组合，很多人搞不清楚优先级；比如数值比较时，要不要包含边界值，容易搞错。
这时候厂商的实施团队就很重要了。好的实施团队会帮财务人员把第一批规则配置好，并且做好培训，让财务人员在实际使用中逐步掌握。差的实施团队扔下一本操作手册就走人，财务人员遇到问题找不到人问，最后规则引擎就闲置了。
选型时要问清楚实施服务的具体内容：包不包括规则配置？包不包括培训？培训几次？后续有问题怎么支持？这些细节决定了系统上线后能不能真正用起来。
6.4 与现有RPA的共存问题
很多银行在引入智能财务Agent之前，已经部署了RPA来处理一些重复性工作。智能财务Agent上线后，跟现有RPA是什么关系？是替代还是互补？
如果Agent的能力覆盖了RPA的工作，那RPA可以逐步退役；如果Agent只覆盖了一部分，那两者需要共存，就要考虑任务调度和结果同步的问题。比如Agent处理完单据后，需要RPA把凭证录入财务系统，这两个系统之间怎么传递数据、怎么保证不重复处理，都需要提前设计。
选型时要考虑Agent的开放能力——有没有标准的API、能不能跟现有的RPA平台集成、支不支持消息通知。这些能力决定了Agent能不能融入现有的自动化体系，而不是成为一个信息孤岛。
7. 我个人在实际操作中的几点体会
做了几个信创环境下的智能财务Agent选型项目之后，我最大的体会是：不要被厂商的演示迷惑，一定要在真实环境里跑一遍。
演示环境是厂商精心准备的，网络是通的、数据是干净的、硬件是顶配的。真实环境里，网络可能不稳定、数据可能有各种脏东西、硬件可能差好几个档次。只有在真实环境里跑通了，才算数。
另一个体会是从小场景切入。不要一上来就追求全流程自动化，先选一个最痛的点——比如发票识别——把这个问题解决好，让财务人员看到效果，再逐步扩展。全流程自动化听起来很美，但实施周期长、风险大，一旦某个环节卡住，整个项目都会受影响。
最后一点是重视财务人员的反馈。智能财务Agent最终是给财务人员用的，他们觉得好不好用，决定了系统能不能真正落地。选型阶段就要让财务人员参与进来，让他们试用、提意见。有时候技术人员觉得很好的功能，财务人员根本不关心；财务人员很在意的细节，技术人员觉得不重要。只有让真正用的人参与选型，才能选到合适的系统。
信创环境下的智能财务Agent选型，本质上是在技术可行性、业务匹配度、合规安全性三者之间找平衡。没有完美的方案，只有最适合当前行里实际情况的方案。把上面这些评估维度想清楚，把POC做扎实，大概率不会选错。
