企业合规智能化：LLM+RPA+Agent架构设计与实战

企业合规这事儿我这两年被问得最多的就是一句话“明明配了人、定了制度、走了流程怎么还总是出事”其实答案很扎心纯靠人工盯合规本质上是在用有限的人力对抗无限变化的规则和系统。就拿供应商准入审查来说业务员催着下单合规专员得去登录工商系统查主体信息去裁判文书网看涉诉记录去内部ERP比对历史合作黑名单一套流程下来小半天漏看一个司法风险点后面可能就是几百万的坏账。后来我把思路换成了LLMRPA结合智能Agent的架构把“看懂规则”和“执行操作”两件事分开又串起来落地了一套合规审查与监控的自动化框架。这篇文章就把整个技术方案、架构设计、踩坑过程和提示词细节全部拆开讲清楚适合正在做合规数字化、风控中台或者流程自动化的团队参考。看完你能直接照着搭一套出来至少能省掉八成重复劳动。1. 人工合规管控为什么总是漏——先聊聊痛点的根源1.1 人工合规的三个结构性缺口先说第一个缺口依赖个人经验。很多企业的合规规则其实写在制度文件里但是不同专员执行的时候尺度完全不一样。同样是审核一份经销商合同老员工知道要额外核查对方是否在行业黑名单里新员工根本不知道有这一步。这种隐性知识不沉淀到系统里就是巨大的管理漏洞。第二个缺口是跨系统操作断层。合规审查永远不只是点一个按钮的事。你查一个企业的资质要登录市场监管局官网要去企业信用平台查年报要去司法机关网站看涉诉还要回到自己的管理后台比对历史记录。这些系统彼此独立人工要把所有信息粘合到一起光复制粘贴就够折腾一旦哪个系统的页面改版或者字段位置变化专员没注意到这条数据就废了。第三个缺口是对规则变化响应太慢。合规政策不是一成不变的某些行业时不时出新规比如数据安全法一落地所有涉及个人信息处理的业务都要重新评估。纯靠邮件通知、会议宣贯来同步规则大概率是文件躺在邮箱里没人看真正执行时还在按老经验办事。这三个缺口叠加起来的结果就是企业花了大价钱搭的合规体系实际拦截率不到六成。而剩下的四成风险往往恰恰是最致命的那部分。1.2 什么样的合规场景最先应该被自动化不是所有合规业务都适合马上上智能体。根据我跑过的项目最值得优先自动化的场景有三个特征高频重复、强规则性、跨系统取数。最适合的先说供应商准入审查。每次来一个新供应商要核营业执照、查涉诉、比对黑名单、评估股东背景这套动作完全标准化只是每次数据不同。第二个是费用报销合规校验发票真伪、发票抬头是否与合同一致、报销金额是否超标准、是否重复报销这属于典型的多源数据比对。第三个是合同关键条款审查检查合同中是否包含对赌条款、无限责任条款、数据安全承诺缺失等高风险点。这三个场景在传统RPA阶段其实做过一轮自动化但效果并不好。原因在于传统RPA只能做“规则确定”的动作比如下载文件、登录系统、抓取指定字段。一旦涉及需要理解语义、判断模糊场景——比如“这一条违约条款是否明显加重了我方责任”——传统RPA就无能为力了。你不可能为每个判断场景都写死几十个if-else工作量爆炸而且维护困难。所以这个阶段引入LLM不是赶时髦而是真的被逼出来的需求。大模型能干的是语义理解、抽取、判断和生成而这些正是RPA最薄弱的部分。两者天然互补。2. LLM、RPA与Agent到底怎么配合——理解技术底座的协同逻辑2.1 RPA与LLM各自的能力边界先把这两件事的能力边界讲清楚不然很容易做出一堆花架子。RPA的核心能力是“模拟人工操作”鼠标点击、键盘输入、页面字段读取、文件下载、系统间数据搬运。它执行的是确定性流程比如登录某个后台、输入日期范围、导出报表这些操作必须在规则完全明确、页面结构稳定的前提下才能稳定运行。一旦界面改版、弹窗位置变了、按按钮的元素属性失效RPA脚本就会挂掉这是它的天然局限。LLM的核心能力是“理解与生成语言”可以从一段非结构化文本里抽取关键信息可以判断一份合同里是否存在不合理条款可以根据上下文自动生成审查意见甚至可以对比两份文件之间的差异。但LLM的问题在于没有手和脚它不能替你去登录系统点按钮也不能直接调用某个内部接口拉数据。它只能基于喂给它的文本做推理。所以这两者放在一起化学反应才成立。RPA负责把外部系统和数据源里的内容“抓过来”变成文字LLM负责理解这些文字并做出判断最后再由RPA把判断结果写回系统、触发后续动作。这个协同逻辑是所有合规智能体的核心干法。2.2 智能Agent在整个架构里扮演什么角色有了RPA和LLM是不是就够了还不够。还需要一个东西来“编排”它们——这就是Agent智能体的工作。Agent本质上是一个带目标的调度器。它接收一个高层级任务比如“审查2024年所有新增供应商”然后自己拆解成多个子步骤先列出供应商名单再逐个调取外部数据再触发LLM审查再汇总异常项最后生成报告并通知相关人员。每一步调用RPA还是调用LLM由Agent根据任务判断而不是靠人一步一步写死。用Agent还有一个好处是处理异常。假设在批量审查过程中某个供应商的页面加载超时了传统RPA脚本直接报错退出Agent可以自主判断“重试一次”或者“先跳过记录异常最后统一处理”。这种动态容错能力在规模化运营时非常关键。我把整个架构拆成了四个层次感知层RPA采集数据、OCR识别证件、认知层LLM理解、抽取、判断、决策层Agent基于规则库和模型结果编排动作、执行层RPA写回结果、发送通知、触发审批流。数据在四层之间流转上层决策需要什么数据下层就去采集和加工什么数据。2.3 一整套架构的四个层次划分用更具体的方式描述一遍感知层解决“数据从哪来”的问题。合规审查需要的数据通常散落在各个系统里ERP、CRM、外部信用平台、司法网站、内部文件服务器。RPA在这层做的事情就是模拟人工登录、检索、抓取、截图留痕把非结构化的内容转成结构化文本交给上层。认知层解决“数据是什么意思”的问题。LLM在这里被调用做实体抽取、关键条款识别、风险等级判断、逻辑推理。例如判断一份合作协议里是否包含“单方无限责任条款”或者从一段裁判文书里抽取出被告方名称和判决金额。决策层解决“接下来做什么”的问题。Agent根据认知层的输出加上预设的业务规则决定当前事项的走向通过、人工复核、拒绝、补充材料。规则引擎在这个层面设置阈值比如“涉诉金额超过100万且未结案直接升级人工”。执行层解决“动作怎么落”的问题。RPA把决策结果写回业务系统触发OA审批发送邮件或企业微信通知归档审计日志。整个过程可追溯每一步都留下操作记录和证据截图。这个分层架构的好处是每一层都可以独立升级。模型效果不好就换认知层的模型页面改版了就修感知层的RPA脚本规则调整就改决策层的规则配置。不需要推倒重来维护成本可控。3. 智能化合规架构的模块设计与技术选型3.1 完整数据流转链路我以供应商准入审查为例把这条链路完整画出来。首先RPA从ERP系统批量导出待审查供应商清单包含公司名称、统一社会信用代码、所属行业、拟合作金额等信息。然后RPA逐个登录国家企业信用信息公示系统、裁判文书网、执行信息公开网把查询结果的页面内容抓取下来保存成本地文本和截图。这些文本汇总后进入LLM处理环节。我会写一个审查专用的提示词模板要求模型从文本中提取企业状态存续还是吊销、是否有行政处罚、涉诉案件数量、涉诉金额、是否存在被执行信息然后按照预设的风险评级规则输出结构化结果。注意这里一定要让模型用JSON格式输出字段固定方便后面做规则判断。接下来Agent把LLM的结构化输出与业务规则进行比对例如“行政处罚超过3条标记高风险”“涉诉总额超过100万标记中风险”“当前状态为吊销直接拒绝合作”。所有中低风险的进入人工抽检队列高风险的直接生成预警工单推给合规负责人。整个流程跑完需要多久人工没有半小时跑不完一个供应商全流程RPA加LLM大约在40秒到1分钟完成一个供应商的全维度审查而且全天可以7乘24小时轮询新增供应商这是质的提升。3.2 技术选型的关键考量模型选择上用来做合规审查的LLM要兼顾效果和成本。原则很粗暴高风险场景用能力更强的大模型批量低风险场景可以用小模型或者云端API。合规领域和聊天不一样宁可每次调用贵一点也不能输出不稳定。我自己一般会用两个模型做交叉验证主力模型出结果辅助模型检查明显错误两轮结果一致才提交不一致就转人工。RPA平台的选择要考虑三个指标跨系统兼容性——能不能覆盖网页端、Windows桌面应用和Java系统稳定性的维护成本——有的平台选择器维护起来很崩溃和Agent编排的难易程度——要支持API方式触发流程而不是只能人工点按钮运行。知识库和规则库是容易被忽视却极其重要的模块。LLM是一个概率推理器如果什么知识都靠内置回答的准确率一定不稳定。我的做法是把企业的内部合规制度、外部监管法规、历史审查案例、常见风险特征都整理进向量数据库让模型在回答时先检索相关知识再给出结论。这一步叫RAG检索增强生成是让模型变得“懂你公司”的关键。实操下来加上RAG之后合规判断的准确率能提高一到两成。3.3 知识库与规则库的建设思路规则库不要做成代码里的if-else也不要全靠模型推理。我的经验是三层结构最底层是数据字典定义好合规审查涉及的标准术语比如“失信被执行”和“限高”的区别中间层是评分卡把各风险维度打分加权最上层才是决策引擎根据总分和单项分决定通过或升级。这样规则调整的时候只改评分卡不碰代码。知识库的搭建要边跑边沉淀。一开始别贪多先把最重要的几十份制度文件和最近一两年的审查记录丢进去后续每完成一次异常案例的处理就把处理过程和结论追加进去。这样知识库会越用越聪明模型给出的意见越来越贴近公司实际业务。4. 实战把供应商合规审查做成一套可复现的Agent流程4.1 场景梳理与流程拆分直接上手写代码之前必须先干一件事把原有业务流程拆到不能再拆。找一个资深合规专员让他把审查一个供应商的全部操作一步步念出来你在旁边记。你会发现很多细节他是下意识完成的比如先看注册资本再决定要不要查股权穿透这些都要记下来。我带团队做的时候会把流程拆成五个阶段供应商登记、外部信息采集、风险分析与评级、审批决策、留档归档。每一阶段再细化为若干动作节点标注出每个节点的数据来源、判断标准、执行人和产出物。这一步做完后面所有开发都会顺很多。这里特别提醒拆分流程的时候一定要让一线专员参与不要自己闷头设计。他们嘴里的“一般是这样偶尔有例外”就是规则引擎里最难处理的边界情况这些信息只有当面聊才能聊出来。4.2 设计Agent的工作流流程梳理完成之后开始设计Agent的工作流。我用的是类似状态机的设计每个供应商实例维护一个状态Agent根据当前状态触发下一步。第一步Agent检查任务队列里有没有新增供应商数据有就交给RPA去采集信息。第二步等待感知层回调采集完成之后把数据送进LLM处理。第三步读取LLM输出调用规则引擎评分。分数落在不同区间分流到不同节点绿灯直接通过黄灯人工复核红灯拦截。最后所有信息同步到合规台账归档留痕。每个环节都要设置超时和重试机制。比如RPA采集失败重试两次第三次还是失败就标记异常并转人工不要卡死整个队列。LLM调用设置了30秒超时模型返回内容格式不对就重试一次重试仍不合格就自动降级为人工审查。这些容错逻辑看起来琐碎但大规模跑起来就是交付稳定性的生死线。4.3 关键提示词与规则配置这是整个方案最核心的部分我把实际在用的提示词框架分享出来你们在这个基础上改就行。你是一位企业合规审查专家熟悉企业信用风险评估。以下是从公开系统抓取到的企业信息请提取关键风险信号并生成结构化审查结果。 企业名称{company_name} 当前时间{current_date} 抓取信息 {scraped_data} 请按以下要求处理 1. 提取企业当前经营状态存续、注销、吊销、迁出等 2. 提取行政处罚记录条数与主要处罚事由 3. 提取涉诉记录条数、涉及总金额、主要案由 4. 提取被执行信息、失信信息 5. 根据提取结果按以下规则输出风险等级 - 高风险状态为吊销/注销或有失信被执行记录 - 中风险行政处罚超过3条或涉诉总金额超过100万 - 低风险无以上异常情况 严格按JSON格式输出不要包含任何解释 { company_name: , biz_status: , penalty_count: 0, penalty_reasons: [], litigation_count: 0, litigation_amount: 0, litigation_causes: [], risk_level: 低风险, risk_reasons: [] }规则配置我走的是评分卡加否决项的双轨制。评分卡负责平时差异化处理比如行政处罚、涉诉数量、诉讼金额按不同权重打分否决项是硬指标一旦出现就是直接拦截比如“营业执照状态为异常”“存在未结清的重大被执行案件”。提示词里有个容易踩的坑不要一次性把所有信息全塞给模型就让它输出字数一多提取质量会明显下降。更稳的做法是把抓取的文本按来源拆开工商信息单独一段、司法信息单独一段、执行信息单独一段分别调用模型提取字段后再汇总。虽然多了几次调用但准确性换回来是值得的。4.4 RPA执行细节与人机协同兜底RPA脚本这一层重点要处理好登录态和页面变化两个问题。外部网站的验证码识别目前没有100%的完美方案我的做法是尽量优先走开放接口或者让RPA自动检测登录态避免重复登录实在需要验证码的用打码平台的接口兜底虽然有点成本但比人工处理效率高太多。另外页面元素定位不要全部写死尽量用相对路径和语义化属性寻找元素。我踩过的坑是某个信用查询网站某天在搜索结果里加了一个广告位原来的绝对路径定位直接失效整批任务失败。改成语义化文本匹配之后后面几次改版都没有再受影响。人机协同这里要反复强调永远要让系统给人类留一个确认出口。我的设计是每个供应商的审查结果卡片上都有一个“人工确认通过”按钮合规专员可以一键驳回系统判断结果并填写理由。这个理由会被记录下来定期汇总分析如果某类驳回理由反复出现说明规则库和提示词需要更新了。系统不是取代人而是帮人把重复劳动接走让人专门处理真正需要专业判断的边界事情。5. 落地过程中的坑与排查方法5.1 大模型输出不稳定怎么办这是所有LLM项目里被问得最多的问题合规场景尤其敏感因为模型说错一句话就可能导致错误拦截或者风险漏放。我的经验是双保险第一是要求模型严格输出JSON固定格式不满足格式就判本次调用失败第二是用一个独立的小模型或者简单规则做交叉校验比如提取出来的诉讼金额如果在原文本里找不到对应数字就认为提取错误。温度参数一定要调低我一般控制在0.1以下。合规审查不是创意写作不需要模型太有想象力。输入超长的时候要分段处理。有的判决文书很长一次喂给模型会出现遗漏尾部关键信息的情况分段抽取再汇总能把漏判率明显降低。5.2 RPA执行失败的常见原因页面改版是最常见的防不胜防。应对方法是做一个页面监控任务每天巡检关键系统的页面元素是否还在发现变化马上告警。其次就是需要处理弹窗阻挡、系统超时这类干扰因素脚本里对这些要加兜底逻辑检测到才点击不要盲等。还有一个容易踩的坑是数据源本身的问题有些数据源压根查不到你要的公司不是RPA坏了是源里没有。这时候要区分“查无记录”和“采集失败”两个状态不要混在一起否则风险评估会被严重污染。5.3 合规证据链如何留痕合规系统自己也要合规这一点经常被忽视。系统做出的拦截决定如果拿不出证据法务是不认可的。我会在每个审查节点做三层留痕原始抓取页面截图、结构化的提取结果、模型推理的输入输出记录。这些文件按企业名称和时间戳归档压缩加密存储定期同步到审计存储区保证事后可以追溯。底层逻辑是给整个流程拍了部“行车记录仪”一旦后续产生纠纷可以回放整个审查过程。特别是涉及系统拒绝合作这种会产生强烈对抗的情况证据链完整性决定了企业是否处于有利位置。5.4 组织层面的推进阻力技术问题都好解决最难的是让“被替代”的人愿意配合。合规专员往往会担心这套系统搞下来自己被裁员所以推进过程中我的经验是初期定位为工具而不是替代品。系统生成的结果标注为“参考意见”最终决策权永远在人手上。等大家用顺手了、信任建立了再把一些低风险事项改成系统自动处理。还有一个推动阻力来自信息化部门——他们怕你搞的东西不受控制。所以一开始就要把权限管理、接口文档、维护手册准备齐全主动纳入信息化部门的统一管理减少内部摩擦。5.5 常见问题速查表问题现象排查思路处理方式LLM输出乱码或格式错误检查提示词模板是否被注入、温度参数是否过高固定温度≤0.1增加JSON格式校验与重试RPA识别不到目标元素网站是否改版、元素是否异步加载改用语义化选择器配置页面监控告警审查结果被人工大量驳回规则库阈值不合理或提示词理解偏差汇总驳回原因迭代评分卡与提示词网站限制访问频率高频请求被识别为异常行为增加随机延时控制并发数配置代理池轮换涉诉信息漏判多个案号合并显示模型分段处理漏项拆分文本分段抽取交叉校验关键金额6. 复盘与扩展哪些经验值得带走6.1 从试点到铺开的节奏不要第一天就想把所有合规场景全部自动化。我建议先挑一个“流程最标准、数据最在线、业务量最大”的场景做试点比如供应商审查跑通一个完整闭环再逐步复用到其他场景。这样做有三个好处团队在单场景里积累的经验教训可以复用到后续所有场景业务部门看到试点成果后后续推广阻力更小投入成本可控效果证明之后再扩投入。我遇到一个同行他们一开始就想把反商业贿赂、出口管制、个人信息保护等等场景全部纳入系统搞了大半年还在模型调试阶段什么都没落地。这是典型的反面教材。敏捷落地、小步快跑在合规这个领域同样适用。6.2 核心评估指标评估合规智能体到底有没有用不能光看“自动化率”。我常看的三个核心指标风险拦截率——系统主动拦截的真实风险占全部风险的比例漏判率——系统判断为正常但事后出问题的比例平均处理时长——单个审查任务的耗时对比人工的降幅。三个指标一起看才能衡量系统质量。还有一个指标叫人工介入率录着录着你会发现人工介入率从最初的100%逐渐下降说明系统在学习但是如果某个阶段人工介入率突然上升那很可能是最近规则或数据源变了需要及时排查。6.3 还能扩展到哪些合规场景供应商审查只是冰山一角。这个架构本质上是把“外部数据抓取语义理解规则判断流程执行”串起来了你换一套提示词和规则库就可以横向复用到非常多场景。我目前在规划和推进的几个扩展方向合同自动审查用LLM抽取合同关键条款并与标准模板比对标出异常差异点费用报销合规校验把发票、合同、报销单三单匹配自动化识别重复报销和超标准费用数据分类分级自动扫描非结构化文档中的个人敏感信息给出风险标签审计底稿自动生成定期把各系统的操作日志、审批记录、异常处理记录汇总成审计方需要的底稿。最后再分享一个从项目里得到的体会做合规自动化最难的不是技术实现而是让业务方相信系统值得信赖。技术路线上老老实实做好留痕校验、人机协同和规则迭代组织路线上尊重原岗位的专业判断把系统定位成放大专业能力的工具这套架构才能从“好看”变成“好用”。如果你也正准备做合规方向的智能化改造建议先拿一个具体场景跑通再谈规模化的野心这个项目的核心经验就是别贪多先把一条链路跑稳。