基于浏览器扩展的AI代操作开发实践教程

教程目标

本教程的目标是帮助读者完成一个最小可用且安全可控的方案：在用户明确授权的条件下，让AI助手能够复用当前浏览器会话，并在目标网页中执行点击、输入、滑动、表单提交、信息提取、跨页面整合等操作。

最终要实现的效果不是简单抓取公开网页数据，而是在真实登录环境中，以“用户授权、代理执行、过程可审计、风险可控制”的方式完成网页任务。也就是说，AI不是脱离用户身份单独行动，而是在用户许可范围内，借助浏览器扩展和本地安全代理，代表用户完成具体网页操作。

本教程适合以下读者：

• 前端开发工程师、全栈开发工程师；
• 浏览器扩展开发者；
• 自动化测试工程师；
• 运维人员、效率工具建设人员；
• 技术负责人、企业数字化平台负责人；
• 需要建设内部AI操作能力的企业用户。

适用场景

在正式开发前，需要先明确适用场景。浏览器代操作能力并不适合所有网页自动化需求，尤其应避免用于绕过权限、绕过风控、批量注册、违规抓取等场景。较合适的场景包括：

1. 内部系统重复操作
   例如定期填写报表、提交工单、更新台账、维护配置项等。此类任务步骤固定、规则清晰，适合由AI辅助完成。

2. 登录后的数据整理
   例如从内部后台导出指标、复制摘要、汇总多页面信息，再交给AI进行结构化整理。

3. 运维辅助操作
   例如查询服务状态、确认工单进度、检查告警页面、提交变更申请等。此类场景通常涉及登录态和内部权限，需要严格审计。

4. 业务流程测试
   在测试环境中使用真实账号验证页面流程，例如表单提交、状态流转、按钮可用性、提示信息是否正确。

5. 跨页面信息整合
   AI可以在多个已授权页面之间切换，提取关键字段，并生成结构化结果。

需要特别强调：本方案应建立在用户拥有账号、拥有访问权限、并且明确同意AI执行操作的前提下。对于涉及支付、删除、权限变更、对外发送等高风险动作，应默认要求人工确认。

核心原理

要让AI像用户本人一样操作浏览器，不能只依赖页面抓取或简单脚本，而应建立分层架构。推荐采用以下三层结构：

1. 扩展运行时层

该层运行在浏览器中，是AI与网页之间的执行入口。它负责：

• 监听用户授权；
• 识别当前页面；
• 访问页面DOM；
• 执行点击、输入、选择、滚动等动作；
• 读取任务所需的页面内容；
• 将执行结果返回给本地代理。

扩展运行时层不应直接访问与任务无关的页面，也不应读取全部Cookie或历史记录。

2. 本地安全代理层

该层运行在用户本机，负责协调AI任务与浏览器扩展之间的通信。它承担以下职责：

• 接收AI任务请求；
• 校验任务是否来自本机；
• 校验任务是否在用户授权范围内；
• 管理任务生命周期；
• 控制执行频率；
• 记录审计日志；
• 在任务结束后清理临时会话。

本地安全代理应避免将用户Cookie、登录凭据、页面敏感内容直接上传到远端。若企业有统一日志和监控需求，可将脱敏后的审计日志写入企业日志服务。

3. 任务适配层

该层负责把自然语言或结构化任务转换成可执行的网页操作步骤。例如：

• “帮我创建一个测试工单”；
• “查询本周服务状态并汇总”；
• “下载最近一次报表并提取关键字段”。

任务适配层需要将任务拆解为步骤序列，包括目标页面、操作类型、目标元素、输入内容、成功判据和异常处理方式。

前置准备

在开始实现前，需要准备以下基础条件：

1. 支持扩展机制的桌面浏览器
   浏览器需要支持加载本地扩展、执行内容脚本、访问当前标签页，并具备存储和消息通信能力。

2. 前端开发基础
   需要理解DOM、事件机制、异步通信、页面存储、跨窗口通信、动态渲染页面等概念。

