企业官网建设流程全解析

每年做合规审计的时候，都是企业风控部门最头疼的时候。一堆合同要过、几百张报销单要核、供应商资质要重新审查，人工一个个过，既慢又容易漏。更麻烦的是，那些真正藏得深的合规风险——比如合同里夹带的不合理条款、报销单背后的关联交易、供应商之间的隐秘股权关系——往往要靠“人肉”经验才能嗅出不对劲。我见过不少企业尝试用传统RPA机器人做合规管控，结果发现机器人只能按固定规则跑，遇到语义模糊、需要判断的场景就抓瞎了。最近我在一个企业数字化改造的模拟项目里，落地了一套基于LLM（大语言模型）加RPA的智能化合规架构，结合“实在Agent”这类能自主决策的智能体框架，把原来靠人工拍脑袋判断的合规审核环节，变成了“规则引擎兜底、大模型推理判断、机器人自动执行、人工只处理高危异常”的流水线。这篇文章把整套架构的拆解思路、核心模块的落地细节、以及我实操中踩过的坑都梳理一下，给正在被合规管控折磨的同行们一个可参考的路线。

1. 项目背景与需求拆解

1.1 人工合规管控的典型漏洞到底在哪

做这类型项目之前，得先搞清楚一个核心问题：人工管控为什么会漏？我接触的多数企业，合规审核其实都有标准流程，但战线拉太长、人手不够、业务压力大，流程执行就打折扣了。比如合同审核，法务部一个人一天要过几十份合同，重点条款能看过来就不错了，那种藏在附录里的风险条款、前后矛盾的定义、不合理的违约责任分配，很容易扫一眼就放过去。再比如费用报销，财务审核看票据齐全度、金额是否超限，但报销背后的业务合理性——为什么这家供应商的报价比市场价高出一截？为什么同一家供应商连续三个月出现？——靠人工去逐条深挖根本不现实。

除了效率问题，人工管控还有一个结构性的短板：标准不一致。同样一份合同，A审核员觉得这条免责条款没问题，B审核员认为必须修改，最后批不批全看撞到谁手上。这种不一致性在审计的时候特别尴尬，同一个风险点，不同月份的处理方式完全不一样，外审一查就暴露了。

1.2 传统自动化（RPA）为什么只能打半场

很多人一听“合规自动化”，第一反应就是上RPA。不可否认，RPA在处理“规则明确、流程固定、系统操作重复”的场景上确实高效——自动登录系统、抓取页面数据、比对表单字段、提交审批，这些事机器人做得又快又准。但合规审核的难点从来不在“流程执行”，而在“风险判断”。判断需要理解上下文、需要看语义、需要综合多方信息做推理，传统的RPA脚本只能做字段级的关键字匹配，比如“合同金额是否超过100万”“发票号码是否存在”，一旦遇到“这个条款是否显失公平”“这个报销人和供应商是否存在潜在利益关联”这类需要深度理解的问题，传统RPA就无能为力了。

所以在项目设计初期，我就明确了方向：RPA不是不需要，而是不能只靠RPA。用RPA解决“执行层”的问题——把跨系统的数据抓齐、把重复动作自动跑完、把结果推送到审批流；用LLM解决“判断层”的问题——规则不好覆盖、标准不统一、需要语义理解的审核动作，全部交给大模型来推理。这就是LLM+RPA组合打法的核心逻辑。

1.3 项目目标与约束条件

基于上面的分析，我在项目启动时定了几个明确目标：第一，把合规审核的覆盖范围从“抽查”变成“全量”，每一份合同、每一张报销单、每一个供应商都过一遍机器审核；第二，把审核标准的执行统一到大模型推理上，消除人工判断的差异性；第三，高危风险必须保证零漏判，大模型的每个判断结果都要有依据说明，方便人工复核。同时还有一个约束条件——企业的核心业务系统不能动，不能用改造ERP的方式来做合规，只能在现有系统外层套一个“合规检查大脑”，所以RPA作为桥接层是必然选择。

