应用场景、RPA

• 设计检查点保存
• 管理凭证状态
• 实现幂等防重

跨网站表单流程需通过检查点、凭证状态和幂等标识避免重复提交。检查点：在每个关键步骤（表单填充后、提交前、提交后）保存状态快照（已填数据、当前 URL、步骤位置），失败时可从检查点恢复，不重头开始。凭证状态：记录登录态、会话状态，跨步骤/跨站点保持，避免因登录失效导致重复输入。幂等标识：为每次提交生成唯一业务标识（如订单号、请求 ID），提交时携带该标识，服务端/Agent 侧检查是否已处理过，避免重复提交同一操作；Agent 侧记录已提交的标识，重试时检测到已提交则跳过。异常处理：提交前检查幂等标识，提交后验证结果（成功响应、订单号），若不确定是否已提交（网络超时），用幂等标识查询而非重复提交。跨站点还要注意各站点独立的幂等机制。

防重复提交的核心是"检查点 + 幂等"。检查点支持恢复，凭证状态保持连续性，幂等标识保证重复执行不产生重复副作用，三者结合避免重复提交。

• 理解流程自动化边界
• 区分可自动化与需人工步骤
• 设计人机分工

客服、销售、采购流程中，应区分可自动化与需人工的步骤。可自动化：数据录入与抓取（客户信息、订单、库存读取）、表单填写、状态查询、通知发送、邮件/消息的初筛与分类、报表生成、常规操作（如状态更新、批量操作）。这些步骤确定、可验证、低风险。必须保留人工判断：涉及重大决策的（价格谈判、折扣审批、合同条款）、高风险变更（付款、退款、删除、信用调整）、需要同理心与判断的客户沟通（复杂投诉、情绪化客户）、异常与边界情况（超预算、异常订单、合规风险）、需要法律/合规判断的。分工原则：自动化处理确定性、可重复的步骤，人工负责判断、决策、异常与高风险操作；自动化提供数据与候选，人工做最终决策。用"自动化 + 人工审批"的混合模式，既能提效又守住判断边界。

分工的核心是"确定性自动化、判断性留人"。录入、查询、通知等可自动化，决策、审批、高风险、复杂沟通需人工，自动化提供支撑、人工做决策。

• 设计降级链
• 理解降级目标
• 实现重试策略

当 Browser Use 失败时，应设计多级降级链。页面不可用（站点宕机、接口 500）：降级到稍后重试——按指数退避重试，或进入延迟队列，等待站点恢复；若长时不可用，转人工通知。选择器失效（DOM 变化）：降级到脚本——用确定性脚本（Playwright 重定位、备用选择器）尝试，或重新采样页面对比新旧结构；若脚本也无法处理，转人工队列。模型连续失败（多次推理失败）：降级到人工队列——把任务进入人工处理队列，附上失败上下文（截图、日志、已执行步骤），由人工完成或修复。降级设计原则：按失败类型匹配降级路径，设置重试上限（避免无限重试），降级后记录原因；人工队列作为最终兜底，保证任务不被放弃。降级链为"自动重试 → 脚本重定位 → 人工队列 → 稍后重试"，按场景选择。

降级的核心是"按失败类型分流"。页面不可用稍后重试、选择器失效用脚本、模型失败转人工，每条路径有上限并记录，人工队列兜底保证任务完成。

• 理解 ROI 评估维度
• 权衡成本与收益
• 建立真实 ROI 模型

计算真实 ROI 需综合收益与成本，且不能只看节省时长。收益维度：节省人工时长（自动化节省的人工时间 × 人工成本）、成功率提升（自动化承担的任务价值）、返工减少（自动化正确率的提升减少返工成本）、风险事件避免（自动化降低误操作/合规风险带来的损失）。成本维度：模型调用成本、截图与视觉推理成本、基础设施成本、开发与维护成本、人工接管/纠错成本。真实 ROI 公式：ROI =（节省人工 + 减少返工 + 避免风险损失 − 全部成本）÷ 全部成本。关键是不夸大：只算"真实节省"（扣除人工接管、纠错、维护的成本），把成功率纳入（低成功率会推高返工与人工成本），把风险事件纳入（避免风险损失往往是最大收益）。应建立基准对比（人工完成 vs 自动化完成）的量化数据。

