你让AI代理去修一个bug，它开始装依赖、跑测试、执行命令。几分钟后你才发现，它动过的东西远不止这个项目。你不想盯着它的每一步，但也不敢把整台机器交给它。

Docker给出的答案是：给代理一台自己的开发机。Docker Sandboxes为AI编码代理提供隔离环境，本地沙箱用microVM把代理的执行环境与宿主机分开。代理可以在里面干活、装工具、跑代码，网络访问和凭据则通过明确的控制来管理。

这套思路的重点不是削弱代理的能力，而是让它自主工作，同时不必默认信任它的每一个动作。

先登录，再启动

上手的第一步是安装Docker Sandboxes，按官方入门指南操作。登录并查看可用命令：

  • sbx login
  • sbx --help

配置完成后，启动一个受支持的编码代理：

sbx run --name my-agent claude

把claude换成你惯用的受支持代理即可。核心变化在于：代理不再直接跑在你日常的环境里，而是通过沙箱流程启动。具体配置取决于操作系统、代理和认证方式，需要对照当前文档确认前置条件。

网络不是全开也不是全关

隔离不只是把文件分开。AI代理经常需要联网下载依赖、抓取文档，或者与模型提供方通信。难点在于：放行它需要的连接，又不让所有目的地默认可达。

Docker Sandboxes提供网络策略预设和可配置规则。查看已配置的策略：

sbx policy ls

如果开发流程需要npm仓库，可以显式放行：

sbx policy allow network registry.npmjs.org

这里的原则是：给代理完成当前任务所需的资源，而不是假定它需要不受限制的网络。生效的策略仍需核查，尤其是当额外工具或配置自带权限时。

凭据别随手放

代理可能需要向模型提供方或外部服务认证。这不意味着可以把API密钥随手写进项目文件，或者通过shell命令暴露出去。Docker Sandboxes支持旨在减少原始凭据直接暴露给代理的凭据管理机制。

受支持的Anthropic凭据可以这样配置：

sbx secret set anthropic

具体凭据设置取决于提供方和环境，需按官方凭据管理指南操作。隔离环境只是安全的一部分，密钥怎么交到代理手里同样关键。

沙箱能挡住什么，挡不住什么

Docker Sandboxes帮助建立边界，但它不保证每个动作都安全。素材把保护范围拆成四块：

  • 执行：代理运行在隔离环境中。
  • 网络：策略帮助控制出站连接。
  • 凭据：受支持的机制可以减少原始密钥的不必要暴露。
  • 权限：任何显式共享给代理的东西仍需仔细考量。

代理仍可能在自己的环境里犯错。网络规则可能配错，凭据如果被刻意放在代理能读到的地方，照样会暴露。沙箱更适合作为整体安全方案中的一层，而不是代码审查和权限管理的替代品。

正方会说，这就是代理走向自主的必经之路：给它一台机器，划好边界，人就不用当保姆。反方会提醒，边界是人划的，规则是人配的，配错的那一刻，隔离感会变成虚假的安全感。

我的判断偏向前者，但有个前提：沙箱解决的是“代理能碰到什么”，解决不了“代理做对了没有”。给代理足够的自由把活干完，同时把不必要的访问挡在外面——这两件事得同时成立，缺一件，另一件就只是心理安慰。