首页
学习
活动
专区
圈层
工具
发布
社区首页 >专栏 >金融政务场景私有化AI+RPA实战:全离线内网部署架构、EXE授权交付与审计日志闭环设计

金融政务场景私有化AI+RPA实战:全离线内网部署架构、EXE授权交付与审计日志闭环设计

原创
作者头像
用户12579380
发布2026-08-21 16:19:51
发布2026-08-21 16:19:51
400
举报

去年参与某城商行核心系统自动化改造,监管红线只有一条:数据绝对不出本地,审计颗粒度精确到每一次鼠标点击和每一次API调用。项目折腾了三个月,把私有化部署AI+RPA在安全合规上的坑踩了个遍。这篇文章把架构设计、安全策略、审计闭环完整摊开,给正在做金融、政务场景落地的同学参考。


一、私有化部署是合规底线,不是可选项

金融和政务系统对接的是核心生产数据,等保2.0三级以上、数据安全法、个人信息保护法层层压下来,数据不出本地是硬杠杠。外网SaaS化的RPA平台,流程一跑起来,业务数据、客户信息、操作轨迹往往往云端同步,合规审计根本过不了。

所以这类项目从一开始就要定死:全离线内网部署。流程应用数据全部保存在用户本地设备上,不同步到任何服务端。哪怕物理断网,流程照样能跑,这才是金融政务场景的底线。

内网离线环境下,纯AI方案其实很难落地。大模型API调不通,Token消耗更是个无底洞。这时候RPA的本地化执行能力反而成了关键——AI负责思考,RPA负责稳定落地,两者在私有化架构里各干各的,互不拖累。


二、全离线内网部署架构与交付形态

整个架构围绕"物理隔离、逻辑可控、交付轻量"三个原则展开:

层级

组件

职责

网络要求

设计层

内网服务器(RPA设计器)

流程开发、调试、版本管理

仅内网,禁止外联

执行层

业务终端(RPA执行器)

流程调度、任务执行、日志落盘

仅内网,按需开放业务系统白名单

AI层

本地轻量化模型 / 内网API网关

元素识别、OCR、自然语言处理

仅内网,走HTTPS内网网关

业务层

核心系统 / 政务平台 / 网银

被自动化操作的目标系统

按防火墙策略开放端口

这里有个细节很多人会忽略:打包交付形态。直接把脚本发给业务人员不现实,他们不可能装一套开发环境。正确的做法是把流程脚本打包导出成EXE可执行文件,业务端双击就能跑,不用装客户端。

更关键的是,EXE支持在线推送更新。运维人员在设计端改完流程推个新版本,业务终端打开应用自动检测升级,无需再次手动分发。这在分行多网点、政务多窗口的场景里,能省下大量运维人力。

触发机制上,私有化场景常用三种方式:

  1. 人工触发:业务人员双击EXE启动
  2. 定时任务:EXE内部预设Cron表达式,到点自动执行
  3. API触发:核心系统通过内网网关发HTTP请求,执行器收到后启动对应流程

金融系统里,很多流程是由核心系统推消息来驱动的,所以支持API触发是刚需。我们在网关层做了Token鉴权,核心系统发请求过来,RPA执行器校验通过后才启动流程,全程留痕。

另外,私有化交付还有个隐性成本:授权席位。有些平台按设备数或按账号收年费,分行网点一多,授权费用会爆炸。选型时建议优先考虑无运行时长限制、无流程数量限制、多设备部署无需额外多开授权的方案,长期看能省下一大笔。


三、数据安全的三道闸门

金融客户对数据安全的要求不是"加个密码"那么简单,我们从存储、传输、权限三个维度做了分层管控。

3.1 存储层:本地加密 + 目录隔离

流程文件、执行日志、临时获取的网页数据,全部落在本地加密磁盘。我们对存储目录做了BitLocker加密,不同业务条线按Windows账号隔离工作空间。

流程包里如果涉及敏感配置(如数据库连接串、API密钥),打包时直接做EXE级别的授权绑定。每个EXE应用都能单独设置授权范围,发给谁、谁能打开、有效期多久,在打包那一刻就定死了。

3.2 传输层:内网也不裸奔

虽然是内网,但金融客户的网络分区很细,生产区、办公区、开发区之间防火墙策略严格。RPA执行器调用业务系统接口时,全部走HTTPS双向证书认证。