真实 ROI 的关键是"全面核算，不夸大收益"。把成功率的返工、人工接管、风险事件这些隐性成本纳入，才能得到接近真实的 ROI，而非仅算名义节省时长。

• 理解扩展与独立应用的架构差异
• 比较权限、更新、兼容性
• 评估选型

浏览器扩展形式的 Computer Use Agent 与独立应用在多个维度有差异。权限模型：扩展受浏览器扩展权限模型约束（manifest 声明权限，如 tabs、storage、clipboard），权限范围受浏览器限制，能访问页面 DOM 与浏览器 API；独立应用拥有系统级权限（可访问文件系统、桌面、系统调用），权限更广但需单独处理系统授权。更新分发：扩展通过浏览器商店/内部签名分发，更新自动、受商店审核；独立应用需自行分发更新（安装包、自动更新服务），更新流程更可控但更重。浏览器兼容性：扩展受限于浏览器（Chrome/Firefox/Edge 的扩展 API 差异），且可能受浏览器版本影响；独立应用可跨浏览器控制（通过 CDP/Playwright），但需自行处理浏览器集成。适用性：扩展适合"在浏览器内辅助用户"（轻量、权限适中、分发便捷）；独立应用适合"自动化整个浏览器环境"（需要更广权限、跨浏览器、涉及系统操作）。选型按权限需求、分发渠道与浏览器范围决定。

差异的本质是"运行环境与权限边界"。扩展受浏览器约束（权限、分发、兼容），独立应用自主（系统权限、自管分发、跨浏览器），按需求和分发方式选型。

• 理解字段级错误处理
• 设计字段级重试
• 建立人工复核队列

抽取结果与页面不一致时，应做字段级处理而非整任务重跑。字段级重试：对不一致的字段单独重试——重新定位该字段对应的页面元素，重新抽取，或换定位策略（DOM→视觉）重试；只重试失败的字段，成功字段保留，避免重复抽取与成本。校验：对每个字段做校验（值格式、数据范围、与页面的一致性），识别不一致字段。人工复核队列：对多次重试仍不一致的字段，进入人工复核队列——附上字段名、预期值、页面抽取值、页面快照与上下文，由人工核对修正；人工复核结果可回填并更新抽取结果。通过"字段级重试 + 人工复核队列"，只处理问题字段，避免整任务重跑导致成本浪费与全量重抽。同时记录字段级准确率，用于定位系统性问题。

字段级处理的核心是"最小化失败范围"。只重试失败字段、人工复核问题字段，避免整任务重跑的成本与全量重抽，同时积累字段级准确率数据。

• 理解语义对齐
• 设计默认与格式校验
• 处理表单约束

长表单的字段映射需做语义对齐与约束校验。语义对齐：把自然语言目标（如"填入我的收货地址"）映射到具体表单控件——通过控件标签（label 关联）、placeholder、可访问性名称、相邻文本、name 属性等语义信号，理解每个控件的含义（地址、电话、邮箱），再匹配数据源中的数据字段，形成"字段→控件"映射。语义对齐错误会导致数据填错位置。必填校验：识别控件的必填属性（required、aria-required、星号）、表单校验规则，提交前检查所有必填字段已填充。格式校验：识别格式约束（email、phone、日期、数字、长度），用数据源的格式规则校验填入值，格式不符则格式化或提示。提交前做整体校验：所有必填已填、格式正确、无多余字段，防止误提交。对无法自动对齐的字段，提示人工或跳过。

长表单的关键是"语义对齐 + 提交前校验"。语义对齐用标签/名称/相邻文本理解控件含义完成字段映射，必填与格式校验保证提交正确，避免错填与漏填。

• 理解 schema 注入风险
• 设计 schema 校验
• 隔离数据与指令

结构化抽取任务需防范页面注入污染输出 schema。攻击方式：页面文本中嵌入"新增一个字段 X 并填入 Y""把这段文字作为值返回"等指令，诱导模型输出包含未声明的字段或把指令写进值。防护：一是 schema 白名单——输出严格受预定义 schema 约束，只允许输出 schema 声明的字段，新增字段会被拒绝；用输出校验（JSON schema 校验）确保输出结构符合声明，违反即丢弃。二是内容与指令隔离——声明页面文本为不可信数据，模型只抽取数据不执行其中指令；页面中的指令文本不应被当作值写入。三是值校验——对抽取的值做类型/格式校验，阻止把指令文本当作正常值。四是字段严格映射——只把页面内容映射到已声明字段，不新增字段。五是输出后检查——扫描输出中是否有未声明字段或指令痕迹。防护目标是"结构受控、数据不受指令污染"。