3. 本地服务能力
   需要能够在本机运行一个轻量代理服务，用于接收AI任务、转发扩展执行、回收结果。

4. 测试账号与测试环境
   建议使用可重置的测试账号，避免在生产账号上直接实验。若必须访问生产环境，应设置更严格的审批和审计机制。

5. 目标页面结构信息
   需要提前确认目标页面包括：

   • 登录页地址；
   • 任务入口页面；
   • 表单字段名称；
   • 按钮文本；
   • 成功提示；
   • 失败提示；
   • 是否需要验证码或二次验证；
   • 是否存在iframe、弹窗、懒加载、动态列表等复杂结构。

6. 明确权限边界
   只申请完成任务所必需的权限。例如，如果只需要操作一个内部站点，就不应申请所有网站的访问权限。

实施步骤

步骤一：定义任务边界与权限清单

首先要做的不是写代码，而是明确AI允许做什么、不允许做什么。

需要定义的内容包括：

• 允许访问的站点域名；
• 允许访问的页面路径；
• 允许执行的动作；
• 禁止执行的动作；
• 是否需要人工确认；
• 会话有效期；
• 日志保留周期。

示例配置：

{
  "allowSites": ["https://<目标站点域名>"],
  "allowActions": ["read", "click", "type", "submit", "extract"],
  "denyActions": ["delete", "permissionChange"],
  "sessionPolicy": "explicitUserGrant"
}

该步骤的作用是建立最小权限模型。AI只能访问用户明确授权的站点，只能执行白名单动作，不能随意修改权限、删除数据或触发敏感操作。

注意事项：

• 不要为了开发方便申请全量站点权限；
• 不要默认允许所有点击和提交；
• 对高风险动作应单独标记；
• 权限清单应可配置，而不是硬编码在代码中。

步骤二：设计登录态复用方案

浏览器扩展的最大优势之一，是可以在用户已登录的浏览器上下文中运行。因此，登录态复用应优先考虑“复用当前会话”，而不是提取和传输凭证。

推荐方案：

• 由用户在浏览器中正常登录；
• 扩展在用户授权后访问当前页面上下文；
• 操作执行时直接复用当前会话；
• 不读取、不记录、不上传明文密码；
• 不主动解析高敏感Cookie；
• 若遇到验证码、二次验证、设备验证，应暂停任务并提示用户人工处理。

不推荐方案：

• 将Cookie复制到远端服务；
• 将登录凭证保存到本地明文文件；
• 将页面完整HTML上传到外部系统；
• 在日志中输出请求头或认证字段。

该步骤的核心是降低凭据泄露风险。AI操作应建立在用户真实会话之上，而不是把用户身份数据转移到不可控环境中。

步骤三：搭建扩展骨架

扩展是执行网页操作的核心载体。一个最小扩展通常包括以下部分：

1. 扩展清单文件
   用于声明扩展名称、版本、权限、后台脚本、内容脚本、匹配站点等基础信息。

2. 后台脚本
   负责扩展生命周期管理、消息中转、任务状态维护、与本地代理通信。

3. 内容脚本
   注入到目标页面中，负责读取DOM、定位元素、执行点击和输入、提取页面内容。

4. 本地存储
   用于保存任务状态、临时配置、用户授权状态等。

5. 消息通信模块
   用于扩展后台、内容脚本和本地代理之间传递任务与结果。

扩展清单示例：

{
  "name": "Authorized Web Assistant",
  "version": "0.1.0",
  "permissions": ["storage", "activeTab", "scripting"],
  "background": { "service": "background.js" },
  "contentScripts": [
    {
      "matches": ["https://<目标站点域名>/*"],
      "js": ["content.js"]
    }
  ]
}

该配置的含义是：扩展只匹配目标站点，不作用于所有网页；后台负责任务管理；内容脚本负责页面操作；存储权限用于保存必要状态。

注意事项：

