01项目概览
企业场景下的 RPA 体验与选型报告
比较人工与自动化的真实操作，判断一套工具适合承担哪些工作。
公司考虑用 RPA 处理 HR 主数据运维。我围绕执行效率、稳定性和业务影响整理测试评估，比较人工、AI Agent 与预设流程，形成当前版本暂不进入核心生产操作的建议。
02评估目标
明确适用范围
RPA 通过操作界面代替人完成重复工作。但 HR 主数据中的人员状态、组织归属等信息还会影响下游系统，选工具时需要确认：能否稳定完成、识别失败、留下记录，并在出错后恢复。
能否节省工作
同时计算操作耗时、终端占用、人工介入和流程维护，判断自动化是否真的减少了负担。
能否承担后果
区分低影响查询与核心数据修改，对权限、校验、审计和恢复提出不同要求。
本轮使用会议内容导出和 OA 报销入口导航作为替代场景，未直接操作 HR 主数据。测试用于判断当前版本及交付模式是否满足生产准入条件。
03测试展示
测试过程
测试设计
先记录人工完成目标所需的时间，再比较 Agent 与预设流程。Agent 根据截图判断下一步；预设流程事先写好步骤，按顺序执行。测试同时记录是否完成、卡在哪里，以及需要怎样的人工介入。
| 场景 | 目标 | 比较方式 |
|---|---|---|
| 会议内容导出 | 打开记录并导出内容 | 人工、Agent、预设流程 |
| OA 报销导航 | 从已登录首页进入报销界面 | 人工、Agent |
内容导出
同一次导出任务中，人工用时 24.613 秒，Agent 用时 456.542 秒，约为人工的 18.5 倍。Agent 反复截图、识别、移动鼠标、点击，再截图确认，每个环节的等待累积为七分多钟。
| 方式 | 耗时 | 完成情况 |
|---|---|---|
| 人工 | 24.613 秒 | 完成导出 |
| Agent | 456.542 秒 | 完成，但持续占用操作终端 |
| 预设流程 | 未稳定完成 | 软件端与网页端均卡在多级菜单 |
预设流程能识别部分静态控件，却没有稳定处理菜单展开、悬停和二级选项变化。问题在于整段交互能否连续执行。
OA 导航
人工从首页进入报销界面用时 4.098 秒。Agent 经过多次调整指令和重试后到达目标，按截图时间估计约 10 分钟。期间出现网址拼接错误、服务异常和登录验证问题。
| 失败位置 | 观察到的问题 | 影响 |
|---|---|---|
| 任务理解 | 将两个地址拼接为同一网址 | 点击前就偏离目标 |
| 执行服务 | RPA 服务、算法模块异常 | 任务中断，需要重新尝试 |
| 页面操作 | 登录验证、浏览器接管受阻 | 无法顺利继续导航 |
这次最终到达页面依赖人工介入。因此，后续评估需要记录首次成功率、连续运行结果和恢复时间，而不仅是最终是否完成。
04判断逻辑
按任务选工具
耗时更长、失败分散在多个环节，且权限控制与恢复机制尚未得到充分验证。对影响下游系统的 HR 主数据操作，我给出的结论是：当前版本及当前交付模式，不用于核心读写和无人值守生产运维。
核心操作
优先使用 API，让程序提交明确的数据请求，并读取返回结果。权限、输入校验、重复提交控制和审计都有对应位置；人员状态等重要变更再加入审批和变更差异确认。
受控试点
没有 API 的遗留系统，可以选择只读、页面稳定、结果可人工复核的任务，使用独立账号和隔离环境测试。连续运行时记录成功率、人工介入率、错误类型和恢复时间，再决定是否扩大范围。
低频操作
临时、简单的小操作，把配置、调试和维护时间一并计入成本。若这些投入高于人工操作，可以继续人工完成，或保留有人值守的自动化。
05我的工作
从测试到决策
- 明确评估问题围绕 HR 主数据运维，拆分功能、效率、稳定性、维护与治理要求。
- 整理操作证据对照录屏时长与异常记录，区分已完成、未稳定完成和依赖人工介入的流程。
- 形成技术建议将测试结果对应到业务影响，提出 No-Go 范围、替代路线和复测条件。
把成功条件写完整
只问“能不能做成”，容易忽略反复改指令、重跑服务和占用员工终端的成本。我把这些过程纳入比较，让最终建议同时回答：哪些工作可以继续试，哪些工作现阶段不该交给它。
06完成情况
评估交付
已形成 11 页测试结论稿 v1.1（2026 年 7 月），包含测试设计、结果比较、风险矩阵、技术路线、证据索引和管理层摘要，可用于采购与试点讨论。
当前成果是评估与建议。后续需由供应商补充连续运行和治理能力的证据，再复核准入条件。