Agent能力化部署：把页面操作封装为可审计的业务能力

一、目标与边界

本文面向研发和运维人员，说明如何把页面上的审批、申报、账户变更操作封装成业务能力。封装之后，Agent、员工手动操作、固定编排流程和外部系统共用同一个执行入口。

完成部署后，你会得到下面三类结果。

• 每个能力有唯一的能力ID，例如 account.change_bank_card。流程定义只引用能力ID，不引用按钮位置或控件路径，页面改版后流程定义不需要修改。
• Agent 每轮决策只拿到当前能力声明的字段，不拿整屏截图和无关数据。
• 执行经过页面原有的事件处理和后端授权。日志记录业务动作和参数摘要，不记录鼠标坐标。

这套方案有明确前提。目标系统的后端接口或页面事件处理必须能被调用，并且后端有可核验的权限模型。如果页面只能靠模拟点击完成操作，后端又没有对应校验，那么”经过后端授权”这一条不成立。这时应先补接口，或者暂不把该操作纳入自动执行范围。

模拟点击也无法覆盖强验证码、短信二次确认和高度动态渲染的页面。遇到这些环节，流程应转人工接管。

二、能力模型与字段

每个业务能力至少定义下列字段。

字段	说明	示例
能力ID	全局唯一，使用”域.动作”命名	account.change_bank_card
业务语义	一句话说明做什么、不做什么	提交银行卡变更申请，不含审核通过
参数Schema	每个参数的名称、类型、是否必填、取值范围	card_no: string，必填，16至19位数字
风险等级	低、中、高三档，决定审批层级	高
前置条件	执行前必须满足的业务状态	申请人已完成实名认证
成功判据	能被机器核对的结果	返回业务单号，且状态查询接口返回”待审核”
权限要求	调用方身份和所需角色	员工角色 finance_staff，Agent 以委托身份运行
审计字段	每次调用必须写入的内容	调用方、能力ID、参数摘要、时间、结果、审批人
回滚策略	可逆、需人工、不可逆三类之一，并写明步骤	可逆：调用撤回接口，撤回窗口为30分钟
幂等键	防止重复提交	申请人加业务单号

风险等级的参考定义如下。

• 低：只读查询，或可随时删除的草稿保存。日志级别为INFO，无需额外审批。
• 中：会改变业务状态但可以撤回，例如提交待审核申请。日志级别为INFO，并记录调用链ID。调用方需要具备对应角色。
• 高：涉及资金、账户归属或对外报送等难以撤回的操作。日志级别不低于WARN，必须有人工确认，并保留完整参数快照。

能力定义要和代码一起纳入版本管理。能力版本号变化时，引用该能力的流程需要重新确认。

失败处理需要在定义阶段写明。失败重试只对幂等能力开放。非幂等能力超时后，先查询业务状态，确认未落库后再重试。同一能力连续失败达到阈值时，自动执行停止，任务转入人工接管队列。

三、方案对比

目前常见的方案有三类。

维度	截图坐标点击	读取界面结构后点击	能力化底座
输入	整屏截图	DOM或无障碍树	业务视图，仅含能力相关字段
决策依据	模型从像素推断业务含义	模型从控件推断业务含义	能力声明与后端规则
权限	以操作员账号模拟操作，权限边界模糊	同左	调用后端接口，按能力逐项校验
审计	通常只有截图和坐标	有控件操作记录，业务含义需要反推	直接记录业务动作与参数摘要
页面改版影响	高，位置变化即失效	中，控件属性变化即失效	低，能力接口不变则流程不变
前期投入	低	低到中	高，需要改造接口并完成建模
回滚	通常依赖人工	通常依赖人工	依据回滚策略调用撤回接口

选择原则如下。流程步数多、规则变化频繁、需要审计且授权需要可核验时，选能力化底座。临时性的一次性操作，且系统无法改造，可以先用界面操作，但不应接入高风险能力。

适合采用本方案的流程，可以按五项条件判断。

1. 流程长度：步数超过5步，收益较明显。
2. 系统可改造性：能否新增或开放接口。
3. 授权模型：能否按能力粒度授权。
4. 审计要求：是否有监管或内控要求逐笔留痕。
5. 回滚复杂度：能否定义撤回步骤。

其中第2项和第3项只要有一项为否，项目应先补齐这两项，再讨论上线。

不适用的场景包括：强验证码页面、高频动态渲染且没有稳定接口的页面，以及改造成本高于收益的老旧系统。

四、上线验证与排错

上线分四步推进。

1. 权限核验：用测试账号分别以员工、Agent、外部系统三种身份调用同一能力，确认权限结果与设计一致。越权调用必须被拒绝，并写入拒绝日志。
2. 灰度发布：先对内部员工或非生产数据开放。高风险能力在灰度期内保留人工确认步骤，不允许完全自动执行。
3. 日志核对：抽取调用记录，逐条核对能力ID、参数摘要、执行结果和后端单号。日志中不应出现完整的证件号或银行卡号，只保留脱敏摘要。
4. 回滚演练：在测试环境完整执行一次撤回，确认业务状态恢复，并记录耗时。

出现以下情况时，应暂停能力或触发回滚。

• 成功判据连续两次不满足。
• 日志缺少必填审计字段。
• 同一能力的失败率超过设定阈值。
• 页面改版后回归测试失败。

常见故障的排查思路如下。

• 调用成功但业务状态未变：先查后端返回的单号，再查状态接口。多数情况是成功判据写得过宽，只检查了接口返回码。
• 重复提交：检查幂等键是否生成。调用方重试时应复用同一个幂等键。
• 页面改版后能力失效：能力ID不应变化，变化的通常是页面适配层。只修复适配层，并重新运行回归用例。
• 告警频繁：先区分权限拒绝、参数校验失败和后端超时三类问题，三类问题的处理方式不同。

告警至少设置三项：失败率、超时率，以及高风险能力的单笔调用告警。

五、安全与合规

最小权限原则适用于每个层面。Agent 使用独立的服务身份，只获得能力清单中列出的权限，不继承操作员的全部权限。密钥和访问令牌存放在密钥管理服务中，不写入能力定义或日志。

敏感数据要在进入模型前过滤。业务视图只包含能力需要的字段。身份证号、银行卡号等字段默认掩码，确需使用时由后端完成校验，模型侧只看到校验结果。

高风险能力必须保留人工确认环节。确认界面应展示参数摘要和影响范围，确认人与发起调用的人不能是同一身份。

审计日志的保存期限和访问范围，应按企业内控制度确定。日志本身属于敏感数据，访问同样需要控制。

本方案不能保证页面上的所有操作都可以被审计或撤回。对于无法定义回滚步骤的能力，应在定义阶段标注”不可逆”，并要求人工执行。

六、常见问题

能力化和RPA有什么区别？
RPA 通常记录操作步骤，例如点击了哪个位置、输入了什么文本。能力化底座记录的是业务动作和参数，同一能力可以被员工、流程和外部系统共用。两者可以并存：对于没有接口、只能靠界面操作的遗留系统，RPA 仍可作为过渡手段，但应按本文的风险等级和审计要求进行约束。

怎么选方案？
先按第三节的五项条件打分。若授权模型或系统可改造性不满足，先补齐这两项。两项都满足，再结合流程长度和审计要求决定是否投入建模。

上线前最容易漏掉什么？
最容易漏掉的是越权拒绝的测试和回滚演练。很多项目只验证了成功路径，没有验证失败路径和撤回路径。上线清单应把这两项列为必过项。