zerostack：用 Rust 重寫的輕量 coding agent，記憶體足跡壓到 16MB

zerostack 針對的是哪一種成本問題

多數 coding agent 的資源曲線是這樣的：啟動慢、常駐記憶體高、閒置時 CPU 仍在跑事件迴圈。zerostack 把這件事當成主要設計目標，而不是事後優化。README 的 Performance 段落給出四個數字：核心程式碼約 30k LoC（不含測試）、二進位檔 26MB、平均 RAM 約 16MB 且峰值約 24MB、閒置 CPU 0.0% 而使用工具時約 1.5%。同一段也拿 opencode 這類 JS 實作對比，稱其 RAM 約 300MB、峰值約 700MB，閒置約 2%、工作時約 20%。這些數字來自專案自己的 README，量測環境寫的是 Intel i5 第七代，我沒有重跑驗證，讀者應把它當成作者提供的參考值。

目標使用者因此很清楚：在記憶體吃緊的機器上跑 agent 的人、同時開好幾個 agent 的人、以及把 agent 當成長時間背景程序而非一次性互動工具的人。專案另外提供 multistack，README 描述為「parallel agent manager」，用來從終端協調多個 zerostack 實例。如果你的工作模式是一次只跑一個 agent、而且機器記憶體充裕，那 zerostack 最主打的優勢對你幾乎沒有意義，你該比較的是工具鏈與權限設計。

供應商抽象與工具層：多供應商不是賣點而是前提

zerostack 支援 OpenRouter、OpenAI、Anthropic、Gemini、Ollama，以及自訂供應商。工具集方面，README 的說法是「all of the standard tools exposed to coding agents, as described by the opencode documentation」，也就是它沒有自創一套工具語意，而是對齊 opencode 的文件定義。這個選擇的實際意義是：模型端的 tool calling 行為、以及你對 agent 工具集的既有認知，可以沿用。

幾個具體機制值得注意。第一個是 prompts system：可以在執行期切換系統提示模式（`code`、`plan`、`review`、`debug` 等），README 明確把它定位成「不用管理 Skills 就能調整 agent 行為」的替代路徑。第二個是 prompt chaining，會在 brainstorm → plan → code → review 各階段完成後提議推進，而且每個轉換點由設定控制。第三個是 ARCHITECTURE.md，專案把它描述成 AGENTS.md 的同伴檔案，用途是讓多個 agent 在同一份程式碼庫上共用核心知識。這三件事合起來看，zerostack 對「agent 之間如何共享上下文」有明確立場：用檔案，而不是用隱含的對話歷史。

Subagents 用於探索程式碼庫，README 稱其為平行且快速。Advisor 則是另一個模型，讓主 agent 在 session 中途諮詢策略建議，並有可選的人工接手模式。兩者都是 gated feature，這點在下一節會展開。

編譯期 feature gate 是 zerostack 最需要先讀懂的一頁

zerostack 把一批功能放在編譯期開關後面，README 直接標為 gated 的有：ACP 支援、persistent memory、lifecycle hooks、advisor、multimodal input。這意味著用預設參數安裝，你拿到的不是完整功能集。

安裝路徑有三條。腳本安裝是 `curl -fsSL https://raw.githubusercontent.com/gi-dellav/zerostack/main/install.sh | bash`。Cargo 安裝則區分預設與完整：`cargo install zerostack` 的預設 feature 組合是 loop、git-worktree、mcp、subagents、archmd、status-signals、multithread；`cargo install zerostack --all-features` 打開全部；也可以指定，例如 `cargo install zerostack --features acp,memory,hooks,advisor`。Homebrew 走 `brew tap gi-dellav/tap`、`brew trust gi-dellav/tap`（README 註明 Homebrew 6.0.0+ 需要這步）、`brew install zerostack`。Nix 則提供 nix-run、profile 安裝與 overlay 三種用法。

這裡的判斷很直接：如果你打算用 persistent memory 或 hooks，Cargo 這條路比腳本安裝更可控，因為你能明確列出 feature。反過來說，`--all-features` 會把 ACP server、MCP、sandbox 相關依賴全部拉進來，與「最小足跡」的初衷有張力，README 沒有說明各 feature 對二進位大小或記憶體的實際影響，這是我在材料中找不到答案的地方。安裝完成後，README 建議在 zerostack 內執行 `/prompt autoconfig`，以互動方式瀏覽文件並完成設定。

權限模式、sandbox 與那個「best effort」註記

zerostack 的權限系統有五種可設定模式，支援 per-tool pattern、session 層級的 allowlist，以及可設定的 mode-to-rule 套用策略。它與 lifecycle hooks 是兩層不同的控制：權限決定工具呼叫是否放行，hooks 則可觀察或攔截工具呼叫、提示與 session 生命週期事件，透過外部指令執行，schema 與 Claude Code hooks 大致相容。

sandbox 這塊需要特別讀。`--sandbox` 會把每條 bash 指令放進隔離環境，README 的定位很誠實：這是 seatbelt，不是對抗不受信任程式碼的 boundary。後端有兩個，bubblewrap 與 zerobox；bubblewrap 僅限 Linux，macOS 上要改用 zerobox，安裝方式是 `cargo install zerobox`，並在設定裡指定 `sandbox-backend = "zerobox"`。