2. 架构设计与技术选型解析

2.1 总体架构：LLM、RPA与Agent怎么分工协作

整套架构如果画成一张图，最底层是企业的各类业务系统——OA审批流、财务系统、CRM、供应商管理平台，再往上是RPA执行层，负责跟这些系统打交道：读数据、写数据、触发操作。RPA之上是Agent决策层，这是核心，它接收RPA采集来的原始数据，进行LLM推理判断，输出审核结论。最上层是人工复核台，只有Agent判断为“高风险”或“无法判断”的项目才会推到这一层，人工只需要处理小比例的异常单。

这里“实在Agent”扮演的角色是LLM与RPA之间的“调度中枢”。它把RPA采集到的非结构化数据——合同PDF、发票图片、审批意见、供应商公开信息——做结构化处理，然后根据不同的合规场景（合同审核、费用风控、供应商准入）选用不同的Prompt策略和推理链路。Agent还负责维护整个审核任务的上下文记忆，比如某份合同上一轮修改了第三条条款，下一轮审核时Agent要能记得这个修改结果，不能每次重新推理。

2.2 为什么选LLM+RPA而不是纯LLM或者纯RPA

有人会问：既然LLM这么能干，能不能让大模型直接把所有事都干了？理想情况下可以，但现实是——大模型接触不到企业内部系统的数据。它没有权限登录你的OA，读不到你的财务数据库，更没法在审批流里提交一个审核结果。LLM是一个“绝顶聪明的分析师”，但它是个没有手脚的分析师。RPA恰好补上了“手脚”：“分析师看完报表后指示机器人去执行具体操作”。反过来，纯RPA的问题是“手脚很勤快但脑子不够用”，只能按写死的规则跑，遇到规则没覆盖到的情况就崩了。

所以LLM+RPA的组合本质上是“大脑+手脚”的配合。LLM负责认知——理解条款、识别风险、对比政策；RPA负责行动——采集数据、触发流程、回填结果。Agent则把这两者粘合成一个闭环：感知（RPA采集数据）—推理（LLM分析判断）—执行（RPA提交操作）—反馈（结果回传Agent更新上下文）。

2.3 数据流与控制流的路径设计

我重点讲一下数据流的设计，这里是容易翻车的地方。合规审核依赖的数据源非常杂：内部系统里有合同台账、报销单、供应商资质文件；外部互联网有企业的工商信息、涉诉记录、行政处罚公告、新闻舆情。RPA要从这些异构来源里把数据全部捞出来，统一清洗成LLM能吃进去的格式，这一步工作量占比其实是最重的。

我用的方案是：RPA负责原始采集，把PDF、Word、网页、系统界面上的数据全部抓成长文本或表格；Agent做数据清洗和规范化，把杂乱的原文切分成“字段+内容”的结构化格式，带上来源标签，然后填充到Prompt模板里。控制流上采用“两级判定”：第一级是规则引擎，用硬规则快速过滤，比如合同金额超限、发票号重复、供应商证照过期，命中规则的直接标记异常；第二级才是LLM深度判断，处理规则引擎无法覆盖的语义类风险。这样设计的好处是节省LLM的调用成本，毕竟大模型按Token计费，能省则省。

3. 核心模块实操实现

3.1 合规规则库的知识工程建设

LLM不是万能的，它需要知道“什么算风险”，这就需要做知识工程。我的做法是先拉着合规部、法务部做了三轮访谈，把企业现有的合规制度、业务红线、历史审计发现的问题全部整理出来，编成一本结构化的“合规知识手册”。这本手册不是给人看的，而是用来构建规则库和Prompt指令集的。

规则库分成两部分：一部分是“刚性规则”，可以直接写成代码或规则引擎配置，例如：

{ "rule_id": "R001", "rule_name": "合同金额超限审查", "rule_type": "hard_rule", "condition": "contract_amount > 5000000", "action": "直接标记高风险并推送人工复核", "priority": "P0" }