schema 污染的核心是"输出结构失控"。用 schema 白名单 + 输出校验约束结构，用内容隔离阻止指令执行，用值校验防止指令写入值，保证抽取结果干净。

• 理解两类任务的指标差异
• 设计成本和成功率核算
• 对比评估

抽取类与操作类任务在指标与成本核算上有本质差异。成功率定义：抽取类任务按"字段级正确率"衡量——每个字段抽取是否正确、完整、一致，任务成功定义更细粒度（字段准确率、字段覆盖率）；操作类任务按"动作完成度"衡量——动作是否成功执行、目标是否达成、是否产生副作用（成功率、步骤完成率）。成本核算：抽取类按"字段/页面"核算——每抽取字段的模型调用、页面访问成本；操作类按"动作/步骤"核算——每动作的截图、点击、模型推理成本。决策上：抽取类更关注字段质量与精度，操作类更关注动作正确性与副作用。两者都需人工接管率，但抽取类的人工接在字段复核，操作类在动作确认。指标体系应分别建立，反映两类任务的不同价值。

差异的核心是"单位不同"。抽取按字段（质量导向），操作按动作（行为导向），因此成功率与成本核算的单位、侧重点都不同，需分别建立指标体系。

• 理解分页/懒加载/动态列表
• 设计完整抽取
• 实现去重

抽取任务遇到分页、懒加载、动态展开列表时，需保证完整性与去重。分页：遍历所有页（点击下一页、读取页码），直到到达最后一页，按页码记录已抽取页，避免重复或遗漏。懒加载：滚动触发加载，逐步滚动直到列表不再增长，等待加载完成再抽，确认所有数据已加载。动态展开列表：点击展开/读取子项，覆盖所有展开层级。完整性：用"数据标识"（唯一 ID、主键）跟踪已抽取数据，确认遍历到末尾（无"下一页"、无加载更多、列表长度稳定）。去重：以唯一标识（订单号、ID、记录 ID）去重，合并跨页/跨层重复数据；对无唯一标识的数据用内容哈希去重。抽取后校验：总记录数、去重后数量、是否含所有页。实现上维护"已抽取标识集合"，避免重复写入。

完整性与去重的核心是"标识跟踪 + 遍历终止判断"。用数据标识跟踪已抽数据，识别遍历终点（无下一页/无加载更多），用唯一标识去重，保证不遗漏不重复。

• 设计 schema 版本管理
• 实现向后兼容
• 处理语义变化

抽取 schema 的版本管理与兼容需保证下游消费方不被破坏。版本管理：给 schema 分配版本号（如 v1、v2），schema 变更时发布新版本，记录变更日志（新增字段、废弃字段、语义变化）。向后兼容：新增字段采用"可选新增"——新字段不破坏旧字段，下游无感；废弃字段先标记 deprecated 再逐步移除，给下游迁移时间。语义变化：字段含义变化（如单位、格式）需显式升级版本并通知下游改造，避免静默破坏。兼容机制：输出 schema 版本化，下游消费时声明其支持的 schema 版本；提供迁移/映射层，把新 schema 映射到旧格式；对解析失败做兼容处理。发布流程：schema 变更走版本评审，配备破坏性变更检测（新字段是否破坏下游解析），并测试下游消费方兼容性。目标：字段新增向后兼容，语义变化显式升级并协调迁移。

schema 兼容的核心是"向后兼容 + 显式升级"。新增字段可选向后兼容，废弃字段渐进迁移，语义变化显式版本升级并通知下游，避免静默破坏消费方。

• 设计提交前校验
• 验证实际填入值
• 防止误提交

