AI 浏览器任务失败怎么排查：Context、Session、Page State 和 Task Log 检查清单

很多团队开始使用 AI 浏览器或浏览器自动化后会遇到一种情况AI 能打开页面。AI 能点击按钮。AI 能填写表单。AI 能执行下一步。但任务还是失败。这时很多人会先查模型能力、提示词、选择器、页面加载速度或脚本逻辑。这些当然要查。但在长期任务里还有一类更常见的问题AI 拿到的运行上下文不对。比如当前账号环境不是预期环境Session 看起来还在但任务不能继续页面停在上一次失败位置current_url 和任务入口不一致上一次失败没有复盘截图和日志没有关联 task_id人工复核结论没有同步到下一次任务。所以AI 浏览器任务失败后不要只查“AI 会不会点页面”。更应该先检查Context 是否正确。Session 是否可继续。Page State 是否符合预期。Task Log 是否能复盘。Evidence 是否完整。本文整理一套面向团队任务的排查清单。1. 常见现象先看几个典型现象。现象表面原因更可能的上下文原因AI 找不到按钮selector 失效页面停在非预期 URLAI 重复点击脚本循环问题上一次任务状态未清理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当前运行上下文 IDaccount_id对应账号profile_id浏览器环境 IDowner当前负责人last_operator最近操作人context_statusnormal / paused / need_review / archivednext_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_statusvalid / expired / unknowncurrent_url当前页面 URLpage_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任务 IDcontext_id运行上下文 IDoperator操作者或自动化执行方started_at开始时间ended_at结束时间statussuccess / failed / pausedfailed_step失败步骤current_url失败时 URLerror_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 是否为 validcurrent_url 是否符合预期page_state 是否等于 expected_page_statereview_required 是否为 falseTask Run 是否记录 task_idfailed_step 是否可追踪screenshot_path 是否保存error_message 是否可读next_action 是否明确是否有人负责 Review是否有暂停和归档状态所以AI 浏览器任务失败后不要只查模型和脚本。模型负责理解页面。脚本负责执行动作。但长期任务能不能稳定取决于运行上下文是否完整。Context、Session、Page State、Task Run、Evidence 和 Review 如果没有串起来任务失败后就很难复盘。先把这些状态检查清楚再去优化提示词、脚本或执行策略排查效率会高很多。