• 不要申请与任务无关的权限；
• 内容脚本应运行在隔离环境，避免直接污染页面全局变量；
• 后台脚本应保持无状态或轻状态，任务状态最好集中管理；
• 扩展版本更新时，应保留任务日志和配置兼容性。

步骤四：建立本地安全代理

本地安全代理是AI与浏览器扩展之间的受控桥梁。其作用是避免AI直接访问浏览器内部能力，也避免扩展直接暴露给外部网络。

本地代理应具备以下能力：

• 只监听本机回环地址；
• 校验请求来源；
• 使用一次性会话令牌；
• 校验动作是否在白名单内；
• 控制任务超时；
• 支持取消任务；
• 记录审计日志；
• 在任务结束后释放会话。

伪代码示例：

on_task_request(request):
  if not is_local_request(request):
    reject("仅允许本机请求")
  if not valid_token(request.token):
    reject("令牌无效或已过期")
  if not in_allowlist(request.action):
    reject("动作不在允许范围内")
  task = create_task(request)
  wait_user_confirmation(task)
  if user_confirms(task):
    dispatch_to_extension(task)
    result = wait_result(task)
    audit_log(task, result)
    return result
  else:
    cancel_task(task)

该步骤的作用是建立安全边界。AI任务不能绕过本地代理直接操作浏览器，扩展也不能无条件执行所有请求。

步骤五：实现页面结构解析与元素定位

网页操作的关键难点之一是元素定位。页面可能使用动态类名、随机ID、iframe、Shadow DOM、懒加载列表等结构，因此不能只依赖固定CSS选择器。

推荐采用多级定位策略：

1. 稳定属性优先
   例如表单字段名称、按钮文本、ARIA标签、测试标识等。

2. 文本匹配辅助
   当按钮文本稳定时，可通过文本定位按钮，例如“提交”“保存”“查询”。

3. 上下文约束
   如果页面存在多个相同按钮，需要结合所在表单、区域标题、列表行内容进行约束。

4. 可见性判断
   元素必须存在、可见、可点击，并且未被弹窗遮挡。

5. 降级定位
   当主选择器失效时，可尝试文本、位置、语义角色等降级策略。

示例流程：

locate_element(task):
  candidates = find_by_selector(task.selector)
  if candidates is empty:
    candidates = find_by_text(task.text)
  if candidates is empty:
    candidates = find_by_role(task.role)
  scored = rank_candidates(candidates, task.context)
  return choose_best(scored)

注意事项：

• 不要依赖随机生成的类名；
• 不要在多个相似元素中盲目点击第一个；
• 对重要操作应显示元素描述，供用户确认；
• 页面改版后应能重新学习元素，而不是直接失败。

步骤六：封装原子操作动作

为了让AI操作可审计、可重试、可控制，应将网页操作封装为原子动作。常见动作包括：

• 打开页面；
• 等待元素；
• 点击；
• 输入；
• 清空；
• 下拉选择；
• 勾选；
• 滚动；
• 提取文本；
• 提交表单；
• 等待成功提示；
• 截图或生成页面摘要。

每个动作都应有统一接口，便于记录日志和判断结果。

伪代码示例：

perform_step(step):
  if step.type == "click":
    element = locate(step.selector)
    assert_visible(element)
    assert_enabled(element)
    log("click", element.description)
    click(element)
  if step.type == "type":
    element = locate(step.selector)
    clear(element)
    type(element, mask_sensitive(step.text))
    assert_value(element, step.text)
  if step.type == "submit":
    if requires_confirmation(step):
      show_confirmation(step)
    click(submit_button)
    wait_for_result(step.success_text)

注意事项：

• 点击前检查按钮是否可用；
• 输入前检查字段是否允许编辑；
• 提交前检查必填项是否完整；
• 对敏感字段进行脱敏显示；
• 操作之间加入合理等待，避免过快触发风控；
• 不要自动重复提交表单。

步骤七：加入审批、灰度与人工接管

浏览器代操作的风险不仅是技术风险，也包括业务风险。例如误提交表单、误修改配置、误触发通知等。因此，应加入审批和人工接管机制。

