企业官网建设流程全解析

"外面在为财务智能助手做供应商预审。对方展示的Demo能把报销单、发票识别、自动记账串成一条漂亮的流水线，页面也做得很有金融范儿。但当我问‘你们的Agent在鲲鹏ARM架构上真实跑过吗？接的是达梦还是Oracle？国密改造怎么对接？’的时候，对方明显犹豫了。这种场景我遇到不止两三回了。在信创环境下给银行或证券公司选智能财务Agent，本质上不是在买一个AI，而是在买一个能跟现有财务系统共生、能被审计认可的整栈工程。这篇东西就是把我这些年做选型、做POC、被供应商画饼后踩坑攒下来的要点写清楚，给真正要拍板的人一个抓手。"

1. 不可绕开的前提：为什么财务Agent要把信创兼容放在第一位

1.1 财务业务在银行/证券的特殊性

银行和证券的财务系统，跟我以前做过的零售、电商财务完全不是一个量级。这里说的"财务Agent"，不是简单帮你写个报销单的聊天机器人，而是要和总账、费用、固定资产、税务、监管报送等模块联动，自动完成单据识别、科目判断、凭证生成、预算检查、异常提醒甚至初步审批建议。

这类场景有三个非常硬的要求：

• 精度要求极高：金额差一分钱都不行，科目挂错更是事故。普通客服Agent回答错了可以再答一次，财务Agent入账错了是要调账的。
• 审计追溯极强：每一笔自动生成的凭证，要能说清楚"为什么这么记"。模型推理过程、数据来源、操作人、审批链都要留痕。
• 系统交互极深：Agent不只是对话，它要读取核心系统数据、调用记账接口、触发审批流，甚至操纵报表引擎。

这三个要求叠加在一起，导致一个结论：财务Agent的选型核心不在模型跑分，而在它能不能在你们真实的信创技术栈里稳定、合规、可解释地跑起来。

1.2 信创不是"装个国产系统就行"

我见过很多甲方把信创要求写成"操作系统麒麟、数据库达梦"，觉得列上去就行了。实际上，财务Agent涉及到的信创改造远比想象中复杂。一套完整的Agent系统从上到下包括：

任何一个层级掉链子，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），把企业财务制度、历史凭证样例喂进去。

选型时要重点考察三件事：

1. 供应商能否提供财务领域的微调能力和语料积累，而不是只包装一个开源模型就说"支持财务"。
2. 模型更新/迭代时，回归测试怎么做？金融场景最忌讳"模型行为漂移"，上次对了这次错了。
3. 推理框架是否已适配你们指定的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也要考虑信创RPA

Agent不是只靠一张嘴做财务的，它还要调用系统。银行证券的老财务系统很多是存量系统，没有对外开放的API，这时候就要靠RPA来操作界面，或者靠中间件收发报文。这就引出一个问题：Agent要能调用RPA，而RPA本身也要信创适配。

目前国内主流RPA厂商基本都有信创版本，比如来也UiBot、艺赛旗、云扩等，能跑在麒麟/UOS上，也能控制WPS、国产浏览器环境。但要注意，Agent和RPA之间的编排方式，是简单的"触发一个脚本"还是"动态传入参数并获取结果"？很多供应商的Demo里，Agent和RPA各做各的，中间靠人copy paste，这就不叫智能财务Agent了。

比较实际的架构是：Agent生成任务清单，每个任务对应一个RPA流程，Agent把结构化参数传给RPA，RPA执行完把结果回传，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个完整场景，要求供应商现场演示：

1. 差旅报销：多张发票混合，计算总额，判断超标，生成报销单。
2. 对公付款：合同关键信息提取，关联供应商，检查预算。
3. 费用分摊：一张发票，多成本中心分摊，按比例生成多张凭证。
4. 异常检测：重复发票、连号发票、金额阈值触发审批。
5. 审批后修改：审批人退回，Agent根据意见自动调整。
6. 跨系统联动：从费控系统读取数据，调用财务系统生成凭证。

每个场景都要记录：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一个场景一个场景落，这条路最稳。