Zerostack - 純粋なRustで書かれたUnix風コーディングエージェント

 (crates.io)
1 ポイント 投稿者 GN⁺ 4 시간 전 | 1件のコメント | WhatsAppで共有
  • zerostackはRustで書かれた最小構成のコーディングエージェントで、複数のLLMプロバイダーとカスタムプロバイダーをあわせてサポートする
  • ファイルの読み取り・書き込み・編集、grep、ファイル検索、ディレクトリ一覧、権限ゲート付きのBash実行、MCP、Exa Webツールを提供する
  • 約7千LoC、8.9MBのバイナリで、RAMは空のセッションで約8MB・作業中で約12MB、CPUはアイドル時0.0%と測定されている
  • 既定のプロバイダーはOpenRouterで、cargo install zerostackでインストールでき、--sandboxでBash分離を使うにはbubblewrapが必要
  • code・plan・reviewなどの組み込みプロンプト、4種類の権限モード、セッション再開、反復ループ、Git worktrees統合を含む

zerostack 概要

  • zerostackはRustで書かれた最小構成のコーディングエージェントで、piとopencodeに着想を得ている
  • OpenRouter、OpenAI、Anthropic、Gemini、Ollama、カスタムプロバイダーをサポートするマルチプロバイダー構成を持つ
  • ファイルの読み取り・書き込み・編集、grep、ファイル検索、ディレクトリ一覧のようなファイルツールと、権限ゲート付きのBash実行を提供する
  • セッションの保存・読み込み・再開、コンテキストウィンドウ維持のための自動圧縮、crosstermベースのターミナルUI、MCPサーバー接続、ExaベースのWebFetch・WebSearchツールを含む
  • /worktreeでGit worktree間を移動でき、長時間作業向けの反復ループも統合されている

性能とインストール

  • zerostackは約7千LoC規模で、バイナリサイズは8.9MB
  • RAM使用量は空のセッションで約8MB、作業中で約12MBであり、opencodeや他のJSベースのコーディングエージェントの約300MBと比較されている
  • CPU使用率はアイドル時0.0%、ツール使用中で約1.5%と測定されており、Intel i5 第7世代ではopencodeがアイドル時約2%、作業中約**20%**と比較されている
  • インストールにはCargoとgitが必要で、次のコマンドを使う 
    cargo install zerostack
  • --sandbox使用時にすべてのBashコマンドを隔離環境で実行するには、bubblewrapをインストールする必要がある 
    # Debian/Ubuntu  
apt install bubblewrap  

# Fedora  
dnf install bubblewrap  

# Arch  
pacman -S bubblewrap

クイックスタート

  • 既定のプロバイダーはOpenRouterで、APIキーは環境変数で設定する 
    export OPENROUTER_API_KEY="[api_key]"
  • 対話型セッションは既定のプロンプト code で実行される 
    zerostack
  • 一度だけ実行するモードでは -p でプロンプトを渡す 
    zerostack -p "Explain this project"
  • 最後のセッションは -c で続きから実行する 
    zerostack -c
  • プロバイダーとモデルを明示できる 
    zerostack --provider openrouter --model deepseek/deepseek-v4-flash

プロンプトシステム

  • zerostackは、エージェントの挙動や口調を変える組み込みシステムプロンプト群を含む
  • 目標は、superpowerやClaude公式skillsを代替できるプロンプト群を作ること
  • /promptで登録済みプロンプトを一覧表示したり、別のプロンプトへ切り替えたりできる

  • 組み込みプロンプト

    • code は既定値で、完全なファイル・BashツールアクセスとTDDワークフローを使うコーディングモード
    • plan はコードを書かずに探索したうえで計画を作る、計画専用モード
    • review は正確性、設計、テスト、影響を確認するコードレビューモード
    • debug は修正案を出す前に根本原因を見つけるデバッグモード
    • ask は読み取り専用モードで、read・grep・globのみを許可し、書き込みやBashは許可しない
    • brainstorm はコードを書かずにアイデアを探索し、設計を提示する設計専用モード
    • frontend-design は独自性があり本番レベルのUI向けフロントエンドデザインモード
    • review-security は悪用可能な脆弱性を探すセキュリティレビューモード
    • simplify は動作を変えずに明快さを高めるコード簡素化モード
    • write-prompt はエージェントプロンプトを作成・最適化するプロンプト作成モード
    • カスタムプロンプトは、$XDG_CONFIG_HOME/zerostack/prompts/にMarkdownファイルを置き、名前で参照して作成できる
    • プロジェクトルートまたは親ディレクトリのAGENTS.mdまたはCLAUDE.mdを自動で読み取り、システムプロンプトに挿入し、-nまたは--no-context-filesで無効化できる

