AI Helper 浏览器助手升级：定时执行、CDP 页面调试与标签页级上下文

浏览器 AI 助手正在从“聊天窗口”变成真正的浏览器工作台。采用 MIT 许可证开源的 Chrome 扩展 AI Helper，近期集中加入了定时任务调度、基于 Chrome DevTools Protocol（CDP）的 debug_page 页面调试工具，以及侧边栏全局/标签页绑定两种作用域模式；聊天历史定位和时间戳体验也同步得到改进。

这些变化的价值不只在于多了几个按钮。它们分别解决了三个长期问题：任务何时自动执行、AI 能看到多少页面运行状态，以及多个标签页之间如何隔离上下文。

从“等用户提问”变成按时间触发任务

定时任务让浏览器助手具备了主动工作的入口。适合放进浏览器的任务通常和当前登录状态、网页内容或本地工作流有关，例如：

• 每天固定时间打开内部系统并整理待办；
• 周期性检查某个页面是否出现新内容；
• 在工作日结束前提醒填写工时或提交日报；
• 定期汇总浏览器中的研究标签页。

不过，浏览器调度并不等于服务器上的 Cron。浏览器可能退出，设备可能休眠，扩展后台也可能被 Chrome 挂起。因此，真正可靠的任务需要记录“计划执行时间”和“实际执行时间”，并考虑错过触发后的补偿策略。

如果想理解这类能力的实现边界，可以先运行一个最小的 Manifest V3 定时扩展示例。下面的项目不是 AI Helper 的内部接口，而是一个可直接加载的通用 Chrome 扩展示范：它每分钟触发一次任务，并把最近 20 次执行记录写进扩展存储。

mkdir -p scheduled-extension-demo
cd scheduled-extension-demo

cat > manifest.json <<'EOF'
{
  "manifest_version": 3,
  "name": "Scheduled Task Demo",
  "version": "1.0.0",
  "permissions": ["alarms", "storage"],
  "background": {
    "service_worker": "service-worker.js"
  }
}
EOF

cat > service-worker.js <<'EOF'
const ALARM_NAME = "demo-task";

chrome.runtime.onInstalled.addListener(async () => {
  await chrome.alarms.clear(ALARM_NAME);
  chrome.alarms.create(ALARM_NAME, {
    delayInMinutes: 1,
    periodInMinutes: 1
  });
  console.log("Scheduled task installed");
});

chrome.alarms.onAlarm.addListener(async (alarm) => {
  if (alarm.name !== ALARM_NAME) return;

  const executedAt = new Date().toISOString();
  const { runs = [] } = await chrome.storage.local.get("runs");
  const updatedRuns = [...runs, { executedAt }].slice(-20);

  await chrome.storage.local.set({ runs: updatedRuns });
  console.log("Task executed at", executedAt);
});
EOF

运行时打开 chrome://extensions，启用“开发者模式”，选择“加载已解压的扩展程序”，然后选中 scheduled-extension-demo。在扩展详情页打开 Service Worker 检查窗口，即可观察执行日志。

用于生产任务时，还应补上三类保护：

1. 幂等键：例如以 task_id + planned_date 作为执行标识，避免重复提交表单或重复发送消息。
2. 失败重试上限：网络失败可以重试，但需要指数退避和最大次数。
3. 浏览器离线补偿：重新启动后检查上次成功时间，而不是假设每次闹钟都准时触发。

涉及全天候执行、严格 SLA 或关键业务写操作时，服务器调度仍然更合适；浏览器定时任务更适合利用本地登录态完成轻量自动化。

debug_page 为什么比“读取网页文本”更进一步

普通网页助手大多依赖页面正文、选区或 DOM 快照。基于 Chrome DevTools Protocol 的调试工具则进入了另一个层级：CDP 是 Chrome DevTools 与浏览器页面通信时使用的协议，覆盖 Runtime、DOM、Network、Console 等多个域。

