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

企业合规这事儿，我这两年被问得最多的就是一句话：“明明配了人、定了制度、走了流程，怎么还总是出事？”其实答案很扎心：纯靠人工盯合规，本质上是在用有限的人力对抗无限变化的规则和系统。就拿供应商准入审查来说，业务员催着下单，合规专员得去登录工商系统查主体信息，去裁判文书网看涉诉记录，去内部ERP比对历史合作黑名单，一套流程下来小半天，漏看一个司法风险点，后面可能就是几百万的坏账。

后来我把思路换成了LLM+RPA结合智能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 常见问题速查表

6. 复盘与扩展：哪些经验值得带走

6.1 从试点到铺开的节奏

不要第一天就想把所有合规场景全部自动化。我建议先挑一个“流程最标准、数据最在线、业务量最大”的场景做试点，比如供应商审查，跑通一个完整闭环，再逐步复用到其他场景。这样做有三个好处：团队在单场景里积累的经验教训，可以复用到后续所有场景；业务部门看到试点成果后，后续推广阻力更小；投入成本可控，效果证明之后再扩投入。

我遇到一个同行，他们一开始就想把反商业贿赂、出口管制、个人信息保护等等场景全部纳入系统，搞了大半年还在模型调试阶段，什么都没落地。这是典型的反面教材。敏捷落地、小步快跑，在合规这个领域同样适用。

6.2 核心评估指标

评估合规智能体到底有没有用，不能光看“自动化率”。我常看的三个核心指标：风险拦截率——系统主动拦截的真实风险占全部风险的比例；漏判率——系统判断为正常但事后出问题的比例；平均处理时长——单个审查任务的耗时对比人工的降幅。三个指标一起看，才能衡量系统质量。

还有一个指标叫人工介入率，录着录着你会发现，人工介入率从最初的100%逐渐下降，说明系统在学习；但是如果某个阶段人工介入率突然上升，那很可能是最近规则或数据源变了，需要及时排查。

6.3 还能扩展到哪些合规场景

供应商审查只是冰山一角。这个架构本质上是把“外部数据抓取+语义理解+规则判断+流程执行”串起来了，你换一套提示词和规则库，就可以横向复用到非常多场景。

我目前在规划和推进的几个扩展方向：合同自动审查，用LLM抽取合同关键条款并与标准模板比对，标出异常差异点；费用报销合规校验，把发票、合同、报销单三单匹配自动化，识别重复报销和超标准费用；数据分类分级，自动扫描非结构化文档中的个人敏感信息，给出风险标签；审计底稿自动生成，定期把各系统的操作日志、审批记录、异常处理记录汇总成审计方需要的底稿。

最后再分享一个从项目里得到的体会：做合规自动化，最难的不是技术实现，而是让业务方相信系统值得信赖。技术路线上老老实实做好留痕校验、人机协同和规则迭代，组织路线上尊重原岗位的专业判断，把系统定位成放大专业能力的工具，这套架构才能从“好看”变成“好用”。如果你也正准备做合规方向的智能化改造，建议先拿一个具体场景跑通再谈规模化的野心，这个项目的核心经验就是：别贪多，先把一条链路跑稳。