另一部分是“柔性规则”，需要LLM来解读，例如“合同争议解决条款是否对己方不利”“付款条件是否明显缺乏合理性”，这类规则写不成代码，只能转化成语义化的Prompt指令，通过Few-shot示例让模型学会识别。这里有个心得：柔性规则的Prompt示例要尽可能用历史真实案例，正例反例各给3到5条，模型学出来的判断标准才贴合企业自身业务。

3.2 RPA与LLM的接口设计与数据清洗

实操中最大的坑在数据清洗。合同PDF看起来是文本，但很多扫描件实际上是图片，RPA抓出来之后是乱码；发票上的关键字段位置不固定，OCR软件识别精度也不稳定。我整理了一套清洗管线，分三步：

第一步是格式标准化。所有采集到的文件统一转成文本，扫描件先过OCR引擎；图片类的证据单独存放，文本内容抽取出来用于审核。第二部是字段抽取与对齐。用LLM从长文本中抽取关键字段——合同编号、签约主体、金额、日期、违约条款内容——输出成JSON格式：

{ "contract_id": "HT-2024-0892", "signing_parties": ["某某科技有限公司", "某某实业发展有限公司"], "contract_amount": 820000, "amount_currency": "CNY", "sign_date": "2025-06-15", "key_terms": { "违约责任": "若甲方延期交付，每延迟一日按合同总额0.5%支付违约金，但最高不超过合同总额30%", "争议解决": "双方争议应提交某某仲裁委员会仲裁" } }

第三步是语义校验。字段抽取后不能直接进审核流程，要先做一轮自洽性检查，比如合同金额前后是否一致、签约主体名称与工商登记是否匹配，逻辑上站不住的数据直接打回重新采集。这套管线跑通之后，RPA采集的数据质量稳定了很多，LLM的判断准确率也上来了。

3.3 智能审核引擎与人工复核闭环

审核引擎是整个架构的决策核心。我设计了一套多级审核链路，第一级规则引擎——毫秒级响应，把明显的硬性问题直接拦住；第二级LLM推理——处理语义类风险，每次推理要求模型先给出“判断依据”，再给出“风险等级”和“整改建议”，例如对合同做风险分析时，LLM输出要求严格缩写以下格式：

风险等级：高 风险摘要：争议解决条款约定仲裁地为对方所在地仲裁委员会，且适用对方所在地法律，对己方可能产生不利影响 判断依据：合同附录B第7.2条明确约定“仲裁机构为乙方所在地某仲裁委员会，适用乙方所在地法律”。鉴于本合同履行地为甲方所在地，该条款增加了甲方的维权成本与不确定性。 处理建议：建议修改争议解决条款，将仲裁地变更为甲方所在地仲裁委员会或中立地点的仲裁机构，或在商务谈判中争取适用合同履行地法律。

第三级人工复核——只处理高风险单和模型置信度偏低的单。这里要单独说下置信度机制，因为LLM天生不会说“我不会”，它就算不确定也会硬给一个结论。我的方案是让模型在推理前先做一轮“已知信息充分度自评”，信息不足时强制要求触发补充采集，不能直接下结论。

3.4 审计日志与全链路追溯

合规系统本身也要过审计这一关。系统跑出的每一条审核结果，都要能追溯到“谁在什么时间看了什么数据，基于什么规则或者模型得出了什么结论”。我在这套架构里做了全链路日志，具体包括几个维度：

基础的日志字段包含任务流水号、输入数据快照、命中的规则编号、LLM推理的原始输入和输出、执行时间戳，以及操作人账号。输入数据快照这块比较关键，因为合同、发票这类原始文件可能会在后续被替换或删除，如果没有留底，审计的时候就没法还原当时的判断场景。我把每个审核任务关联的原始文件全部做了副本存储，权限上只有审计管理员可读，业务人员改不了。

数据层面还做了一层完整性校验，日志记录里的关键字段每批次都生成哈希值，防止内部篡改日志的情况。这套设计一开始觉得有点过度设计，结果后来真的有监管检查要求复现某个月的审核情况，全链路日志直接派上了大用场。

