动作不可用
ACTION_UNAVAILABLE 表示动作已经注册，但当前不能执行。这与“找不到动作”不同：声明存在，业务或界面闸门拒绝。正确做法是解释并解除前置条件，不是重试或寻找绕过路径。
排查面
| 检查 | 说明 |
|---|---|
available() | 业务前置条件是否返回 false |
disabled | 原生控件是否禁用 |
| 区域 | 动作是否在活跃区域、弹窗之外或隐藏步骤 |
| 遮挡 | 是否有 modal、loading mask 或固定层挡住目标 |
| 记录状态 | 目标行是否已锁定、删除或不属于当前用户 |
| 角色 | 当前用户是否具备操作权限 |
| 筛选 / 分页 | 目标是否已不在当前业务视图 |
读取原因
错误消息可能包含前置条件、记录状态或可用区域信息。错误文案可以给出方向，但程序逻辑仍应使用稳定错误码。调试面板应保留动作 id、目标记录与当时快照。
执行器返回结构化结果，而不是向循环抛出异常：
json
{
"error": {
"code": "ACTION_UNAVAILABLE",
"message": "Action is currently unavailable: approve@order:SO-1042; reason: order is locked"
}
}示例里的原因是页面自定义的。不要根据 message 做程序分支；如果运维需要聚合失败，应在页面诊断中提供稳定的业务原因。
排查顺序
- 从失败请求中复制动作 id 与目标记录，不要使用旧对话里的值。
- 重新 describe 页面，确认动作仍然存在，且所在区域处于活跃状态。
- 对照当前 DOM 与页面快照：控件是否禁用、步骤是否隐藏、弹窗是否关闭、行是否已被替换。
- 通过页面读取动作或状态视图确认当前业务记录。
- 若控件在视口外，先使用已声明的 reveal / scroll 能力，再重试。
- 若必须由人解锁、批准或完成前置步骤，停止自动执行并转入人工接力。
不要用相似动作、DOM 点击或直接改数据来“修复”问题。这些路径绕过了让该动作安全成立的契约。
不要做的事情
- 不要重复调用同一个不可用动作；
- 不要切换到相似 id 绕过权限；
- 不要用通用点击或脚本伪造可用；
- 不要把“等待确认”当成不可用；
- 不要在没有人工授权时自动改变业务状态。
恢复方式
- 若缺少前置步骤，先执行允许的前置动作，再重新描述。
- 若目标被筛选掉，恢复筛选或选择新的业务视图。
- 若控件被弹窗遮挡，先关闭或完成弹窗。
- 若记录已锁定，请求拥有者处理。
- 若权限不足，转人工；Agent 不能自授权。
- 若动作是
handoff，向用户展示需要的操作并等待结果。
页面设计建议
- 为不可用动作返回具体原因，而不是只返回 false；
- 保留动作 id 稳定，避免把“不可用”做成“消失”，除非业务上确实不应让 Agent 知道；
- 将确认、人工接力、不可用区分开；
- 用状态视图暴露会影响可用性的步骤、角色和记录状态。
验收
- 动作不可用时，业务处理函数从未执行。
- 存在具体前置条件时，返回消息应说明它。
- 清除前置条件并重新 describe 后，动作恢复可用。
- 权限失败与临时界面状态保持不同错误语义。
- 恢复后重试不会重复前一次业务副作用。