来源摘要明确指出 debug_page 基于 CDP，但没有列出它开放的全部指令。因此，不能直接假设它支持所有 DevTools 能力。就技术路径而言，这种设计有机会让 AI 不只回答“页面写了什么”，还可以围绕以下运行时证据协助排查：

• JavaScript 是否抛出异常；
• 页面元素是否存在、隐藏或被覆盖；
• 请求是否失败，以及状态码是否异常；
• 运行时表达式的返回值是什么；
• 前端状态与最终渲染结果是否一致。

开发者可以用一个隔离的 Chrome 实例观察 CDP 暴露的页面目标。以下示例适用于安装了 Chrome、curl 和 jq 的 Linux 环境；macOS 或 Windows 用户需要替换 Chrome 可执行文件路径。

rm -rf /tmp/chrome-cdp-profile

google-chrome \
  --remote-debugging-port=9222 \
  --user-data-dir=/tmp/chrome-cdp-profile \
  about:blank

保持浏览器运行，再打开另一个终端：

curl -s http://127.0.0.1:9222/json/version | jq
curl -s http://127.0.0.1:9222/json/list \
  | jq '.[] | {title, url, type, webSocketDebuggerUrl}'

第二条命令会列出可调试目标及其 WebSocket 地址。真正的 CDP 客户端会通过该地址发送诸如 Runtime.evaluate 或 Network.enable 的协议消息。

这里必须强调安全边界：调试协议可能读取页面内容、执行 JavaScript，并接触当前浏览器会话中的敏感数据。实践中应使用临时用户目录，只监听本机地址，不要把调试端口暴露到局域网或公网，也不要在包含生产管理后台、支付页面或密钥控制台的日常浏览器配置中随意开启远程调试。

全局与标签页绑定：上下文应该跟谁走

侧边栏作用域模式解决的是上下文归属问题。

全局模式适合跨页面连续工作。例如，用户先阅读需求文档，再查看接口说明，最后打开管理后台，希望助手保留整个调查过程。它的优势是连续，风险则是不同项目、客户或账号的信息容易被混在同一个对话中。

标签页绑定模式更像给每个页面配一名独立助手。排查前端错误、比较多个候选产品、同时处理测试与生产环境时，这种隔离尤其重要。标签页关闭后如何保存记录、页面导航后是否延续上下文，则需要用户根据扩展的实际行为确认。

可以用下面的选择规则快速判断：

历史定位与时间戳改进看似只是界面细节，却会直接影响调试可信度。页面状态不断变化，“这条结论基于哪个时间点的页面”往往比结论本身更重要。排查问题时，建议在提示词中明确记录环境、页面、时间和操作步骤，例如：

请分析当前页面的运行状态，并按以下格式输出：
1. 检查时间
2. 当前 URL 与页面标题
3. 可观察到的错误或异常请求
4. 支持结论的页面证据
5. 建议的下一步验证动作

不要执行提交、删除、发布或付款操作；如需修改页面状态，先征求确认。

这类提示词不能代替权限控制，但能减少助手在信息不足时直接执行高风险动作。

上线前别只检查“能不能用”

将这些能力纳入日常开发流程前，可以按下面的清单逐项验证：

• 定时任务在浏览器关闭、休眠和网络中断后如何处理；
• 重复触发是否会产生不可逆副作用；
• 全局会话是否可能混入其他项目或账号的数据；
• 标签页刷新、跳转和关闭后，上下文如何变化；
• debug_page 具体开放了哪些 CDP 操作；
• 调试记录中是否包含 Cookie、令牌、表单或客户数据；
• 所有写操作是否需要人工确认；
• 历史记录能否按时间和页面追溯。

这轮更新真正值得关注的地方，是浏览器助手开始同时具备时间触发、运行时观察和上下文隔离三种基础能力。它们组合起来可以形成实用的浏览器自动化工作流，但能力越接近 DevTools 和真实登录会话，权限、审计与误操作防护就越不能依赖一句提示词。比较稳妥的采用方式是从只读调试和低风险提醒开始，再逐步开放页面操作与周期任务。