影刀RPA进阶教程：机器人执行记录分析——从日志发现性能瓶颈

同一个采集流程，别人跑四十分钟，你的机器人跑三个小时，差在哪？大部分新手只会一遍遍点运行，凭感觉改参数。其实影刀RPA把每次执行的痕迹都留下来了——控制台的执行记录加本地的运行日志，把这两样看明白，性能瓶颈基本都能定位到具体某一条指令上。

我曾接手过一个商品详情采集流程，跑一次两小时四十分钟，靠分析执行记录和日志打点，最后压到五十分钟以内。这篇就把"看记录、读日志、找瓶颈、做优化"这套方法完整讲一遍。

不用会编程，文中用到的Python只有几行，跟着抄就能用。

执行记录在哪看：控制台与客户端两个入口

如果你用的是企业版调度，第一入口是控制台。路径：影刀RPA控制台 → 任务管理 → 执行记录。所有执行记录统一放在这一个菜单里，包括API触发的执行，点开单条能看到任务里每个应用的运行详情。

执行记录页面能做三件事，很多人只用过第一件：

1. 查看每个应用的开始时间、结束时间，直接算出耗时
2. 对执行出异常的计划查看失败原因，点「重新运行异常的应用」单独重跑
3. 结束卡死的执行中的计划，别让机器人一直占着

计划维度的入口在「常规任务计划」列表，点操作列蓝色的「记录」按钮，一键跳转到这条计划自己的执行记录，比全局列表里翻快得多。

本地客户端这边，「任务监控」页面聚合了调度核心数据，四个数字每天扫一眼就够：当前执行应用数、等待执行应用数、今日完成应用数、今日执行异常。等待执行的应用数长期堆高，说明机器人不够或单个任务太慢，这就是最粗粒度的瓶颈信号。

本地运行日志的三个入口

控制台记录的是"每次跑了多久、成没成"，而本地运行日志记录的是"每一条指令做了什么"，找瓶颈要靠后者。打开方式有三个：

• 按快捷键 Win+R 打开运行窗口，输入日志路径 %localappdata%\ShadowBot\log，回车直接打开日志文件夹，文件按时间倒序排列，看最新的那个
• 资源管理器地址栏直接粘贴同一路径，效果一样
• 5.14版本及之后，在客户端个人头像点击右键 → 设置 → 关于影刀 → 点击「导出日志」按钮，把日志打包导出到指定位置

日志文件里信息很杂，一条条翻效率太低。我的习惯是先按时间戳定位到那次执行的起止区间，看两个时间点之间的间隔——间隔异常大的地方就是嫌疑人，再去流程里对号入座。

**易错点：别在出问题当天才想起来日志的事。**日志会滚动清理，隔几天再看，当天的文件可能已经没了。

让日志能分析：打印日志指令的正确用法

想让日志可分析，前提是流程自己会"说话"。影刀RPA里的「打印日志」指令就是干这个的，它把变量或文本输出到「运行日志」里查看，日志类型有调试、信息、警告、错误四种，默认为信息类型。

打点的原则：每个关键节点打印"我到哪了、带着什么数据、花了多久"。循环类流程必须在循环体内外各打一条，不然你根本不知道慢在循环外还是循环内。

用Python节点配合time模块做精确计时，是最实用的组合：

import time
import xbot

# 输入：无；输出：把各阶段耗时打印到运行日志
t0 = time.time()
xbot.logging.info('开始打开商品列表页')   # info类型，普通进度

# ……打开网页、等待元素出现等指令……

t1 = time.time()
xbot.logging.info(f'列表页加载耗时: {t1 - t0:.1f}秒')

t0 = time.time()
for i in range(20):                       # 模拟循环提取20条数据
    pass
    # 每N条打一次，别每条都打，日志会爆炸
    if (i + 1) % 5 == 0:
        xbot.logging.info(f'已提取 {i + 1} 条')

t1 = time.time()
xbot.logging.info(f'提取阶段耗时: {t1 - t0:.1f}秒')

除了print式的输出，xbot.logging模块还提供debug()、info()、warning()、error()四个级别的方法，写法都是传入一段文本。把进度打info、可忽略的异常打warning、失败打error，之后在日志文件里搜error和warning，问题段落一目了然。

想留存分析的话，用「导出日志」指令把「运行日志」的内容导出成txt文件，指定文件夹路径和文件名称即可，每天跑完自动归档一份。

从时间差找瓶颈：等待、定位与循环翻页

日志看多了会发现，流程慢的原因翻来覆去就那几种，按出现频率排个序。

**第一名：固定等待堆太多。**很多教程让你页面加载后等5秒、翻页后等3秒，20页翻下来光等待就一两分钟。正确做法是全部换成条件等待——「等待元素出现」指令设个合理超时，元素一出现立刻往下走。把所有固定等待换成条件等待，往往一步就能省下百分之二三十的时间。