建议按环境分级：

环境	推荐策略
开发环境	可自动执行，但必须限制测试账号
测试环境	半自动执行，关键动作需确认
预发环境	重要动作必须人工确认
生产环境	高风险动作必须人工确认并留痕

需要支持的控制能力包括：

• 暂停任务；
• 终止任务；
• 回退到上一步；
• 查看当前步骤；
• 查看将要执行的动作；
• 修改输入内容；
• 手动接管浏览器；
• 记录人工接管原因。

该步骤的目的是让AI成为辅助执行者，而不是不受控的自动操作主体。

步骤八：日志审计与敏感信息保护

任何涉及账号、页面内容、表单提交的操作，都应记录审计日志。但日志内容必须经过脱敏和最小化。

建议记录：

• 任务ID；
• 创建时间；
• 结束时间；
• 站点域名；
• 页面路径；
• 动作类型；
• 执行结果；
• 错误码；
• 耗时；
• 是否需要人工确认；
• 是否发生人工接管。

不建议记录：

• 密码；
• 验证码；
• 完整Cookie；
• 完整请求头；
• 身份证号；
• 手机号；
• 银行卡号；
• 完整表单内容；
• 未脱敏的业务敏感数据。

日志可根据企业需求保存在本地或写入企业日志服务。例如，在百度智能云等通用云环境中，可结合日志服务、监控告警、对象存储等通用能力进行集中分析，但前提是完成脱敏并符合企业安全规范。

步骤九：结果回传与异常补偿

任务完成后，AI需要得到结构化结果，而不是只得到“成功”或“失败”两个字。结果应包括：

• 任务ID；
• 执行状态；
• 成功步骤；
• 失败步骤；
• 错误原因；
• 页面提示；
• 提取数据；
• 是否需要人工处理；
• 建议下一步动作。

常见成功判据：

• 页面跳转至成功页面；
• 页面出现成功提示；
• 数据列表中新增记录；
• 导出文件已生成；
• 状态字段发生变化；
• 后端状态查询确认成功。

异常补偿策略：

• 网络超时：等待后重试一次；
• 元素未出现：刷新页面或重新定位；
• 表单校验失败：根据提示修正字段；
• 登录失效：暂停并提示用户重新登录；
• 权限不足：终止任务并记录原因；
• 重复提交风险：停止自动重试，转人工确认。

配置说明

为了让方案更易维护，应将关键行为配置化。以下为常见配置项及其含义：

1. siteAllowlist：站点白名单
   限定扩展可操作的站点。建议按域名和路径控制，而不是开放全部站点。

2. actionAllowlist：动作白名单
   限定允许执行的动作。例如只允许读取、点击、输入、提取，不允许删除或修改权限。

3. confirmationLevel：确认级别
   可取自动执行、执行前确认、人工接管等模式。生产环境建议采用更严格模式。

4. timeoutMs：单步超时时间
   控制每个动作的等待时间。可根据页面加载速度调整，常见范围为数秒到十几秒。

5. retryLimit：最大重试次数
   控制失败后的自动重试次数。对于提交类动作，应避免自动重复重试。

6. rateLimit：操作频率限制
   控制单位时间内的点击、请求、提交次数，避免触发目标站点风控。

7. logLevel：日志级别
   开发环境可使用详细日志，生产环境建议使用信息级或警告级日志。

8. sensitiveFields：敏感字段规则
   用于识别和脱敏密码、手机号、邮箱、身份证号等字段。

9. sessionTTL：会话有效期
   控制授权会话存在时间。任务结束后应及时销毁临时会话。

10. auditRetention：审计日志保留周期
    根据企业合规要求配置日志保留时间。

示例说明

下面给出一个通用任务定义示例。该任务用于创建一个测试工单，实际使用时需要替换为业务系统中的真实页面和字段。

