zerostack 产品分析用 Rust 把 AI 编程助手的内存压到 16MB概述AI 编程助手赛道这两年最大的变化之一是终端原生这个方向被越来越多的人认可。从 Claude Code 到 agentty各种工具都在尝试用更轻量的方式把 AI 带进开发者的终端。zerostack 是这个方向上的又一个参与者但它选择了一条和大多数人都不同的路——用 Rust 重写把内存占用压到 16MB二进制文件只有 26MB代码量大约 3 万行。它不是某个大公司的产品而是一个独立开发者 Giuseppe Della Vedova 用两周时间搭出原型、然后持续迭代到今天的开源项目。这篇文章想拆解一下zerostack 到底做了什么怎么做的以及它和同类产品相比到底有什么不一样。产品背景zerostack 诞生的背景其实很清晰。2025 年前后以 opencode 为代表的一批基于 JavaScript/TypeScript 的终端 AI 编程助手开始流行。这类工具功能上已经比较完善但有一个绕不开的问题它们跑在 Node.js 上。Node.js 的内存占用是出了名的高——opencode 这类工具日常运行就要吃掉大约 300MB 内存峰值能到 700MBCPU 空闲时也有 2% 左右的占用。对于一个只是帮你写代码的终端工具来说这个代价太大了。zerostack 的作者显然对这个问题有切身体会。他在博客里提到zerostack 的原型只用了两周就搭出来了灵感来自 pipi.dev和 opencode 两个项目。但和它们不同的是zerostack 从第一天就用 Rust 来写。选择 Rust 不是偶然的——它直接解决了 JavaScript 运行时带来的内存和启动开销问题。从 GitHub 数据来看zerostack 创建于 2026 年 5 月到 7 月中旬已经拿到了 1400 多颗星和 100 多个 fork。对于一个独立开发者的项目来说这个增长速度说明它确实切中了一部分开发者的需求。更深一层看zerostack 的出现也反映了 AI 编程工具领域的一个趋势从功能堆砌转向体验打磨。当基础功能代码补全、文件编辑、命令执行已经被多个产品实现之后差异化就开始出现在性能、资源占用、架构设计这些更底层的维度上。zerostack 选择在这些维度上做到极致而不是去追功能数量。功能分析zerostack 的功能体系可以分成几个层次来看。核心功能多模型支持是基础能力。zerostack 默认使用 OpenRouter但也支持 OpenAI、Anthropic、Gemini、Ollama以及任何自定义的 OpenAI 兼容端点。用户可以通过--provider和--model参数指定也可以在运行时通过/model命令切换。标准工具集覆盖了 AI 编程助手的基本操作read读取文件、write写入文件、edit编辑文件、bash执行命令、grep搜索内容、find_files查找文件、list_dir列出目录、todo待办事项。这些工具的定义参考了 opencode 的文档规范。终端 UI基于 crossterm 构建支持 Markdown 渲染、鼠标选择/复制、回滚浏览、推理过程显示切换等功能。权限系统zerostack 的权限系统设计得比较精细提供了五种模式模式行为restrictive每个操作都需要确认配置规则默认被忽略readonly只允许读取类工具拒绝所有写入和执行guarded允许读取写入/执行需要确认配置规则生效standard默认允许 CWD 内的路径工具安全命令自动放行其他需要确认yolo全部放行但破坏性命令rm、dd、mkfs 等仍需确认权限可以按工具、按文件路径的 glob 模式进行细粒度配置。还有一个会话白名单机制——你在会话中确认过的操作会被记住不需要重复确认。另外还有一个循环检测功能相同的工具调用重复 3 次以上会触发警告或拒绝防止 agent 陷入死循环。Prompt 系统这是 zerostack 比较有特色的设计。它内置了一套可切换的系统提示词让同一个 agent 可以在不同任务模式下工作code默认编码模式完整的文件和 bash 工具访问plan只做规划不写代码review代码审查模式debug调试模式先找根因再修ask只读模式不允许写入或执行brainstorm设计模式只探索想法frontend-design前端设计模式review-security安全审查模式simplify代码简化模式refactor重构模式orchestrator编排模式可以并行调用多个 zerostack 子进程write-text非代码写作模式用户还可以在$XDG_CONFIG_HOME/zerostack/prompts/下放置自定义 prompt 文件。这个设计的思路是用 prompt 切换来替代传统的 Skills 系统——不需要维护一堆技能文件切换一个模式就能改变 agent 的行为。Prompt 链式调用当brainstorm、plan或code模式完成任务后zerostack 可以提示你进入下一个阶段brainstorm → plan → code → review每一步都可以选择继续、停留、或者带着额外指令继续。每个转换可以独立配置是否启用。子代理Subagentszerostack 支持并行子代理用于代码库探索。主 agent 通过task工具发起子代理调用每个子代理是只读的只能用 read、grep、find_files、list_dir、todo通过tokio::spawn并行执行。子代理有独立的模型配置可以用更便宜/更快的模型来做探索工作。Git Worktree 集成zerostack 内置了 git worktree 工作流。通过/worktree name创建并切换到新的工作树/wt-merge合并回主分支/wt-exit不合并退出。退出时还可以配置自动合并--wt-auto-merge遇到冲突时会提示用户选择 abort、手动解决、还是让 agent 帮忙解决。循环系统Loop对于长时间任务zerostack 提供了一个迭代循环机制。通过/loop prompt启动agent 会反复读取任务、执行计划项、运行测试、更新计划直到任务完成或达到迭代上限。也支持通过 CLI 参数启动无头循环模式。其他功能MCP 支持可以连接 MCP 服务器扩展工具能力编译时特性Exa 搜索集成内置 WebFetch 和 WebSearchACP 支持可以作为 ACP agent 被 Zed 等编辑器调用编译时特性持久化记忆基于 Markdown 文件的跨会话记忆系统编译时特性生命周期钩子通过外部命令观察或控制工具调用和会话事件编译时特性Advisor可以让 agent 在会话中咨询第二个模型获取战略建议编译时特性多模态输入支持附加图片和 PDF编译时特性输入队列可以在 agent 运行时继续输入内容会排队等待侧边问题/btw可以在不中断主 agent 的情况下并行提问状态信号通过 Unix socket 发射 start/stop/git-conflict 事件供外部工具监听ARCHITECTURE.md类似 AGENTS.md 的 companion 文件提供架构级上下文解决了什么问题zerostack 解决的核心问题可以归纳为以下几点第一资源占用过高的问题。这是 zerostack 最直接的卖点。基于 JavaScript 的 AI 编程助手opencode 等日常占用约 300MB 内存峰值 700MB空闲时 CPU 占用约 2%。zerostack 把这些数字压到了 16MB 平均内存峰值 24MB和 0% 空闲 CPU。对于在低配机器上工作、或者同时开很多终端会话的开发者来说这个差距是实实在在的。第二功能与性能的取舍问题。很多轻量级工具为了追求性能会砍掉功能但 zerostack 通过 Rust 的零成本抽象和编译时特性门控在保持轻量的同时没有牺牲功能丰富度。它的功能覆盖面和 opencode、Claude Code 基本处于同一水平。第三AI 对代码库理解不够深的问题。通过 ARCHITECTURE.md 机制zerostack 让 agent 在进入会话时就拥有项目的架构级上下文而不是从零开始探索。配合子代理系统agent 可以并行地深入理解代码库的不同部分。第四长时间任务的可靠性问题。循环系统让 agent 可以自主地迭代完成复杂任务不需要用户一步步引导。配合会话压缩auto-compaction机制即使任务很长也不会超出上下文窗口。第五多任务并行的问题。输入队列和/btw侧边问题机制让用户可以在 agent 工作时继续输入或提问不需要等待当前任务完成。子代理系统则让 agent 自身也能并行处理多个探索任务。产品实现分析zerostack 的技术实现在同类产品中算是相当讲究的。整体架构zerostack 的整体架构可以概括为基于 rig 框架的 agent 核心 crossterm TUI tokio 异步运行时。┌──────────────────────────────────────────────────────────────────┐ │ zerostack │ │ │ │ ┌─────────────────────────────────────────────────────────────┐ │ │ │ CLI 层 (clap) │ │ │ │ 参数解析 → 配置加载 → Provider 解析 → 权限模式确定 │ │ │ └─────────────────────────────────────────────────────────────┘ │ │ │ │ │ ▼ │ │ ┌─────────────────────────────────────────────────────────────┐ │ │ │ TUI 层 (crossterm) │ │ │ │ ┌──────────┐ ┌────────────┐ ┌────────────────────────┐ │ │ │ │ │InputEditor│ │ Renderer │ │ SlashCommand 处理 │ │ │ │ │ │(输入编辑) │ │(Markdown │ │ (/model, /loop, │ │ │ │ │ │ │ │ 渲染) │ │ /btw, /prompt...) │ │ │ │ │ └──────────┘ └────────────┘ └────────────────────────┘ │ │ │ │ ┌──────────────┐ ┌──────────────────────────────────┐ │ │ │ │ │Permission │ │ Event Loop (tokio) │ │ │ │ │ │Handler │ │ 用户事件 ←→ Agent 事件 │ │ │ │ │ │(权限检查) │ │ AgentEvent: Token/ToolCall/ │ │ │ │ │ └──────────────┘ │ ToolResult/Done │ │ │ │ └───────────────────┴──────────────────────────────────┘ │ │ │ │ │ │ ▼ │ │ ┌─────────────────────────────────────────────────────────────┐ │ │ │ Agent 核心 (rig) │ │ │ │ ┌──────────┐ ┌──────────┐ ┌─────────────────────────┐ │ │ │ │ │ Provider │ │ Session │ │ Tool Registry │ │ │ │ │ │ 抽象层 │ │(会话管理) │ │ read/write/edit/bash/ │ │ │ │ │ │(OpenAI/ │ │ 压缩/ │ │ grep/find_files/ │ │ │ │ │ │Anthropic/│ │ 恢复 │ │ list_dir/todo/task │ │ │ │ │ │Gemini/ │ │ │ │ │ │ │ │ │ │Ollama) │ │ │ │ [gated] memory/hooks/ │ │ │ │ │ └──────────┘ └──────────┘ │ advisor/multimodal │ │ │ │ │ └─────────────────────────┘ │ │ │ └─────────────────────────────────────────────────────────────┘ │ │ │ │ │ ┌─────────────┼─────────────┐ │ │ ▼ ▼ ▼ │ │ ┌──────────────┐ ┌──────────────┐ ┌──────────────────┐ │ │ │ Subagents │ │ Git Worktree │ │ [Gated Features] │ │ │ │(并行只读探索) │ │ (分支工作流) │ │ ACP/MCP/Memory/ │ │ │ │ │ │ │ │ Hooks/Advisor/ │ │ │ │ │ │ │ │ Loop/Multimodal │ │ │ └──────────────┘ └──────────────┘ └──────────────────┘ │ └──────────────────────────────────────────────────────────────────┘关键技术选择rig 框架zerostack 使用 rig版本 0.39作为 LLM 客户端抽象层。rig 提供了统一的CompletionModeltrait让 zerostack 可以用同一套代码对接 OpenAI、Anthropic、Gemini、Ollama 等不同提供商。流式响应通过StreamingChattrait 处理。tokio 异步运行时整个应用的 I/O 都是异步的。agent 运行在一个 tokio task 中通过mpsc通道向 UI 层发送AgentEventToken、Reasoning、ToolCall、ToolResult、Done。UI 层在另一个线程中处理用户输入和渲染。这种分离让 UI 永远不会因为 agent 的阻塞操作而卡住。crossterm TUI没有使用 ratatui 等更重量级的 TUI 框架而是直接用 crossterm 做终端操作。Markdown 渲染使用 pulldown-cmark 解析然后自行渲染到终端。这样做的好处是依赖更少、二进制更小。mimalloc 内存分配器全局使用 mimalloc 替代系统默认的内存分配器这对小字符串频繁分配的场景SSE 解析、JSON 处理、UI 渲染有明显帮助。编译时特性门控zerostack 大量使用 Rust 的 feature 机制来门控可选功能。默认构建包含 loop、git-worktree、mcp、subagents、archmd、status-signals、multithread。而 acp、memory、hooks、advisor、multimodal、pdf 等功能需要显式启用。这样做的好处是二进制体积更小不需要的代码不会被编译进去编译速度更快运行时没有未使用功能的开销核心模块分析Provider 层src/provider.rs通过AnyClient和AnyAgent两个类型擦除的 trait 对象来统一不同提供商的接口。resolve_provider_config函数根据配置解析出 ProviderKind然后创建对应的 rig client。Agent 构建src/agent/builder.rs负责组装 agent包括系统提示词构建注入 AGENTS.md、ARCHITECTURE.md、当前 prompt 模式的内容、工具注册、权限检查器配置等。Agent 运行src/agent/runner.rsAgentRunner封装了一个正在运行的 agent task持有event_rx接收 AgentEvent 的通道和abort_handle用于取消运行中的 agent。流式响应通过 rig 的StreamingChat获取然后逐事件转发给 UI。权限系统src/permission/PermissionChecker根据当前模式和配置规则决定每个工具调用是否需要用户确认。AskSender通过 tokio mpsc 通道将确认请求发送给 UI 层。权限检查在工具执行之前进行确保没有未授权的操作能够执行。会话管理src/session/Session结构体保存对话历史、token 计数、压缩状态等。支持自动压缩auto-compaction以保持在上下文窗口内。会话持久化到$XDG_DATA_HOME/zerostack/sessions/。子代理系统src/extras/subagents/TaskTool实现了一个task工具接受一个或多个 prompt每个 prompt 启动一个只读子代理。子代理通过tokio::spawn并行执行使用futures::future::join_all收集结果。子代理有独立的系统提示词和工具集只有读工具。内存优化的具体手段zerostack 能做到 16MB 内存不是偶然的而是多个层面优化的结果没有 JavaScript 运行时这是最大的因素。Node.js 的 V8 引擎本身就占用大量内存。Rust 的零成本抽象trait、枚举、模式匹配等高级特性在编译后没有运行时开销。紧凑字符串使用compact_str::CompactString替代String短字符串≤24 字节直接内联存储避免堆分配。SmallVec小向量直接栈上存储减少堆分配。mimalloc针对小对象分配优化的内存分配器。流式处理LLM 响应是流式处理的不需要一次性把整个响应加载到内存中。按需加载通过 feature 门控不需要的功能根本不会被编译进去。安全设计沙箱支持通过 bubblewrapLinux提供命令执行的沙箱隔离权限系统五种模式 细粒度 glob 规则 会话白名单循环检测防止 agent 重复执行相同的破坏性操作工作区边界文件系统工具默认限制在项目目录内编译期安全#![deny(unsafe_code)]禁止所有 unsafe 代码产品优势和同类产品相比zerostack 有几个明显的优势极致的资源效率。这是 zerostack 最核心的竞争力。16MB 内存 vs 300MBopencode0% 空闲 CPU vs 2%26MB 二进制 vs 数百 MB 的 Node.js 运行时。对于在低配机器、远程服务器、容器环境中工作的开发者来说这个差距直接决定了工具能不能用。功能不妥协。很多轻量级工具为了追求性能会砍功能但 zerostack 通过 Rust 的零成本抽象和 feature 门控在保持轻量的同时提供了和 opencode、Claude Code 同一水平的功能覆盖。从多模型支持到子代理、git worktree、循环系统、MCP、ACP该有的都有。Prompt 系统替代 Skills。用可切换的系统提示词来改变 agent 行为比维护一堆技能文件更简单直观。用户不需要学习新的技能格式切换一个模式就能让 agent 从写代码变成做审查或做设计。ARCHITECTURE.md 机制。这是一个很有价值的设计。通过一个结构化的架构文档让 agent包括子代理在进入会话时就理解项目的整体设计而不是从零开始探索。这直接减少了 token 消耗和响应时间。编译时特性门控。用户可以根据需要选择编译哪些功能不需要的功能不会产生任何运行时开销。这比运行时插件系统更高效也比 monolithic 构建更灵活。独立开发者的敏捷性。作为一个独立项目zerostack 的迭代速度很快。从 5 月创建到 7 月已经有 1400 多颗星说明作者对社区反馈的响应很及时。GPL-3.0 许可证也保证了代码的开放性。当然zerostack 也不是没有短板。作为一个相对年轻的项目2026 年 5 月创建它的社区规模和生态还无法和 Claude Code、Cursor 这些成熟产品相比。Windows 支持明确标注为未测试。一些高级功能memory、hooks、advisor、multimodal需要显式启用增加了使用门槛。GPL-3.0 许可证对商业使用有一定限制。总结zerostack 是一个定位清晰、执行到位的产品。它没有试图在所有维度上和 Claude Code、Cursor、opencode 竞争而是精准地切入了一个细分市场追求极致性能和资源效率、同时不想牺牲功能丰富度的终端开发者。从技术实现来看zerostack 的架构设计是扎实的。rig 框架提供了良好的 LLM 客户端抽象tokio 异步运行时保证了 UI 的响应性crossterm 的直接使用减少了依赖和体积feature 门控机制让用户可以按需定制。16MB 的内存占用不是营销数字而是 Rust 语言特性、紧凑数据结构、流式处理、按需编译等多个层面优化的综合结果。Prompt 系统和 ARCHITECTURE.md 是两个值得关注的创新。前者用更简单的方式实现了类似 Skills 的功能后者解决了 agent 对代码库理解不够深的问题。这两个设计如果被更多产品采纳可能会成为 AI 编程助手领域的标准实践。对于一个独立开发者的项目来说zerostack 已经展现出了足够的成熟度和完整性。它可能不会成为主流开发者的首选工具但对于那些在终端里生活、对资源占用敏感、喜欢折腾工具的开发者来说zerostack 是一个值得认真考虑的选择。参考 URLzerostack GitHub 仓库https://github.com/gi-dellav/zerostackzerostack 官网https://gi-dellav.github.io/zerostack/zerostack 架构文档https://github.com/gi-dellav/zerostack/blob/main/docs/ARCHITECTURE.mdzerostack 子代理设计文档https://github.com/gi-dellav/zerostack/blob/main/docs/SUBAGENTS.mdzerostack 记忆系统设计文档https://github.com/gi-dellav/zerostack/blob/main/docs/MEMORY.mdzerostack 配置文档https://github.com/gi-dellav/zerostack/blob/main/docs/CONFIG.mdzerostack 快速开始指南https://github.com/gi-dellav/zerostack/blob/main/docs/GET_STARTED.mdzerostack 提供商文档https://github.com/gi-dellav/zerostack/blob/main/docs/PROVIDERS.md博客What We Built in 2 Weekshttps://rocketup.pages.dev/posts/what_we_built_in_2_weeks/博客How zerostack Memory Workshttps://rocketup.pages.dev/posts/how-zerostack-memory-works/博客How zerostack Subagents Workhttps://rocketup.pages.dev/posts/how-zerostack-subagents-work/Xavier’s Memory Analysishttps://xavierforge.dev/en/posts/zerostack-memory-design/rig 框架https://github.com/0xPlaygrounds/rigopencodezerostack 的灵感来源之一https://opencode.ai/pizerostack 的灵感来源之一https://pi.dev/docs/latest/usage