mitsuhiko：AST 解释器不宜作 agent 沙箱唯一隔离

10 月 10 日，知名开发者 mitsuhiko（《抛弃 Docker》等文作者）在与网友讨论 codemode（让 agent 生成并执行代码）的实现方案时，系统阐述了他对代码沙箱隔离的顾虑：他不放心把 AST 解释器作为代码执行的唯一隔离机制，因为实现工作量大、沙箱化非常棘手，甚至对仅靠 wasm/worker 做隔离也有所保留。

已确认

• mitsuhiko 说明自己最初否决了共享进程的 codemode 方案（不使用 QuickJS），原因是复杂度高、缺乏 proper isolation；他认为这类路线是合理的，但自己用着不放心。
• 他给出了核心论据：基于长期维护 jinja2/minijinja 的经验，这类模板引擎对完全不可信的输入本就不安全——除非在中间再加一道操作系统级别的隔离边界。这解释了他为何认为共享 worker 等方案不足。
• 在与 Dev Agrawal 的讨论中，他针对「把生成代码放到独立 worker 里执行是否就够了」给出实测：如果只做基础隔离、让多个调用共享同一个 worker，一段死循环代码会耗尽内存，把机器拖垮（附实例演示）。
• 在同一讨论串中他补充：opencode 用 AST 解释器做代码执行的权衡是可以接受的，但如果是今天从零开始做 Pi，他不会从这条路线起步。
• 开发者 thdxr 解释其团队在 codemode 实现中刻意没有采用 QuickJS：它会引入 wasm 复杂性、强制使用 worker 线程，还要在主线程与 worker 之间来回序列化数据，并建议正在实现类似功能的人参考他们的做法。

为什么重要

• 随着 agent 让模型生成并执行代码成为主流模式，沙箱隔离是否可靠直接决定安全边界；mitsuhiko 的观点代表了谨慎派：单一隔离手段（AST 解释器、共享 worker 甚至 wasm/worker）都不应被绝对信任，实现者需要在复杂度与隔离强度之间做出明确取舍。

2026-10-10 ~ 2026-10-10 · 8 条相关

• 【源头】开发者弃用 QuickJS 做 codemode:规避 wasm 复杂度与序列化开销 — cravenceiling · 2026-10-10
• 【源头】mitsuhiko:AST 解释器不宜作 agent 沙箱唯一隔离手段 — mitsuhiko · 2026-10-10
• mitsuhiko:opencode 的隔离权衡可接受,Pi 不会照搬 — mitsuhiko · 2026-10-10
• mitsuhiko：因复杂度与隔离不足，未采用共享进程的 codemode 方案 — mitsuhiko · 2026-10-10
• mitsuhiko 质疑 code mode 方案：共享 worker 隔离不足有风险 — mitsuhiko · 2026-10-10
• 【源头】mitsuhiko：模板引擎跑不可信输入，不加 OS 级隔离就是不安全 — mitsuhiko · 2026-10-10
• mitsuhiko 演示:AI agent 沙箱里共享 worker 跑死循环会拖垮内存 — mitsuhiko · 2026-10-10

另有 1 条近重复转述:mitsuhiko