権限システム

  • zerostackは、最も安全な方式から最も許容的な方式まで4種類の権限モードを提供する

  • 権限モード

    • restrictive または -R は、設定で明示的に許可されていないすべてのツール操作ごとに承認を求める
    • standard は既定値で、ls、cd、git log、cargo checkのような安全なコマンドは自動承認し、書き込みや破壊的操作は確認を求める
    • accept-all または --accept-all は、作業ディレクトリ内のすべての操作を自動承認し、外部パスは確認を求める
    • yolo または --yolo は、プロンプトなしですべての操作を自動承認する
    • 設定ファイルでツールごとのglobパターンを指定して、権限を細かく構成できる
    • たとえば write **.rs を自動許可しつつ、他のファイル書き込みは常に確認を求めるようにできる
    • セッション許可リストは、承認済みの判断をセッション中保持し、同じ操作を繰り返し確認しないようにする
    • 同一のツール呼び出しが3回以上繰り返されると、doom-loop検知が警告プロンプトを表示するか、設定に応じて拒否し、エージェントが破壊的作業を繰り返せないようにする

スラッシュコマンドとセッション管理

  • 主なスラッシュコマンドは、モデル、思考レベル、会話、セッション、ループ、プロンプト、権限モードを制御する
  • /model はモデルを切り替え、/thinking は思考レベルを設定する
  • /clear は会話を消去し、/session はセッションを一覧表示・保存・読み込みする
  • /loop は反復プロンプトを予約し、/prompt はエージェントプロンプトを一覧表示または変更する
  • /mode は権限システムのモードを設定し、すべてのコマンドは/helpで確認する
  • セッションは$XDG_DATA_HOME/zerostack/sessions/に保存される
  • -c は直近のセッションを再開し、-r はセッションを参照して選択し、--session <id> は特定のセッションを読み込む

反復ループ

  • zerostackは、長時間作業向けの反復コーディングループを含む
  • エージェントは作業を繰り返し読み、計画から項目を選び、作業を実行し、テストを実行し、計画を更新し、作業完了または反復上限到達までループを続ける
  • ループシステムは実験的機能

  • ループの使い方

    • /loop Implement the user authentication system は指定したプロンプトでループを開始する
    • /loop stop はアクティブなループを停止する
    • /loop status は現在のループ状態を表示する
    • 各反復には、元の作業、変化するLOOP_PLAN.md、前回反復の要約、検証出力が含まれる
    • ループが有効な間は、スラッシュコマンドでない入力はブロックされる

  • CLIベースのヘッドレスループ

    • 次のコマンドでヘッドレスループを実行できる 
      zerostack --loop --loop-prompt "Refactor the API" --loop-max 10 --loop-run "cargo test"
    • --loop はヘッドレスループモードを有効にする
    • --loop-prompt <text> は各反復で使うプロンプトを指定する
    • --loop-plan <path> はカスタム計画ファイルのパスを指定し、既定値はLOOP_PLAN.md
    • --loop-max <N> は最大反復回数を指定し、既定値は無制限
    • --loop-run <cmd> は各反復後に実行する検証コマンドを指定する

