让 AI 自动上网，大家都在做。但有没有人认真想过：你怎么管它去了哪里？

GitHub 上一个正在爆红的项目给出了一个让人眼前一亮的答案：域名白名单。

先说这个项目在做什么

browserbase/skills，一套让 Claude Agent SDK 真正"上网干活"的工具集。

背后是 Browserbase——一家提供云端浏览器基础设施的公司，让 AI Agent 可以像真实用户一样操作浏览器：打开网页、填表单、点按钮、处理验证码。

代码接入后，Claude 就能：

  • 自动浏览网页提取信息
  • 登录你的账号帮你操作
  • 跑多步骤工作流（查价格、填申请、提交报告）

这件事本身不是新鲜事。OpenAI 有 Operator，Google 有 Project Mariner（Google DeepMind，2024年底发布），大家都在做"AI 操作浏览器"。

真正有意思的，是这个项目里一个叫 safe-browser 的 skill。

safe-browser：给 AI 浏览器装了一道门

safe-browser 的设计很简单，但非常清醒：

AI 只能访问你明确允许的域名。其他的，一律拒绝。

# 允许 AI 访问的域名白名单
allowed_domains:
  - company.com
  - internal-dashboard.corp
  - approved-vendor.com

这不是给开发者用的小功能，这是整个"AI 自主上网"问题的核心解法之一。

想象一下没有这道门的场景：你让 AI 帮你整理竞品价格，结果它顺手访问了某个钓鱼网站，把你的 Cookie 数据带走了。或者你的 Agent 在完成任务的过程中，被恶意网页注入了指令，开始做你没有授权的操作。

这不是夸张。Prompt Injection 通过网页内容攻击 AI Agent，是目前已经被证实存在的攻击方式。

safe-browser 用最朴素的方式解决了这个问题：不是去分析每个页面有没有风险，而是直接只允许去已知安全的地方。

和 OpenAI Operator、Google Mariner 的路径比较

三家都在做 AI 操作浏览器，但哲学不同：

OpenAI Operator：用户侧产品，强调"AI 帮你完成任务"，安全靠 OpenAI 平台审核合作商家，用户自己决定授权什么网站。

Google Project Mariner（Google DeepMind，2024年底发布）：深度集成 Chrome，靠 Google 的账号体系和权限系统做隔离，安全逻辑在 Google 那一层。

Browserbase 这套：开发者工具，把安全控制权交给部署 Agent 的工程师——你自己定白名单，你自己负责。

三种路径没有绝对的对错，但对应的用户完全不同：

  • 普通用户 → OpenAI/Google 方案（平台帮你管）
  • 企业内部部署 → Browserbase 这类方案（自己管，可审计，可定制）

除了 safe-browser，这个项目还有一个叫 cookie-sync 的工具：把你本地 Chrome 的 Cookie 同步给 AI Agent，让它能以你已登录的状态访问网站。

这让 Agent 的能力大幅提升——不需要让用户重新登录，不需要处理 OAuth 流程，直接"借用"你的登录凭证。

功能很强大。但随之而来的问题也很直接：

一旦 Cookie 被同步出去，那台云端浏览器里的 Agent，拥有和你完全相同的访问权限。

这条路走好了，是企业自动化的利器。走岔了，是一个精心设计的权限泄露口。

safe-browser + cookie-sync 组合使用的正确姿势是：先用白名单锁死可访问范围，再开放登录凭证。任何一个单独使用，都只做了一半。

AI Agent 自主上网的三个未解问题

这个项目很好，但它也把整个领域还没解决的问题摆上了桌面：

  1. 审计问题：AI 访问了哪些网页、做了什么操作，有没有完整可查的日志？（这个项目有 browser-trace，专门抓 CDP 协议层的完整记录，这点做得不错）

  2. 越权问题：白名单能防"去了哪里"，但防不了"在被允许的网站上做了什么超出预期的事"。

  3. 责任问题：当 AI Agent 的操作造成了损失，谁来承担——开发者？平台？用户？

这三个问题，整个行业目前都没有标准答案。

一句话总结

让 AI 上网容易，管好它上什么网才是真本事。

browserbase/skills 里最有价值的东西不是浏览器自动化本身，而是 safe-browser 这个设计——在能力边界还不清晰的时候，先把物理边界划清楚。

这个思路，值得所有在做 AI Agent 的工程师认真学一遍。