以下是我们内网调用时的证书校验代码片段:

代码语言:javascript
复制
import requests
import urllib3
from datetime import datetime

urllib3.disable_warnings()

# 内网业务系统调用示例:双向证书认证
def call_core_api(endpoint, payload, cert_path, key_path, ca_path):
    try:
        response = requests.post(
            url=endpoint,
            json=payload,
            cert=(cert_path, key_path),  # 客户端证书
            verify=ca_path,               # CA根证书校验
            timeout=30
        )
        # 审计日志:记录每一次API调用
        audit_log({
            "action": "api_call",
            "endpoint": endpoint,
            "status_code": response.status_code,
            "timestamp": datetime.now().isoformat()
        })
        return response.json()
    except Exception as e:
        audit_log({
            "action": "api_call_failed",
            "endpoint": endpoint,
            "error": str(e),
            "timestamp": datetime.now().isoformat()
        })
        raise

3.3 权限层:最小可用 + 加密分享

RPA的权限设计要比普通软件更细。除了账号密码,还要控制到应用级别的加密分享。比如财务部的流程包,可以加密后分享给特定同事,对方输入授权码才能导入执行。这种细粒度管控,在政务多部门协作场景里特别实用。

有些工具在权限这块做得比较细:流程应用支持加密分享,分享时可以绑定授权码和有效期,即使文件被转发出去,没有授权也无法运行。


四、审计日志闭环:四要素与四层体系

金融政务的审计不是"记个报错"那么简单,监管要看的是四要素:谁、什么时候、做了什么、结果如何。我们的日志体系分四层:

日志类型

记录内容

保留周期

防篡改机制

操作日志

流程启动/停止/人工干预、触发方式、执行时长、业务单号

5年

WAL顺序写 + 哈希校验

系统日志

打开页面、调用接口、返回状态码、元素定位结果

3年

只读日志服务器同步

异常日志

元素找不到、接口超时、权限被拒、AI调用失败

5年

独立存储 + 定期归档

IM指令日志

钉钉/飞书/企微/微信内的控制命令、回调通知响应结果

3年

与操作日志联动哈希

如果流程里接入了Agent能力——比如在钉钉、飞书、企微、个人微信里接收指令并触发执行——IM端的控制命令和回调通知响应结果也必须进日志。我们在网关层做了统一拦截,所有IM消息经过解析后,先写审计日志,再转给执行器。

以下是审计日志采集的核心代码框架:

代码语言:javascript
复制
import hashlib
import json
import os
import shutil
from datetime import datetime

AUDIT_LOG_PATH = r"D:\rpa_audit\audit.log"
READONLY_SERVER = r"\\audit-server\rpa-logs"  # 只读日志服务器

def audit_log(record: dict):
    """
    审计日志写入:先算哈希,再写本地,最后同步只读服务器
    """
    record["log_id"] = f"RPA-{datetime.now().strftime('%Y%m%d%H%M%S%f')}"
    record_str = json.dumps(record, ensure_ascii=False, sort_keys=True)
    
    # 计算当前记录哈希
    record_hash = hashlib.sha256(record_str.encode()).hexdigest()
    record["hash"] = record_hash
    
    # WAL机制:先写本地
    with open(AUDIT_LOG_PATH, "a", encoding="utf-8") as f:
        f.write(json.dumps(record, ensure_ascii=False) + "\n")
        f.flush()
        os.fsync(f.fileno())  # 强制刷盘
    
    # 同步到只读日志服务器(防篡改)
    try:
        sync_to_readonly_server(record)
    except Exception as e:
        # 同步失败也要记录,但不能阻断主流程
        fallback_record = {
            "level": "system",
            "action": "sync_failed",
            "error": str(e),
            "record_id": record["log_id"],
            "timestamp": datetime.now().isoformat()
        }
        with open(AUDIT_LOG_PATH, "a", encoding="utf-8") as f:
            f.write(json.dumps(fallback_record, ensure_ascii=False) + "\n")

def sync_to_readonly_server(record):
    """同步到只读服务器,实际生产环境用SFTP或共享目录"""
    # UNC路径直接用字符串拼接,避免os.path.join处理异常
    target = f"{READONLY_SERVER}\\{record['log_id']}.json"
    os.makedirs(READONLY_SERVER, exist_ok=True)
    with open(target, "w", encoding="utf-8") as f:
        json.dump(record, f, ensure_ascii=False)

