zerostack：用 Rust 重写的编码 Agent，把内存压到 16MB 的代价是什么
Lightweight coding agent written in Rust, optimized for memory footprint and performance
秒懂
- 它是什么？
- zerostack 是一款用 Rust 编写的轻量编码 Agent，README 宣称平均内存占用约 16MB，并提供了多 provider、权限系统、持久记忆、生命周期钩子等大量可编译时裁剪的功能。本文基于仓库文档梳理它的机制、安装路径与真实约束。
- 适合谁用？
- zerostack 适合那些在意常驻内存、愿意用 Rust 工具链自己编译、并且能接受 Linux 优先与文档仍在补齐的工程师；如果你的团队依赖 Windows 桌面、需要开箱即用的图形化配置，或者不愿意为 GPL-3.0 的分发义务做评估，它现在不是合适的选择。上手前先确认三件事：`cargo install zerostack` 默认启用的特性列表是否覆盖你需要的 acp、memory、hooks、advisor；`--sandbox` 在你机器上是否真的装好了 bubblewrap，否则命令会以未沙箱方式运行；以及 `settings.json` 的钩子 schema 与 Claude Code 的兼容程度是否满足你已有的自动化脚本。
- 能商用吗？
- 可以，但有条件。GPL-3.0 是 copyleft 许可证：如果你分发包含它的软件，就必须以同一许可证公开该软件的源代码。只在内部运行、不对外分发，则不会触发这项义务。
- 还在维护吗？
- 在维护。仓库最近一次提交在 1 天前。
- 用什么语言写的？
- 主要是 Rust（依据 GitHub 的语言统计）。
以上回答依据项目的 GitHub 数据（最近同步于 2026年9月15日）和我们的分析，不构成法律意见。
开源项目深度解析
zerostack 解决的是哪个具体问题
编码 Agent 这类工具本身不复杂，复杂的是它的运行时开销。README 给出的对照很直接：zerostack 平均 RAM 约 16MB、峰值约 24MB，而 opencode 等基于 JavaScript 的编码 Agent 被描述为约 300MB、峰值约 700MB。CPU 方面，README 称 zerostack 空闲时 0.0%、调用工具时约 1.5%，对照组是空闲约 2%、工作时约 20%，测试机器标注为 Intel i5 第七代。
这些数字来自项目自己的说明，本文没有复现，读者应当把它当作作者声明而非第三方结论。但方向是清楚的：目标用户是那种会同时开好几个 Agent 会话、或者在内存紧张的开发机上长期挂着 Agent 的人。二进制 26MB、核心约 30k 行代码，这个体量也解释了为什么它把大量功能做成编译时可选，而不是全部塞进默认构建。
它并不试图在功能广度上超过对手。README 自己写明灵感来自 pi 和 opencode，工具集也参照 opencode 文档中描述的标准编码 Agent 工具。zerostack 的差异化在运行时，不在能力清单。
编译时特性开关决定了你实际拿到什么
zerostack 最值得注意的设计是把一批功能做成 gated，也就是需要显式开启的编译特性。README 的安装说明里，默认特性是 loop、git-worktree、mcp、subagents、archmd、status-signals、multithread。而 acp、memory、hooks、advisor、multimodal 这几项被单独列出，需要 `cargo install zerostack --features acp,memory,hooks,advisor` 这样的写法才会编进去。
这个划分不是随意的。被 gated 的功能大多涉及额外的常驻状态或外部进程：持久记忆要读写全局 MEMORY.md 和每项目日志，生命周期钩子要执行外部命令，advisor 要再挂一个模型，ACP 要起一个服务端供 Zed 这类编辑器连接。把它们排除在默认构建外，是维持体积和内存数字的前提。
代价是用户必须提前知道自己要什么。用安装脚本或 Homebrew 装到的版本，特性组合可能与 `cargo install --all-features` 不同，README 没有逐条说明各分发渠道对应的特性集。想确认自己装到了什么，只能回到编译命令本身。
权限、沙箱与钩子构成的三层约束
zerostack 的权限系统提供五种可配置模式，支持按工具的模式匹配、会话级允许列表，以及可配置的模式到规则的应用策略。这是 Agent 工具里比较标准的做法，真正需要留意的是它和另外两层机制的关系。
第一层是沙箱。`--sandbox` 会把每条 bash 命令放进隔离环境，Linux 上依赖 bubblewrap，macOS 上可以改用 zerobox，通过 `sandbox-backend = "zerobox"` 指定后端。README 对它的定位说得很克制：这是一条安全带，不是对抗不可信代码的边界。更关键的是它的失败行为，当所选后端的二进制文件缺失时，bash 命令仍然会执行，只是不带沙箱，仅在日志里留下警告。要让这种情况直接变成硬失败，需要加 `--sandbox-required`，或在配置里写 `sandbox-required = true`。默认配置下，沙箱是尽力而为。
第二层是生命周期钩子，通过外部命令观察或拦截工具调用、提示词和会话事件，`settings.json` 的 schema 与 Claude Code hooks 大体兼容。这给了团队把自有策略插进 Agent 循环的入口，但也意味着钩子本身成了新的故障面：外部命令的失败模式、超时行为，README 没有展开。
记忆与子 Agent 的落盘方式
持久记忆采用纯 Markdown：一个全局 MEMORY.md，加上按项目划分的每日日志、scratchpad 和 notes，每次会话注入系统提示词。这个选择的好处是可读、可 diff、可手工编辑，不依赖数据库；代价是它会持续占用上下文窗口，项目日志越长，注入成本越高。README 提到会话管理支持自动压缩以留在上下文窗口内，但没有说明压缩是否会作用于注入的记忆内容。
子 Agent 被描述为并行且快速，用途是探索代码库。与之配套的是 ARCHITECTURE.md，项目把它称为 AGENTS.md 的伴随文件，目的是让同一代码库上的多个 Agent 共享一份核心知识。这是一个务实的做法：与其让每个子 Agent 重新读一遍目录结构，不如让它们读同一份人工维护的架构说明。前提是这份文件得有人维护，否则它会和代码一起腐烂。
提示词链是另一个协作机制，在 brainstorm、plan、code、review 各阶段之间提供推进建议，每个转换由配置控制开关。它只做建议，不强制流程。
装起来要跑哪些命令
安装脚本是最短的路径：`curl -fsSL https://raw.githubusercontent.com/gi-dellav/zerostack/main/install.sh | bash`。也可以从 GitHub Releases 手动挑 tarball。
用 Cargo 则能精确控制特性：`cargo install zerostack` 走默认特性，`cargo install zerostack --all-features` 全开，`cargo install zerostack --features acp,memory,hooks,advisor` 按需组合。Homebrew 路径需要先 `brew tap gi-dellav/tap`，Homebrew 6.0.0 及以上还要 `brew trust gi-dellav/tap`，然后 `brew install zerostack`。Nix 用户可以用 `nix-run` 直接跑，或通过项目的 overlay 引入 `pkgs.zerostack`。
装完之后，README 建议在 zerostack 内部运行 `/prompt autoconfig` 来交互式浏览文档并完成配置。多 provider 支持覆盖 OpenRouter、OpenAI、Anthropic、Gemini、Ollama 以及自定义 provider。想在终端里编排多个 Agent，需要另外安装同作者的 multistack。
平台、许可与维护成本
README 明确写着 Windows 支持未经任何测试，只欢迎尝试后提 issue。这不是保守措辞，而是当前的实际边界：bubblewrap 是 Linux 专属，macOS 需要换 zerobox 后端，Windows 连沙箱路径都没有对应说明。把 zerostack 放进 Windows 为主的团队，等于把沙箱和平台支持一起放弃。
许可证是 GPL-3.0。这意味着如果你把 zerostack 修改后分发给他人，需要按同一许可证开放对应源码；把它作为内部工具使用则不受分发条款约束。本文不提供法律意见，涉及商业分发时应由法务确认。
维护节奏方面，仓库在 2026 年 9 月上旬连续发布了 v1.8.2、v1.8.3、v1.8.4 三个版本，最后一次推送在 2026-09-09，项目未归档。版本号密集说明仍在活跃迭代，也说明接口和配置项可能变动。gated 特性尤其如此：README 用 gated 标注它们，本身就暗示这些部分尚未稳定到可以默认开启。
与 opencode 的路线差异
README 反复把 opencode 作为对照，两者最根本的区别在运行时选型。opencode 走 JavaScript 技术栈，换来的是成熟的插件生态和更低的参与门槛；zerostack 走 Rust，换来的是作者声明的内存和 CPU 数字，以及一个 26MB 的静态二进制。
这个差异会传导到使用方式上。JS 系 Agent 通常 npm 一把装完，功能全在；zerostack 要求你在安装时就想清楚要哪些编译特性，装完还可能因为缺 bubblewrap 而悄悄退回无沙箱执行。前者把复杂度放在运行时，后者把复杂度前移到构建和部署环节。
功能层面，README 承认标准工具集是参照 opencode 文档实现的，所以工具能力上两者不会有本质差距。真正的取舍是：你要一个开箱即用、生态丰富的 Agent，还是一个体积小、需要自己组装、但常驻内存低一个数量级的 Agent。
编辑结论
zerostack 适合那些在意常驻内存、愿意用 Rust 工具链自己编译、并且能接受 Linux 优先与文档仍在补齐的工程师；如果你的团队依赖 Windows 桌面、需要开箱即用的图形化配置，或者不愿意为 GPL-3.0 的分发义务做评估，它现在不是合适的选择。上手前先确认三件事：`cargo install zerostack` 默认启用的特性列表是否覆盖你需要的 acp、memory、hooks、advisor；`--sandbox` 在你机器上是否真的装好了 bubblewrap，否则命令会以未沙箱方式运行；以及 `settings.json` 的钩子 schema 与 Claude Code 的兼容程度是否满足你已有的自动化脚本。
社区笔记