很多团队开始使用 AI 浏览器或浏览器自动化后，会遇到一种情况：
AI 能打开页面。
AI 能点击按钮。
AI 能填写表单。
AI 能执行下一步。
但任务还是失败。
这时很多人会先查模型能力、提示词、选择器、页面加载速度或脚本逻辑。
这些当然要查。
但在长期任务里，还有一类更常见的问题：
AI 拿到的运行上下文不对。
比如：
当前账号环境不是预期环境；
Session 看起来还在，但任务不能继续；
页面停在上一次失败位置；
current_url 和任务入口不一致；
上一次失败没有复盘；
截图和日志没有关联 task_id；
人工复核结论没有同步到下一次任务。
所以，AI 浏览器任务失败后，不要只查"AI 会不会点页面"。
更应该先检查：
Context 是否正确。
Session 是否可继续。
Page State 是否符合预期。
Task Log 是否能复盘。
Evidence 是否完整。
本文整理一套面向团队任务的排查清单。
1. 常见现象
先看几个典型现象。
| 现象 | 表面原因 | 更可能的上下文原因 |
|---|---|---|
| AI 找不到按钮 | selector 失效 | 页面停在非预期 URL |
| AI 重复点击 | 脚本循环问题 | 上一次任务状态未清理 |
| AI 提交失败 | 表单异常 | Session 已不可继续 |
| AI 执行错账号 | 环境选择错误 | account 与 context 映射不清 |
| 任务失败后无法复盘 | 日志不足 | screenshot、URL、step 没有关联 |
| 多人接手后反复问人 | 交接问题 | owner、last_operator、next_action 缺失 |
如果这些问题只靠人工记忆处理，后期会越来越难排查。
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 | 当前运行上下文 ID |
| account_id | 对应账号 |
| profile_id | 浏览器环境 ID |
| owner | 当前负责人 |
| last_operator | 最近操作人 |
| context_status | normal / paused / need_review / archived |
| next_action | 下一步动作 |
示例：
{
"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 / expired / unknown |
| current_url | 当前页面 URL |
| page_state | 当前页面状态 |
| expected_page_state | 预期页面状态 |
| can_continue | 是否允许继续 |
| review_required | 是否需要人工复核 |
示例：
{
"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 浏览器任务里经常被忽略的一层。
常见状态可以这样定义：
| 状态 | 含义 | 是否允许继续 |
|---|---|---|
| ready | 页面符合预期 | 可以 |
| wrong_url | 当前 URL 不符合任务入口 | 不建议 |
| middle_step | 停在中间步骤 | 需要判断 |
| error_page | 页面出现异常提示 | 不建议 |
| expired_page | 页面状态过期 | 不建议 |
| unknown | 无法判断 | 需要人工复核 |
示例记录：
{
"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 | 任务 ID |
| context_id | 运行上下文 ID |
| operator | 操作者或自动化执行方 |
| started_at | 开始时间 |
| ended_at | 结束时间 |
| status | success / failed / paused |
| failed_step | 失败步骤 |
| current_url | 失败时 URL |
| error_message | 错误信息 |
| screenshot_path | 截图路径 |
| next_action | 下一步动作 |
示例：
{
"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 如果没有串起来，任务失败后就很难复盘。
先把这些状态检查清楚，再去优化提示词、脚本或执行策略，排查效率会高很多。