事件概述

Plimsoll 是一个以 Show HN 形式发布在 Hacker News 首页的开源项目（仓库当前有 75 次提交），定位是运行不可信代码的自托管沙箱服务，主要面向 AI Agent 自动生成并执行的代码。它最核心的主张是：每一次运行的结果都会明确声明这次执行实际处在多强的隔离边界之后，而不是把隔离强度写进一份说明书里。

项目名字来自船体上的 Plimsoll 线（载重线标志）——一条画在船壳外侧、任何人都能检查的载重上限。Plimsoll 把这套思路搬到执行的**隔离层级（isolation tier）**上：运行代码的”墙”有多厚，会作为结果里的一个字段返回。

原文提到该 Show HN 帖获得 9 分、2 条评论，这些数字是抓取时的状态，会随时间变化。

关键技术点

四级隔离等级与 floor 机制

Plimsoll 把隔离强度分成四级，由弱到强依次为：

  • process
  • container
  • kernel
  • vm

隔离等级是每个结果上的一个值，不是数据表里的一句话。请求方可以设置一个 floor，即它能接受的最弱等级；如果守护进程（daemon）达不到这个下限，请求会被拒绝，且任何代码都不会运行，错误标识为 ErrInsufficientIsolation。原文给出的代码示例中，res.Isolation 会报告实际执行的边界，而官方 Go 客户端在结果返回时会再次校验等级。

需要强调的是，这个等级是守护进程收集到的证据（其配置与自身的启动检查），而不是 attestation——不是硬件层面对”正在运行什么软件”的密码学证明。原文明确表示，这里没有任何 provider 提供那种证明。各等级分别依赖什么，见仓库 docs/isolation-tiers.md。

“什么都没运行”的可判定语义

原文特别区分了两类错误。所有”没有运行任何东西”的拒绝都会被标记，并附带原因，原因取值包括：request、permission、protocol、unsupported、isolation、environment、capacity。可以用 sandbox.NotDispatchedReason(err) 读取该标记，无论 provider 是运行在你自己的进程里，还是位于守护进程之后。

没有该标记的错误，可能是在代码已经启动之后才发生的，因此永远不能自动重试。此外，标记只在携带客户端请求 ID 的应答上才生效——这样即使有个代理把某个请求的答案返回给另一个请求，也无法把一次真正运行过的调用伪装成”什么都没运行”。

把”考试”也放进沙箱

同一套机制除了”围住”代码，还能对 Agent 写的代码做一场”考试”。模拟镜像里内置了一个 trial runner，让 Agent 的程序去对抗它自己读不到的场景：每个场景通过一个文件送到 runner，而该文件会在程序启动前被删除。

每次运行都会返回请求发出时与结果返回时的 SHA-256 哈希，官方客户端会重新计算这些哈希。守护进程之外还有一个独立程序 plimsoll-attest，它对已核对的结果进行签名、拒绝调用链中缺失一环的情况，并可重放一次运行。原文强调：考试本身（模拟系统、场景、及格线）始终归你所有，Plimsoll 只提供边界与证据。

原文展示了一个真实运行案例：一个 AI