很多团队开始使用 AI 浏览器或浏览器自动化后，会遇到一种情况：

AI 能打开页面。
AI 能点击按钮。
AI 能填写表单。
AI 能执行下一步。

但任务还是失败。

这时很多人会先查模型能力、提示词、选择器、页面加载速度或脚本逻辑。

这些当然要查。

但在长期任务里，还有一类更常见的问题：

AI 拿到的运行上下文不对。

比如：

当前账号环境不是预期环境；
Session 看起来还在，但任务不能继续；
页面停在上一次失败位置；
current_url 和任务入口不一致；
上一次失败没有复盘；
截图和日志没有关联 task_id；
人工复核结论没有同步到下一次任务。

所以，AI 浏览器任务失败后，不要只查“AI 会不会点页面”。

更应该先检查：

Context 是否正确。
Session 是否可继续。
Page State 是否符合预期。
Task Log 是否能复盘。
Evidence 是否完整。

本文整理一套面向团队任务的排查清单。

1. 常见现象

先看几个典型现象。

如果这些问题只靠人工记忆处理，后期会越来越难排查。

2. 先拆运行上下文对象

一个 AI 浏览器任务，不应该只看“页面动作”。

建议先拆成这些对象：

Account -> Browser Context -> Network -> Session -> Page State -> Task Run -> Evidence -> Review

每一层回答一个问题：

Account：当前任务对应哪个账号或身份。
Browser Context：任务运行在哪个浏览器环境里。
Network：网络、地区、时区、语言是否和任务预期一致。
Session：登录态和页面流程是否可继续。
Page State：当前页面是否处于预期步骤。
Task Run：这次任务执行了什么。
Evidence：失败现场是否保留。
Review：是否需要人工复核，以及下一步动作是什么。

如果这些对象不拆开，所有问题都会变成一句话：

任务失败了。

这句话没有排查价值。

3. Context 字段检查

Context 是任务运行的基础。

至少建议记录这些字段：

示例：

{ "context_id": "ctx_1001", "account_id": "account_a", "profile_id": "P-1001", "owner": "zhangsan", "last_operator": "automation_agent", "context_status": "need_review", "next_action": "check_session_and_page_state" }

如果context_status不是normal或retry_ready，任务不应该直接执行。

很多任务失败，不是 AI 点错了。

而是任务本来就不该开始。

4. Session 字段检查

Session 不等于 Cookie。

Cookie 只是其中一部分。

在浏览器任务里，Session 至少要包含：

Cookie 状态；
LocalStorage 状态；
当前 URL；
页面状态；
是否可继续；
是否需要人工复核。

建议字段：

示例：

{ "session_status": "valid", "current_url": "https://example.com/dashboard", "page_state": "ready", "expected_page_state": "ready", "can_continue": true, "review_required": false }

如果只看账号是否在线，很容易误判。

账号在线，不代表页面状态正确。
Cookie 存在，不代表任务可以继续。
页面能打开，不代表上下文完整。

5. Page State 检查

Page State 是 AI 浏览器任务里经常被忽略的一层。

常见状态可以这样定义：

示例记录：

{ "current_url": "https://example.com/form", "expected_url": "https://example.com/dashboard", "page_state": "middle_step", "expected_page_state": "ready", "review_required": true }

如果current_url和expected_url不一致，不要直接让 AI 继续任务。

应该先判断：

是任务流程正常跳转？
还是上一次失败残留页面？
是否需要人工复核？
是否应该重置任务入口？

6. 执行前 Gate

建议在 AI 浏览器任务执行前加一个 Gate。

不要一启动就执行点击动作。

可以用伪代码表示：

def can_run_task(ctx): if ctx["context_status"] not in ["normal", "retry_ready"]: return False if ctx["session_status"] != "valid": return False if ctx["page_state"] != ctx["expected_page_state"]: return False if ctx["review_required"]: return False return True

这段代码只是示意。

真正要表达的是排查顺序：

先看 Context。
再看 Session。
再看 Page State。
最后看 Review。

如果前置状态不满足，就不要进入执行层。

很多自动化失败，不是执行能力问题，而是缺少运行前门禁。

7. Task Run 不要只记录 failed

很多日志最大的问题是只记录：

task failed

