一句话看懂：开发者 k33g 在 2026 年 10 月 4 日的文章中，把 Zed 编辑器、Docker Agent、ACP 协议与本地模型服务 llmman 的整套组合，从宿主机迁移进 Docker 的 sbx 沙箱中运行，让 Agent 依旧能读写项目、执行 shell，但不再直接触碰用户全盘文件与密钥。
事件核心：发生了什么
这套方案延续了作者此前的实验：用 ACP 协议把 Zed 接到 Docker Agent 上，模型由本地运行的 llmman 提供，推理走自己的 GPU。区别在于，这次 Docker Agent 不再直接在宿主机上跑，而是通过 sbx create docker-agent 命令放进基于 microVM 的沙箱，工作目录以相同路径挂载给 Agent，其余文件系统不可见。
配置上的关键变化只有一处：base_url 从 127.0.0.1 改为 host.docker.internal，因为沙箱有自己的 localhost，无法直接访问宿主机上的 llmman 服务。如果代理拦截了请求，需要用 sbx policy allow network localhost:17434 放行端口。Zed 一侧则在 agent_servers 中把启动命令从 docker-agent 改为 sbx exec，由它进入沙箱执行 docker-agent serve acp。
为什么重要
代码 Agent 与传统工具最大的不同，是它会自行决定执行哪些命令。作者在原文中明确提到，即便 Zed 每条命令都要求确认，一次疏忽或项目文件里被注入的提示，也可能触发误删或向未知服务器发起请求。而在宿主机上，Agent 还能通过 env 或读取配置文件接触到 API Key 等敏感信息。
sbx 的价值在于把爆炸半径限制在工作目录和网络策略允许的范围内：出站流量经过带策略的代理，密钥通过 sbx secret set 在代理侧注入，沙箱内不出现明文，Agent 甚至拥有独立 Docker daemon，不会影响宿主机上的容器。这对本地跑开源模型、又希望保留 shell 能力的开发者来说，是一个可以立刻复用的工程思路。
对用户/开发者/创作者的影响
对开发者，这套组合的门槛并不高：llmman 继续跑在宿主机用 GPU 推理，沙箱只承担隔离与网络管控，改动主要集中在 base_url 和 Zed 配置两项。对使用 Claude Code、Codex、Gemini 等 Agent 工具的用户，sbx 本身也提供通用沙箱入口，意味着同一套隔离思路不必绑定 Docker Agent。
AI 工具推荐
想把多个 AI 模型放在一个入口？
GamsGo AI 集成 ChatGPT、DeepSeek、Gemini、Claude、Midjourney、Veo 等常用模型，适合写作、绘图、视频和日常 AI 工作流。
推广链接：通过此链接购买，我可能获得佣金，不影响你的价格。
对团队而言，这把密钥管理与 Agent 权限拆开了：密钥在宿主机声明、由代理注入，Agent 既读不到也带不走，降低了把本地编码助手接入真实项目时的合规风险。目前公开信息显示，作者只验证了本地模型加 ACP 这一条链路，尚未涉及多用户或远程沙箱场景。
值得关注的后续
一是 sbx 的网络策略与密钥注入能否覆盖更多 Agent 运行时，而不仅是 Docker Agent；二是本地小模型在沙箱内长链路 shell 任务中的稳定性，会直接影响这种模式能否走出个人实验；三是 Docker 是否会把此类沙箱能力产品化，与云端 Agent 执行环境形成正面竞争。