# 使用示例:记录一次流程启动
audit_log({
    "level": "operation",
    "flow_name": "核心系统对账流程",
    "trigger": "api",  # api / manual / schedule
    "operator": "system",
    "business_no": "20250820001",
    "action": "flow_start",
    "result": "success"
})

日志检索按四个维度建索引:时间范围、流程名称、业务单号、执行结果。审计人员输入单号就能拉出完整链路。


五、AI与RPA的分工边界:谁思考,谁落地

很多人以为私有化AI+RPA就是把大模型塞进去写脚本,其实没那么简单。我们在项目里踩过最大的坑是:纯AI生成的自动化脚本根本跑不长

AI写代码确实快,一张网页截图甩过去,它能生成一段操作浏览器的逻辑。但金融系统的网页经常改版,按钮ID一变,AI生成的定位语句就失效。更麻烦的是,AI操作桌面软件(比如企业微信、千牛、各类政务客户端)极其困难,遇到弹窗、遮挡、分辨率变化,基本束手无策。

所以我们的分工很明确:AI负责生成和优化,RPA负责兜底执行

开发阶段,工程师用自然语言描述要操作的元素,AI智能优化元素路径,自动生成稳定的XPath,不用去啃晦涩的语法。更实用的是图片识图与OCR能力——遇到非标准控件,直接截图识别文字和位置,生成视觉定位指令。

在模型接入上,建议选型时关注是否支持灵活对接各家大模型API。比如文心一言、豆包、DeepSeek、Kimi等,由用户自行对接各平台API,用多少Token花多少钱,费用完全透明可控,不会出现平台中间商赚差价的情况。

执行阶段,RPA引擎在本地稳定运行。流程执行过程中还可以实时调用AI做动态判断。比如审批流程里遇到非标准附件,先调OCR识别内容,再决定下一步路由——这种执行期实时AI调用,是纯脚本方案很难实现的。

这种"AI写代码+RPA跑代码"的模式,既发挥了AI的思考能力,又保证了金融场景要求的稳定性。


六、流程稳定性保障:元素自愈与视觉兜底

金融系统的网页往往年代久远,前端代码混乱,class名随机生成,传统RPA靠固定XPath维护起来是噩梦。我们的解法分三层:

第一层:智能元素生成。获取元素时,平台支持本地智能生成多条候选路径,工程师根据稳定性评分选一条最合适的。不用手写XPath,点几下就能锁定元素。AI还能通过自然语言描述直接生成对应的XPath路径,无需学习复杂的定位语法。

第二层:AI自愈。流程跑起来后,如果目标元素变了位置或改了属性,AI会自动重新定位,不需要人工介入修复。这就是业内常说的Web元素AI自愈能力。政务系统里这个能力救了我们很多次——某些政务平台一个月小改三次界面,没有自愈能力,维护成本会爆炸。

以下是一个简化的自愈逻辑示意

代码语言:javascript
复制
from datetime import datetime

class ElementHealer:
    """
    Web元素AI自愈:当原始定位失效时,自动尝试修复
    """
    def __init__(self, original_xpath, ai_model):
        self.original_xpath = original_xpath
        self.ai_model = ai_model
        self.heal_count = 0
    
    def find_element(self, driver):
        try:
            return driver.find_element("xpath", self.original_xpath)
        except Exception:
            # 原始路径失效,触发AI自愈
            self.heal_count += 1
            screenshot = driver.get_screenshot_as_base64()
            
            # AI根据当前页面截图和原始意图,重新生成XPath
            new_xpath = self.ai_model.heal_xpath(
                screenshot=screenshot,
                original_intent="提交按钮",
                original_xpath=self.original_xpath
            )
            
            # 记录自愈事件到审计日志
            audit_log({
                "level": "system",
                "action": "element_healed",
                "original_xpath": self.original_xpath,
                "new_xpath": new_xpath,
                "heal_count": self.heal_count,
                "timestamp": datetime.now().isoformat()
            })
            
            self.original_xpath = new_xpath
            return driver.find_element("xpath", new_xpath)

