RPA与Python爬虫协同：电商数据下载的方案设计

背景一个被低估的效率黑洞电商团队的日常工作里有一类任务长期处于不痛不痒的灰色地带——它不算紧急但每个月都要耗费人力说起来是重复劳动却又因为流程琐碎、容易出差错不敢完全放手让新人去做。月账单下载就是典型代表。以京东商家后台京麦为例财务人员需要按月下载账单明细用于对账、报税、利润核算。单个账号一次操作不过几分钟但一旦涉及多账号、多月份的批量处理时间就会以乘法放大。更麻烦的是这件事通常卡在月初或月末的节点偏偏也是财务最忙的时候。这类任务的特征非常清晰规则固定、重复率高、出错代价低但频率高。这正是自动化最应该介入的场景。然而电商平台的自动化并不像想象中那么简单——平台有自己的商业利益考量并不鼓励数据被批量抓取因此设置了层层风控。如何在合规使用自己账号数据的前提下提升操作效率是这套方案需要回答的核心问题。一、为什么不直接用 RPA也不直接用爬虫面对这类自动化需求工程师通常会在两种路线之间做选择但两条路各有明显的天花板。纯 RPA 的问题在于脆。RPA 依赖界面元素的定位按钮坐标、DOM 结构、文字识别一旦平台改版哪怕只是调整了一个按钮的位置或文案流程就可能整体失效。更深层的问题是RPA 的执行速度受限于页面渲染它需要等待页面加载、等待弹窗出现、等待文件下载完成每一步都在消耗时间。如果要批量处理 12 个月 × 5 个账号的数据累积的等待时间相当可观。纯爬虫的问题在于进不去。爬虫的优势是直接调用接口不依赖界面速度快、稳定。但前提是必须持有有效的登录态 Cookie。现代电商平台的登录风控已经相当成熟行为指纹鼠标轨迹、点击间隔、设备指纹浏览器环境、Canvas 指纹、IP 信誉评分……纯代码模拟登录的成本越来越高且随着平台风控升级需要持续对抗维护是一场没有终点的军备竞赛。两种方案的缺点恰好互补。RPA 擅长过门——它操控真实浏览器行为特征接近真人验证码也可以通过图色识别或第三方打码服务处理登录这件事对 RPA 来说不是难题。爬虫擅长干活——一旦拿到 Cookie接口调用就是纯粹的网络请求没有界面依赖不受渲染速度限制代码逻辑清晰出错率低。这就是这套方案的核心思路让 RPA 负责最难的那一步登录让爬虫负责最频繁的那一步数据获取两者通过 Cookie 做交接各自在自己擅长的领域发挥作用。二、分析目标接口先看懂再动手自动化的第一步不是写代码而是搞清楚目标系统在做什么。很多工程师习惯上来就开始抓包、写脚本结果在一些本可以提前规避的坑上浪费了大量时间。打开京麦月账单页面按 F12 调出浏览器开发者工具切换到Network → Fetch/XHR选项卡这样可以过滤掉图片、CSS 等静态资源只保留真正的数据请求。京麦月账单页面开发者工具已打开切换到 Network → Fetch/XHR此时点击某个月份的下载明细按钮触发实际的下载动作。开发者工具里随即出现了几条新的网络请求浏览器也完成了 zip 文件的下载。点击下载明细后开发者工具出现 3 条网络记录浏览器完成下载点开其中的关键请求切换到Payload标签页可以看到请求体的结构{ monthbillMo: { monthView: 2026-04, secAccountNo: 173669760001, beginDate: 1743436800000, endDate: 1746028799999 } }这里有一个细节值得关注时间范围是用毫秒级 Unix 时间戳传递的而不是直接传月份字符串。这意味着在构造请求时需要先将YYYY-MM格式的月份换算成对应的起止时间戳。这个处理如果依赖手动计算或硬编码在跨月、跨年时就容易出错用代码自动计算则严谨得多。再切换到Response标签页接口返回了标准 JSONcode: 200表示成功data字段是一个临时的 zip 文件下载链接。Payload 标签可见月份和起止时间戳字段值得注意的是这个链接是临时生成的有一定的有效期。这说明整个下载流程是分两步走的先申请一个下载链接再取文件。这种设计在大文件异步生成场景中很常见自动化脚本需要按这个节奏来不能直接跳过第一步去猜链接。至此接口行为已经完全清晰。能提前把这些细节搞明白后面写代码的时候就不会走弯路。三、RPA 负责登录与 Cookie 采集清楚了接口逻辑下一步是解决如何拿到有效 Cookie的问题。从业务角度来说Cookie 本质上是平台对你是谁、你有没有登录这个问题的答案。只要是合法账号正常登录拿到的 Cookie 就是有效的后续用这个 Cookie 调用接口和在浏览器里手动操作没有本质区别。问题在于正常登录这件事对爬虫来说并不容易模拟。影刀 RPA 在这个环节有天然优势它直接驱动真实的 Chrome 浏览器浏览器的 User-Agent、Canvas 指纹、WebGL 特征都是原生的平台的设备指纹检测几乎无从区分。同时影刀支持对接主流验证码识别服务碰到滑块或图形验证码可以在 RPA 流程内直接处理不需要人工介入。登录成功后影刀提供了获取筛选所有 Cookie命令可以一次性取出当前浏览器会话中指定域名下的全部 Cookie以结构化数据的形式返回。影刀 RPA 中获取筛选所有 Cookie命令截图拿到 Cookie 字典后将其按照 HTTP 请求头的格式拼接为keyvalue; keyvalue; ...字符串作为变量传入后续的 Python 脚本。这个交棒的动作是整套方案中 RPA 和爬虫协作的关键接点。四、Python 爬虫负责接口调用与文件下载有了 Cookie接下来完全是爬虫的主场。影刀内置了 Python 运行环境支持 pip 包管理可以直接安装requests等库将脚本作为流程节点嵌入 RPA 中执行。影刀 RPA 中 Python 包管理及 Python 运行命令截图整个脚本逻辑分三步第一步月份转毫秒时间戳from datetime import datetime, timezone def month_to_timestamps(month_str): year, mon int(month_str[:4]), int(month_str[5:7]) begin datetime(year, mon, 1, tzinfotimezone.utc) if mon 12: end datetime(year 1, 1, 1, tzinfotimezone.utc) else: end datetime(year, mon 1, 1, tzinfotimezone.utc) begin_ms int(begin.timestamp() * 1000) end_ms int(end.timestamp() * 1000) - 1 return begin_ms, end_ms用timezone.utc而不是本地时区是因为平台服务端通常以 UTC 为基准处理时间避免因时区差异导致起止时间偏移一天。这种细节在测试阶段看起来没问题但在月初月末边界场景下会稳定地出错。第二步POST 接口获取下载链接payload { monthbillMo: { monthView: MONTH, secAccountNo: SEC_ACCOUNT_NO, beginDate: begin_ms, endDate: end_ms, isGlobalSale: False, } } resp requests.post(API_URL, headersHEADERS, jsonpayload, timeout30) download_url resp.json()[data]第三步下载并解压file_resp requests.get(download_url, timeout60) outer_zip zipfile.ZipFile(io.BytesIO(file_resp.content)) inner_zip_name next((n for n in outer_zip.namelist() if n.endswith(.zip)), None) with open(fjd_bill_{MONTH}.zip, wb) as f: f.write(outer_zip.read(inner_zip_name))下载的文件是外层 zip 套内层 zip的双层压缩结构这在大文件异步打包场景中比较常见。脚本需要先解开外层再取出内层 zip 保存不能直接把外层文件当成最终结果。相比纯 RPA 方案——等页面加载、点按钮、等弹框、等浏览器下载、管理下载目录——爬虫这条路径减少了所有界面交互执行时间从分钟级压缩到秒级且不会因页面布局变化而失效。五、容错设计极端场景的兜底策略任何自动化方案都不可能 100% 无故障运行。把容错设计想清楚比把主流程做到极致更重要因为出了问题时往往是业务压力最大的时候。这套方案的容错逻辑有两层第一层Cookie 失效时自动重新登录。如果 Python 脚本发现接口返回了登录态异常如code不为 200、返回体提示未授权将错误状态回传给 RPA由 RPA 触发重新登录流程更新 Cookie 后重试。Cookie 的有效期通常是小时到天级别正常情况下一次登录可以支撑一整批次的下载任务但重试机制不可省略。第二层接口失败时回退到界面操作。如果接口本身出现异常平台接口升级、临时封禁特定请求、网络问题Python 脚本返回失败RPA 可以切换到界面操作模式直接模拟点击页面上的下载按钮完成兜底。这条路慢一些、稳定性差一些但它的存在意味着整个流程不会因为接口变化而完全瘫痪。[正常路径] 登录 → 获取 Cookie → Python 调接口 → 下载文件 [兜底路径] 接口失败 → 切换界面操作模式 → RPA 模拟点击下载 [重试路径] Cookie 失效 → 重新登录 → 更新 Cookie → 重试这种接口优先、界面兜底的架构本质上是在效率和稳定性之间做了有意识的分层。大多数情况下走快路接口出问题时不崩溃走慢路登录态问题自愈不需要人工介入。六、可扩展的思考这套方案的边界不止于账单下载它代表了一种更通用的思路用 RPA 解决身份认证问题用爬虫解决数据获取问题。往横向延伸同样的架构可以用于运营报表的定时采集、多平台京东、淘宝、拼多多数据的统一归档、订单明细的自动同步入库。只需要针对不同平台重复抓包分析接口 → 编写对应的 Python 脚本这个过程RPA 的登录和 Cookie 采集模块可以复用。往纵向延伸下载到本地只是第一步。拿到 zip 文件后可以继续用 Python 解析 Excel、入库到数据仓库、触发下游的对账脚本或报表生成把整个财务数据流打通而不只是把手工操作搬到了自动化工具里。真正有价值的自动化不是代替人点按钮而是让数据在系统之间流动起来消灭中间的人工传递环节。账单下载只是这条链路上的第一个节点。七、方案对比总结维度纯 RPA纯爬虫RPA 爬虫结合登录风控应对✅ 强真实浏览器行为❌ 弱易被识别拦截✅ 强执行速度慢依赖页面渲染快纯接口调用✅ 快页面变更稳定性❌ 弱界面改版即失效✅ 强接口相对稳定✅ 强验证码处理✅ 方便可对接打码服务需额外开发✅ 方便极端场景兜底仅界面操作无法登录则完全失效✅ 双路径保障扩展性低强依赖界面结构高逻辑清晰易复用✅ 高结语这套方案的底层逻辑是把一个看似完整的任务拆解成两个子问题再用最适合的工具分别解决。认证问题交给 RPA数据问题交给爬虫两者通过 Cookie 完成协作。对于运营和财务团队而言最终感知到的是账单每天自动出现在指定文件夹对于开发团队而言维护成本也相对可控接口变了改脚本界面变了不影响主路径。更重要的是这套思路具备迁移性。把它理解为一种分层架构——用 RPA 管进门用代码管干活——它适用于相当多类似的电商数据场景值得作为一个可复用的模式沉淀下来。