Open Interpreter 是一套開源編碼代理，在 GitHub 累積 68,541 顆星標與 5,889 次複製，以 Rust 重寫並採用 Apache-2.0 授權。專案的前身是 2023 年發布的 Python 版本，2025 年後改以 Rust 重新實作，並以 OpenAI Codex 為基礎分支，目標是讓低成本模型也能達到接近商用代理的表現。最新版本 rust-v0.0.56 於 2026 年 10 月 7 日發布，本文將從官方儲存庫、發布說明與專案文件出發，分析其架構取向、版本改動與生態定位。
Open Interpreter 是什麼？
Open Interpreter 是以 Rust 重寫的開源編碼代理，分支自 OpenAI Codex，主打讓低成本模型執行終端機編碼任務。
專案的官方定位是「為低成本模型最佳化的編碼代理」。它提供終端機介面，讓使用者以自然語言描述任務，由代理讀取專案檔案、執行命令並修改程式碼；與多數商用代理不同的是，開發團隊把重心放在代理框架（harness）與模型之間的搭配，而非綁定單一供應商的模型。
專案由 Open Interpreter 團隊建立，原始版本於 2023 年 7 月發布，早期以 Python 撰寫並支援本機執行程式碼。其後團隊把重心轉向 Rust，把新的實作建立在 OpenAI Codex 的基礎之上，舊版 Python 專案則由社群接手維護，儲存庫另立為 endolith/open-interpreter。
目標受眾包含使用 Kimi、DeepSeek、Qwen、GLM 等低成本模型的開發者，以及希望在終端機內完成多步驟編碼任務的工程團隊。儲存庫的主題標籤列出 acp、coding-agent、deepseek、kimi、python、qwen 與 rust，反映其跨供應商與跨語言的取向。
Open Interpreter 0.0.56 帶來哪些更新？
rust-v0.0.56 在模型目錄加入 GPT-6.1 Sol 與 claude-sonnet-5-5 選項，並修正在恢復閒置執行緒時重新綁定 shell 環境變數的行為。
本版改動集中在模型支援與執行緒狀態兩處。模型目錄新增 GPT-6.1 Sol（gpt-6.1-sol）的後設資料，同時更新維護中的供應商型錄與文件；Anthropic 方面則加入 claude-sonnet-5-5 選項，並保留各供應商既有的可用性規則與型錄防護機制。
修正項針對長時間工作階段的穩定性。版本調整了恢復可用閒置執行緒時重新綁定既有 shell 環境變數的流程，並加入驗證，確保載入執行緒的 shell 政策不被改變、環境變數值也不會外洩。對需要反覆接續同一工作階段的開發者而言，這類修正直接影響代理能否沿用先前的環境設定。
版本節奏亦值得注意。專案在 2026 年 9 月 30 日連續發布 0.0.54 與 0.0.55，10 月 7 日再推出 0.0.56，儲存庫累積超過 10,767 次提交，顯示重寫後的維護頻率明顯提高。
Open Interpreter 的 Harness 模擬架構有什麼特色？
它可透過 /harness 在十種代理框架之間切換，包含 claude-code、kimi-code 與 qwen-code 等，讓同一介面搭配不同模型。
核心機制稱為 harness 模擬。開發團隊觀察到，同一個模型在不同的代理框架下表現差異明顯，因此把各家供應商推薦的框架重新實作於 Rust 之上，使用者只需在介面輸入 /harness 即可切換。目前可選的框架包含 native、claude-code、claude-code-bare、zcode、kimi-code、kimi-cli、qwen-code、deepseek-tui、swe-agent 與 minimal 共十種。
以 Kimi K3 為例，官方說明指出專案已把供應商推薦的 Kimi Code 框架以 Rust 重新實作，讓該模型在近似 Codex 的介面下取得較佳表現。這種做法把「模型能力」與「框架選擇」拆成兩個獨立維度，使用者可以按成本與任務類型調整，而不必更換整套工具。
沙箱與權限控制是另一項基礎能力。專案在 macOS、Linux 與 Windows 上使用原生沙箱機制執行命令，並支援 exec、MCP、skills、hooks、權限設定與 AGENTS.md 指令檔。內建的 QA skill 則可透過 agent-browser 驅動真實瀏覽器測試網頁，或以 trycua 操作原生應用程式。
Open Interpreter 如何維持與現有工具鏈的相容性？
它支援 ACP 與 Codex 執行協定，可沿用 AGENTS.md 與 .agents/skills 目錄，既有 Codex SDK 只要覆寫執行檔路徑即可改用，無須改寫程式。
相容性建立在共用標準之上。專案支援 Agent Client Protocol（ACP），使用者可在相容的編輯器與客戶端中透過 interpreter acp 啟動代理；同時它遵循 OpenAI Codex 的執行協定，既有的 Codex SDK 只需加入一行執行檔覆寫設定，即可改用 interpreter 作為後端。
檔案與技能目錄採用共享慣例。專案優先使用倉庫層級的 AGENTS.md 與共用的 .agents/skills 目錄，MCP 設定亦可沿用；僅有尚未形成共同標準的設定與執行狀態，才會放在 ~/.openinterpreter 之下。官方把這項取向稱為可攜性，目標是讓使用者能在不同代理之間自由遷移，而非被單一產品格式綁住。
這種設計降低了替換成本。當團隊已建好技能目錄與指令檔，改用另一套代理時不需要重新撰寫內容；反之，若日後要把工作流程搬回原本的工具，既有資產同樣可以保留。
Open Interpreter 在編碼代理生態中扮演什麼角色？
它與 Claude Code、Codex CLI 同屬終端機編碼代理，但主打跨供應商與低成本模型；相較綁定單一模型的工具，更適合預算受限或需多模型切換的團隊。
市場位置與商用代理重疊，取向卻不同。Anthropic 的 Claude Code 與 OpenAI 的 Codex CLI 都把框架與自家模型緊密整合，換取較一致的體驗；Open Interpreter 則保留代理層，讓模型可替換，代價是使用者需自行評估哪一種框架搭配最合適。對於使用 GLM、DeepSeek 等價格較低模型的團隊，這種彈性直接反映在成本上。
與其他開源代理相比，差異在於協定層的投入。部分專案專注於自訂代理迴圈或工具整合，Open Interpreter 則把心力放在模擬供應商推薦的框架，並同時支援 ACP 與 Codex 協定，讓它更容易嵌入既有編輯器與 SDK 生態。
商業模式方面，專案以 Apache-2.0 授權釋出，並透過官方網站提供文件與安裝腳本，未見以託管服務收費的跡象。這種路線讓企業可在內部環境自行部署，但支援與服務保證仍需自行安排。
如何快速開始使用 Open Interpreter？
在 macOS 與 Linux 執行官方安裝腳本，Windows 使用對應 PowerShell 指令，安裝後於終端機輸入 i 或 interpreter 即可啟動工作階段。
安裝流程刻意壓縮為單一步驟。macOS 與 Linux 使用者可執行官方提供的 shell 安裝腳本，Windows 使用者則執行對應的 PowerShell 指令，完成後在終端機輸入 i 或 interpreter 便會啟動互動工作階段。
# macOS 與 Linux
curl -fsSL https://www.openinterpreter.com/install | sh
# Windows（PowerShell）
irm https://www.openinterpreter.com/install.ps1 | iex
啟動後的第一項設定是選擇模型與框架。使用者可在介面內以 /model 切換供應商與模型，或透過 interpreter –chat-completions 指定任何相容 OpenAI Chat Completions 的端點，再以 /harness 選擇代理框架。若要確認與 Codex SDK 的相容性，儲存庫另附本機測試腳本，可在不呼叫供應商的情況下驗證。
Open Interpreter 的統計數據與授權條件為何？
專案累積 68,541 顆星標、5,889 次複製，貢獻者達 616 人，以 Rust 撰寫並採 Apache-2.0 授權。
授權條款屬寬鬆類型。Apache-2.0 允許商業使用、修改與再散布，並附帶專利授權條款，僅要求在副本中保留著作權與授權聲明；相較 MIT，它對專利與商標另有規範，較常被企業內部採用。
維護活躍度可從提交與貢獻者觀察。儲存庫累計超過 10,767 次提交，貢獻者達 616 人，目前有 13 個未結議題與 464 位關注者；專案建立於 2023 年 7 月，最近一次推送為 2026 年 10 月 7 日，版本發布節奏維持在數週一次。
出處連結有哪些？
本文資訊整理自 openinterpreter/openinterpreter 的 GitHub 儲存庫、rust-v0.0.56 發布說明與官方終端機文件。
- GitHub 儲存庫：https://github.com/openinterpreter/openinterpreter
- rust-v0.0.56 發布說明：https://github.com/openinterpreter/openinterpreter/releases/tag/rust-v0.0.56
- Harness 文件：https://www.openinterpreter.com/docs/terminal/harness
- ACP 說明：https://www.openinterpreter.com/docs/terminal/acp
- Codex SDK 相容說明：https://www.openinterpreter.com/docs/terminal/sdk
- 可攜性說明：https://github.com/openinterpreter/openinterpreter/blob/main/docs/portability.md
- Apache-2.0 授權條款：https://github.com/openinterpreter/openinterpreter/blob/main/LICENSE
總結：Open Interpreter 適合什麼團隊？
Open Interpreter 適合預算受限、需在 GLM、Kimi、DeepSeek 等模型間切換，並重視代理可攜性的團隊。
Open Interpreter 的價值在於把編碼代理拆成可替換的兩層。代理層由專案維護，並模擬十種供應商推薦的框架；模型層則交由使用者選擇，涵蓋 Kimi K3、GLM 5.3 等低成本選項。搭配 ACP 與 Codex 協定相容、共用 AGENTS.md 與技能目錄，既有工具鏈多數無須改寫即可接上。
採用前仍須衡量實際條件。框架切換需要時間摸索，不同模型在同一框架下的表現差異仍需自行驗證；專案本身不提供託管服務，沙箱設定、權限政策與版本升級都由團隊負責。若需求集中在單一供應商且重視開箱體驗，商用代理能更快產出結果；若流程分散於多個模型、預算壓力明顯，或需要把代理嵌入既有 SDK 與編輯器，Open Interpreter 的可替換設計便具備明確優勢。是否採用，最終取決於團隊在成本彈性與整合體驗之間的取捨。