合作请联系官网

本文纯技术落地复盘，不涉及特定公司项目宣传，只聊方案选型、风险、边界和踩过的坑

数电票全面推开之后，财税自动化变成很多SaaS、代账系统绕不开的需求。

很多开发者第一反应：RPA直接模拟人工登录电子税务局，一键下载发票，快速交付。

我也是沿着这条路线一步步踩坑，先后经历：纯RPA方案 → RPA+浏览器插件双轨并行 → 以插件为主、RPA为辅 → 尝试引入Agent做任务编排。

这篇复盘，把每一套方案的初衷、优点、硬伤、合规风险、适用边界全部拆开，给做财税票据自动化的同行做参考。

一、第一阶段：传统RPA方案，快速上线的选择

方案思路

RPA核心就是模拟人的浏览器操作：自动打开网页、填入账号密码、点选文字验证码、进入发票模块、查询、下载数电票OFD、PDF，下载完成之后读取本地文件，解析票面信息，入库给到后端记账模块。

优势

上手快，不用对接官方乐企API，不需要走服务商、白名单申请，没有对接费、每张票的通道费；

页面是什么样，RPA就怎么写流程，页面不改就能稳定跑；

对原有业务改动很小，可以快速演示给客户。

踩坑和硬伤（这是最核心的痛点）

页面强耦合：电子税务局页面改版、按钮位置变动、弹窗规则更新，流程直接挂掉，需要频繁改元素定位、重调xpath；

验证码不可控：文字点选、滑块、图灵验证码随机性很强，RPA很难稳定识别，一旦触发风控，账号直接限制登录；

合规风险高：很多地区税局用户协议，不允许非官方接口、自动化脚本高频模拟人工登录访问；高频跑RPA极易触发风控，轻则人机验证，重则锁账号；

环境依赖重：RPA机器人需要常驻机器、浏览器环境，客户电脑版本、插件、缓存不一样，同样一套流程，A电脑能跑，B电脑直接失败；

异常链路难追溯：登录失败、下载超时、文件丢失、权限弹窗，报错五花八门，很难统一做结构化异常上报。

当初选型RPA，核心诉求就是零API对接成本、快速验证业务，但是跑一段时间之后，风控和维护成本开始持续上涨。

二、第二阶段：寻找官方对接方案——乐企直连，但是门槛卡死

RPA风险越来越明显，自然转向官方正规路线：乐企平台（数电票服务平台）API对接。

两种模式：自用 / 联用

自用：企业自己申请乐企白名单，自己调用API，只能采集本企业自身发票；

联用：第三方服务商拿到联用资质，可以给多家代账客户企业做票据归集，这正是代账SaaS最需要的模式。

遇到的现实卡点

联用白名单不是开放申请，有准入门槛，不是提交材料就能过；

市面上商用服务商（比如诺诺等）大多是按单张发票收费 + 一次性技术对接费；

这里有一个很现实的矛盾：API本身是标准化接口，开发者自己写对接代码，但是服务商依然收取技术对接服务费，对于初创产品，成本压力非常大；

收费模式不适合早期产品：客户量还没起来，每一张票都抽成，商业模式很难跑通。

结论：乐企是长期最优合规方案，但短期拿不到联用资质、不想承担按量收费，这条路线暂时走不通，必须准备备选方案。

这也是为什么我们没有直接放弃自动化，而是继续自研旁路方案。

三、第三阶段：双轨方案成型：浏览器插件为主，RPA为辅

既然乐企短期卡脖子，RPA风险高，我们拆分边界，做职责切割：

【主力方案】浏览器插件（Manifest V3）

【兜底方案】RPA机器人（只做插件覆盖不了的特殊场景）

浏览器插件的设计定位（重点）

插件不主动替用户填账号密码、不自动登录税局，规避高风险的自动登录行为。

职责边界：

用户手动登录电子税务局（人来完成登录、过验证码）；

插件在页面内监听票据下载动作，拦截OFD/PDF文件；

自动解析下载的票据文件、提取XML结构化数据；

加密上传到后端平台，完成归集、归档、入账；

提供任务日志、异常告警、票据校验。

✅ 优势

合规性大幅提升：登录、过验证全部由人工完成，插件只接管已经授权后的文件采集，没有模拟登录行为，风控风险远低于RPA；

不依赖页面按钮定位：不需要点查询、点下载，用户正常手动操作，插件被动捕获文件；页面改版基本不影响；

跨客户稳定，环境兼容性比RPA好很多；

可以免费给到客户使用，没有按票收费。

⚠️ 短板

需要用户有简单操作动作，不能做到完全“一键全自动、无人值守”；

只能捕获用户主动下载的票据，没办法主动去后台批量拉取；