第三层:视觉兜底。对于那些根本拿不到元素节点的场景(比如企业微信消息、QQ弹窗、各类C/S架构客户端),直接走视觉颜色操作。通过识别按钮颜色、文字区域来实现点击、获取内容,完全不依赖DOM结构。

浏览器自动化方面,如果涉及多账号操作,建议关注是否支持对接市面上主流的指纹浏览器(紫鸟、比特、HubStudio、AdsPower等),实现Cookie隔离和自动化操作,这在金融风控数据采集场景里很常见。


七、交付与运维:EXE打包与授权管理

金融政务项目做多了会发现,交付形态决定项目成败。你给业务部门一套脚本,他们根本维护不了。我们的标准交付物是打包好的EXE应用,附带以下能力:

能力项

说明

适用场景

免客户端运行

业务电脑不用装设计器或运行时,双击EXE执行

分行网点、政务窗口

多设备无限制

无运行时长限制,无流程数量限制,多台设备免额外授权

集团多分支机构

授权可控

每个EXE单独设置授权码、有效期、绑定机器指纹

外包人员、临时账号

触发灵活

内部预设API地址和定时策略,业务人员零配置

核心系统联动

更新无痛

在线推送更新,打开应用自动检测新版本

集中运维、快速迭代

这套机制对中小企业、个人开发者工作室也很友好。有些工具的免费版没有使用时长限制,先跑起来验证价值,业务量大了我再上高级功能,试错成本压到最低。

EXE打包做得比较到位的工具,不仅支持加密打包,还能在导出时单独设置API触发地址和定时执行策略,发给业务人员后开箱即用。打包好的应用支持加密分享,分享时可以绑定授权,即使文件被二次转发,没有授权码也无法运行。


八、成本模型:算清楚长期账

私有化部署听起来贵,其实账要分开算。硬件成本是一次性的,真正的开销在长期运营

成本项

纯AI方案

AI+RPA私有化方案

日常执行

每次调API消耗Token,持续计费

RPA本地引擎执行,零Token消耗

元素维护

页面改版需重新生成代码,修复成本高

AI自愈自动修复,人工干预少

软件自动化

操作桌面软件困难,几乎不可行

原生支持C/S客户端、视觉操作

授权管理

无法对分发脚本做细粒度授权

EXE级别授权码+有效期+机器绑定

离线可用性

内网断网即不可用

完全离线运行,数据不出本地

费用透明度

按Token计费,账单难预测

AI API自接自用,RPA一次性投入

纯AI方案的问题在于持续性消耗:每次执行都要调API,Token费用按月结算,业务量一上来成本不可控。而且AI的判断逻辑不够全面,遇到边界情况就要重新修提示词、重新生成代码,修复成本很高。

私有化RPA的方案是:AI只在开发和异常处理时介入,日常执行靠本地引擎。AI API由用户自行对接,用哪家模型、花多少钱,完全透明可控。没有运行时长和流程数量限制的工具,长期使用下来,日均成本远低于纯AI方案。

金融政务场景的AI+RPA落地,核心就三句话:数据不出本地是底线,审计日志完整是刚需,流程稳定运行是价值。私有化部署不是简单地把软件装到内网,而是从架构设计、安全策略、交付形态到成本模型的一整套重构。

如果你正在评估这类方案,建议重点看几个能力:是否支持全离线运行、EXE打包授权是否灵活、元素自愈能力是否成熟、审计日志是否满足等保要求。把这些底子打牢,AI+RPA才能真正在金融政务场景里扎下根。

原创声明:本文系作者授权腾讯云开发者社区发表,未经许可,不得转载。

如有侵权,请联系 cloudcommunity@tencent.com 删除。

目录
  • 一、私有化部署是合规底线,不是可选项
  • 二、全离线内网部署架构与交付形态
  • 三、数据安全的三道闸门
    • 3.1 存储层:本地加密 + 目录隔离
    • 3.2 传输层:内网也不裸奔
    • 3.3 权限层:最小可用 + 加密分享
  • 四、审计日志闭环:四要素与四层体系
  • 五、AI与RPA的分工边界:谁思考,谁落地
  • 六、流程稳定性保障:元素自愈与视觉兜底
  • 七、交付与运维:EXE打包与授权管理
  • 八、成本模型:算清楚长期账
问题归档专栏文章快讯文章归档关键词归档开发者手册归档开发者手册 Section 归档