OpenCode 2 於 2026 年 9 月 11 日正式推出，把這個累積 219,545 顆星標的開源編碼代理帶進第二代架構。專案由 Anomaly 團隊以 TypeScript 開發、採 MIT 授權，自 2025 年 4 月建立以來，已從單一終端工具擴張為包含終端介面、桌面應用、伺服器與模型市集的完整產品線，最新版本 2.1.2 於 10 月 21 日發布。
OpenCode 2 是什麼？
OpenCode 2 是開源 AI 編碼代理的第二代，採 MIT 授權，提供終端、桌面與伺服器元件，內建 build 與 plan 兩種代理角色。
專案的定位在 README 中寫得相當直白：一套在終端運行的開源編碼代理。它不綁定特定模型供應商，透過設定檔描述供應商、模型與變體，再把使用者的自然語言指令轉換為檔案編輯、指令執行與版本控制操作。V2 在此基礎上加入伺服器與桌面客戶端，讓同一個工作階段可以在不同介面之間延續。
與第一代最大的結構差異，在於產品被拆成多個獨立元件。儲存庫現有 tui、desktop、server、console、client、plugin、sdk 等目錄，終端介面與桌面應用共用同一套伺服器，外部整合則透過 SDK 與 HTTP 介面接取。這種拆分讓團隊可以把代理嵌入自有系統，而不必依附官方介面。
商業層面同步落地。官方推出 OpenCode Zen 模型市集與 OpenCode Go 訂閱方案，把「工具免費、模型收費」的模式具體化，這是理解 V2 設計取捨的關鍵背景。
OpenCode 2 與第一代有哪些重大差異？
官方列出三項破壞性變更：插件改用新 API、伺服器介面重寫、終端設定改為單一全域 cli.json。兩代共用同一指令，預設無法並存。
三項變更的性質並不相同。終端設定檔的調整屬於自動化範圍，首次啟動 V2 時會把支援的全域 tui.json 設定與偏好遷移到 ~/.config/opencode/cli.json，專案層級的客戶端設定則不再遷移，因為 V2 的客戶端設定改為全域單檔。
插件與伺服器介面則需要人工處理。官方文件明確指出，V1 的插件實作無法在 V2 執行，單純搬移檔案或更改設定名稱並不足夠，入口點、鉤子、工具、事件與套件匯出都必須按新的插件指南重寫。呼叫 V1 伺服器介面的外部整合，同樣要改用 @opencode/client 套件與新的端點契約。
安裝層面也出現實質限制。兩代版本共用 opencode 指令，預設不再並存，使用套件管理器安裝 V1 的環境必須先移除，才能以 curl 安裝腳本或套件管理器換上 V2。官方建議在驗證完成前保留 V1 設定的備份，但同時提醒不能讓 V1 指向已轉為原生 V2 格式的設定檔。
OpenCode 2 的代理與終端體驗有什麼改動？
V2 保留 build 與 plan 兩種內建代理，新增 general 子代理。終端加入待辦清單與差異檢視，長時間指令不受五分鐘連線上限中斷。
代理設計延續第一代的雙角色分工。build 具備完整開發權限，plan 則為唯讀模式，預設拒絕檔案編輯並在執行指令前要求確認，適合在陌生程式碼庫中先探索再動手。V2 另外提供 general 子代理，透過 @general 呼叫，負責複雜搜尋與多步驟任務。
終端體驗的改動集中在可觀測性。2.1.0 版加入待辦清單功能，啟用後模型可取得任務寫入工具，清單同時顯示於工作階段與側邊欄。2.0.30 版加入逐回合的變更檔案檢視，每一輪完成的回合都會列出異動檔案、行數與可展開的差異，並提供可停駐的差異面板，用 f 鍵在側欄與全螢幕之間切換。
穩定性修正同樣具體。過去插件指令與終端請求受限於執行環境的五分鐘連線上限，長時間任務容易中途斷線，2.1.0 版解除這項限制。2.1.2 版則在免費額度用盡時顯示重置時間、還原已提交的提示詞，並提供升級或切換模型的直接操作，取代原本的通用錯誤訊息。
OpenCode 2 在跨平台與遠端協作上補了什麼？
V2 在 Windows 提供持續性終端與原生 ARM64 版本，並經 WinGet 發佈。桌面版可用 QR 碼配對遠端裝置，接回同一工作階段。
Windows 長期是這類終端工具的弱項。V2 在 Windows 補上持續性終端，讓使用者取得與 macOS、Linux 相同的互動體驗，同時提供原生 ARM64 建置，不再依賴 x64 模擬。官方亦上架 WinGet 套件，後續升級交由 WinGet 處理，減少手動替換執行檔的需求。
遠端存取在 2.0.29 版成形。桌面版的設定頁新增配對功能，啟用 OpenTunnel 遠端存取後可取得 QR 碼或可複製連結，讓另一台裝置接回同一台主機的工作階段。這項能力改變了使用情境：代理執行在效能夠強的桌機上，操作介面則可以出現在平板或手機。
供應商帳號管理同步補強。過去切換多組 API 金鑰需要手動編輯設定，V2 改為在連線對話框或設定頁直接新增、重新命名、切換與移除帳號。對於同時使用多家模型供應商的團隊，這項改動省下的是日常維護成本，而非一次性設定。
插件與伺服器 API 為何需要重寫？
V2 把插件設定由 plugin 改為 plugins 並以物件描述套件與選項，伺服器介面重新設計並推出 @opencode/client，舊實作不會自動相容。
設定結構的變化反映的是責任重新分配。V1 的插件清單把套件名稱與選項以元組方式並列，閱讀與驗證都較為困難；V2 改為每個項目一個物件，套件與選項分開描述，設定檔因此可以加入結構描述與驗證。本機插件的搜尋路徑也擴充，.opencode/plugin/ 與 .opencode/plugins/ 都會被辨識。
真正的門檻在實作層。官方警告 V1 插件在 V2 完全不會執行，因為插件介面本身已更換，入口點、鉤子、工具註冊、事件與套件匯出全部需要重寫。對於把權限控管、日誌或自訂工具寫成插件的團隊，這是升級前必須盤點的工作量。
伺服器介面的調整幅度相近。V2 重新設計 HTTP 介面並提供獨立的客戶端套件，同時在 2.1.0 版進一步統一事件欄位命名，把不同介面上原本分歧的 providerState、resultState 一律改為 native。既有工作階段、憑證與舊版匯入資料仍可透過相容解碼器讀取，資料庫不需要遷移，但自行串接事件流的整合方必須同步調整欄位。
OpenCode 的商業模式如何運作？
工具維持開源免費，營收來自模型存取。Zen 採預付餘額按請求計價且不加價，Go 每月 10 美元、Go Plus 40 美元，提供更高額度。
Zen 的設計是把模型選擇市場化。官方對外說法是，市面上的模型數量龐大，但真正適合編碼代理的組合有限，因此由團隊實測並與供應商協調設定，再以零加價方式轉售。使用者儲值 20 美元後按請求扣款，餘額降到 5 美元時自動加值，並可設定每月上限。
Go 與 Go Plus 則是訂閱層。Go 每月 10 美元，主打精選平價模型與寬鬆額度；Go Plus 每月 40 美元，提供更高請求上限與較少中斷。官方同時保留限時免費模型作為拉新手段，2.1.2 版加入的環境變數則讓企業可以從目錄與預設值中完全隱藏免費模型，避免團隊成員在無意間把內部程式碼送往免費額度。
這套結構解釋了 V2 為何願意承擔破壞性變更。當工具本身免費、收入來自模型呼叫，介面就必須支援多供應商、多帳號與可觀測的用量統計；V2 的帳號管理、用量顯示與成本彙總，都是圍繞這個目標設計。
OpenCode 2 的主要數據有哪些？
儲存庫累積 219,545 顆星標、29,287 個分支與 3,785 個未結議題。npm 套件近一個月下載 892,371 次，最近一週 273,568 次。
下載量與星標數的比例值得注意。近一個月 892,371 次下載對上 219,545 顆星標，意味著相當比例的星標來自實際安裝過的開發者，而非單純的關注行為。每週 273,568 次的下載節奏，也顯示使用者在持續更新，而不是一次安裝後停用。
分支數同樣反映採用深度。29,287 個分支對上二十萬顆星標，比例約為七分之一，明顯高於一般示範型專案。這種分布通常出現在團隊維護自有分支、或企業在內部客製插件與供應商設定的情境。
議題數量則呈現另一面。3,785 個未結議題說明功能面廣、使用密度高，也意味著評估導入時需要自行判斷特定功能的成熟度。官方對此的策略是把變更記錄寫得極細，2.1.2 版的每一項修正都附上對應的合併請求編號，讓團隊可以回溯具體行為變化。
版本節奏則顯示團隊投入程度。V2 從 9 月 11 日的 2.0.0 推進到 10 月 21 日的 2.1.2，六週內完成三十餘個版本，包含一次次版本號跳躍與兩次介面統一。這種密度對使用者是雙面刃：功能補得快，但也代表升級前必須先讀變更記錄。
如何從 OpenCode 1 遷移到 OpenCode 2？
官方建議先保留 V1 設定備份，移除套件管理器安裝的 V1 再裝 V2。啟動後依序驗證模型、憑證、代理、權限與 MCP 伺服器，最後移植插件。
遷移路徑的第一個現實問題是安裝衝突。兩代共用同一個指令，套件管理器安裝的 V1 必須先移除，V2 的安裝腳本會覆蓋既有執行檔。官方建議在驗證完成前保留一套可回退的備份，這也是唯一能避免工作中斷的做法。
設定層面比預期寬鬆。V2 讀取與 V1 相同的位置，包括系統層、全域與專案層的設定檔，並在記憶體中把支援的舊欄位正規化，不會改寫原始檔案。這代表多數團隊可以先沿用現有設定啟動，確認模型與憑證可用之後，再考慮是否轉為原生格式。
必須重寫的只有三塊。插件要按新的介面重寫，呼叫伺服器介面的外部整合要改用新的客戶端套件，終端設定則由系統自動遷移為全域單檔。官方另外提供一個實用做法：直接把遷移需求寫成提示詞交給代理執行，讓它檢查完整設定檔並只改必要欄位，避免一次改動過多導致行為偏移。
驗證順序建議照官方清單執行。先確認模型與供應商憑證可用，再檢查代理定義、權限規則與 MCP 伺服器是否如預期載入，最後才測試插件。同一份設定不要同時餵給兩代版本，否則格式轉換會讓其中一方讀到非預期的內容。
哪些團隊適合採用 OpenCode 2？
已在多供應商之間切換、需要遠端接回工作階段的團隊最合適。若重度依賴自寫插件或 V1 伺服器介面，應先評估重寫成本。
第一類是模型組合複雜的團隊。當同一個專案需要依任務切換不同供應商與模型變體，V2 的帳號管理、用量統計與成本彙總能直接減少人工維護；免費模型可被隱藏這項設計，也讓企業在合規審查時有明確交代。
第二類是硬體與作業系統分散的團隊。Windows 的持續性終端、原生 ARM64 建置與 WinGet 套件，讓過去被排除在外的成員可以納入同一套流程。桌面版的遠端配對則適合以單一高效能主機執行代理、多台裝置遙控的模式。
第三類是打算把代理嵌入自有產品的開發者。V2 拆分出的伺服器、SDK 與插件體系，讓整合方可以呼叫穩定介面而非模擬終端行為。這條路徑的代價是要跟上介面版本的變化，2.1.0 的事件欄位統一就是一個明確例子。
反過來說，若團隊的流程高度依賴自寫插件，而且插件只是內部小工具，則需要先衡量重寫成本。官方文件對此沒有提供自動轉換工具，實際做法是照新介面重寫一次。
出處連結有哪些？
本文數據取自 anomalyco/opencode 官方儲存庫、V2 變更記錄、官方文件與 npm 下載統計，皆於 2026 年 10 月 22 日讀取，版本資訊以 2.1.2 為準。
官方儲存庫：https://github.com/anomalyco/opencode
V2 的變更記錄以 CHANGELOG.md 維護，逐版列出功能、修正與破壞性變更，並附上合併請求編號。官方文件分為 V1 與 V2 兩套站點，V2 另有一份從 V1 遷移的專頁，說明設定對應關係與必須重寫的範圍。下載數據取自 npm registry 的統計介面，星標與分支數取自 GitHub 儲存庫頁面。
總結：OpenCode 2 值得升級嗎？
若把編碼代理當作日常工具、且需要多供應商與跨裝置存取，V2 的體驗與穩定性提升明確值得升級。若插件投資較深，建議先完成重寫評估再切換，避免工作中斷。
OpenCode 2 的意義不在功能清單變長，而在產品形態改變。第一代是一套終端工具，第二代則把終端、桌面、伺服器與模型市集組成一個體系，並以開源工具加模型收費的方式維持營運。這種結構讓專案在商業上更可持續，代價是介面穩定性必須靠版本節奏來換。
升級判斷可以簡化為兩個問題。團隊是否需要在不同裝置與不同模型之間切換？若是，V2 補上的遠端配對、帳號管理與用量統計都是立即有用的功能。團隊是否有自寫插件或自行串接伺服器介面？若是，則應先估算重寫工作量，再把升級排進排程，而不是跟隨版本自動更新。
六週內三十餘個版本的節奏，說明這個專案仍處於快速演進階段。對願意持續追蹤變更記錄的團隊，這種速度代表問題修正得快；對希望一次設定長期不動的團隊，則需要更嚴格的版本鎖定策略。