4. 典型业务场景实战拆解

4.1 合同条款合规审查场景

合同审核是这套架构跑通后最稳定的场景。流程大概是这样的：RPA机器人每天定时从OA系统里扫描新建的合同审批单，把合同正文PDF下载到本地，同时抓取合同台账里的关联业务信息，比如项目编号、预算金额、申请人部门。Agent收到材料后先做字段抽取，标准化成结构化数据，然后送进两级审核链路。

第一级规则引擎跑硬规则，比如合同金额超出部门预算范围、合同缺少法人签字页、合同有效期早于当前日期，这些都是即查即决。第二级LLM做深度条款审查，重点检查五类风险：违约责任失衡、知识产权归属不清、保密条款缺失或过弱、争议解决条款对己方不利、付款条件明显不合常理。LLM跑出来的结果直接在审批流里生成一条风险评估记录，作为法务审批时的辅助参考。

推到这个阶段我踩过一个坑：一开始Prompt设计得过于笼统，让模型“请审查本合同是否存在法律风险”，模型输出的内容也很泛泛，什么都能找出点问题，但什么都说不到点上。后来改成拆分子任务——先看违约责任是否对等，再看争议解决条款，逐个审查，每个维度单独出结论，最后汇总。效果差别非常大。

4.2 费用报销单据智能风控场景

费用报销的合规难点在于“真实合理性”。一张发票本身是真的、金额没超标、审批流程也走完了，但背后可能涉及虚构业务、关联方套现、重复报销。传统RPA做报销审核，最多查一下发票号是否重复、抬头是否匹配，更深层的利益关联判断根本查不出来。

我在这个场景里设计了几个增强点：一是报销人与供应商的关联关系识别，把报销单上的供应商名称与工商大数据里的股权关系做匹配，如果发现报销人是该供应商的股东、监事或亲属持股，系统自动标记为高风险。二是报销合理性判断，LLM会结合报销人岗位、出差记录、项目背景综合分析，比如一个销售岗位的人报销了一笔大额技术服务费，模型会提示“该支出与岗位职责关联性存疑，建议补充业务说明”。三是连号发票检测，RPA从历史报销库里筛查同一批次开出的连号发票，命中直接预警。

4.3 供应商准入与关联交易识别场景

供应商准入审核信息量很大，一家供应商要审营业执照、行业资质、财务报表、涉诉记录、股东结构、是否被列入严重违法失信名单。而且中介机构、代理公司、关联公司之间的嵌套关系非常隐蔽，人工去查非常耗时。

这套架构在这个场景的做法是：RPA每天自动去外部数据源抓取供应商相关的工商变更、涉诉信息、行政处罚公告，并定时把供应商的全部股东链条拉取下来做股权穿透分析。LLM负责把股权穿透结果跑出来的模型数据进行语义解读，识别是否存在直接或间接的关联关系，以及是否形成竞合关系。输出结果综合风险等级、判断依据、建议动作，直接推送给采购审批人。这个场景实际跑起来准确率还不错，关键是RPA定时抓取外部信息的能力要稳定，这块后面单独展开讲。

5. 常见问题与排查技巧实录

5.1 大模型幻觉导致误判率偏高怎么办

合规场景对误判率极其敏感：模型把没问题的合同判定为高风险，业务部门会烦死；把有问题的合同放过去，更是不可接受。我跑了大概两个星期之后就遇到幻觉问题——模型煞有介事地写“合同第4.3条存在违约风险”，我去翻原文根本没有这条，这种“一本正经地胡说八道”最可怕。

排查之后发现根源在Prompt太开放。我调整了几个地方：第一，强制模型在输出判断依据时带上原文引用，并且明确指出出自合同的哪一条哪一款，没有原文佐证的风险结论自动降级为“建议关注”而不是“高风险”。第二，在推理前增加一轮“条款确认”步骤，让模型先从原文中提取出认为有风险的条款原文，再基于这些原文做分析，相当于先用分隔符把内容锁定。第三，对于无法完全确定的高风险结论，默认走人工复核而不是直接拦截，宁可多人工看一张单，也不能错杀。

