我叫罗伯特·布伦南，是 OpenHands 的首席执行官。今天我想和大家谈谈使用沙箱化编码智能体的话题，为什么这是一个非常重要的模式，以及实施它的不同方式。先简单介绍一下我自己。
正如我刚才所说，我是 OpenHands 的联合创始人兼首席执行官，我们在两年多前创立了这家公司。我们的目标是将编码智能体引入社区，让软件开发者在发生在我们工作中的巨大变革中拥有话语权。我们以 MIT 许可证发布了 OpenHands，作为一个编码智能体。如今我认为我们已经发展成为一个发布编码智能体的平台，涵盖了从运行框架、基础设施和控制平面到大规模监控这些智能体的一切。
我想简要回顾一下基于 AI 的开发历史，以及我们如何走到今天这一步，并谈谈我对未来走向的看法。我们从聊天机器人生成的代码片段开始说起。我记得第一次在 GPT 聊天中输入“写一个执行 X 操作的 SQL 查询”时，第一眼看到结果我就被震撼了，当时我感到非常惊叹。嗯，这在今天看来可能有点过时了。但我最初的工作流程是：进入 ChatGPT，粘贴一些内容到我的 IDE 中，按下回车键，然后将错误信息再贴回 ChatGPT。
很快我就意识到：“嘿，这有点傻气。我可以直接连接一些 API。” 于是我们很快就迎来了像 Cursor 和 GitHub Copilot 这样的基于 AI 的 IDE，它们能执行自动补全等功能。现在你拥有代码库的上下文信息，不再仅仅是在聊天窗口中生成代码片段，而是实际上在修改代码本身。你可以看到那里可用的变量名。
因此 AI 变得稍微聪明了一些，对上下文更加敏感了。然后在 2024 年初的某个时候发生了巨大的飞跃，那就是向智能体的跃迁。也就是说，人工智能不再仅仅编写代码，而是实际上运行所编写的代码。它们会查看错误信息、搜索相关信息，并在大语言模型之上执行整个开发周期。这大致就是我们今天所处的阶段。
我认为大多数开发者目前仍然在笔记本电脑上运行类似 Claude Code、OpenHands 或 Code Acts 的工具。由于我指的是结对编程模式，他们需要手动启动这些工具。我们看到组织在 2026 年之前正在做出的飞跃，实际上是让智能体在云端运行。而这正是沙箱发挥作用的地方。
首先是因为你需要一个地方让它们在云中工作，对吧？你需要为智能体提供终端、文件系统等。其次是因为一旦这些智能体在云端运行，你能做更多的事情。你必须确保它们只能访问被允许访问的内容，因为不一定总有人在一旁照看它们。
展望未来，我认为我们在云中使用的自主工作、响应来自 GitHub、DataDog 和 Slack 等系统事件而非接收手动提示的智能体越多，智能体之间的交互就会越频繁。例如一个智能体打开拉取请求（PR），另一个进行代码审查，然后它们交换这些内容。
我们看到多智能体团队正在涌现。我认为最终目标是实现软件开发生命周期（SDLC）的完全自动化，人们甚至不需要查看源代码。但今天我想谈谈的是，我们如何从第三阶段过渡到第四阶段？即从我们在本地机器上运行智能体，转变为让智能体在云端运行。让我们先谈谈本地启动的情况。这里有多少人是在笔记本电脑上运行 Claude 的代码，或者执行代码操作，或者是使用 OpenHands 等某种本地智能体？
很好。比我预期的要少一些。如果你使用的是危险权限，请保持举手状态。是的，好的。不知为何比之前举手的更多了。
所以在本地运行智能体是一个巨大的权衡，对吧？你可以选择坐在那里点击“是、是、是”，一遍又一遍地允许它这样做，并在一旁观察智能体的工作；或者你可以进入“跳过权限很危险”的模式，确保智能体不会删除对你非常重要的文件，或访问你的工作数据库等。嗯，所以在本地运行时你基本上局限于这两种选择。
如果你以安全权限在本地运行，智能体可以访问很多东西。它可以访问你的整个本地文件系统，可以访问环境变量中的任何密钥，还可以访问例如你主目录中的任何秘密。
如果你连接到生产数据库或生产 Kubernetes 集群，智能体也可以访问它们。它几乎拥有你所能拥有的所有权限。因此非常重要的一点是，你必须要么坐在那里盯着它看它在做什么，要么找到一种方法切断它的某些权限，实际上只给它提供完成工作所需的访问权。这是我们早在智能体出现之前的安全时代就熟知的范式，即最小权限原则。
其理念是，无论是智能体还是人类，都只应拥有完成工作所需的访问权限。因此，智能体不应有权访问你系统中的每个秘密或每个文件，它应该只能访问正在编辑的 GitHub 仓库以及可能需要访问本地数据库的几个密钥之类的东西。所以在开始对这些智能体进行沙箱化时，重要的是我们要审视这个智能体到底需要做什么来完成它的工作。
然后我们可以创建一个恰好包含这些内容的沙箱。这样我们就知道，无论是快速部署攻击还是智能体困惑导致出错等任何可能出问题的情况，我们都可以通过限制智能体的访问来限制其爆炸半径。因此人们倾向于尝试的第一种策略是在笔记本电脑上的 Docker 容器内运行。
实际上，我们最初发布 OpenHands 作为接口时就是这样做的：每次你与智能体开始新的对话时，我们都会启动一个全新的 Docker 容器。每个智能体获得自己的容器。这在几个方面效果很好：首先，它是临时的（ephemeral）。所以智能体可以做任何它想做的事。
如果它运行 rm -rf 删除了所有内容，你只需终止容器并重新开始即可。这非常好。智能体可以像钟表一样按部就班地行动，你不需要太担心它会做什么。而且因为它在你的笔记本电脑上本地运行，你也可以选择性地挂载来自本地文件系统的东西，比如 Git 仓库。
你可以挂载端口，以便智能体运行应用程序并在浏览器中查看。你可以为智能体挂载特定的密钥和环境变量。你可以在笔记本电脑本地或 Docker 容器内运行 MCP 服务器。这很方便，因为智能体仍然可以使用你本地的代码副本，对吧？这与你在工作站上有本地代码副本时习惯的工作方式类似。
现在由智能体进行编辑，而不是你手动修改，你可以决定何时提交等。但这并不具备很好的可扩展性。笔记本电脑上能运行的 Docker 容器数量有限，且无法监听来自 Slack、DataDog 等服务的事件。因此在功能上相当受限。
我们看到的下一个策略是云代码与 GitHub Actions 的结合。这与在电脑上运行 Docker 容器截然不同，你不再使用本地副本。智能体位于 GitHub Actions 中的临时环境里，克隆仓库、执行操作然后提交，一旦动作完成整个环境即消失。好处是可以按需运行尽可能多的 GitHub Actions 实例。
它具有内置的密钥注册表等功能，提供隔离环境。更酷的是可以按计划运行智能体，例如每周一早上 9:00 自动更新依赖。还可以设置当拉取请求打开时，由智能体检查代码并实现自动化。但这也受限于 GitHub Actions 这一专有标准，无法移植到其他平台。
它只能响应来自 GitHub 的事件，不能像通过 Slack 或 DataDog Webhook 那样灵活反应。因此仅靠 GitHub Actions 组合功能仍有限制。下一个策略与 Open-Clamp 热潮相关，即在云端获取独立计算机（如虚拟机或 Mac mini）并部署所有智能体。这与 GitHub Actions 不同，拥有持久化的环境。
这种持久性既好又坏：智能体修改系统后重启时状态一致，但机器也可能陷入错误状态需排查。你可以像 GitHub Actions 一样按计划运行智能体。在虚拟机上，可以监听来自 Twilio、Slack、DataDog 或 GitHub 的 Webhook 和事件，自动启动智能体。
但仍存在最小权限原则问题：所有智能体共存于同一虚拟机，共享访问权限。例如代码审查代理旁可能有 DataDog 故障分类机器人，前者可能意外获得后者访问权甚至编辑其内存。这种共址问题导致智能体拥有超出工作所需的数据权限，交互越多出错机会越大。
第四种也是更可靠的策略是使用 Kubernetes 或其他高可扩展的临时环境。每个智能体会话获得独立 Pod，运行完成后销毁整个环境。这无需担心虚拟机式的长期状态问题或陷入错误状态，因为每次运行都相当于重置环境。
你获得了无限扩展能力：只要愿意支付内存和 CPU 成本，可运行任意数量智能体。由于基于 Kubernetes 且位于云端，你可以响应 HTTP 事件（如来自 Slack、GitHub、Jira），通过 Cron Job 按计划运行，完全自动化执行。
快速对比这些策略时，我关注几个维度：本地还是远程？在笔记本使用副本还是在云端克隆代码？扩展性如何？本地仅能运行少量智能体，Kubernetes 可支持数千个。隔离级别：本地操作危险权限无保护；虚拟机智能体间可能互相干扰，而 Kubernetes 每个代理拥有独立工作区。
韧性方面：虽然可通过保存文件提升稳定性，但笔记本和虚拟机默认提供持久化系统。触发机制也不同：本地通常仅靠指令启动，云端可支持计划任务或事件响应。如果你曾因不想让 Claude 关闭代码而带着打开的笔记本骑车回家，这就是迁移到云端的绝佳理由。
最后我想强调，沙箱并非万能药。
有证据表明，智能体正在突破沙箱限制。例如，在 Anthropic 测试 Mythos 期间的一次测试中，其中一个 Myths 实例成功脱离了沙箱访问互联网或执行其他操作。存在容器逃逸攻击，如果使用较旧版本的 Docker 等已知情况，风险更高，这并不理想。
虽然仍需保持谨慎，但这至少是限制智能体行为的良好初步尝试。最后简要介绍 OpenHands Agent Canvas，这是一种兼容各类沙箱的工作方式，可通过 Claude Code、Code X 或 OpenHands Harness 运行。默认情况下在笔记本上运行时，如同以极低权限运行 Claude Code；但只需一键切换即可开始在 Docker 容器中执行任务。
通过另一个开关，可以在远程虚拟机中运行；再一个开关即可在 Kubernetes 内部署。这提供了选择合适工作环境的极佳方式，因为有时确实需要本地代码库副本进行快速迭代开发并审查智能体生成的代码；而另一些时候，则需要触发事件让智能体在 Kubernetes 或虚拟机中自主后台运行数小时。
这种在不同环境间灵活切换的能力非常实用，能够根据实际需求选择最合适的运行场景。以上就是我的分享，我很乐意回答观众提出的问题。