一個人需要訂閱幾家 LLM 才夠用？答案是 0 家

Claude Max、ChatGPT Plus、Perplexity Max、Gemini Advanced、Cursor Pro、GitHub Copilot……

認真算一下，如果你是重度使用者，一個月訂閱費破 150 美金是基本盤。更誇張的是，訂了之後你還是覺得不夠——這家強 code、那家強 research、另一家強長文。於是繼續加訂閱、繼續付費、繼續覺得少一塊。

我想說一件反直覺的事：這不是訂閱數量的問題，是架構的問題。

一個設計得好的 agent council，用 1 個免費雲端模型 + 幾個本地小模型，完整度不會輸給月費 150 鎂的組合。我把它叫做**「六位一體」**。

換個角度看 AI 產能

多數人有一個隱藏假設：「我的 AI 工具強不強 = 我訂了哪幾家頂級模型」。

但真正決定產能的不是單點模型強度，是 orchestration——誰決定誰做什麼、資訊怎麼流動、結果怎麼匯整。

同一顆 GPT-5，被亂用時只能寫邊角料；被好好 orchestrate 時可以扛起整個系統。差別不在模型，在架構。

於是問題變成：有沒有一種架構，讓我不必訂閱任何一家大模型也能完整運作？

有。

六位一體（零訂閱版）

六個角色，零月費：

硬體需求：任何能塞下 32B Q4 量化模型的機器都行——舊筆電 + 外接 GPU、二手工作站、幾台 Mac mini、甚至幾台 NUC 串起來。你不需要 H100，只需要 48GB 以上 RAM 和一點耐心。

Gemini CLI 是 Google 官方的命令列工具，用 Google 帳號登入就有每天 1000 次免費額度，對個人使用者幾乎等於無限。它負責當 orchestrator，本地模型當 worker。

反差小標：那為什麼不用 AutoGen / CrewAI / LangGraph？

這是會被問的第一個問題。這些框架推銷「讓 agent 自己討論出答案」，聽起來很先進。

實際上三個致命問題：

一、抽象層會吃掉你換模型的自由

這些框架為了支援 "multi-agent conversation" 做了大量抽象，結果你綁死在框架的 agent 生命週期管理裡。哪天想把 GPT 換成本地 Qwen，或想把記憶從 Redis 換成 mem0，要改的不只是一兩行 config——是重構。

二、agent 自主性越高，失控機率越高

Multi-agent 框架的賣點是「agent 會互相協作」，但實際跑起來常常是：它們繞過你預設的分工互相聊天，丟出一個你沒要的答案。小模型尤其嚴重——它們的「創意」通常是幻覺。

三、多 agent 對話 = token 大爆炸

每個 agent 的上下文都要塞進其他 agent 說過的話，token 消耗是幾何級數增長。你以為省了錢，實際是 context 爆量 + 推論時間爆量。

所以我的選擇是——自幹 300 行 bash/python + 檔案 I/O，完勝 3000 行框架。每個 agent 只看自己那一輪要處理的 briefing.md，寫回 answer.md，乾乾淨淨。

四條核心原則

1. Orchestrator 只做決策，不寫 code
   Gemini 只做三件事：判斷路由、包 briefing、綜合 answer。要技術答案就丟給對應 worker，不讓 orchestrator 自己回答。

2. CLI + File I/O，不走長 context
   所有 agent 透過 ~/agent-workspace/briefing.md 和 answer.md 溝通。每次 call 都是獨立的，避免 context 漂移。

3. 禁止 agent 自由發揮
   System prompt 死死框住：「Only do X. Do NOT propose other actions. Do NOT ask follow-up questions.」小模型的創意 = 幻覺。

4. 敏感資料不上雲
   Gemini 免費版會被拿去訓練。隱私任務（內部 code、私人記憶）一律路由到本地 Analyst；只有公開資訊、技術 Q&A 才丟給 Gemini。

四層北極星：為什麼要這樣設計

做這套系統前，先想清楚你的北極星在哪。我的排序：

• L1 省錢：不訂閱雲端大模型
• L2 去 vendor 綁定：Gemini 掛了換 Qwen，Ollama 掛了換 llama.cpp
• L3 長期存續：硬體是自己的，模型是本地的，帳號被封不會死
• L4 保護注意力（最重要）：你不該盯著 dashboard，agent 應該在背景默默完成

L4 是終局。省錢只是表面，真正重要的是把 Claude / ChatGPT 從 default 變成 explicit choice——你不再每件事都先開聊天視窗，而是想好 "這件事該交給誰" 再動作。

建議的啟動順序

不要一次架六顆。從最小迴路開始：

1. 第一階段：Gemini CLI → 1 顆本地 Analyst → 回 Gemini
2. 第二階段：加第二個 worker（Engineer），教 Gemini 判斷 "這題該丟誰"
3. 第三階段：接 mem0 記憶層
4. 永遠保留 fast path：急事直接開 Gemini CLI 問，不走 orchestrator

每一階段都要穩定跑 1-2 週再加下一個。多數人失敗在一次全上，然後每個組件都半殘。

結語

如果你現在每個月被 LLM 訂閱費追著跑，不是你該換便宜的那家，是該換架構。

六位一體不是規模問題，是觀念問題。它不需要你有 H100、不需要你訂 Claude Max、不需要你是 infra 工程師。它只需要你接受一件事——

AI 的產能不在訂閱費，在 orchestration。

你可以用 0 元月費組出一個完整的 agent council。前提是你願意放棄「讓 agent 自己聰明起來」的幻想，改成你親手設計每個 agent 的邊界、讓它們乖乖 input/output。

這不是技術問題，是設計哲學。

如果你對完整的實作細節（Ollama 安裝、mem0 自架、Gemini CLI 串接）有興趣，後續會出 part 2。

我是江中喬，一位具有 TPM 與產品管理背景的 AI 系統建構者，目前專注於 AI 認知增強系統與多 Agent 協作架構的設計與實踐。