5.2 RPA机器人不稳定、流程中断怎么办

RPA的稳定性很多情况下取决于被自动化系统的稳定性。页面改版了、弹窗变多了、网络慢了几秒，都可能让RPA流程中断。我遇到过最头疼的是企业OA系统升级后登录页结构变了，所有RPA任务集体罢工。后来总结了两条经验：一是所有RPA操作尽量走接口而不是走界面操作，能和系统API对接的操作优先用API，万不得已才用UI自动化，接口的稳定性远高于界面识别。二是给RPA任务加“看门狗”机制，每个执行步骤都有超时控制，超时自动重试，重试三次还失败就发告警消息给运维人员，而不是让机器人静默卡死。

5.3 人工复核任务积压、处理不及时

系统上线初期会遇到一个尴尬局面：机器审核确实发现了不少问题，但人工复核岗忙不过来，高风险单积压，审批流被堵死。合规部门的人本来就少，不可能天天坐那看机器推过来的单子。

解决办法是给复核台做“分级路由”。P0级别的单（可能涉及刑事风险、重大财务造假的）必须24小时内处理，直接推送邮件加短信提醒；P1级别的单（存在显著合规瑕疵但不涉及重大违法）48小时内处理即可，安排在复核台排队；P2级别的单（模型置信度低但风险不明确）不强制时限，攒到一定数量后批量处理。这样一分级，人工压力就下来了，紧急问题也能保证及时响应。

5.4 性能与成本怎么平衡

LLM调用成本是按Token算的，如果每一份合同都丢给大模型做全文推理，成本会非常夸张。我测试过一篇二十页的合同全文推理大概消耗两万多Token，按商业模型的价格算下来不便宜。成本优化的方向有几个：第一，规则引擎前置过滤，能通过硬规则直接判断的单子不调大模型，实测下来大概能挡掉四成左右的单子。第二，全文太多就做分段切片，只送关键条款进LLM推理，比如违约条款、争议解决条款、知识产权条款，这些合规风险高发地段单独送，背景信息支持性内容不送。第三，高频相似的场景用模型蒸馏做轻量化处理，前置部署一个小参数模型，只有小参数模型判断不了的时候才调用大模型兜底。

6. 实操心得与扩展方向

这套LLM+RPA智能化合规架构上线运行之后，我感触最深的一点是：转型的真正价值不是把人工审核这份工作干掉，而是把人从低价值的重复劳动里解放出来。机器把八成的合同初审、发票核对、信息采集全部跑完了，合规人员只需要盯着剩余两成的异常案件做深度分析。原来一个合同审核员一天看二十份合同加班到晚上九点，现在一天只需要精审五六份高风险合同，反而有精力把每单的背后逻辑摸透。

我个人比较推荐的做法是，在推广这套系统时不要一上来就追求“自治化全流程”，而是先用六到八周做“辅助审核”模式，机器只出结论和依据，不直接拦截业务，让合规部门的人用实际案例去校验模型。校验数据攒够了再逐步调高机器直接拦截的比例，给业务部门一个适应期，也给模型调优留出数据积累的时间。

后续可以扩展的方向其实不少。我目前正在研究的是把时间线拉长，做“持续合规监控”，不只做单据触发式的检查，而是让Agent定期主动扫描业务数据，发现中长期的风险趋势——比如某类供应商的准入材料有效期快过期了、某个部门的费用结构出现异常波动。另一个方向是用多Agent协同应对更复杂的跨部门合规场景，比如一个Agent管合同、一个Agent管资金流、一个Agent管供应商，当两个Agent交叉感知到同一主体关联异常时自动联合研判。这套架构的想象空间很大，而且最关键的是，它不需要推翻企业现有的IT系统，是在旧系统外面加一层“合规智能大脑”，对大多数企业来说，落地门槛比想象中要低很多。