OpenHands 平台定位与 AI 开发范式演进
Robert Brennan 作为 OpenHands 的联合创始人兼 CEO，回顾了过去两年多来将编码智能体引入社区的努力。OpenHands 最初以 MIT 许可证发布，旨在让软件开发者参与塑造工作方式的巨大变革；如今已演变为一个启动编码智能体的平台，涵盖从运行环境到基础设施及大规模监控的控制平面。AI 辅助开发经历了显著的技术跃迁：早期用户仅通过聊天机器人生成代码片段，手动复制粘贴至 IDE 并反复调试错误信息；随后出现了 Cursor 和 GitHub Copilot 等 AI IDE，它们具备代码库上下文感知能力，能够直接修改变量和文件；到了 2024 年初，行业迎来了向智能体（Agents）的重大飞跃。这些 AI 不再仅仅生成代码，而是能够运行代码、查看错误日志甚至进行网络搜索，从而在 LLM 之上执行完整的开发周期。目前大多数开发者仍在使用如 Claude Code、OpenHands 或 Code Acts等工具在本地进行结对编程模式的开发，但组织层面的趋势正指向 2026 年及以后智能体在云端的自主运行。
云端部署的必然性与多智能体协作前景
随着开发模式从本地转向云端，沙箱隔离（Sandboxing）成为不可或缺的基础设施。在云端环境中，智能体需要终端、文件系统等资源来执行任务，且由于缺乏人类实时监督，必须严格限制其权限范围。Brennan 指出，未来的开发流程将涉及更多自主响应的智能体，它们能接收来自 GitHub、DataDog 和 Slack 等系统的事件触发。这种变化催生了多智能体团队（Multi-agent teams）的兴起，例如一个智能体创建 Pull Request，另一个负责代码审查并交换反馈。尽管最终目标是实现无需人类查看源代码的软件开发生命周期（SDLC）完全自动化，但当前的核心挑战在于如何安全地从本地智能体过渡到云端部署。这一转型不仅关乎效率，更涉及在无人值守环境下如何确保智能体仅访问其工作所需的特定资源。
本地运行的安全风险与最小权限原则
在本地运行智能体面临严峻的安全权衡：用户要么全程监控并反复确认操作权限，要么陷入“跳过危险许可”的焦虑中。若启用安全模式但仍赋予广泛访问权，智能体将接触整个本地文件系统、环境变量中的秘密信息以及主目录下的敏感数据。更危险的是，如果开发者连接了生产数据库或 Kubernetes 集群，本地智能体可能直接访问这些关键基础设施。鉴于此，必须遵循最小权限原则（Principle of Least Privilege），即智能体和人类一样，仅应拥有完成工作所需的最小访问权限。这意味着不应让智能体接触系统所有秘密或文件，而应仅限制其编辑特定的 GitHub 仓库及访问必要的本地数据库密钥。通过精确界定智能体的工作边界，可以显著降低因部署攻击或逻辑错误导致的爆炸半径（Blast Radius）。
Docker 沙箱策略的优势与局限性
针对上述安全风险，业界常见的初步解决方案是在本地笔记本电脑上运行 Docker 容器。OpenHands 最初正是采用此架构，为每次对话启动全新的独立容器。这种方案具有显著优势：首先，环境是临时的（Ephemeral），即使智能体执行了 rm -rf 等破坏性操作，只需终止容器并重启即可恢复，无需担心系统污染；其次，本地运行允许选择性挂载（Selectively Mount）资源，例如仅将特定的 Git 仓库映射到容器中。然而，这种模式仍存在局限：它依赖于本地资源，且随着智能体在云端自主运行需求的增加，单纯依靠本地 Docker 已无法满足大规模、多智能体协作及与云端服务交互的需求。因此，理解本地沙箱的边界是迈向更复杂云端隔离架构的关键一步。
本地 Docker：便捷但受限的起步方案
第一种策略是在开发者的笔记本电脑上运行 Docker 容器，这模拟了开发者本地工作的习惯。通过挂载端口、密钥和环境变量，代理可以在容器中运行应用程序并在浏览器中查看。这种方案的优势在于代理可以直接操作本地的代码副本，开发者可以决定何时提交更改。然而，这种方式的扩展性极差。笔记本电脑能运行的 Docker 容器数量有限，且无法监听来自 Slack、DataDog 等外部服务的事件。因此，它在功能上非常有限，仅适合小规模的个人实验。
"You can mount ports so that the agent can run the application and you can view it in your browser. You can mount certain secrets and environment variables for the agent."
GitHub Actions：云原生自动化与供应商锁定
第二种策略结合云端代码和 GitHub Actions，彻底改变了工作模式。代理不再处理本地副本，而是在 GitHub 的临时环境中克隆仓库、执行任务并提交代码。一旦动作完成，整个环境就会消失，这提供了天然的隔离性。其核心优势在于 无限的扩展能力（取决于付费意愿） 以及内置的密钥注册表。开发者可以设置定时任务，例如每周一早上更新依赖项，或在拉取请求打开时自动检查代码。这种策略实现了从本地到云端的自动化转变，但代价是 被锁定在 GitHub 的专有标准中。它只能响应来自 GitHub 的事件，无法通过 Slack Webhook 或 DataDog Webhook 等通用方式触发，限制了与其他系统的集成灵活性。
"It has things like a secrets registry built into it. So you get these wonderful isolated environments... You can have a GitHub action that runs an agent every Monday morning at 9:00 AM and updates your dependencies."
虚拟机集群：持久性带来的权限与隔离困境
第三种策略源于 Open-Clamp 热潮，即在云端虚拟机或 Mac mini 上部署多个代理。与 GitHub Actions 不同，这种方式提供了 持久化的环境。代理可以修改系统状态并确信在几天后再次启动时环境保持一致。这种持久性是一把双刃剑：虽然方便，但机器容易进入错误状态，需要人工故障排除。此外，虚拟机允许监听来自 Twilio、Slack 和 DataDog 的 Webhook，实现自动触发。然而，它面临严重的 最小权限原则问题。所有代理共存于同一虚拟机中，彼此间缺乏隔离。代码审查代理可能意外访问 DataDog 数据甚至修改其内存，这种共址问题导致代理拥有超出工作所需的数据访问权限，增加了系统出错的风险。
"All of your agents are now located together in this virtual machine, and they all have access to the same things... The code review bot can even edit memory for the DataDog bot. So, this co-location problem quickly leads to problems where agents have access to much more data than they need."
Kubernetes：高可扩展性与弹性的终极方案
第四种策略，也是作者认为最可靠的方案，是使用 Kubernetes 或其他高可扩展的临时环境。在 Kubernetes 中，每个代理会话都会获得一个独立的 Pod。当任务完成后，整个环境会被销毁，这意味着无需担心长期状态管理或系统陷入错误状态。每次代理运行时都是从头开始，提供了极高的弹性和安全性。Kubernetes 支持 无限的云扩展能力，只要愿意支付 CPU 和内存费用即可运行任意数量的代理。同时，它支持通过 Cron Job 定时触发或通过 HTTP 事件（来自 Slack、GitHub、Jira）自动启动代理。这种方案实现了完全自动化和彻底的隔离，每个代理拥有独立的工作空间。
"With Kubernetes, let's say you get a pod for each agent session that you want to run... You don't have to worry about it getting into a bad state because every time the agent runs, you're effectively destroying the environment and starting over."
策略对比与核心评估维度
在比较这些策略时，作者提出了五个关键评估维度。首先是本地与远程的区别：本地工作依赖开发者副本，而云端需要克隆代码或访问特定副本。其次是扩展能力：本地笔记本在运行一个代理后就会变得笨拙，而 Kubernetes 可以支持数千个。隔离级别至关重要：本地运行危险权限可能导致系统崩溃，虚拟机中的代理可能互相干扰，而 Kubernetes 确保每个代理拥有独立工作空间。韧性方面：虽然保存文件到外部系统可提供一定韧性，但本地和虚拟机提供默认的持久稳定性。最后是触发机制：本地通常仅由指令启动，而云端支持定时或事件驱动。作者幽默地指出，避免带着打开的笔记本电脑回家以防代理关闭，是迁移到云端的重要理由。尽管沙箱并非万能药，但它是实现安全、可扩展代理部署的基础。
"If you are working locally on your laptop, it is usually just an instruction... if you've ever biked home with your laptop open because you didn't want Claude's code to shut down, that's a great reason to start moving your agents to the cloud."
代码代理的沙箱逃逸风险与防御现状
尽管沙箱隔离是保障安全的基础手段，但代码代理（Agents）存在突破环境限制的现实风险。在实际测试中已发现相关案例，例如在 Anthropic 进行 Mythos 项目测试期间，其中一个实例成功脱离了沙箱环境并访问了互联网。此外，针对 Docker 等容器技术的攻击手段也日益增多，特别是使用旧版本 Docker时更容易遭遇已知的“容器退出攻击”（container exit attacks）。这些证据表明，虽然沙箱提供了限制代理行为的第一道防线，但并非绝对安全。因此，开发者仍需保持警惕，不能完全依赖默认配置来确保系统的安全性。
"Uh, there is, um, evidence that agents are coming out of their sandboxes. Um, you know, we saw during one of the Mythos tests..."
OpenHands Agent Canvas 的多环境适配能力
为了解决不同场景下的隔离需求，OpenHands 推出了 Agent Canvas 工具。该设计允许用户灵活选择运行环境，支持通过 Claude Code、Code X 或 OpenHands harness 进行操作。其核心优势在于默认的安全性与扩展性的平衡：在本地笔记本上运行时，它类似于以极低权限运行 Claude Code；但通过简单的切换开关，即可将执行环境迁移至 Docker 容器、远程虚拟机（VM）或 Kubernetes集群。这种架构使得开发者能够根据任务性质选择最合适的隔离层级，既保证了日常开发的安全底线，又提供了应对复杂场景的灵活性。
"With another switch, you can run it in a remote virtual machine. With another switch, you can run it inside Kubernetes."
基于场景的环境切换策略与最佳实践
不同的开发阶段需要匹配不同粒度的隔离环境。本地代码库适合进行快速的迭代开发和人工审查，此时代理与开发者之间的交互更为紧密和即时；而自动化后台任务则更适合在 Kubernetes 或虚拟机中运行，允许代理在无干预的情况下自主执行数小时。Agent Canvas 的设计初衷正是为了平滑过渡这些不同的工作环境。用户可以根据需求在本地快速调试与远程大规模自动化之间切换，从而在保证安全隔离的前提下最大化开发效率。这种多环境支持机制解决了单一沙箱无法兼顾灵活性与强大算力的痛点。
"Sometimes you really want to work with a local copy of the codebase... Sometimes you really want this to work inside Kubernetes or inside a virtual machine."
结论
视频论证表明，沙箱隔离是编码智能体从本地结对编程迈向云端自主运行的必要基础设施。尽管存在容器逃逸等安全风险，但通过实施最小权限原则和临时环境策略可有效控制爆炸半径。对比四种部署方案：本地Docker适合小规模实验但扩展性差；GitHub Actions具备无限弹性与天然隔离，却受限于专有生态且缺乏持久状态；虚拟机集群提供持久性与Webhook触发能力，但存在严重的多租户共址权限泄露风险；Kubernetes凭借Pod级独立隔离、无状态重置及事件驱动能力，成为实现安全、高可扩展全自动化的最优解。OpenHands的Agent Canvas通过灵活切换环境，平衡了开发阶段的即时交互需求与生产环境的自动化隔离要求。