表单自动化提交前应校验实际填入值，防止误提交不可逆表单。校验步骤：读取表单中各控件的实际值（而非输入时的意图）——通过 DOM 读取 input/select/contenteditable 的当前值，与预期值比对，确认填入正确；校验必填字段是否都已填充、格式是否正确（email、电话、数字）、无遗漏字段；校验关键字段（金额、收件人、日期）与数据源一致。对不可逆表单（提交、付款、删除）提交前做额外确认：确认目标按钮语义（不是"取消"或"退出"）、弹窗确认、必要时人工审批。提交前整体校验通过的信号是"所有字段值正确、必填齐全、格式合规、目标按钮正确"。校验失败则中止并提示，避免误提交。校验应在"提交前"的强制闸门执行，而非可选的。

防误提交的核心是"提交前校验实际值"。从 DOM 读取真实填入值验证正确性，检查必填与格式，确认目标按钮，把校验作为不可跳过的强制闸门。

• 设计结果与快照关联
• 支持溯源
• 实现审计复核

抽取结果应与页面快照关联以支持溯源。关联字段：为每条抽取结果记录来源信息——URL（来源页面）、时间戳（抽取时间）、DOM 哈希（页面结构指纹）、页面快照（截图/DOM 快照引用）、抽取时的上下文（使用的 schema 版本、模型版本）。这些信息让每条结果可溯源：事后能定位"这条数据来自哪个页面、何时抽取、页面当时的状态"。审计与复核：复核人员可通过关联的快照回到原始状态，核对抽取值是否正确；审计时能验证结果的来源与完整性；出现争议时能回溯。实现上，抽取结果与快照存于同一存储，用任务/记录 ID 关联，快照可脱敏存储。DOM 哈希用于检测页面是否变化（若哈希变化，说明结果可能过期）。目标：每条结果可溯源、可复核、可审计。

溯源的核心是"结果与来源关联"。URL、时间戳、DOM 哈希、快照构成完整来源上下文，让每条结果可溯源、可复核、可审计，支撑事后质检。

• 理解采集技术分层
• 建立首选与兜底关系
• 按场景选型

Web 采集应分层使用：API 作为首选，传统爬虫作为补充，Browser Use 作为兜底。API：当站点提供官方 API 时，优先使用——确定性、稳定、合法、结构化、成本低，是采集的第一选择。传统爬虫（requests/HTML 解析器）：当无 API 但页面结构稳定、数据可静态解析时，用确定性爬虫——高效、低成本、可控，适合稳定页面。Browser Use：当页面复杂（JS 渲染、登录、反爬、动态交互）且无 API、爬虫无法处理时，用 Browser Use——模拟浏览器获取动态渲染内容，但成本高、不稳定。选型原则：能用 API 用 API，能用爬虫用爬虫，最后用 Browser Use。分层还体现在"兜底"关系：API 失败/缺失时降级爬虫，爬虫无法处理动态页面时用 Browser Use。同时 API 与爬虫优先也能降低采集成本与合规风险。

分层采集的核心是"确定性优先"。API 最稳定合法，爬虫其次，Browser Use 应对动态复杂页面作兜底，既降成本又降风险。

• 理解 API/MCP/RAG 与 GUI 的差异
• 论证确定性优先
• 权衡成本与可靠性

能用业务 API、MCP Tool 或 RAG 解决的任务不应优先 GUI 操作，因为 GUI 是最后手段。API：确定性、结构化、稳定、低成本、可测试、可审计，能直接返回数据与执行操作，无 GUI 的解析错误与风险。MCP Tool：把专业能力封装为确定性工具，比 GUI 精确可靠。RAG：通过检索返回知识，比 GUI 抓取更直接、更可控。GUI 操作是概率性的、易受页面变化影响、成本高（截图+模型）、且可能误操作，只在"无 API、无工具、必须通过界面"时使用。选型原则：优先 API/MCP/RAG 等确定性能力，GUI 作为兜底。理由：确定性优先级高（可靠性、可测试性、审计性）、成本低、风险小。GUI 适合"确定性的数据/操作不可得"的场景，而非首选。

核心是"确定性优先"。API/MCP/RAG 提供确定性数据与操作，GUI 是概率性的兜底。能确定性获取就不该用 GUI，避免无谓的成本与风险。

• 理解 Browser Use 的必要场景
• 界定选型依据
• 设计退出条件

