你有没有想过，每天点击成百上千个链接时，为什么电脑没被搞垮？

浏览器在过去 30 年里，悄悄建成了一个专门用来运行「敌意代码」的沙盒——任何来自网络角落的不可信代码，只要用户一点链接，就能立刻执行，而你的系统依然安然无恙。

这听起来像是个奇迹，但事实就是如此。

一个不用下载几 GB 的 AI 代理

Google 的 Web 平台开发者倡导者 Paul Kinlan 最近把注意力转向了「编码代理」。他很快意识到，要让 AI 代理在本地安全运行，沙盒是关键。

于是他做了一个叫 Co-do 的演示。这个应用让你选择本地文件夹，配置 AI 提供商和 API 密钥，然后就能通过聊天界面让 AI 帮你处理文件——比如问它「三个最近编辑的文件是什么？」，它会返回一个表格，列出文件名和修改日期。

最神奇的是什么？它不需要你下载几个 GB 的本地容器，就能提供类似 Claude Cowork 的功能。所有操作都在浏览器里完成。

浏览器沙盒的三个核心

Paul 的研究指出，一个完整的沙盒需要三个要素：文件系统访问、网络控制、安全代码执行。浏览器恰好都有：

• 文件系统：通过 File System Access API（目前只有 Chrome 支持），可以让网页访问你选择的本地文件夹
• 网络控制：结合 CSP 头和 <iframe sandbox>，限制哪些网络请求能发出
• 代码执行：在 Web Workers 里运行 WebAssembly，隔离执行环境

有个细节很有意思：<input type="file" webkitdirectory> 这个标签其实在 Firefox、Safari 和 Chrome 里都支持，能让浏览器一次性获取整个目录的只读访问。有人用它做了个文件管理器，能显示 12,000 多个文件、2,000 多个文件夹，还能按类型筛选和预览。

但浏览器沙盒真的安全吗？

这里就出现了分歧。

支持者认为，浏览器沙盒经过了数十亿用户点击可疑链接的实战检验，是目前最成熟的客户端沙盒方案。

反对者则搬出数据：2024 年 Google 报告了 75 个零日漏洞可以突破浏览器沙盒。有人直言：「浏览器沙盒是漏洞百出的」。

还有人吐槽：「浏览器包含数千万行代码，比操作系统内核更复杂，攻击面巨大」，「依赖 350 个证书颁发机构，无法验证应用签名」。

关于 <iframe sandbox>，连原作者 Simon Willison 都抱怨：「文档太薄了，尤其是跨浏览器兼容性方面」。Paul 的帖子提供了详细的技术细节，包括复杂的双 iframe 技术来应用网络规则——这些信息在其他地方几乎找不到。

沙盒之争：浏览器 vs 操作系统

有人提出根本问题：「操作系统应该负责沙盒，而不是浏览器」，「安全应该默认启用，而不是需要用户主动开启」。

也有人指出：「Unix 权限模型不足以保护软件相互隔离」，而 Android 把 Unix 用户权限作为沙盒基础。还有讨论提到「Linux 内核存在大量本地权限提升漏洞」，但在已打补丁的系统中，从非特权沙盒提升权限并不容易。

怀念 Flash 的人

讨论中还有个意外的怀旧声音：有人怀念 ActionScript 和 Flash 时代，认为「Flash 7 或 8 在 2000 年代初比现在更先进和强大」。有人把 Flash 的消失归咎于苹果——「苹果不愿开源 Flash 或投入资源改进其技术基础」。

不过也有人指出，Flash 的脚本语言 ActionScript 直接影响了 ECMAScript 和 TypeScript 的设计，它的遗产还在。

未来：浏览器作为 AI 代理平台

尽管有争议，但浏览器作为代理环境确实开辟了大量可能性：

• 代理现在可以基于 HTML/CSS 标准提供 UI
• 在 WASM 容器中安全运行第三方代码
• 以足够信心将信息存储在磁盘上

有人认为「将推理任务移到客户端可以解决 GPU 成本问题」，但也有人指出「浏览器沙盒限制了系统调用、二进制执行和硬件访问」。

结语

浏览器沙盒就像个老练的保镖——它可能不是完美的，身上也有伤疤（漏洞），但它在过去的 30 年里确实保护了数十亿人。

而现在，它可能要承担新的使命：成为 AI 代理的安全运行环境。

问题是，这个 30 岁的保镖，准备好迎接 AI 时代了吗？