指纹浏览器都用了，为什么任务还是要人盯着？

很多团队上了指纹浏览器以后，会发现一个有点尴尬的问题：

环境确实稳定了一些。

账号也能按 Profile 隔离。

Proxy、Cookie、LocalStorage 也能更清楚地管理。

但每天还是要有人打开页面、看状态、点按钮、确认结果。

这说明一个问题：

指纹浏览器解决的是环境层，不是任务层。

如果没有任务编排、状态机和证据链，系统还是离不开人盯页面。

1. 指纹浏览器解决的是"在哪跑"

指纹浏览器的价值是把浏览器运行环境管起来。

它解决的问题大概是：

能力	解决的问题
Profile 管理	不同账号使用独立浏览器环境
Session 保留	Cookie、LocalStorage、IndexedDB 等状态可持续
Proxy 绑定	网络出口、地区策略和账号环境匹配
Browser Config	时区、语言、UA、插件配置更稳定
环境隔离	避免账号之间状态混用
团队交接	工作区和 Profile 关系更清晰

这些能力很重要。

但它们主要回答的是：

text 复制代码

任务应该在哪个浏览器环境里执行？

它没有自动回答：

text 复制代码

任务应该怎么执行？
执行到哪一步了？
页面状态对不对？
失败了能不能重试？
什么时候必须暂停？
谁来复核结果？

这就是为什么有了指纹浏览器，任务仍然可能需要人盯着。

2. 任务真正需要的是状态机

很多浏览器任务看起来只是几个点击动作。

但工程上，它更像一个状态机。

例如一个最简单的任务可以有这些状态：

ts 复制代码

type TaskStatus =
  | "created"
  | "preflight_checking"
  | "running"
  | "waiting"
  | "paused"
  | "review_required"
  | "retrying"
  | "finished"
  | "failed";

如果没有状态机，任务就只有两种状态：

text 复制代码

人在点
或者没人点

这显然不够。

任务需要知道自己现在处于哪个阶段。

是环境检查中？

是执行中？

是等待页面加载？

是出现了异常？

是需要人工复核？

还是已经完成？

没有这些状态，自动化系统就很难替人盯页面。

3. 任务开始前不能直接跑

指纹浏览器提供了 Profile，但任务开始前仍然要做 Preflight Check。

至少要检查：

检查项	通过标准
Profile 是否固定	task.profile_id 与 workspace 主 Profile 一致
Cookie 是否可用	登录态正常，未过期
LocalStorage 是否完整	关键配置字段存在
IndexedDB 是否完整	本地队列和业务状态可读
Proxy 是否一致	地区、时区、语言匹配
页面入口是否可达	URL 可访问，页面标题符合预期

如果这些条件不满足，任务不应该继续执行。

否则就是把错误环境交给自动化流程。

这也是为什么单纯有指纹浏览器还不够。

环境存在，不代表环境可用。

4. 每一步都要有 State Check

浏览器自动化最容易踩的坑是：

只判断动作有没有执行，不判断执行后状态是否正确。

比如：

按钮确实点了。

但页面没有跳转。

输入框确实填了。

但提交时出现了错误提示。

任务确实执行完了。

但中途出现过安全验证。

所以每个步骤都应该有 State Check。

例如：

ts 复制代码

type TaskStep = {
  stepId: string;
  action: "open" | "click" | "input" | "submit" | "extract" | "verify";
  target: string;
  expectedUrl?: string;
  expectedTitle?: string;
  expectedElement?: string;
  timeoutMs: number;
};

这一步解决的是：

text 复制代码

不是只看有没有点，而是看点完以后是不是对的。

5. Evidence 决定能不能少盯

如果没有证据链，人就必须一直盯着。

因为出了问题以后没人知道当时发生了什么。

每个关键步骤建议保存 StepEvidence：

字段	说明
step_id	步骤编号
action	执行动作
target	操作目标
url	当前页面 URL
page_title	页面标题
before_screenshot	操作前截图
after_screenshot	操作后截图
assertion	预期状态
result	实际结果
reason	Agent 或脚本判断理由

有了这些证据，人工不需要一直盯着全过程。

只需要在异常或不确定时查看证据。

这就是 Evidence 的价值。

它不是为了多存几张截图。

而是为了让任务从"人工盯现场"变成"异常时可复盘"。

6. FailureReason 要分类

任务失败后，如果只返回一个 error，人还是要打开页面看。

更合理的是分类：

failure_type	含义	处理建议
session_invalid	会话不可用	检查 Cookie、LocalStorage、IndexedDB
env_mismatch	环境不匹配	检查 Profile、Proxy、时区、语言
page_changed	页面结构变化	保存截图，确认是否改版
action_timeout	操作超时	检查网络、等待策略、页面加载
security_verification_required	需要安全验证	暂停任务，人工完成官方验证
agent_uncertain	Agent 判断不确定	保存证据，进入人工复核

有了 FailureReason，系统才能决定下一步：

可以重试？

应该暂停？

需要人工确认？

还是直接失败？

7. RetryPolicy 和 PausePolicy 要分开

很多脚本失败后只会重试。

但浏览器任务里，不是所有失败都适合重试。

比如页面加载慢，可以重试。

但登录态失效、安全验证、环境快照不一致，就不应该盲目重试。

可以这样拆：

ts 复制代码

type RetryPolicy = {
  maxRetries: number;
  retryAllowedFor: string[];
};

type PausePolicy = {
  pauseImmediatelyFor: string[];
  reviewRequiredFor: string[];
};

示例：

ts 复制代码

const retryPolicy: RetryPolicy = {
  maxRetries: 2,
  retryAllowedFor: ["action_timeout"]
};

const pausePolicy: PausePolicy = {
  pauseImmediatelyFor: [
    "security_verification_required",
    "session_invalid",
    "env_mismatch"
  ],
  reviewRequiredFor: ["agent_uncertain"]
};

这样任务不再是"失败就继续试"。

而是按风险分支处理。

8. 人工复核不是失败，而是流程的一部分

真正成熟的自动化系统，不会试图把所有事情都自动做完。

它会把低风险、重复性的事情自动化。

把高风险、不确定的事情交给人工复核。

场景	是否建议人工复核
只读页面巡检	可选
修改配置	建议
提交表单	建议
删除或覆盖数据	必须
Agent 判断不确定	必须
环境快照不一致	必须暂停

这也是为什么 ReviewQueue 很重要。

它不是让人继续每天盯页面。

而是让人只处理真正需要判断的分支。

9. 一个完整任务链路

可以把任务链路设计成：

text 复制代码

Scheduler
  -> Load Workspace/Profile
  -> Preflight Check
  -> Run State Machine
  -> Save StepEvidence
  -> Classify FailureReason
  -> Retry / Pause / Review
  -> Save RunTrace

这条链路里，指纹浏览器提供环境基础。

任务编排负责流程执行。

状态机负责阶段管理。

Evidence 负责复盘。

ReviewQueue 负责高风险分支。