在 API 缺失或遗留系统场景，Browser Use 是必要的，因为：遗留系统往往没有现代 API，或 API 不完整、不稳定，只能通过界面操作；数据/操作只能通过网页或桌面交互获得，无法用确定性方式获取。选型依据：确认无 API 或 API 不足以支撑业务、页面交互复杂且需动态处理、任务价值足以覆盖成本与容错。界定退出条件：当出现 API 时切换回 API（厂商开放 API、自建 API）；当页面稳定可静态解析时改用传统爬虫/脚本；当成本过高或成功率不达标时停用或转人工；当出现更稳定的替代方案时退出。退出条件应明确写在方案中，避免"一旦用上就永远用"的陷阱。Browser Use 是"过渡性/兜底"方案，应持续评估是否有更确定性的替代。

Browser Use 的必要性源于"无 API 的世界"。选型依据是"无确定性能力且任务价值够"，退出条件是"确定性能力出现或成本/成功率不达标时切换"，避免长期依赖脆弱方案。

• 理解步骤与时间预算
• 按任务类型设置
• 平衡效果与成本

步骤预算与时间预算应按任务类型调整。步骤预算（最多动作数）：限制 Agent 执行的动作总数，防止无限循环与成本失控。简单任务（单一查询、点击）预算小（如 5~10 步）；复杂任务（多页表单、跨站流程）预算大（如 30~50 步）。时间预算：限制任务总时长，防止长时间卡死。不同类型：交互任务（下单、提交）需严格预算，防止误操作；抽取任务（遍历数据）预算较大但需覆盖完成；长任务（报表）需较大预算但分段。设置原则：预算要"够完成任务 + 留余量"，但不能大到容许失控；超预算即停止并转人工/降级。预算按任务复杂度、历史成功率、成本上限动态调整，并监控超预算率。合理预算平衡"完成率"与"成本/风险"。

预算的核心是"限制失控 + 按复杂度配置"。步骤/时间预算按任务复杂度设置，保证完成任务的同时防失控，超预算触发降级。

• 理解合规审查要素
• 设计上线审查流程
• 管控合规风险

Browser Use 上线前需将网站条款、robots、版权和账号政策纳入合规审查。审查内容：服务条款（ToS）——是否允许自动化访问、数据抓取、用途限制；robots.txt——目标路径是否被禁止爬取；版权——抓取内容是否有版权限制、是否允许复制使用；账号政策——用户名/账号是否允许多开、自动化、是否有封号风险。审查流程：上线前对目标站点做合规清单检查（ToS、robots、版权声明、账号条款），评估抓取/操作是否合规；对高风险站点（严格 ToS、受版权保护、涉及个人数据）设置人工审批门槛；审查结果记录并定期复审（站点条款可能变化）。风控措施：遵守 robots 与速率限制、数据最小化、用途合规、取得授权或使用 API。审查不通过则不上线或改用合规方案。审查是"上线门禁"，防止法律与合规风险。

上线审查的核心是"合规前置"。把条款、robots、版权、账号政策纳入检查清单，高风险站点人工审批，是管控法律风险与封号风险的关键门禁。

• 识别高风险/关键场景
• 理解 API 的确定性优势
• 建立优先级

支付、登录、关键操作等高风险场景应优先用 API 而非 Browser Use。原因：这些场景正确性要求极高、不可逆、涉及资金与安全，Browser Use 的概率性错误（误点、误提交、坐标偏移）会造成严重后果。具体场景：支付——必须用支付 API（确定性、可验证、可审计、支持幂等与退款），GUI 支付易误操作且难审计；登录——用认证 API（OAuth、SSO）确定性且安全，GUI 登录易受验证码、反爬影响且凭证风险高；关键操作——删除、转账、数据修改、发送等，用业务 API 保证事务性、幂等与审计。同理，任何"必须精确、可审计、不可逆、涉及资金/安全"的操作都应优先 API。Browser Use 仅用于无 API 的辅助/读取场景。原则：正确性优先于便利性，关键操作走确定性通道。

优先 API 的核心是"高风险场景必须确定性"。支付、登录、关键操作涉及资金与安全，API 提供确定性、幂等、审计，Browser Use 的概率性错误不可接受。

• 理解账号关联风险
• 设计隔离与指纹管理
• 规避风控