这对复盘帮助不大。

建议 Task Run 至少包含：

示例：

{ "task_id": "task_20260708_001", "context_id": "ctx_1001", "operator": "automation_agent", "started_at": "2026-07-08 10:00:00", "ended_at": "2026-07-08 10:08:00", "status": "failed", "failed_step": "submit_form", "current_url": "https://example.com/form", "error_message": "page_state_not_expected", "screenshot_path": "/evidence/task_20260708_001.png", "next_action": "manual_review" }

这里最关键的是：

失败步骤。
失败 URL。
错误信息。
截图路径。
下一步动作。

这些字段齐全，团队才能复盘。

8. Evidence 要和任务绑定

截图不是单独保存一张图片。

截图应该能关联到任务和上下文。

错误示例：

error_001.png error_002.png error_003.png

这种命名看起来有截图，但后续很难知道：

这张图对应哪个任务？
失败步骤是什么？
当前 URL 是什么？
后面是否复核过？

更好的 Evidence 结构：

{ "evidence_id": "ev_001", "task_id": "task_20260708_001", "context_id": "ctx_1001", "failed_step": "submit_form", "current_url": "https://example.com/form", "screenshot_path": "/evidence/task_20260708_001.png", "log_path": "/logs/task_20260708_001.log", "review_result": "page_state_mismatch", "next_action": "pause_and_review" }

Evidence 的价值不是“留存”。

而是能让后面的人还原失败现场。

9. Review 状态流

AI 浏览器任务失败后，不建议直接重试。

建议先进入 Review 状态流。

running -> failed -> need_review -> retry_ready -> paused -> archived

可以这样理解：

failed：任务失败。
need_review：需要人工复核。
retry_ready：已确认可以重试。
paused：暂时不要继续。
archived：不再进入任务池，仅保留记录。

这样做的好处是：

不会让 AI 在不确定状态下继续跑。
不会让失败任务反复重试。
不会让截图和日志变成孤立文件。
不会让接手人重新问一遍发生了什么。

10. 团队排查时，最好把这些状态放在一起看

如果只是个人测试，简单日志可能够用。

但如果团队已经多人协作，并且开始使用 AI 浏览器任务，Context、Session、Page State、Task Run、Evidence 和 Review 就不适合分散管理。

常见分散方式是：

账号关系在表格里。
浏览器环境在工具里。
截图在聊天记录里。
日志在脚本目录里。
复核结论在私聊里。
下一步动作靠口头同步。

这些信息都存在，但无法快速复盘。

有些团队会把账号、Profile、Session、页面状态、任务日志、失败证据和人工复核统一放进 AI 浏览器任务工作流 里。重点不是让 Web4 替代 Playwright、RPA 或 API，而是让团队能在同一个上下文里判断：AI 当前能不能执行、失败后证据在哪里、下一步是继续还是复核。

11. 排查顺序

建议按这个顺序排查：

Step 1：确认 context_id 和 account_id Step 2：检查 context_status Step 3：检查 session_status Step 4：检查 current_url Step 5：检查 page_state 和 expected_page_state Step 6：判断 review_required Step 7：查看 Task Run Step 8：查看 Evidence Step 9：给出 next_action Step 10：决定重试、暂停或归档

不要一开始就改脚本。

先确认任务是否在正确上下文里运行。

12. 最终 Checklist

发布任务前，可以检查：

• context_id 是否存在？

• account_id 是否明确？

• context_status 是否允许执行？

• session_status 是否为 valid？

• current_url 是否符合预期？

• page_state 是否等于 expected_page_state？

• review_required 是否为 false？

• Task Run 是否记录 task_id？

• failed_step 是否可追踪？

• screenshot_path 是否保存？

• error_message 是否可读？

• next_action 是否明确？

• 是否有人负责 Review？

• 是否有暂停和归档状态？

所以，AI 浏览器任务失败后，不要只查模型和脚本。

模型负责理解页面。

脚本负责执行动作。

但长期任务能不能稳定，取决于运行上下文是否完整。

Context、Session、Page State、Task Run、Evidence 和 Review 如果没有串起来，任务失败后就很难复盘。

先把这些状态检查清楚，再去优化提示词、脚本或执行策略，排查效率会高很多。