jcode：用共享守護程序把 20 個並行編碼代理壓進 91 MB 記憶體

概覽：把「記憶體佔用」當作第一性指標的編碼代理外殼

jcode（1jehuang/jcode）是一個用 Rust 編寫的終端編碼代理「harness」（外殼），MIT 許可，支援 Linux、macOS 和 Windows。專案自我定位只有兩句話：最省記憶體，也最聰明。它和 Claude Code、Codex CLI、OpenCode、GitHub Copilot CLI、Cursor Agent、pi、Antigravity CLI 屬於同一賽道，但取捨很不一樣：別人把力氣花在模型提示詞和工具鏈上，jcode 先把執行時本身做到極致輕量，再在其上疊加記憶圖譜、多代理協作（swarm）和高速終端渲染。

安裝只需一行：macOS 與 Linux 用 `curl -fsSL https://jcode.sh/install | bash`，Windows 11 用 PowerShell 的 `irm https://jcode.sh/install.ps1 | iex`。在 TUI 中執行 `/update`，或在終端執行 `jcode update`，即可後臺下載最新穩定版並保留會話過載。README 還寫明瞭防降級策略：版本更舊或相同則跳過；開發版會把本地二進位制的 Git 提交與釋出標籤比較；無法驗證祖先關係時寧可停止更新，也不冒降級風險。預設通道是 `features.update_channel = "stable"`，顯式設為 `"main"` 才跟隨原始碼分支。

核心架構：一個共享守護程序，多個輕客戶端

jcode 最關鍵的設計在於「會話共享同一個守護程序（daemon）」。README 對無頭（headless）會話的測量說得很直白：jcode 的多個會話共享一個 daemon，而 Claude Code 為每個會話啟動一個 `claude -p --input-format stream-json` 程序。程序模型的差別，直接決定了記憶體曲線的斜率。

作者給出的無頭會話基準（每個會話完成 5 輪真實模型呼叫，包括列目錄、讀檔案、倉庫搜尋、總結、回覆，然後統計所有相關程序的 PSS 總和；兩者都使用 claude-sonnet-4-6）資料如下：1 個會話時 jcode 為 32.6 MB，Claude Code 為 261.0 MB，約 8.0 倍；5 個會話時 51.0 MB 對 908.6 MB，17.8 倍；10 個會話時 66.7 MB 對 1749.7 MB，26.2 倍；20 個會話時 90.6 MB 對 3376.8 MB，37.3 倍。每新增一個會話，jcode 約增加 3.1 MB，Claude Code 約增加 164 MB，相差約 54 倍。測試日期為 2026-09-29，版本為 jcode v0.89.19-dev（預設構建，未編譯本地嵌入）與 Claude Code 2.1.267，可用 `python3 scripts/bench_headless_memory.py` 復現。

這組數字的意義在於斜率，而不是絕對值。當你把代理當作「可批次啟動的工人」使用，比如同時跑 20 個並行任務，Claude Code 路線需要約 3.4 GB，jcode 路線約 91 MB。記憶體不再是並行度的瓶頸，瓶頸轉移到模型配額和呼叫成本上。

互動式效能：首幀 14 毫秒

除記憶體外，README 還測了啟動延遲，方法是 10 次互動式 PTY 啟動。首幀時間：jcode 14.0 ms（範圍 10.1 到 19.3 ms），Antigravity CLI 383.5 ms，pi 590.7 ms，Codex CLI 882.8 ms，OpenCode 1035.9 ms，GitHub Copilot CLI 1518.6 ms，Cursor Agent 1949.7 ms，Claude Code 3436.9 ms（範圍 2032.7 到 8927.2 ms），後者約為 jcode 的 245.5 倍。首次可輸入時間：jcode 48.7 ms，Claude Code 3512.8 ms，約 72.2 倍。

互動式記憶體對比裡數字更復雜，也更誠實。單會話時，關閉本地嵌入的 jcode 為 27.8 MB，開啟本地嵌入的 jcode 為 167.1 MB，pi 為 144.4 MB，Codex CLI 為 140.0 MB，Claude Code 為 386.6 MB。也就是說，開啟本地語義嵌入後，jcode 的單會話佔用並不比 pi 和 Codex 低。優勢出現在擴充套件時：10 個會話時，jcode 為 260.8 MB（關閉嵌入為 117.0 MB），Codex CLI 為 334.8 MB，pi 為 833.0 MB，Claude Code 為 2300.6 MB，OpenCode 為 3237.2 MB。每增加一個會話的額外 PSS：jcode 約 10.4 MB，Codex CLI 約 21.6 MB，pi 約 76.5 MB，Claude Code 約 212.7 MB，OpenCode 約 318.4 MB。

記憶系統：向量嵌入加記憶圖譜

jcode 的「聰明」主要來自 agent memory。按 README 的描述，每一輪對話與回覆都會被嵌入為語義向量；每輪都會在記憶圖譜裡做餘弦相似度查詢，找出相關記憶條目，注入對話，或者交給一個「記憶側代理」（memory sideagent）先核驗相關性再注入。

寫入側同樣是非同步的：當出現語義漂移、距上次提取已過 K 輪、會話結束等條件時，側代理會提取記憶並寫入圖譜。此外還有顯式的記憶工具，讓主代理可以主動檢索或儲存，不必完全依賴被動後臺流程；並提供會話搜尋，對歷史會話做傳統 RAG。最後，環境（ambient）模式會定期整理記憶：重組、檢查過期與衝突。這套設計把「被動召回、主動讀寫、後臺整理」三條通路分開，思路接近人類的聯想記憶加覆盤。

