I Agent 浏览器任务在真实运行中，最需要谨慎处理的一类异常是安全验证。
它和普通 timeout、选择器失效、页面加载慢不同。
安全验证通常意味着平台认为当前登录环境、网络环境或操作行为需要确认。这个时候继续自动点击、刷新、重试，往往会让问题更难排查。
更稳妥的做法是：识别验证状态，暂停任务，保存现场证据，进入人工复核。
1. 为什么安全验证不能当成普通失败
很多自动化任务失败后会进入统一 retry 流程：
```text
task failed -> retry -> retry -> retry
```
这对临时网络抖动可能有效，但对安全验证并不合适。
安全验证的本质不是“页面没加载出来”，而是“当前任务现场需要人工确认”。
如果继续自动重试，可能出现几个问题：
| 问题 | 影响 |
|---|---|
| 连续刷新验证页 | 让验证触发更频繁 |
| 自动重复提交 | 增加账号风控风险 |
| 覆盖现场截图 | 后续无法复盘 |
| 错误归类为 timeout | 排查方向被带偏 |
| 继续执行后续步骤 | 在不可信状态下产生错误结果 |
所以安全验证应该是一个明确的失败类型，而不是普通异常。
2. 建议增加 security_verification_required
可以在失败分类中单独增加：
| failure_type | 含义 | 处理建议 |
|---|---|---|
| security_verification_required | 页面要求安全验证 | 暂停任务，人工完成官方验证 |
| session_invalid | 会话不可用 | 检查 Cookie、LocalStorage、IndexedDB |
| env_mismatch | 环境不匹配 | 检查 Profile、Proxy、时区、语言 |
| page_changed | 页面结构变化 | 保存截图，确认是否改版 |
| action_timeout | 操作超时 | 检查网络、等待策略、页面加载 |
| agent_uncertain | Agent 判断不确定 | 保存证据，进入人工复核 |
任务识别到 `security_verification_required` 后，不应该进入普通重试队列。
3. 识别安全验证时需要保存什么
安全验证出现时，最重要的是保留现场。
建议保存：
| 字段 | 说明 |
|---|---|
| run_id | 单次运行 ID |
| job_id | 任务 ID |
| workspace_id | 工作区 ID |
| profile_id | Profile ID |
| current_url | 当前页面 URL |
| page_title | 页面标题 |
| screenshot | 当前页面截图 |
| detected_text | 页面中识别到的提示文本 |
| failure_type | security_verification_required |
| reason | Agent 或脚本判断理由 |
| created_at | 记录时间 |
这些字段能回答一个关键问题：
任务是在什么环境、什么页面、什么提示下被暂停的？
4. EnvironmentSnapshot 也要一起保存
安全验证往往和环境变化有关。
因此除了页面截图，还建议保存环境快照：
| 检查对象 | 建议记录 | 排查重点 |
|---|---|---|
| Profile | profile_id、browser_version、extensions_hash | 是否换过浏览器环境 |
| Session | cookie_status、local_storage_status、indexeddb_status | 登录态是否稳定 |
| Proxy | proxy_id、region、exit_type | 网络出口是否切换 |
| Browser | timezone、language、user_agent_version | 是否与账号环境一致 |
| WebRTC | policy、observed_state | 是否暴露异常网络信号 |
| Automation | runner_version、entrypoint、job_id | 是否从正确入口运行 |
如果这些字段没有记录，后续很难判断是页面变化、账号状态变化，还是运行环境变化。
5. 一个推荐的处理流程
可以把流程设计成：
```text
Start Task
-> Preflight Check
-> Execute Step
-> Detect Security Verification
-> Save StepEvidence
-> Save EnvironmentSnapshot
-> Pause Task
-> Push ReviewQueue
-> Manual Verify
-> Resume or Close
```
其中最重要的动作是 `Pause Task`。
只要识别到安全验证，就不要继续自动执行高影响操作。
6. 最小配置示例
```yaml
failure_policy:
security_verification_required:
retry_allowed: false
pause_immediately: true
save_screenshot: true
save_environment_snapshot: true
review_required: true
next_action: manual_official_verify
retry_policy:
retry_allowed_for:
- action_timeout
pause_immediately_for:
- security_verification_required
- session_invalid
- env_mismatch
- agent_uncertain
```
这个配置的核心思想很简单：
低风险异常可以有限重试。
安全验证、环境异常、会话异常必须暂停。
7. ReviewQueue 建议字段
人工复核队列可以包含：
| 字段 | 说明 |
|---|---|
| review_id | 复核任务 ID |
| run_id | 关联运行 ID |
| failure_type | 失败类型 |
| priority | 复核优先级 |
| evidence_path | 截图和日志路径 |
| environment_snapshot_path | 环境快照路径 |
| assigned_to | 负责人 |
| status | pending / reviewed / resumed / closed |
| reviewer_note | 复核说明 |
这样能让暂停后的任务有明确归属，不会卡在没人处理的状态。
8. 实践建议
遇到安全验证时，建议遵守几条原则：
| 原则 | 说明 |
|---|---|
| 不要自动绕过验证 | 走平台提供的官方验证入口 |
| 不要连续刷新重试 | 避免让验证触发更频繁 |
| 保存现场证据 | 保留截图、URL、标题、环境快照 |
| 固定 Profile | 避免账号环境频繁变化 |
| 记录 Proxy 变更 | 排查地区、时区、语言不一致问题 |
| 人工确认后再恢复 | 复核通过后再继续任务 |
这类设计看起来比直接重试慢，但长期看更稳。
9. 总结
AI Agent 浏览器任务遇到安全验证时，正确处理方式不是继续尝试，也不是把它当成普通 timeout。
更合理的流程是：
识别安全验证。
保存步骤证据。
保存环境快照。
暂停任务。
进入人工复核。
人工完成官方验证或确认后，再决定是否恢复。
这套流程能降低不可复盘问题，也能避免自动化任务在不可信现场里继续执行。
Web4Browser 关注 Agent 浏览器任务中的环境连续性、证据链和人工复核机制，适合作为这类工作流的基础设施参考。
参考：
https://web4browser.io/cn/
