当 AI 代理开始替你写代码、跑命令，一个绕不开的问题浮出水面：这些代码该在哪里执行？Plimsoll 给出的答案是——自托管沙箱。
发生了什么
Hacker News 上出现了一个名为 Plimsoll 的 Show HN 项目，定位是“为你的 AI 代理所写代码准备的自托管沙箱”。从标题和摘要来看，它瞄准的是 AI 代理生成代码后的执行环节：代理写完代码，不能直接扔进宿主机运行，而是先进入一个隔离环境。目前该项目在 HN 上获得了一定关注，但具体实现细节、支持的语言和隔离机制尚未在摘要中展开。
为什么重要
过去一年，编码代理（coding agent）从补全单行代码进化到能自主修改文件、安装依赖、执行测试。能力越强，风险越大：代理可能误删文件、引入恶意依赖，或者被提示注入攻击后执行危险命令。传统的做法要么是让代理在本地裸跑，要么依赖云端沙箱服务。前者不安全，后者意味着代码离开你的机器。Plimsoll 选择自托管路线，切中的正是那些既想要隔离、又不愿把代码交给第三方的团队。
这和近期一系列动态一脉相承：从 OpenAI 的 Codex 到各类开源代理框架，都在强调“可执行”能力，但执行环境的安全模型始终模糊。Plimsoll 把“沙箱”单独拎出来作为一个产品，说明市场开始意识到，代理的可靠性不只取决于模型，还取决于它脚下的地面是否稳固。
影响与看点
对开发者而言，自托管沙箱意味着可以更放心地让代理在 CI/CD 或本地开发环境中执行任务，而不必担心污染主机。对平台方来说，如果沙箱成为标配，代理的部署门槛会进一步降低，但也会带来新的运维复杂度——谁来维护沙箱的镜像、网络策略和资源限制？
值得关注的几个点：一是隔离强度，是容器、microVM 还是更轻量的方案；二是与现有代理框架的集成成本；三是自托管带来的更新和安全补丁责任。目前 Plimsoll 还处于早期，HN 上的讨论热度也有限，但它提出的问题很实在：当 AI 代理成为代码的主要生产者，执行环境的安全边界必须重新设计。
一个独立判断：沙箱不会让代理变得绝对安全，但它能把“信任”从模型转移到基础设施上，这可能是代理走向生产环境的必要一步。