{
  "task": "创建测试工单",
  "steps": [
    { "type": "open", "url": "https://<目标站点域名>/ticket/create" },
    { "type": "waitFor", "selector": "[name='title']" },
    { "type": "type", "field": "title", "value": "自动化测试工单" },
    { "type": "select", "field": "priority", "value": "P3" },
    { "type": "click", "text": "提交" },
    { "type": "waitFor", "text": "创建成功" },
    { "type": "extract", "field": "ticketId" }
  ]
}

执行流程如下：

1. 用户发起任务；
2. 扩展检查当前页面是否在白名单内；
3. 本地代理生成任务ID；
4. 用户确认任务；
5. 内容脚本打开目标页面；
6. 等待标题字段出现；
7. 输入标题；
8. 选择优先级；
9. 点击提交；
10. 等待成功提示；
11. 提取工单ID；
12. 返回结果并记录日志；
13. 若失败，返回失败步骤和页面提示。

该示例体现了一个重要原则：任务不是简单一段脚本，而是由可验证的步骤组成。每一步都应有明确的前置条件、执行动作和成功判据。

结果验证

完成开发后，需要从多个维度验证方案是否可用。

1. 功能验证

检查AI是否能够完成目标操作：

• 是否能打开正确页面；
• 是否能找到目标元素；
• 是否能正确输入内容；
• 是否能提交表单；
• 是否能判断成功；
• 是否能提取结果。

2. 权限验证

检查权限边界是否生效：

• 非白名单站点是否被拒绝；
• 未授权动作是否被拦截；
• 过期会话是否无法执行；
• 未确认任务是否会停止；
• 高风险动作是否要求人工确认。

3. 安全验证

检查敏感信息是否得到保护：

• 日志中是否没有明文密码；
• 日志中是否没有完整Cookie；
• 本地代理是否未暴露公网；
• 令牌是否一次性使用；
• 任务结束后临时数据是否清理。

4. 稳定性验证

检查方案是否适合长期使用：

• 连续执行多次是否稳定；
• 页面加载慢时是否会误判失败；
• 元素改版后是否可降级定位；
• 网络波动时是否有重试机制；
• 长时间任务是否支持暂停和终止。

5. 体验验证

检查用户是否能够理解并控制AI行为：

• 用户是否能看到当前任务步骤；
• 用户是否能提前确认高风险动作；
• 用户是否能随时终止任务；
• 用户是否能查看审计记录；
• 失败后是否有清晰提示。

常见问题与排查

1. 登录状态失效

可能原因：

• 会话过期；
• 账号在其他设备登录；
• 目标站点启用了单点登录；
• Cookie属性限制；
• 用户主动退出登录。

排查思路：

• 提示用户重新登录；
• 检查会话有效期；
• 检查扩展是否运行在正确浏览器上下文；
• 避免频繁切换账号；
• 对需要二次验证的场景暂停任务。

2. 找不到目标元素

可能原因：

• 页面改版；
• 元素位于iframe中；
• 元素位于Shadow DOM中；
• 页面尚未完成渲染；
• 选择器过于依赖动态类名。

排查思路：

• 使用文本、角色、字段名等稳定特征定位；
• 增加等待机制；
• 检查是否需要进入iframe；
• 更新元素选择器；
• 记录页面结构快照，便于后续修复。

3. 操作被目标站点拦截

可能原因：

• 操作频率过高；
• 行为过于机械；
• 页面检测到自动化特征；
• 触发验证码；
• 触发风险验证。

排查思路：

• 降低操作频率；
• 增加合理等待；
• 避免连续高频点击；
• 对验证码场景转人工；
• 遵守目标站点规则，不绕过风控。

4. 扩展无法访问页面

可能原因：

• 扩展未匹配目标站点；
• 权限不足；
• 页面是受限页面；
• 内容脚本未注入；
• 页面结构特殊。

排查思路：

• 检查扩展清单中的匹配规则；
• 检查权限声明；
• 检查当前页面是否属于受限页面；
• 检查内容脚本是否加载；
• 对特殊页面采用用户主动触发方式。