Git worktrees統合

  • zerostackは、ブランチ単位の作業フローをgit worktreeで提供する
  • チャットUI内でworktreeを作成し、その中で作業し、マージし、離脱できる
  • Git worktrees統合は実験的機能

  • worktreeコマンド

    • /worktree <name> は <name> ブランチにgit worktreeを作成してそこへ移動し、すでに存在する場合は作成をスキップする
    • /wt-merge [branch] はworktreeブランチを[branch]へマージし、pushし、後片付けを行ったあとメインリポジトリへ戻る
    • /wt-exit はマージせずにメインリポジトリへ戻る

  • 例のワークフロー

    • /worktree feature-x は新しいブランチとworktreeディレクトリを作成してそこへ移動する
    • 以後は通常どおりzerostackを使えば、変更はfeatureブランチに残る
    • /wt-merge はエージェントにブランチのマージ、push、後片付けを行わせたうえでメインリポジトリへ戻らせる
    • /wt-exit はマージせず即座にメインリポジトリへ戻る

対応プロバイダーとライセンス

  • 既定のプロバイダーはOpenRouter
  • OpenAI互換プロバイダーとしてvLLM、LiteLLMなどをサポートする
  • Anthropic、Gemini、Ollamaをサポートする
  • カスタムプロバイダーは$XDG_CONFIG_HOME/zerostack/config.jsonで任意のbase URLとAPIキー環境変数により構成できる
  • ライセンスはGPL-3.0-only

関連記事