關鍵限制寫在 README 裡：`--sandbox` 是 best effort，當所選後端執行檔不存在時，bash 指令仍會執行，只是不隔離，並在日誌留下警告。要把它變成硬性要求，得加 `--sandbox-required`，或在設定中寫 `sandbox-required = true`（README 原文在此處被截斷，只到「turn that into a guara」，完整敘述無法從材料確認）。對 CI 或自動化場景，這個差別是實質的：預設行為是靜默降級，你必須主動指定 required，否則隔離失效只會出現在日誌裡。

持久記憶走純 Markdown，代價是每回合都要注入

persistent memory 是 gated feature，設計是跨 session 的純 Markdown：一個全域 MEMORY.md，加上每個專案的 daily logs、scratchpad 與 notes，每次 session 開始時注入系統提示。專案有兩篇設計說明可讀，README 連結了「memory design」與「xavier's memory analysis」兩篇外部文章。

這個設計的優點是可審計：記憶就是你能用編輯器打開、diff、進版控的檔案，沒有向量資料庫，沒有嵌入模型，也沒有檢索階段的不可預測性。缺點同樣來自這個選擇。既然內容是每回合注入系統提示，記憶規模就直接吃掉 context window，而 zerostack 的應對是 auto-compaction。也就是說，記憶越有用，壓縮越早觸發，而壓縮本身是有損的。README 沒有給出記憶檔案大小與壓縮頻率的建議門檻，這是我認為文件最薄的一塊：實際使用時你得自己觀察 daily log 累積速度，決定什麼該留在 MEMORY.md、什麼該留在 per-project notes。

另一個未解的問題是隱私邊界。全域 MEMORY.md 跨專案共用，如果你同時處理多個客戶的程式庫，哪些內容會從 A 專案流入 B 專案的系統提示，取決於你自己怎麼寫這個檔案。工具不會替你分區。

與 opencode 的差異不在功能清單，在執行模型

zerostack 的 README 開頭就說它受 pi 與 opencode 啟發，工具集也對齊 opencode 文件。所以拿 opencode 當替代方案時，真正要比的不是「有沒有某個工具」，而是執行模型。

opencode 是 JS 生態，zerostack 是 Rust 單一執行檔。這個差異會傳導到三件事上。部署方面，zerostack 可以用 Cargo、Homebrew、Nix 或 tarball 取得，不需要 Node 執行環境；而 JS agent 通常綁定 Node 版本與 npm 依賴樹。資源方面，README 給出的對比是 16MB 對 300MB 的常駐記憶體。擴充路徑方面，zerostack 的擴充主要靠編譯期 feature 與外部指令形式的 hooks，opencode 則靠其生態的套件。

反過來，Rust 加編譯期 feature 也有代價。想改一個 gated 功能的行為，你面對的是重新編譯，而不是改個設定或裝個外掛；`--all-features` 雖然能一次打開全部，但你同時失去了對依賴面的控制。如果你的團隊已經圍繞 JS 生態建了工具鏈，例如自訂的 MCP server 或既有的 hook 腳本，遷移成本會落在這些周邊而非 agent 本身。zerostack 的 MCP 支援是預設 feature 之一，hooks 的 schema 又與 Claude Code 大致相容，這兩點確實降低了遷移摩擦，但 README 用的是「largely compatible」，不是完全相容，實際欄位差異需要你自己對照。

生命週期、發版節奏與 GPL-3.0 的實際含義

專案未封存，最後推送時間是 2026-09-09，最近三個版本 v1.8.2、v1.8.3、v1.8.4 分別落在 2026-09-06 與 2026-09-07，也就是兩天內三個 patch。發版密集是事實陳述，不代表品質，但對採用者有一層實務意義：如果你打算鎖定某個版本並自行編譯，patch 之間可能夾帶行為調整，你的建置流程要能指定確切版本，而不是跟著 main 走。

授權是 GPL-3.0。這是 copyleft 條款，如果你把 zerostack 散布給外部（包含以修改版本形式提供給客戶，或在產品中隨附），會觸發相應的源碼提供義務。純內部使用通常不構成散布，但邊界取決於你的具體情境，這不是本文能替你判斷的，需要法務確認。值得注意的是專案本身有贊助與捐贈管道（Ko-fi 與 sponsor 聯絡信箱），README 也提到公司贊助，但這與授權條款是兩件事，贊助不會改變 GPL-3.0 的義務。

維護成本落在兩個地方。第一是 feature 組合：你必須自己維護一條可重現的建置指令，因為預設安裝拿不到 gated 功能。第二是 sandbox 後端的可用性，bubblewrap 在 Linux 上要另外安裝，macOS 要改用 zerobox，而後端缺失時預設是降級執行。這兩件事都不難，但都需要寫進你的環境說明，而不是留給下一個接手的人去猜。

編輯結論

如果你在意的是常駐記憶體與啟動開銷，而且能接受自己編譯、自己承擔 GPL-3.0 的義務，zerostack 值得排進候選名單；如果你的團隊需要 Windows 正式支援、需要有人對穩定性負責，或無法接受 GPL-3.0 的散布條件，那它現在不是合適的選擇，因為 README 明說 Windows 未經任何測試。動手前先確認三件事：你要的 gated feature（acp、memory、hooks、advisor、multimodal）是否已在你的建置指令裡打開；`--sandbox` 在你的機器上是否真的生效，而不是降級成 unsandboxed 並只在日誌留下警告；以及 `settings.json` 的 hooks schema 與你既有 Claude Code 設定能對上多少。

官方來源

1. gi-dellav/zerostack on GitHub
2. License: GPL-3.0
3. Project website
4. README
5. Releases