5. 本地代理无法连接

可能原因：

• 代理进程未启动；
• 端口被占用；
• 监听地址错误；
• 防火墙拦截；
• 令牌校验失败。

排查思路：

• 确认代理进程状态；
• 检查监听地址是否为回环地址；
• 检查令牌是否有效；
• 检查请求来源；
• 检查任务是否超时。

6. 表单重复提交

可能原因：

• 未等待成功状态；
• 提交按钮未禁用；
• 网络超时后自动重试；
• 任务恢复时重复执行提交步骤。

排查思路：

• 提交后先判断是否成功；
• 提交后禁用按钮；
• 对提交动作设置幂等控制；
• 失败重试前检查是否已创建记录；
• 高风险提交默认不自动重试。

7. 数据提取不完整

可能原因：

• 页面懒加载；
• 数据异步加载；
• 列表分页；
• 内容位于折叠区域；
• 元素可见性判断过早。

排查思路：

• 等待网络请求完成；
• 滚动加载更多内容；
• 展开折叠区域；
• 分步提取；
• 增加完整性校验。

优化建议

1. 安全优化

• 坚持最小权限；
• 使用一次性会话令牌；
• 高风险动作必须人工确认；
• 不在日志中记录敏感信息；
• 不将用户凭据上传到远端；
• 对任务会话设置短有效期；
• 支持随时终止和审计追踪。

2. 性能优化

• 缓存页面结构信息；
• 减少全量DOM扫描；
• 使用精确选择器；
• 批量读取页面数据；
• 避免不必要的截图和全量日志；
• 对重复任务建立模板。

3. 稳定性优化

• 为每步操作设置超时；
• 限制自动重试次数；
• 增加健康检查；
• 支持失败降级；
• 支持人工接管；
• 对关键任务增加成功判据校验。

4. 可维护性优化

• 将任务步骤配置化；
• 将选择器集中管理；
• 将动作封装为原子能力；
• 将日志、审计、权限模块分离；
• 对页面版本变化建立回归测试。

5. 成本控制优化

• 限制并发任务数量；
• 控制日志采样率；
• 按需保留审计日志；
• 避免无意义全量页面快照；
• 对高频任务进行结果缓存或摘要缓存。

6. 企业级落地建议

对于企业用户，可在本地安全代理和扩展能力之上，结合百度智能云等通用云能力进行增强，例如：

• 使用身份认证能力管理用户授权；
• 使用日志服务集中分析脱敏审计日志；
• 使用监控告警发现异常任务；
• 使用对象存储保存任务模板和脱敏结果；
• 使用容器平台或计算资源承载任务调度服务。

需要注意的是，即使用到云端能力，也应遵循“敏感数据不出端、凭证不上云、日志先脱敏、权限最小化”的原则。

总结

本文围绕“让AI在用户授权下操作浏览器”这一通用目标，给出了一套可落地的开发实践路径。核心并不是简单让程序点击按钮，而是建立一套可信、可控、可审计的网页操作闭环。

关键步骤包括：

1. 明确任务边界和权限清单；
2. 设计安全的登录态复用方案；
3. 搭建浏览器扩展骨架；
4. 建立本地安全代理；
5. 实现页面解析与元素定位；
6. 封装原子操作动作；
7. 加入审批与人工接管；
8. 完善日志审计和敏感信息保护；
9. 设计结果回传与异常补偿；
10. 通过配置、验证、排查和优化持续提升稳定性。

在实际落地过程中，应始终遵循以下原则：

• 用户授权优先；
• 最小权限优先；
• 敏感信息保护优先；
• 高风险操作人工确认优先；
• 可审计、可追溯、可终止优先。

后续还可以继续关注几个方向：自然语言任务编译、页面自愈选择器、操作回放、失败自动修复、企业级权限治理，以及基于百度智能云等通用云能力的集中监控与审计体系建设。通过这些能力的组合，可以进一步提升浏览器代操作的稳定性、安全性和可维护性。