浏览器自动化任务失败时，日志里最常见的一句话是：
failed
这句话对排查帮助很小。
因为它没有告诉你：
哪个账号失败；
在哪个 Profile 里失败；
当时用的哪组网络配置；
Session 是否还有效；
页面停在哪个 URL；
有没有截图；
下一步应该重试，还是人工复核。
很多团队会先看 Profile：
Profile 能打开。
页面也能显示。
Cookie 好像还在。
于是判断任务可以继续。
但从工程角度看，这个判断不够。
Profile 已打开，只说明浏览器环境启动成功。
它不代表任务上下文可以继续。
一、Profile 不是运行结果，而是运行上下文
在个人使用场景里，Profile 可以被简单理解成一个独立浏览器环境。
但在团队任务里，Profile 更像运行上下文的一部分。
可以把一次浏览器任务拆成这条链路：
Account -> Profile -> Network -> Session -> PageState -> TaskRun -> Evidence -> Review
每个对象负责一层信息。
Account 表示业务账号。
Profile 表示浏览器环境。
Network 表示代理、地区、时区、语言等配置。
Session 表示当前会话是否能继续。
PageState 表示当前页面是否符合任务预期。
TaskRun 表示一次任务执行。
Evidence 表示失败现场。
Review 表示人工复核结论。
如果只看 Profile 是否打开，就等于只看到了链路中的一段。
真正要判断的是：
这条链路是否完整。
二、先确认 Account 和 Profile 是否对应
任务继续之前，第一步不是看 Cookie。
而是确认账号和 Profile 是否对应。
一个基础上下文可以这样记录：
{
"account_id": "account_001",
"profile_id": "profile_001",
"owner": "member_a",
"last_operator": "member_b",
"last_open_time": "2026-07-07 10:30:00"
}
这几个字段回答的是：
当前任务到底跑在哪个账号环境里？
如果 account_id 和 profile_id 不清楚，后面所有判断都会失准。
比如：
脚本执行的是 Profile A；
运营以为它对应账号 1；
实际上上一次有人把账号 2 放进了这个 Profile；
失败后日志只记录了 Profile A。
这种情况下，Profile 能打开也没意义。
因为上下文已经错了。
三、Network 变更会影响任务判断
浏览器任务里，Network 不只是“代理能不能连”。
它还可能影响地区、时区、语言、页面状态和后续复盘。
建议至少记录：
{
"profile_id": "profile_001",
"network_label": "us_proxy_group_a",
"region": "US",
"timezone": "America/Los_Angeles",
"language": "en-US",
"updated_by": "member_b",
"updated_at": "2026-07-07 09:40:00",
"review_status": "checked"
}
自动化任务开始前，要问几个问题：
network_label 是否和 Profile 绑定？
region、timezone、language 是否一致？
配置是否刚刚变更？
变更后是否复核？
任务失败是否发生在变更之后？
如果网络配置刚变更，但 review_status 不是 checked，就不应该直接继续执行。
这不是为了让流程变慢。
而是为了避免任务在不确定环境里继续跑。
四、Cookie 不等于 Session
很多任务误判来自一个问题：
Cookie 还在，所以任务可以继续。
这不一定成立。
Cookie 是本地状态。
Session 是当前会话是否还能继续。
PageState 是当前页面是否符合任务预期。
这三者不能混在一起。
可以把 Session 状态设计成：
valid
uncertain
expired
need_review
如果 session_state 是 uncertain，就不应该进入下一步任务。
更稳的处理流程是：
save_current_url -> save_screenshot -> mark_need_review -> wait_for_review
也就是先保存现场，再进入复核。
不要因为 Profile 已打开，就默认继续执行。
五、PageState 是自动化任务的前置条件
页面能打开，不代表页面状态正确。
自动化任务至少要检查：
current_url 是否符合预期；
页面是否停在上一次失败步骤；
是否有错误提示；
是否需要人工确认；
是否已经保存截图。
示例：
{
"profile_id": "profile_001",
"current_url": "https://example.com/dashboard",
"expected_url": "https://example.com/dashboard",
"page_state": "need_review",
"last_step": "open_dashboard"
}
如果 page_state 是 need_review，任务就应该停。
这里的重点不是“自动化能不能继续点”。
而是任务是否还处在可控状态里。
六、TaskRun 不能只记录 failed
一次浏览器任务失败后，至少要留下能复盘的 TaskRun。
{
"run_id": "run_20260707_001",
"account_id": "account_001",
"profile_id": "profile_001",
"network_label": "us_proxy_group_a",
"step_name": "check_dashboard_status",
"current_url": "https://example.com/dashboard",
"screenshot": "/evidence/run_20260707_001.png",
"error_message": "page_state_uncertain",
"next_action": "manual_review"
}
这些字段能回答：
任务在哪个账号上失败；
使用哪个 Profile；
当时是哪组网络配置；
失败发生在哪一步；
页面停在哪里；
截图在哪里；
下一步是谁处理。
没有这些字段，任务失败后只能靠人回忆。
而回忆不是工程能力。
七、状态流转不要只有 success 和 failed
很多浏览器任务一开始只有两个状态：
success
failed
这对简单脚本可能够用。
但对团队任务不够。
更合理的状态流转可以是：
ready -> running -> evidence_saved -> need_review -> retry_ready -> completed
-> failed
ready：上下文检查完成。
running：任务执行中。
evidence_saved：失败现场已保存。
need_review：需要人工判断。
retry_ready：复核完成，可以重试。
completed：任务完成。
failed：任务终止。
这个状态流转的价值在于：
接手人看到 need_review，就知道不要直接重跑。
看到 retry_ready，才知道可以进入下一次执行。
看到 evidence_saved，才知道失败现场已经保留。
状态不是为了形式化。
状态是为了减少团队沟通成本。
八、AI Agent、RPA、脚本和人工复核要分边界
很多团队开始把 AI Agent、RPA、脚本放进浏览器任务。
但能力越多，边界越重要。
一个更稳的分工是：
API 适合结构化、官方支持的任务。
脚本适合规则明确、流程稳定的任务。
RPA 适合固定路径和重复点击。
AI Agent 适合读取页面、整理信息、生成异常摘要。
人工复核适合不确定判断、重要提交、权限变更和异常确认。
不要问：
AI 能不能替代所有操作？
应该问：
这个步骤适合交给谁？
能 API 完成的，不要让 AI 猜。
能脚本稳定执行的，不要强行大模型化。
不确定状态下，不要自动继续。
涉及责任判断时，进入人工复核。
九、建议增加 precheck 阶段
自动化任务开始前，建议加一个 precheck。
precheck -> running -> evidence_saved -> need_review -> retry_ready -> completed
precheck 至少检查：
account_id 是否明确
profile_id 是否正确
network_label 是否最近变更
session_state 是否 valid
current_url 是否符合预期
page_state 是否 normal
last_task_status 是否允许继续
如果任意一项不确定，任务不应该进入 running。
可以直接进入：
blocked -> evidence_saved -> need_review
这一步会牺牲一点执行速度。
但能换来更低的复盘成本。
浏览器自动化不是越快越好。
它要可控。
十、这份检查最好沉到工作流里
如果团队只有一个人操作，简单备注和脚本日志可能够用。
但一旦多人协作，信息分散会很快变成问题。
常见情况是：
Profile 在工具里；
网络配置在表格里；
任务日志在脚本里；
截图在群聊里；
复核意见在私聊里；
下一步动作没人记录。
这些信息单独看都存在。
但没有形成上下文。
更合理的方式，是把 Account、Profile、Network、Session、PageState、TaskRun、Evidence 和 Review 放在同一个工作流里。比如 浏览器任务上下文工作流 这类方案，重点不是替代 Playwright、RPA、API 或人工判断，而是让团队能在同一个上下文里看见环境状态、任务过程和失败证据。
十一、工程 Checklist
Account
- 是否有 account_id；
- 是否能对应业务账号；
- 是否有 owner；
- 是否能看到当前状态。
Profile
- 是否有 profile_id；
- 是否记录 last_operator；
- 是否绑定 network_label；
- 是否有 next_action；
- 是否能被接手人理解。
Network
- 是否记录 region；
- 是否记录 timezone；
- 是否记录 language；
- 是否记录 updated_by；
- 是否记录 review_status。
Session
- 是否区分 Cookie 和 Session；
- 是否记录 session_state；
- 是否保存 current_url；
- 是否标记 page_state；
- 不确定时是否进入 need_review。
TaskRun
- 是否有 run_id；
- 是否记录 step_name；
- 是否记录 current_url；
- 是否保存 screenshot；
- error_message 是否可读；
- next_action 是否明确。
Evidence
- 是否和 run_id 绑定；
- 是否包含截图；
- 是否包含 URL；
- 是否包含错误信息；
- 是否能被接手人找到。
Review
- 是否有复核人；
- 是否有复核结论；
- 是否能决定 retry_ready 或 failed；
- 是否沉淀处理经验。
总结
Profile 已打开，不代表任务上下文可以继续。
从工程角度看，Profile 只是运行上下文的一部分。
真正要判断的是：
Account 是否正确；
Network 是否一致；
Session 是否可继续；
PageState 是否符合预期；
TaskRun 是否留下过程；
Evidence 是否可复盘；
Review 是否能接上下一步。
如果这些对象没有连起来，自动化任务失败后就只能靠猜。
如果它们能进入同一个工作流，浏览器任务才更容易被追踪、交接和复盘。
