RPA 运维 Agent 实践
让一封异常邮件，
变成一次可追溯的闭环。
它不替人修复异常。它负责把事实、截图、AI 方向、人工判断和复测证据放到正确的位置，让维护者少做整理，多做判断。
纯静态沙盒 · 不接 API · 不上传输入 · 刷新即重置
事实入库
人工确认
完整复测
自动处理整理工作
×人工掌握最终判断
=更可靠的异常维护
WORKFLOW / 工作链路
AI 在前面整理，人在关键节点负责。
每一层都有明确职责，AI 推测不会覆盖人工事实，复测通过之前也不会自动结案。
异常邮件
获取应用、流程、原始报错和执行截图。
事实归档
建立原始事件与异常档案，保留来源关系。
Hermes 初判
给出可能原因、依据和下一步排查方向。
人工闭环
完成分析、实际修复、最终原因和完整复测。
经验与总结
同平台经验回流，结果进入当日工作总结。
INTERACTIVE SANDBOX / 交互沙盒
亲手走一遍异常闭环。
下面是预设演示，不连接真实 Agent。你输入的文字只留在当前页面内存中。
待处理 3
高优先级 1
同应用事件 3
已解决 0
DEMO DATA
当前主档
待分析
跨境库存监控（演示）
页面加载超时 · 10:06:35
已确认事实
流程 10｜中转仓下载第 16 条指令出错：等待对话框出现超时
当前只确认原始事件已入库，原因尚未由人工确认。
3 个异常已并入当前主档，原始邮件与附件全部保留，后续只需分析一次。
同平台历史经验
马帮平台高相似
页面切换完成前，等待条件可能落在旧对话框
以前怎么修：关闭残留弹窗，在点击下载后增加“等待任一结果元素出现”，不要只延长固定等待。
2 个已复测案例支持 · 仅供参考Hermes AI 判断（参考）
优先检查页面状态，而不是直接重捕获元素。
三个事件都停在同一对话框等待节点，可能存在弹窗未关闭、页面未切换完成或等待目标设置过窄。以上是排查方向，不是最终原因。
依据：相同流程节点仍需确认：真实卡点
执行截图（虚构示意）
库存导出
正在等待页面返回结果…
00:59演示说明：所有案例、编号、应用和截图均为虚构；页面没有网络请求能力。
OPERATING RULES / 运行规范
不是“AI 说了算”，而是证据逐步升级。
事实与推测分开
邮件原文和截图不可被 AI 改写；AI 内容始终标记为参考。
先分析，再修复
没有人工判断和验证依据，状态不能进入修复中。
最终原因后置
修复阶段只记录实际修改；最终原因留到待复测阶段确认。
复测才是终点
没有运行范围、结果和证据，异常不能标记为已解决。
经验按平台匹配
不把某个平台的操作经验无条件套用到另一个平台。
合并必须由人确认
只有同一应用、尚未进入修复的异常才能并为一个主档。
CAPABILITY BOUNDARY / 能力边界
辅助判断，不替代操作责任。
✓ Agent 可以做
- 读取并解析异常邮件
- 保存原始正文、字段和截图
- 提供初步排查方向和证据
- 匹配同平台历史处理经验
- 聚合重复或同根因异常
- 整理异常档案和工作总结
× Agent 不会做
- 自动打开影刀设计器修改流程
- 把 AI 猜测直接写成最终原因
- 代替人工执行完整业务复测
- 未经确认自动合并或结案
- 处理没有邮件也没有人工补录的异常
- 向公开访客开放真实系统权限
这个公开网址尤其不会：连接真实邮箱调用 Hermes连接飞书读取本地文档保存访客输入
RUNNING EVIDENCE / 真实运行证据
不是效果图，是已经跑过的链路。
以下图片由项目所有者提供，用于证明异常入库、人工闭环和总结归档已经真实运行。点击可放大。
TOOLCHAIN / 工具组成
每个工具只做自己擅长的部分。
Codex
系统设计、代码实现、故障排查与回归验证。
Hermes
异常初判、证据整理、案例比较与对话推理。
飞书 CLI
接收消息事件，并由机器人返回记录结果。
本地看板
承载人工分析、修复、复测、合并和总结确认。
Markdown
保存可迁移、可搜索、可追溯的权威业务记录。