多账号、多租户场景下避免账号关联被平台风控，核心是"隔离与去指纹关联"。隔离：每个账号使用独立浏览器上下文/实例（独立 Cookie、存储、会话），绝不在同一上下文切换账号；每个租户独立执行环境，隔离数据与凭证。指纹管理：避免浏览器指纹（User-Agent、Canvas、WebGL、时区、字体、语言、IP）一致导致账号关联；为不同账号配置不同的指纹或至少避免相同指纹被识别为同一人。IP 管理：不同账号使用不同出口 IP（代理池），避免同一 IP 关联多账号；注意 IP 滥用的风控风险。行为隔离：注意账号的登录时间、操作频率、行为模式，避免异常批量行为触发风控。合规：遵守平台账号政策，避免恶意多开。架构上，用"一账号一环境 + 指纹/IP 隔离 + 行为合规"降低关联风险。

账号关联的核心是"指纹/IP/行为关联"。独立上下文隔离数据，指纹/IP 隔离降低技术关联，行为合规避免触发风控，且需遵守平台政策。

• 理解两者的能力对比
• 比较稳定性、适应、审计、维护
• 建立选型依据

Browser Use 与 UiPath 等 RPA 在多维度有差异。页面稳定性：RPA 基于确定性选择器，对稳定页面高度稳定、可重复；Browser Use 概率性，对稳定页面也能生成一致结果但非绝对确定。长尾适应：RPA 对页面改版脆弱，选择器失效即失败；Browser Use 用语义/视觉定位，能适应页面变化与长尾页面，泛化能力强。审计：RPA 有成熟的企业审计（流程记录、版本控制、合规认证）；Browser Use 审计较新，需自行构建审计体系。维护成本：RPA 维护成本高（页面改版需重录选择器/流程），Browser Use 维护成本相对低（语义定位抗变化），但模型/推理成本高。选型：稳定、核心、可重复流程用 RPA（高可靠、成熟审计）；变化频繁、长尾、需泛化流程用 Browser Use（低维护、抗变化）。两者可混合。

对比的核心是"确定性与泛化的权衡"。RPA 稳定但脆弱于变化、维护成本高；Browser Use 泛化强但概率性、模型成本高。按流程稳定性与变化频率选型。

• 设计企业内的分工
• 理解共存模式
• 建立统一治理

模型驱动的 GUI 操作与传统 RPA 应分工共存、统一治理。分工：稳定、高频、可重复的核心流程（财务结账、数据同步、报表）用 RPA——确定性、可审计、成熟；变化频繁、长尾、需理解与异常处理的流程（动态页面、复杂决策、异常场景）用 GUI Agent——泛化、抗变化。共存模式：RPA 作为主流程，GUI Agent 作为 RPA 的智能补充（RPA 选择器失效时降级到 Agent 重新识别）；或用编排层统一调度两者，按流程特性路由。统一治理：共享编排、调度、审计、监控、权限体系；统一的日志与审计（无论 RPA 还是 Agent 都记录）、统一的凭据管理、统一的风险审批。分工原则：能确定性用 RPA，需要智能用 Agent，两者通过统一平台协同，避免各自为政与重复建设。

共存的核心是"确定性分工 + 统一治理"。RPA 管稳定流程，Agent 管长尾智能，统一编排、审计、权限治理，让两者协同而非冲突。

• 设计输出 schema
• 校验字段级置信度
• 处理低置信字段

结构化抽取需定义输出 schema 并校验字段级置信度。schema 定义：用结构化 schema（如 JSON Schema、TypeScript 类型）声明目标字段、类型、必填/可选、允许枚举，让模型按 schema 抽取，输出受约束。字段级置信度：对每个字段评估抽取置信度——基于模型对值的确定性、来源匹配度（页面值与字段语义一致）、数据完整性（非空、格式正确）；可为每个字段输出置信度分数。低置信字段处置：低置信字段不应直接静默接受，处置策略包括：字段级重试（重新定位/抽取该字段）、标记待人工复核（进入人工队列，附上下文）、阈值过滤（低于置信度阈值则标记为不确定而不写入）、按需重抽（高重要性字段强制复核）。目标：schema 保证结构，置信度保证质量，低置信字段走重试/复核而非盲信，避免错误值进入下游。

schema 与置信度是"结构 + 质量"双保障。schema 约束输出结构，置信度量化字段质量，低置信字段用重试/人工复核处置，防止错误值传播。