插件需要上架、做权限管控，Manifest V3权限管控严格，不能申请越权权限，安全设计要做好；

网银等其他外部系统，插件很难统一覆盖。

RPA降级为兜底

RPA不再是主力，只作为可选兜底开关：只给少数愿意接受风控风险、需要无人值守批量拉票的客户开放，并且明确风险告知，增加频率限流、风控熔断机制。

两套方案并存，产品上分出自用版、代账版，一套底层代码，两套交互入口。

四、第四阶段：引入Agent智能体，做上层任务编排（重点，很多人踩错分工）

很多人会有误区：Agent就是用来代替RPA，让AI去点页面、登录网站、识别验证码。

这里是最重要的踩坑点：Agent不适合直接做底层页面操作。

我们最终的架构分工：

Agent（大模型智能体）：负责业务层决策、任务拆解、异常判断、问题汇总、重试策略；

执行层：浏览器插件、RPA、后续对接的乐企API，是纯粹的执行工具；

Agent不会去点击验证码、输入密码登录。

Agent可以做的事情

接收用户指令：“归集这个月全部进项发票”；

拆解任务：票据采集 → 票据验真校验 → 数据清洗 → 匹配账套 → 生成待入账清单；

识别异常：票据查验失败、文件损坏、重复票据、缺备注、红字发票；

结构化输出异常报告：罗列每一条失败单据、失败原因、建议处理方式；

根据不同执行渠道状态自动路由：乐企可用优先走乐企；乐企不可用走插件；插件不可用时，提示用户是否启用RPA兜底；

持续记录任务日志，给运营/会计推送待处理工单。

Agent不能做（边界红线）

❌ 自主填写账号密码、自动登录电子税务局

❌ AI识别点选验证码自动提交

❌ 高频循环执行自动化操作，绕过人机校验

很多Agent财税项目翻车，就是把Agent和底层操作耦合在一起，让AI直接去操作网页，风控爆炸，稳定性极差。Agent的价值是调度、判断、排错，而不是充当高级RPA。

五、四种方案横向对比汇总表

方案合规度稳定性成本自动化程度适合场景乐企联用API⭐⭐⭐⭐⭐高按量收费+对接费全自动无人值守成熟代账机构，预算充足、长期稳定经营浏览器插件（主力方案）⭐⭐⭐⭐较高自研一次性开发，无后续票费半自动化，需要人工登录初创财税SaaS、中小代账，优先主推RPA机器人⭐⭐低，页面一改就崩开发成本低，维护成本高全自动无人值守小众兜底场景，必须限流风控Agent编排层本身无合规属性，取决于底层执行器取决于下层工具大模型调用成本智能调度、自动排错上层业务智能化，和底层解耦六、衍生出来的产品设计思考：一套底座，两个版本（自用版+代账版）

在迭代过程里，我们决定底层代码共用，对外分成两个版本：

中小企业自用版：企业自己归集自己的发票，对接自家账务；

代账机构版：会计统一管理几十上百家客户账套、批量归集票据、续费台账管理。

共用一套引擎，只是权限面板、工单逻辑、客户管理模块做隔离。

优点：研发成本可控，不用维护两套独立代码；

风险点：权限隔离必须做严格，防止A代账会计看到其他客户账套数据，数据隔离、租户隔离是重中之重。

七、行业长期趋势判断

长期看，乐企API一定是标准答案，所有旁路方案（插件、RPA）都是阶段性过渡方案；

短期来看，联用资质门槛、服务商收费模式，会持续催生自研插件类方案；

Agent不会替代采集工具，而是改造财税系统的交互方式，从“会计手动挨个点功能”变成“自然语言下达任务，系统自动编排、汇总异常”；

单纯RPA财税自动化产品，生命周期会越来越短，税局风控策略只会越来越严。

八、总结与踩坑复盘清单

复盘整条路线，踩的核心坑整理给大家：

不要上来直接重仓RPA，短期爽，长期维护+风控成本爆炸；

区分清楚：Agent是调度大脑，不是点击机器人，不要把大模型绑定页面自动化；

乐企有两条模式，自用和联用资质要求完全不一样，联用才是代账SaaS需要的；

服务商API收费要看清楚：区分接口服务费、每张票据分成、一次性对接费；

插件优先设计成“被动捕获文件”，规避自动登录等高风险动作；

一套底座多版本，租户隔离、权限隔离是安全底线。

财税自动化不是一个技术炫技项目，合规优先、风险可控、成本可控，才是能长期跑下去的核心。

专注财税SaaS自动化、浏览器插件、Agent任务编排方向，持续分享落地踩坑，欢迎一起交流方案选型。