沙箱网页浏览器会在明确受限的浏览器环境中运行网页内容，因此故障或恶意页面影响主机、其他用户或后续会话的方式更少。对于 AI 智能体，"沙箱" 可能指多种不同事物：Chromium 的进程沙箱、独立的浏览器配置文件、本地应用工作区、容器、虚拟机、网络策略或临时远程会话。你需要先明确边界，然后才能评判它。
什么是沙盒 Web 浏览器？
一个有价值的定义包含三个部分：浏览器进程受到约束，浏览器状态被限定范围，周围系统限制会话能够访问或保留的内容。如果产品只是在另一个标签页中打开 URL，那不足以将其称为安全沙箱。如果它启动一个新的远程浏览器，但赋予该浏览器广泛的网络凭据，那么"临时"并不自动意味着低风险。
Chromium 本身将浏览器进程与渲染进程分离，并应用特定于平台的沙箱机制。服务随后可以添加新的用户数据目录、容器或虚拟机、出站网络控制、密钥注入、文件挂载、资源限制和拆除。每一层保护不同的资产，并具有不同的故障模式。
对于 AI 智能体，威胁模型比恶意 JavaScript 更广。智能体可能遵循页面上的提示注入，选择错误的控制项，在表单中暴露密钥，下载不安全文件，或将特权会话复用于非预期任务。因此，浏览器隔离必须与智能体权限和确认策略协同工作。
智能体应使用本地沙盒还是远程沙盒？
按以下顺序做出选择：身份、风险边界、规模，然后交接。第一个无法放宽的需求应决定路线。
- 当任务必须复用已授权的登录、本地扩展或设备绑定状态时，请选择本地持久浏览器。
- 当不可信页面必须远离用户设备、每次运行必须干净启动，或许多会话必须并行运行时，请选择远程沙箱。
- 当人员必须检查、认证、批准或停止运行时，请选择具有经过验证的实时查看和接管路径的本地或远程浏览器。
- 当身份连续性和设备外隔离都必需时，选择混合方案：把依赖账户的步骤留在本地，将匿名或大规模工作发送到一次性远程会话。
| 决策因素 | 本地持久浏览器 | 远程沙箱 |
|---|---|---|
| 现有登录 | 可以复用已授权的本地配置文件或专用本地状态 | 通常根据提供商规则导入、重建或注入状态 |
| 人工接管 | 用户附近直接可见 | 取决于提供商的实时查看/控制支持和延迟 |
| 与主机的隔离 | 浏览器/配置文件边界；主机仍在本地 | 可以增加容器或 VM，与用户主机隔离 |
| 并发 | 受限于单台机器和本地资源争用 | 为预配机群、配额和并行会话而设计 |
| 保管 | 除非同步，否则状态和产物保留在用户机器上 | 状态、流量和产物进入提供商控制的基础设施 |
| 维护 | 用户或团队拥有浏览器、机器、更新和容量 | 提供商拥有更多基础设施；客户拥有策略和集成 |
哪些隔离层真正重要？
至少分别评估六个层面。进程隔离限制被攻破的渲染器能对其他进程做什么。配置文件隔离将 Cookie、本地存储、历史记录和扩展分开。文件系统隔离限制可读和可写的路径。网络隔离控制目标、DNS、代理和私有网络可达范围。计算隔离增加容器或 VM 边界。租户隔离防止一个客户的浏览器、日志、机密或产物进入另一个客户的工作负载。
还要将生命周期与隔离区分开来。十分钟后删除会话会降低持久性，但这不能证明该会话在存活期间无法访问敏感网络。反过来，如果配置文件、智能体权限和任务范围被有意限制，那么持久本地 Space 对于范围狭窄的可信账户工作流来说是可以接受的。
登录状态与数据托管有何不同？
本地持久浏览器可以让 Cookie、本地存储、客户端证书和兼容扩展靠近用户。这消除了重复登录工作，但会加重权限过宽的后果：智能体可能继承比任务所需更多的账户状态。优先使用专用的工作配置文件或 Space，仅允许必需的站点，并对不可逆操作要求确认。
远程沙盒通常以干净状态启动，然后接收存储状态、登录流程或提供商管理的持久化。这提高了可复现性，但会把部分浏览器状态和流量发送到远程控制平面。要审查加密、区域、保留策略、日志、重放产物、员工访问、子进程隔离和删除行为。不要因为提供商支持存储状态字段就上传个人配置文件。
会话过期仍属于应用行为。MFA、风险检查、设备绑定、IP 变更和 Cookie 轮换都可能使任一路径失效。可靠的智能体会检测到已过期的会话，在错误页面上执行操作之前停止，并交还控制权或遵循已批准的重认证流程。
人工接管与调试有何不同？
本地可见执行把浏览器放在用户身边，当人员必须检查上下文、完成认证步骤或立即停止不安全操作时，这很有用。专用的本地 Space 还能避免将智能体操作混入无关的日常标签页。
远程浏览器环境可能暴露实时会话界面、命令流、日志、录制和重放。这些功能可以支持分布式团队和运行后调试，但接管延迟、访问控制、保留策略和区域可用性仍取决于具体实现。请在你实际运行的确切环境中验证它们。
在一次实时已认证的 Airbnb 运行中，Claude Code 使用 ego-browser 路径从可见 UI 验证登录，搜索东京 10 月 20 日至 23 日、两位房客，应用 Entire home 筛选器，打开两个房源，并比较可见字段，同时专用 Space 始终处于 Agent 控制之下。它没有检查会话 Cookie，也没有执行预订、心愿单、发消息或账户操作。
该运行只比较了两个页面可见展示的内容。房源 A 显示一套服务式公寓，价格为 JPY 58,188，评分为 4.89，来自 577 条评价。房源 B 显示一套出租单元，价格为 JPY 43,154，评分为 4.9，来自 489 条评价。两个页面都使用相同的通用措辞 'Free cancellation for 24 hours'，因此智能体没有在未进入预订面板的情况下推断特定日期的取消条款。
对比完成后，用户选择了 Take over。同一个 Space 和房源保持打开，状态从 Agent is in control 变为 You're in control，可用操作变为 Return to agent。这是直接的界面级交接观察；它并不能确定每个网站或被中断的操作会如何表现。
并发、回放和成本有何不同？
本地机器的 CPU、内存、显示资源、配置文件锁和网络容量都是有限的。它适合交互式或低并发工作，但并行 agent 不得同时修改同一个配置文件。远程服务可以预置许多隔离会话并集中管理录制，但配额、启动时间、浏览器分钟数、代理流量、存储和可观测性功能都会影响成本。
成本比较需要匹配的计量单位：已完成任务，而不是仅看原始浏览器分钟数。要包括初始设置、重试、代理流量、CAPTCHA 或 MFA 交接、状态创建、产物存储、失败会话重放和操作员时间。我们没有针对本文的可比计费遥测数据，因此不发布优胜者或价格表。
我们的本地持久化测试显示了什么？
我们在一个专用 ego (lite) Space 中使用了 ego-browser 0.5.0.31 和 Chromium 152.0.7977.54。第一个 Claude Code 进程完成了只读 Airbnb 比较，并将该 Space 交给用户。用户交回控制权后，一个新的 Claude Code 进程恢复了 Space 12，并检查了其现有标签页，没有进行导航、重新加载或更改。
| 检查 | 观察到的结果 |
|---|---|
| 新进程找到了同一个 Space | 是，Space 12 |
| 东京搜索结果标签页保留 | 是，p1 |
| 两个房源详情标签页保留 | 是，p2 和 p3 |
| 可见房源仍处于活动状态 | 是，p3 |
| 需要导航、重新加载或更改标签页 | 否 |
这一观察表明，这台机器上两个 Claude Code 进程之间具有连续性：同一个 Space、三个标签页、标签、标题、URL 和活动房源均仍可用。它不能证明身份验证可无限期保持、浏览器或设备重启后仍持久存在、与每个网站兼容，或远程沙箱中的行为。
我们的远程代理运行显示了什么？
为了进行中立的设备外检查，我们在 Google Colab Linux 运行时中启动了 headless Chromium，并打开了相同的公开东京搜索，条件为 10 月 20 日至 23 日、两名成人和整套房源。未提供 Airbnb 凭据。两次运行分别在 17.66 秒和 16.42 秒内完成。两者都返回 HTTP 200，渲染了房源和地图，提取出相同的五个不同房间链接，并且没有记录到任何封锁信号。
这缩小了此前的证据缺口：一台干净的远程 VM 两次完成了这个匿名公共页面探测。它仍未测试多租户隔离、提供商管理的密钥、会话回放、实时接管、地理出口、账号复用或拆除保证。这些需要带有已授权账号的托管远程浏览器环境，以及单独冻结的测试计划。
何时应使用混合架构？
当同一系统存在互不兼容的信任区域时，使用混合方案。将依赖账号、用户可见的步骤路由到专用的本地 Space，将匿名发现、不可信页面或大规模扇出工作路由到一次性远程会话。区域之间只传递最小结果，例如公共 URL 或规范化记录，而不是整个浏览器配置文件。
安全的路由器会考虑目标信任、所需身份、数据敏感性、并发、地理出口、接管要求，以及官方 API 能否替代浏览器工作。当没有路由符合策略时，它应拒绝任务，而不是静默选择权限最高的浏览器。
最小集成是什么样的？
本地路径会创建一个专用浏览器工作区，导航到现有页面，执行有界任务，验证结果，并关闭由智能体创建的页面。远程路径会向提供商请求会话，连接自动化客户端，执行相同任务，只存储所需工件，并且即使失败也终止会话。
route = policy.choose({
targetTrust, requiredIdentity, concurrency, takeover
})
if (route === "local") {
runInDedicatedVisibleSpace(task)
} else if (route === "remote") {
session = await sandbox.create({ ttl, egressPolicy })
try { await runTask(session.endpoint) }
finally { await sandbox.terminate(session.id) }
} else {
throw new Error("No safe browser route")
}生产代码还应设置超时、幂等键、允许的来源、下载隔离、密钥作用域、工件保留，以及不包含原始凭据的审计记录。
如何验证浏览器沙箱？
- 编写资产与攻击者模型：主机文件、内部网络、凭据、另一个租户、后续会话以及人工操作员。
- 分别映射浏览器进程、配置文件、文件系统、网络、计算、租户和生命周期边界。
- 运行一个金丝雀任务，只尝试已批准的测试读写，然后证明禁止的主机路径和目标仍不可访问。
- 使用命名的非密钥标记验证干净启动和持久化行为。确认拆除确实移除了预期状态。
- 测试过期、崩溃、重试、失去控制、弹窗、下载和登录中断路径。
- 使用实际用户和访问策略验证实时接管与撤销，而不是营销截图。
- 根据保留策略检查工件、日志、回放、备份和支持访问。
- 在真实并发下重复，并且只有在所有分母都可用时才记录已完成任务成本。
ego (lite) 适合放在哪里？
ego (lite) 是一款本地 Chromium 浏览器，旨在让人类与 AI 智能体协同工作；按产品类别来说，它是一款智能体浏览器。它不是 AI 智能体、Chrome 扩展、远程云浏览器，也不是 Playwright 之类的自动化框架。你可以把它当作日常浏览器使用，同时 Claude Code、Codex、Cursor 和 Gemini CLI 等兼容智能体可通过 ego-browser 控制它。ego (lite) 目前运行在 macOS 上，可导入 Chrome 标签页、书签、密码、扩展、cookie、登录会话和配置文件。每个智能体任务都在自己的 Space 中运行，你可以随时观看、暂停或接管工作。
因此，ego (lite) 适合依赖已授权登录态的浏览器操作，例如在 Gmail、Notion、LinkedIn、内部工具或 SaaS 管理后台中查询信息、整理内容、填写表单，这些场景下你已经处于登录状态。由于浏览器在本地运行，它也适合不愿把 Cookie 和浏览会话交给云端托管浏览器的团队或个人，以及需要任务走自己的网络、VPN 或代理的场景。如果决定性的需求是远程多租户隔离、大规模一次性实例、由服务商控制出口流量，或者要把不可信页面挡在本地机器之外，则应改用远程沙箱或混合架构。如果官方 API 或普通 HTTP 请求就能完成任务，可能根本不需要浏览器。
哪些来源定义了这项比较？
关于浏览器进程边界，请阅读 Chromium 的沙箱设计。要进行会话级隔离，请阅读 Playwright 的浏览器上下文隔离指南。关于主机与容器边界，请阅读 Docker 的引擎安全概述。这些来源定义了隔离层和测试原语。它们并不能证明某个特定的托管服务正确实现了每一边界。
常见问题
无痕模式是浏览器沙箱吗？
无痕模式主要改变本地历史记录和存储的持久性。它本身并不会增加虚拟机、租户边界、网络允许列表，也不会提供针对权限过高的智能体的保护。
远程沙箱总是更安全吗？
不是。它可以将工作与用户机器隔离，但安全性仍然取决于租户隔离、网络可达范围、机密信息、提供商保管、保留策略以及智能体被允许的操作。
本地浏览器可以复用我的登录状态吗？
专用的本地配置文件或经授权导入的状态可以保留 Cookie 和存储，但受限于站点策略、过期时间、MFA 和产品兼容性。请使用能满足任务需求的最小范围配置文件。
每个智能体都应该在全新的浏览器中运行吗？
全新会话适用于不可信或可重复的工作。当身份连续性属于任务的一部分，并且权限被有意限制时，持久会话才是合理的。