多代理 Swarm：伺服器感知的協作

在同一倉庫裡啟動兩個以上代理，伺服器會自動管理，實現原生協作。關鍵機制是衝突感知：當代理 A 編輯了代理 B 讀過的檔案（程式碼在 B 腳下發生了變化），伺服器會通知 B。B 可以判斷無關而忽略，也可以重新讀取。代理還能自主呼叫 swarm 工具生成隊友，此時主代理變成協調者，被生成的代理成為工人。

配置層面，swarm 模式把根代理的推理強度和工人強度分開：`~/.jcode/config.toml` 中 `[agents]` 下的 `swarm_root_effort`（對應 `/effort swarm`）和 `swarm_deep_root_effort`（對應 `/effort swarm-deep`），預設均為 `max`，可選 `none`、`minimal`、`low`、`medium`、`high`、`xhigh`、`max`，並對映到各提供商支援的範圍；環境變數為 `JCODE_SWARM_ROOT_EFFORT` 與 `JCODE_SWARM_DEEP_ROOT_EFFORT`。這些設定不改變工人的 `swarm_effort`。「根代理少想、工人多做」或「根代理深想」可按任務成本切換。

提供商與生態：訂閱登入加 OpenAI 相容

jcode 支援訂閱型 OAuth 登入，讓你沿用已付費的模型額度，必要時回退到直連 API。內建登入包括 Claude、OpenAI/ChatGPT/Codex、Google Gemini、GitHub Copilot、Azure OpenAI、Alibaba Cloud Coding Plan、Fireworks、Novita AI、MiniMax、Meta Model API、LM Studio、Ollama，以及自定義 OpenAI 相容端點。內建的 OpenAI 相容檔案還包括 openrouter、deepseek、zai、kimi、moonshotai、opencode 等。原生 OpenAI 提供商使用 Responses WebSocket v2，帶機會性的後臺預熱，並可回退到 HTTPS。

面向指令碼和代理的 `jcode provider add` 命令可以一步寫入檔案，支援 `--api-key-stdin`（金鑰不進 shell 歷史）、`--api-key-env`、`--context-window`、`--no-api-key`（本地 vLLM、Ollama 等無需認證的服務）。`extra_body` 與環境變數 `JCODE_OPENAI_EXTRA_BODY` 允許向請求體注入非標準欄位，例如 NVIDIA NIM 上 DeepSeek-V4 需要的 `chat_template_kwargs` 才會啟用思考。還有 Anthropic Messages 相容閘道器檔案（`type = "anthropic-compatible"`），支援 Bearer、自定義頭或無認證。流式空閒超時預設 180 秒，高推理強度會自動放大（high 為 2 倍，xhigh 為 3 倍，max 為 4 倍）。

MCP 方面，jcode 讀取 `~/.jcode/mcp.json` 與專案內 `.jcode/mcp.json`，併相容 Claude Code 的 `~/.claude.json`、倉庫根的 `.mcp.json`，且是每次實時讀取，不復制快照。目前只支援 stdio 伺服器，HTTP/SSE 型別會被識別並跳過；每個請求預設 30 秒超時，可用 `timeout_secs` 調整。從 Codex CLI 遷移時會一次性匯入 `~/.codex/config.toml`，匯入的環境變數可能含金鑰，需要留意。

介面工程：為速度而生的自研元件

作者自己寫了一個不依賴瀏覽器和 TypeScript 的 mermaid 渲染庫（mermaid-rs-renderer），聲稱圖表渲染快 1800 倍，使側邊欄與聊天區可以內聯渲染流程圖。`panel` 工具可用 Markdown 或 PDF 開啟桌面面板。

「資訊小部件」只佔用螢幕的空白區域，空間不足時自動讓位。jcode 聲稱渲染可超過每秒一千幀，以避免閃爍。自定義滾動回看帶來更多能力，但終端層面無法做到平滑的半行滾動，所以作者又做了自己的終端 Handterm。

影響、侷限與觀察

對開發者而言，jcode 的價值在於把「並行代理」的邊際成本壓到接近零：筆記本上同時跑幾十個會話不再是記憶體問題。對企業而言，OAuth 訂閱複用、Anthropic 與 OpenAI 相容閘道器、自定義請求頭和自託管 vLLM 的支援，使它可以接入內部閘道器。

需要保持審慎的幾點。第一，所有基準都由專案作者在自己的 Linux 機器上完成，尚無獨立復現；各表使用的版本也不完全相同（無頭測試用 v0.89.19-dev 與 Claude Code 2.1.267，互動式表格則列出 jcode v0.9.1888-dev 與 Claude Code 2.1.86），橫向比較時應看清口徑。第二，PSS 反映的是記憶體而非任務質量，「最聰明」是自我宣稱，README 的資料並沒有證明代理的解題能力優於對手。第三，開啟本地嵌入的單會話記憶體並不佔優，優勢依賴共享守護程序和關閉嵌入的配置。第四，MCP 暫不支援 HTTP/SSE，Windows 與 macOS 的表現 README 未給出資料。第五，共享守護程序意味著故障域更集中，一個 daemon 的崩潰會影響所有會話，這類取捨文件中沒有展開。

總體看，jcode 提供了一個值得關注的方向：先把代理外殼做成真正的輕量基礎設施，再討論記憶與協作。如果你在做大規模並行程式碼代理、CI 裡的批次評審，或者在低配開發機上工作，它值得親自跑一遍 `scripts/bench_headless_memory.py` 來核實資料。