gptme：終端機裡的長駐代理，從 CLI 到自主運行的距離
Your agent in your terminal, equipped with local tools: writes code, uses the terminal, browses the web. Make your own persistent autonomous agent on top!
秒懂
- 它是什麼？
- gptme 是一個以 Python 撰寫、MIT 授權的終端機 AI 代理，提供 shell、Python、網頁瀏覽等工具，並支援多種模型供應商與本地模型。本文檢視它的架構、擴充機制、實際限制，以及它與 Claude Code 等產品的本質差異。
- 適合誰用？
- gptme 適合已經熟悉終端工作流、願意自己組裝代理的工程師，尤其是需要跨平台（Linux、macOS、Windows）或想在 CI、tmux、headless 伺服器上跑代理的人。它不適合想要開箱即用、圖形介面優先的開發者，也不適合需要高度封閉整合的企業團隊。
- 可以商用嗎？
- 可以。MIT 是寬鬆授權：你可以使用、修改並販售以它為基礎的軟體，只需保留著作權與授權聲明。
- 還在維護嗎？
- 有在維護。儲存庫在最近一天內有新的提交。
- 用什麼語言寫的？
- 主要是 Python（依據 GitHub 的語言統計）。
以上回答依據專案的 GitHub 資料（最近同步於 2026年9月15日）與我們的分析，不構成法律意見。
開源專案深度解析
終端機代理的早期先行者，現在仍在前線
gptme 自稱是 2023 年春季最早的 agent CLI 之一，初始 commit 在 2023 年 3 月。這個時間點比許多人熟悉的 Claude Code 或 Codex 都早。它不是一個包裝好的 IDE 外掛，而是一個直接在終端機裡運作的代理，強調「anywhere a terminal runs」：筆電、ssh session、tmux、無頭伺服器、CI pipeline。它的目標使用者是那些不排斥命令列、想要讓 AI 直接操作本機工具的人。專案以 Python 撰寫，授權 MIT，主分支持續活躍，最後一次 push 在 2026 年 9 月，代表它不是被遺棄的實驗。從 README 的新聞時間軸可以看出，它從 2023 年至今幾乎每個月都有功能更新，例如 2025 年加入 MCP 支援、plugins、lessons、背景任務，2026 年推出桌面應用程式與雲端服務。這種演進速度說明開發團隊維持著高強度投入，但也暗示了學習曲線可能不低。
核心機制：工具呼叫與本地優先的資料流
gptme 的運作方式可以從它提供的工具窺見。它內建 shell、Python、網頁瀏覽、vision 等工具，代理透過這些工具與系統互動。文件描述它支援 Anthropic、OpenAI、Google、xAI、DeepSeek、OpenRouter，也能透過 llama.cpp 完全本地運行。這代表使用者的對話記錄與工具產生的資料，可以留在自己的機器上，不必上傳到第三方伺服器。一個關鍵設計是「內容可定址儲存」，在 v0.31.0 加入，這暗示了代理的對話與工具輸出是以內容雜湊來管理，而不是依賴傳統的資料庫索引。這種方式對於長期運行的代理特別重要，因為它讓上下文可以重複引用而不需要重複傳輸。另一個機制是「背景任務」，讓代理可以在前景對話之外繼續執行工作，這與 tmux 工具的整合相呼應。整體資料流可以想成：使用者在終端輸入指令，gptme 將訊息送給模型，模型決定呼叫哪個工具，工具執行後將結果回傳，模型再根據結果決定下一步。這個循環是代理的基本架構，但 gptme 的差異在於它把工具權限開到最大，包括 shell 與檔案修改，而不是限制在沙盒中。
取得與啟動：真正的指令與設定
根據 README，安裝方式是從 PyPI 安裝套件，指令為 pip install gptme，因為專案有 PyPI 頁面。啟動後，你需要設定模型供應商的 API 金鑰，例如 Anthropic 或 OpenAI，或者指向本地 llama.cpp 伺服器。具體的環境變數名稱在提供的材料中沒有列出，但文件網站 gptme.org/docs/getting-started.html 應該有詳細步驟。實際使用時，你可以在終端機輸入 gptme 來啟動互動式 session，然後用自然語言要求它執行任務。例如，你可以叫它「建立一個新的目錄並初始化 git」，它會依序執行 shell 指令。若要讓它自主運行，專案提供了 gptme-agent-template，這是一個範本，內含自主運行迴圈與增強的上下文產生。README 提到 Bob 這個代理已經用這個範本長時間自主運行，並監控 GitHub。這表示 gptme 不只是單次互動的工具，而是可以設計成持續運作的代理。但要注意，這些範本與文件是分散在不同 repository，例如 gptme-contrib 存放社群 plugins，gptme-webui 提供網頁介面，gptme.vim 整合 Vim。你需要自己拼湊這些元件。
擴充機制：plugins、skills 與 lessons 的界線
gptme 的擴充方式分為三層：plugins、skills、lessons。Plugins 是程式碼層級的擴充，可以在 v0.30.0 之後動態載入，社群 plugins 存放在 gptme-contrib，包括 Twitter/X、Discord bot、email 工具與 consortium（多代理協作）。Skills 與 lessons 則偏向行為層級。Lessons 系統在 v0.29.0 加入，目的是提供「情境引導」，也就是代理可以從過往經驗中學習，在類似情境下套用特定知識。這與 RAG 不同，gptme-rag 是另一個獨立專案，專門做檢索增強生成。換句話說，lessons 是代理自己累積的規則，而 RAG 是外部知識庫。這種分層設計讓使用者可以選擇：要寫程式擴充功能，用 plugins；要教代理特定工作流程，用 lessons；要串接外部工具，用 MCP。MCP 支援在 v0.28.0 加入，v0.29.0 加入動態載入與探索，代表代理可以根據任務需求動態尋找可用的 MCP 伺服器。這是一個靈活的架構，但也意味著你需要理解三種不同機制的適用情境，而不是單一解決方案。
自主代理的實際樣貌：Bob 與 agent-template
README 中的 Bob 是一個具體例子，說明 gptme 如何被用來建立持久自主代理。Bob 從 2025 年 10 月開始自主運行，結合 GitHub 監控，並在 2026 年 1 月升級到 v0.4，加入自主運行迴圈與增強上下文產生。這個案例顯示 gptme 的設計目標不只是互動式輔助，而是讓代理可以在背景持續運作，監控事件並採取行動。要做到這點，你需要 gptme-agent-template，它提供一個起點，但實際的監控邏輯、決策規則、錯誤處理都要自己寫。這與 Claude Code 這類產品不同，後者主要是互動式 session，你下指令它執行，不會自己跑去監控 GitHub。gptme 的自主模式需要你設計迴圈：代理檢查某個狀態，決定是否行動，執行後記錄結果，然後重複。這個過程會消耗大量 token，所以 v0.31.0 加入成本追蹤功能，讓你可以監控花費。如果你沒有成本控管機制，自主代理可能會不知不覺燒掉預算。
真正的限制與錯誤的使用情境
gptme 最大的限制是它給予代理完整的 shell 與檔案存取權限。這在互動模式下還可以接受，因為你可以在每個步驟確認，但在自主模式下，代理可能會執行破壞性指令，例如刪除檔案或覆寫設定。README 提到了 guardrails，但沒有詳細說明具體的保護機制，這是一個需要你去文件確認的關鍵點。另一個限制是模型依賴性：雖然支援多種供應商，但不同模型的工具呼叫能力差異很大，本地模型如 llama.cpp 可能無法穩定執行複雜的多步驟任務。再者，gptme 的介面是終端機，沒有圖形化編輯器，對於習慣 IDE 的開發者來說，學習曲線明顯。它也不適合需要嚴謹稽核軌跡的企業環境，因為代理的行為記錄方式可能不符合合規需求。最後，gptme 的版本更新非常頻繁，v0.33.1.dev 系列幾乎每週都有開發版，這代表 API 可能隨時變動，你的 plugins 或 lessons 可能因為升級而失效。如果你追求穩定，這會是一個痛點。
與 Claude Code、Codex 的本質差異
README 直接點名 Claude Code、Codex、Cursor、Warp 為替代方案，但 gptme 的定位與它們有根本不同。Claude Code 是 Anthropic 推出的封閉工具，深度整合 Claude 模型，並綁定 Anthropic 的 API。Codex 是 OpenAI 的類似產品，同樣與特定供應商綁定。Cursor 與 Warp 則是圖形化介面，前者是編輯器，後者是終端機。gptme 的核心差異是「provider-agnostic」與「local-first」：它不綁定任何模型，你可以用 Anthropic、OpenAI、Google、xAI、DeepSeek，或完全本地模型。這在資料隱私與成本控制上有實際意義，例如你可以用便宜的 DeepSeek 跑日常任務，用 Claude 處理複雜邏輯。另一個差異是自主性：Claude Code 與 Codex 主要是互動式工具，你必須在 session 中下指令，而 gptme 透過 agent-template 可以設計成背景自主運行的代理。如果你只需要一個互動式編碼助手，Claude Code 的整合度可能更好，因為它針對 Claude 模型最佳化，工具呼叫更順暢。但如果你要打造一個不受供應商綁定的自主代理，gptme 的開放架構是明顯優勢。
維護成本與授權考量
gptme 使用 MIT 授權，這代表你可以自由使用、修改、商用，甚至封閉原始碼，只要保留版權宣告。對於企業內部工具，這是一個低摩擦的選擇。但維護成本來自於兩方面：一是跟上專案更新，因為版本迭代快速，你需要定期閱讀 changelog，文件網站有提供 changelog 頁面。二是自己維護 plugins 與 lessons，因為這些是獨立於核心的程式碼，當 gptme 更新時，你的擴充可能不相容。社群 plugins 存放在 gptme-contrib，這表示核心團隊不直接維護這些 plugins，品質可能參差不齊。另外，gptme 依賴多個外部模型 API，這些 API 的價格與可用性變動會直接影響你的運行成本，v0.31.0 加入的成本追蹤功能可以幫助你監控，但你需要自己設定預算警報。如果你是個人開發者，這些成本可能可控，但如果是團隊部署，你需要建立一個流程來測試新版本對現有代理的影響。
編輯結論
gptme 適合已經熟悉終端工作流、願意自己組裝代理的工程師，尤其是需要跨平台（Linux、macOS、Windows）或想在 CI、tmux、headless 伺服器上跑代理的人。它不適合想要開箱即用、圖形介面優先的開發者，也不適合需要高度封閉整合的企業團隊。採用前應先確認兩件事：一是你偏好的模型供應商是否有對應的 provider 設定，二是你是否有能力處理工具誤用造成的檔案或系統變更，因為 gptme 的設計哲學是給代理完整終端權限，而不是限制它。若你只是要一個輔助寫程式碼的工具，Claude Code 或 Cursor 可能更省事；但若你想打造一個能自主監控 GitHub、背景執行任務的持久代理，gptme 的 plugins、lessons 與 agent-template 提供了具體的起點。它的活躍開發從 2023 年持續至今，版本更新頻繁，但這也意味著你必須跟上變動，不能期待長期穩定的 API。
社群筆記