1件のコメント

 
GN⁺ 4 시간 전
Hacker Newsのコメント

  • こういうツールにはあまり詳しくないのですが、Claude Code のようなモデル／ツールと比べてどんな利点があるのか気になります

  • 余暇に似たようなものを自作していて、エージェントをより深く理解したいのと Rust を学ぶのが目的でした
    ただ、pi の 設定可能性 は維持したいと思っています。自分で変形したり新しいツールを生成したりする能力がとても有用で、こうしたツールが bash を通じた任意コード実行権限を持つべきではないと考えているからです
    もちろん edit と cargo run にアクセスできれば依然として任意コード実行は可能ですが、bash のないエージェントで何かやる必要が出たら、その都度ツールを生成する方針です

    • この問題は考えましたが、Pi は TypeScript ベースなのでスクリプト的な環境を持てる一方、Rust は コンパイル言語 なので制約があります
      そのため、別の形でカスタマイズを許可することにしました。~/.config/hypernova/prompts/ のプロンプトライブラリは Skills のシンプルな代替で、組み込みプロンプトが superpowers と Claude の frontend-design を置き換える想定です
      エージェントを重くし得る機能はコンパイル時の feature flag で無効化でき、コードは短く読みやすいので、必要なら zerostack 自身に zerostack を走らせてカスタム fork を作ることもできます
      権限モデルは README にある通りかなり考えた末に、コマンドのない「Restrictive」からエージェントが望むままに動く「YOLO」までの 4 段階にしてあり、bash 呼び出しには許可／確認／拒否の正規表現も設定できます。この場合は zerostack -R を実行するだけで、すべてのツールに権限確認を強制できます
      プログラマブルなエージェント機能も作業中ですが、まだ発表できる段階ではありません
    • 自分も同じようなものを Zig で作っています

  • 最近、半分冗談・半分本気で 200 行未満のものも作りました: https://github.com/pnegahdar/nano
    REPL、セッション、非対話実行、承認などの機能が入っています。モデルが賢くなるほど、開発者体験を除けば ハーネス の重要性は下がると思っています
    そのうち SWE-bench で回してみるかもしれません

    • 200 行、実際には 190 行だけで作ったなんて本当にすごいですね
      自分も先週、遊びと学習のためにひとつ自作して、たいていのコーディングエージェントのように設定済みの mcpServers との統合まで動くようにしました
      何がなぜ必要なのかを段階的にまとめてあります: https://nb1t.sh/building-a-real-agent-step-by-step/

  • 「RAM footprint: ~8MB on an empty session, ~12MB when working」
    この点が良いです。Claude Code は数 GB 使うので、低スペックのノート PC ではかなりつらいです

    • Go でエージェントフレームワークを作っていますが、とても軽いです
      起動時間は 0.5 秒未満で、RAM 使用量も非常に少ないです。12 年前のノート PC でも重くならず普通に動きます
      本質的には文字列連結エンジンに近いものなので、古いハードウェアを含めてどんなマシンでも遅くなる理由はありません
    • Zed へ移ろうとしているところですが、Agent Client Protocol はかなり良さそうに見えます。Claude Code がこの方式を通るとメモリ圧迫がどれだけ減るのか気になります
      1: https://zed.dev/acp
    • そうですね。この一点だけでも、多くの人が一度試してみる理由になる気がします
    • メモリ使用量 が素晴らしいので、今では shellbox.dev の x1 のような非常に小さなインスタンスでもコーディングエージェントを動かせます
    • LSP プラグインのようなものが一緒に動いていないか確認した方がよさそうです

  • 家に帰ったら試してみたいです。軽くて速いツールはコーディング体験に大きな違いを生みます
    プロンプト方式が、一般的な スキルとサブエージェント の組み合わせと比べて実際どうなのか気になります。自分はビルド失敗があると /fix-ci スキルを実行し、サブエージェントにエラーメッセージ・スタックトレース・関連ログを取り出させて問題を解かせる、といった形でよく組み合わせて使っています
    統合テストで DB クエリの問題が出たら、エージェントが自分で、あるいは自分が少し誘導して、読み取り専用 DB アクセスのスキルを呼んで調査することもあります。長く深く掘る必要がある時は、「Sonnet サブエージェントを使って、DB クエリスキルでこの挙動をデバッグするよう指示して」のように言います
    スキルは即席で追加能力を与え、サブエージェントは文脈肥大を防ぐために隔離してくれます。エージェントが bash で別のプロンプト付きで自分自身を実行すれば似たことはできそうですが、少し滑らかさに欠けそうなので実際に確認してみたいです

    • 多くの場合はスキルのように使いますが、「コマンド」よりは 環境 と考える方が近いです
      たとえば統合プロンプトのひとつである /prompt debug はデバッグ中心のエージェントを開き、その状態で通常のエージェントのように会話し、/prompt code で標準のコーディングエージェントに戻れます
      サブエージェントについては、現在はエージェント全体が 1 つのコンテキストバッファで動いているため、軽量性を保つ目的でまだ対応していません。ただ、探索の多い作業ではコンテキストウィンドウが膨らみやすいので、サブエージェントが追加される可能性は高いです

  • 自分も Claude Code にこういうものをひとつ作らせて、編集には Dirac の ラインハッシュ も入れました
    Rust を使い、プラグインでフックを実装して自己修正可能にすることも考えましたが、最終的には改善点の詳細を別ファイルに作らせて、ソースコードを更新してから再コンパイルする方式に落ち着きました
    ソースコードの場所が固定されているので、エージェントが自分自身を書き換えてビルドできます。2x RTX 6000 Pro で DeepSeek 4 Flash を回して使っていて、だいたい 138 tok/s くらい出ています
    正直、Pi、Dirac、OpenCode を真似したようなものです。ここから盗めるような新しいテクニックはありますか？

    • 軽さ以外で面白い機能としては、プロンプトライブラリ、Git worktree 統合、Ralph Wiggum ループ統合を入れています
    • GitHub で公開されているのか気になります

  • 少し触ってみましたが、実際かなり速かったです
    コントリビューターを探しているのか、それとも個人用ツールとして作っているのか気になります
    ただ、別のモデルを使おうとしていくつか問題に当たりました。Azure の gpt-5.5 は OpenAI 互換エンドポイントを使っても max_tokens が max_completion_tokens に変わっていて動きません
    カスタムヘッダーを渡す方法もないようで、DeepSeek モデルに reasoning_effort を指定できませんでした

    • PR は歓迎します
      言われた内容はコードベース上の明確なバグなので、可能であればバグごとに GitHub issue を立ててもらえると助かります

  • Claude Code と Opencode は自分の環境ではよく動きます
    コーディングエージェントはデータセンターで 1000W 以上の電力と 2TB 以上のメモリを使って動いているのに、人々はノート PC の最後の数 W と数百 MB のメモリに注目しているのが少し面白いです
    どうせコードのコンパイルにかかるエネルギーコストに比べれば埋もれてしまいますが、それでももっと速く軽くするのは悪いことではありません

    • データセンターは専用電源で動いていますが、自分のノート PC は バッテリー で動いています
      今コーディングエージェントを使うとバッテリーの減りがかなり速く、ほとんどの作業が自分のノート PC 上で起きていないことを考えると驚きます
      クライアント側のコーディングエージェントを効率化するのは気候を救うためではなく、勤務時間を延ばすためです。実際には気候にはもっと悪いのかもしれません
    • 当然、人は自分のコンピュータで動くソフトウェアに注目します
      他人のコンピュータで動くソフトウェアは自分の問題ではありません。他人のサーバーで何が動いているかは制御できませんし、たとえできても、その RAM コストを自分が払うわけではないので気にしません
      一方で自分のマシンの RAM は自分が負担します。1KB 未満のテキストを表示する TUI が数 GB のメモリを占有して Windows で他のアプリを OOM で落としたり、Linux で HDD にスワップしてマシン全体を止めたりすれば、気にしないわけにはいきません
      RAM の価格が実際に 5 倍、他の部品価格も 2〜3 倍になっている状況では、メモリ浪費 を避けることは特に重要です
    • それは単純化しすぎです
      モデルが巨大で資源を大量に使うのは事実ですが、ハーネス はモデルがどれだけ多く使われるかに大きく影響し得ます
      たとえばハーネスに強力なツールセットがあれば、モデルははるかに効率よく作業できます

  • コードベースが小さいので、Pi 内の DeepSeek v4 Flash に渡して危ない部分がないかざっと見てもらいましたが、特に心配な点は見つかりませんでした。よくできています

    • OP がコードのかなりの部分を DeepSeek V4 Flash で生成したと言っていたので、古い依存関係がないか確認してみました
      Rust プロジェクトでは、モデルに Cargo.toml を直接編集させず cargo add を使うよう指示しないと、Claude 4.7 Opus でさえほぼ毎回古い依存関係を追加する、という経験があります
      このプロジェクトの依存関係を手で確認してみたところ、すべて最新バージョンだったので良かったです。もちろん、推移的依存関係の中に問題が潜んでいないという意味ではありません
      LLM にコードレビューをさせる話はすぐ好みの問題になりがちです。たとえばコードを目で追っていて、文字列と enum を行き来するいくつかのメソッドを見たとき、「これは strum で #[derive] ひとつ付ければ済むのでは」と思いました。依存関係のない crate をひとつ追加する代わりに、provider.rs はかなり簡潔になるはずです
      面白半分で DeepSeek V4 Pro の Max thinking にコードベースを「監査」させてみたところ、隠れたテレメトリの明白な痕跡はないとのことでした。ただし、プロジェクトが panic handler を abort に設定している点を指摘していて、ここには強い意見があります
      おそらくバイナリサイズを数 KB 減らすために libunwind のリンクを避けたのだと思いますが、その結果、クラッシュ時に即座に中断し、ユーザーにスタックトレースを出さないバイナリになります。panic 時に有用なデバッグ情報が得られるなら、バイナリが約 50KiB 大きくなる方がましだと考えます
      また、非同期タスクで panic が起きた場合、回復して通常のエラーメッセージを表示することもできず、プロセス全体がただちに終了します
    • コードのかなり大きな部分は DeepSeek v4 Flash が書き、TUI ロジックの一部は自分で書きました
      DeepSeek が特定のカーソル移動ロジックで何度も失敗したからです。メモリ最適化の過程はすべて自分で管理し、他のコメントで書いたように、コンパイラ最適化と、より効率的なデータ構造を活用するための Rust crate の利用を組み合わせました
    • 「Pi 内の DeepSeek v4 Flash に渡して危ない部分を見てもらった」というやり方は、プロンプトインジェクション のせいでかなり甘い調査ではありませんか？

  • ちょうど今日出たというのが面白いですね。自分もちょうど Rust でひとつ書き始めようとしていたところでした
    大きなプロジェクトで opencode がじわじわメモリリークして 6GB まで膨らみ、どんどん遅くなっていくのを見ると驚くほどです
    一度見てみます。よさそうです

    • そうです。このプロジェクトは、古いノート PC で Firefox と opencode のインスタンスを 2 つ以上同時に開いたら OOM killer が発動したことがきっかけで始まりました