Nanocoder：社群集體打造的終端機編碼代理，自備模型與資料邊界
An open coding agent for your terminal, built by a community collective rather than a company. Bring your own model, keep your code on your machine, and owe nothing to anyone.
秒懂
- 它是什麼？
- Nanocoder 由 Nano Collective 以社群集體而非公司的形式開發，主打自備模型、本地優先。本文拆解它的供應商抽象層、四種開發模式與 CLI 啟動方式，並指出它在偏好設定與授權標示上的不確定處。
- 適合誰用？
- 如果你已經在用 Ollama 跑本地模型，或者需要把提示與原始碼留在自己機器上，Nanocoder 的 npm 全域安裝、--provider 與 --model 旗標、以及 --mode plan 的稽核流程都值得先試一輪。若你的團隊需要一份明確的授權條款才能過內部審查，這個專案目前的 NOASSERTION 標示與 README 徽章所顯示的 npm license 並不一致，導入前務必先向維護者確認授權全文。
- 可以商用嗎？
- 請先確認。這個儲存庫使用的授權不在我們自動分類的範圍內，商用前請閱讀儲存庫中的 LICENSE 檔案。
- 還在維護嗎？
- 有在維護。儲存庫在最近一天內有新的提交。
- 用什麼語言寫的？
- 主要是 TypeScript（依據 GitHub 的語言統計）。
以上回答依據專案的 GitHub 資料（最近同步於 2026年9月15日）與我們的分析，不構成法律意見。
開源專案深度解析
它解決的是供應商綁定，不是補全速度
多數終端機編碼代理的預設路徑是把你的程式碼送到某一家廠商的 API。Nanocoder 要處理的問題正好相反：它讓代理迴圈本身與模型供應商脫鉤，你可以用 Ollama 跑本地模型，也可以接 OpenRouter、Anthropic、Google 這類 OpenAI 相容的端點。README 的開頭寫得很直白，you decide which provider runs your code and where your data goes。
目標使用者是已經有本地推論環境、或對資料流向有硬性要求的工程師。這裡的取捨很清楚：本地模型的能力上限由你自己承擔，換來的是提示與原始碼不必離開你的機器。它同時也服務另一種人，就是不想被單一廠商鎖定、想在不同模型之間切換比較的開發者。README 提到集體的專案共享慣例、測試與發布標準，這是它宣稱多供應商立場的制度來源。
要注意的是，這不代表 Nanocoder 本身會替你管理模型。它不內建推論，也不附模型權重，Ollama 或任何相容端點都得你自己先跑起來。
代理迴圈、Skills 與 per-project daemon 的分工
從 README 與 docs 目錄可見的架構分層大致是這樣：最上層是終端機介面與 CLI 旗標，中間是代理迴圈與開發模式，底層是供應商轉接與工具呼叫。docs/features/index.md 把 Skills 拆成四類，commands、subagents、tools、event triggers，另外還有 lifecycle hooks、per-project daemon、checkpointing、task management。
這裡值得停下來看的是 per-project daemon 與 checkpointing 的組合。daemon 以專案為單位常駐，意味著跨 session 的狀態不必每次重建；checkpointing 則讓代理在長流程中留下可回復的節點。對於一次要改動多個檔案的重構任務，這兩者比模型選擇更直接影響可用性。Skills 的 event triggers 則把觸發條件從「使用者打指令」擴展到「事件發生」，這是它與單純聊天式 CLI 最大的結構差異。
供應商抽象層的具體介面形狀，README 沒有展開，docs/configuration/index.md 被列為 providers、MCP servers、preferences、logging、timeouts 的入口。要確認轉接層如何處理不同 API 的差異，只能讀那份文件，本文不代為推測。
安裝與啟動：npm、Homebrew、Nix 三條路
最短路徑是 npm 全域安裝，README 的 Quick Start 給的是這兩行：
npm install -g @nanocollective/nanocoder nanocoder
另外也提供 Homebrew 與 Nix Flakes，細節在 docs/getting-started/installation.md 對應的錨點。CLI 旗標可以在 run 前後出現，README 明說 flags can appear before or after 'run' command，所以這三種寫法等價：
nanocoder --provider openrouter --model google/gemini-3.1-flash run "analyze src/app.ts" nanocoder run --provider openrouter "refactor database module" nanocoder --provider ollama --model llama3.1
最後一行不帶 run，進的是互動模式。開發模式用 --mode 指定，README 列出 normal、auto-accept、yolo、plan 四種，其中 plan 適合先稽核再動手：
nanocoder --mode plan run "audit the auth module"
畫面模式有兩個。預設是 inline，完成的訊息會印進終端機原生 scrollback，離開後逐字稿還在。加上 --alt-screen 或把偏好設定裡的 alternateScreen 設為 true，會切到替代螢幕緩衝區的固定高度版面，內建滑鼠滾輪與 PgUp/PgDn 捲動。這裡有個容易踩到的細節：替代螢幕模式下，滑鼠回報會把點選拖曳選取從終端機手上拿走，README 說要按 Ctrl+P 切換選取模式才拿得回來。--no-alt-screen 可以強制回到 inline，即使偏好設定已開啟。
本地優先的代價：模型能力與工具鏈自負
Nanocoder 把推論外包給你選的端點，這在資料邊界上是優點，在體驗上就是限制。用 Ollama 跑本地模型時，代理迴圈能完成多少工作取決於你機器上的模型，而不是 Nanocoder 的程式碼。README 完全沒有給出任何效能數字，也沒有宣稱特定模型下的成功率，任何這類期待都得由使用者自己在環境裡驗證。
另一個限制來自 MCP servers 與 timeouts 這兩個設定項。docs/configuration/index.md 把它們與 providers、preferences、logging 並列，表示這些都是使用者必須自行配置的部分。代理要呼叫外部工具時，逾時與伺服器可用性直接決定任務會不會中斷，而這些不在 Nanocoder 的控制範圍內。
還有一個實際的失敗模式與畫面模式有關。替代螢幕模式奪走終端機的選取行為，如果你習慣用滑鼠直接複製輸出，第一次用會以為複製壞了。Ctrl+P 是解法，但這需要先知道。
與 Claude Code、Aider 的路線差異
README 自己點出對照組：Screen Modes 一節寫的是 mirroring what Claude Code and Codex ship，也就是說畫面模式的設計是參照這兩個工具而來的。差別在於供應商層。Claude Code 綁定 Anthropic 的模型，Nanocoder 的原則是 multi-provider，你可以今天用 OpenRouter 上的某個模型，明天換成本地 Ollama，指令只差 --provider 與 --model 兩個旗標。
與 Aider 相比，差異不在模型支援廣度，而在擴充機制的位置。Aider 的編輯流程圍繞 git 與 diff 操作，Nanocoder 則把擴充點放在 Skills 的四個分類與 lifecycle hooks 上，再加上 per-project daemon 與 checkpointing。這是兩種不同的賭注：一個賭在版本控制的編輯精度，一個賭在代理行為本身可被專案層級客製化。
這裡沒有客觀優劣。如果你的工作流核心是精準的 diff 套用與 commit 訊息，Aider 的模型更貼合；如果你需要的是把同一套代理行為在不同供應商之間搬移，Nanocoder 的多供應商立場才是它真正賣的東西。
維護節奏、授權標示與升級成本
從 release 紀錄看，v1.28.1 在 2026-06-28，v1.29.0 在 2026-07-26，v1.30.0 在 2026-08-26，大約一個月一個版次，patch 版號出現的頻率不高。最近一次 push 是 2026-09-09，與 v1.30.0 相隔約兩週。這個節奏對一個由社群集體維護的工具來說是可追蹤的，但也意味著你不該期待企業級的回應時間。
授權是這個專案最需要自行查核的一點。GitHub 上標示的是 NOASSERTION，而 README 的徽章區塊裡有一個 npm license 徽章。兩者是否指同一份條款，從現有材料無法確認。README 提到 Economics Charter 與贊助頁面，說明這個集體有金流安排，但這不構成授權條款的說明。任何要把它導入公司環境的人，第一步應該是向維護者取得授權全文，而不是從徽章推論。
升級成本方面，npm 全域安裝的好處是升級就是重下一次安裝，壞處是沒有版本鎖定機制時，不同機器可能跑在不同版本上。偏好設定裡的 alternateScreen 這類鍵值，以及 docs/configuration 底下的設定結構，是跨版本最可能變動的部分，升級前值得先看 release notes 有沒有提到設定格式的調整。
誰該採用，誰該等
已經有 Ollama 環境、或對提示外流有硬性限制的個人開發者與小型團隊，是這個工具最直接的適用對象。你可以先用 nanocoder --provider ollama --model llama3.1 進互動模式，確認本地模型在你的專案上能不能撐住代理迴圈，再決定要不要往 Skills 與 daemon 走。
需要明確授權條款才能過內部合規審查的組織，應該先等授權釐清。這不是對專案的評價，而是 NOASSERTION 這個標示本身在採購流程裡就是一個阻斷點。
最後，如果你的核心需求是精準的 diff 編輯與版本控制整合，Nanocoder 的 Skills 與 event triggers 不是為此設計的，Aider 那條路線更貼近。判斷標準應該放在你的瓶頸是模型供應商，還是編輯精度。
編輯結論
如果你已經在用 Ollama 跑本地模型，或者需要把提示與原始碼留在自己機器上，Nanocoder 的 npm 全域安裝、--provider 與 --model 旗標、以及 --mode plan 的稽核流程都值得先試一輪。若你的團隊需要一份明確的授權條款才能過內部審查，這個專案目前的 NOASSERTION 標示與 README 徽章所顯示的 npm license 並不一致，導入前務必先向維護者確認授權全文。查核順序建議是：先確認授權，再看 docs/configuration 底下的偏好設定檔實際位置，最後才評估 Skills 與 per-project daemon 是否納入日常工作流。
社群筆記