**第二名：循环里逐条定位。**列表页数据要一条条点进去看详情的流程，最忌讳在循环体内反复用「点击元素」加「获取元素文本」。改成先用「获取相似元素列表」把整页20条链接一次抓回来存进列表变量，再ForEach列表循环逐个打开，定位次数从20次降到1次。

**第三名：懒加载页面滚太慢。**无限滚动的页面（典型如某些商品流），滚动步长设太大触底了数据没加载，设太小滚的次数翻倍。判断标准很简单：连续两次滚动后页面高度不变就停，配合index去重，别傻滚固定次数。

**第四名：弹窗和iframe反复处理。**弹窗每次出现都走一遍五步处理流程（检测→关闭→验证），不如在流程开头统一处理一次；iframe切换也是同理，先判断是否还在同一frame里再切。

元素定位本身也可能成为瓶颈：XPath写得又长又深，每条指令执行前影刀RPA要在整棵DOM里找，页面大的话单次定位能差出几百毫秒，乘以循环次数就是分钟级差距。CSS选择器（如 .item .price）在简单场景下比长XPath快，定位不稳定时再上正则做文本匹配。

打点的位置也有讲究，别只在主流程里打。子流程的首尾各打一条，才能算出每个模块的耗时占比——我的习惯是子流程开头打"进入XX模块"，结尾打"XX模块完成，本次耗时X秒"，主流程里只打阶段切换点。打太多全是噪音，打太少定位不了，一个流程控制在十五条上下最舒服。

变量内容也值得打进日志：循环到第几条、当前处理的商品ID、提取到的关键字段值。排查"为什么这条数据是空的"这类问题时，日志里有当时的变量快照，比复现一遍快得多。文本输入模式直接写字符串，Python输入模式可以写表达式拼接变量，选中已有变量插进来也行。

把执行记录变成趋势数据：耗时入库与分析

单次排查看日志，长期优化要看趋势。只靠眼睛翻执行记录，发现不了"流程比上周慢了20%"这种慢性病。我的做法是让流程自己在结束前把耗时数据写进SQLite表：

# 输入：各阶段耗时变量；输出：写入本地SQLite耗时表
import sqlite3

conn = sqlite3.connect(r'D:\rpa_data\perf.db')
conn.execute('''
CREATE TABLE IF NOT EXISTS run_cost (
    run_date TEXT,       -- 执行日期
    app_name TEXT,       -- 应用名
    stage TEXT,          -- 阶段名：列表页/详情页/汇总
    cost_sec REAL        -- 耗时秒数
)''')
conn.execute(
    "INSERT INTO run_cost VALUES (?,?,?,?)",
    ('2024-06-18', '商品采集', '详情页', 1240.5))
conn.commit()
conn.close()   # 连接务必释放，否则文件锁住打不开

攒上两三周数据，用pandas按阶段groupby算个平均值和最大值，哪个阶段在恶化一眼就能看出来。这套思路再进一步，可以用开放API的「查询应用运行日志」「最新任务执行记录」接口，把多台机器的耗时数据拉到一处统一分析，鉴权拿accessToken后按文档传参即可。

异常与告警：让数据自己来找你

性能分析不能只看正常执行的记录，异常重跑才是隐形的时间杀手。一个任务失败后人工发现、重跑，来回折腾一小时就没了。

两个机制配合用：控制台「任务监控」页面点「告警通知」，可以设置邮箱、钉钉、企业微信和飞书，计划执行异常时自动收到提醒；流程内部用Try-Catch把每个子流程包起来，Catch块里用「打印日志」记error级别的错误并截图，Finally块做资源清理。

调试阶段还有一个利器别浪费：在指令上右键添加断点，单步执行，配合变量面板看每一步的变量值。很多"慢"其实是流程逻辑绕了远路，比如循环里重复打开同一个页面，断点一走就现形了。

性能排查易错速查

现象	排查方向
单次执行忽快忽慢	查固定等待和网络波动，换成条件等待
循环越跑越慢	查内存泄漏，浏览器标签页和Excel是否在Finally里关闭
日志里大量重复定位失败	元素属性变了，重新捕获或改用模糊匹配
等待元素频繁超时	超时时间设太短，或页面进了iframe没切换
控制台显示成功但数据少	循环里异常被吞了，检查Catch块是否只记日志没重试

写在最后

执行记录告诉你"慢不慢"，运行日志告诉你"慢在哪"，两者结合，优化就不是玄学。我改造过的每个流程，第一步都是先加打点再动指令，没有数据支撑的优化都是瞎猜。文中这套打点模板和日志分析脚本我放在代码仓库 home.linyan.cloud，可以直接参考改造，拿去套在自己的流程上试试。

---

#影刀RPA #RPA自动化 #执行记录 #运行日志 #性能优化 #定时任务

作者：林焱