OpenCode 2.2.3 加入生圖與 Claude Agent，帳號額度要分開看

用 AI 摘要這篇文章：

ChatGPT Claude Perplexity Google Grok

OpenCode 在 10 月 29 日到 30 日之間連續發布了 v2.2.2 到 v2.2.5 四個版本（本篇時間均為 UTC）。10 月 30 日的官方公告把影像生成工具掛在 2.2.3 名下，同一版的版本紀錄則把 Claude Agent 連接列為主打項目。對已經在用這套代理工具寫程式的人，這波更新可以濃縮成一句話：生圖被接進了程式代理的工作區，程式代理也能改用你自己的 Claude Code 登入，但這兩件事用的是不同的模型、不同的帳號，能覆寫哪些檔案也各有各的檢查。

更值得先記住的是時間差。影像工具的預設開啟其實出現在 10 月 29 日的 v2.2.2，官方公告晚了一天，而且掛在下一個版本名下；截至 10 月 31 日，官方文件的工具清單也還沒把這項功能列出來。判斷手上版本有哪些能力，版本紀錄比公告可靠。

公告掛在 2.2.3 名下，預設開啟其實在 v2.2.2 就出廠

OpenCode 官方帳號在 10 月 30 日下午的公告寫到（以下引句為翻譯）：「影像生成已經成為寫程式代理的重要工具，你可以用它生成概念介面，或替遊戲做參考美術。OpenCode 2.2.3 內建的生圖工具，支援 OpenAI、Gemini、Grok 等影像模型。」

對照版本紀錄，這段話的版本歸屬要修正一下。v2.2.2 在 10 月 29 日傍晚發布，它的亮點條目明寫「影像生成預設開啟」：只要連接的供應商支援影像模型，代理不需要額外設定就能呼叫這個工具，偏好模型則透過設定欄位指定。往前追原始碼提交紀錄，工具在 10 月 29 日凌晨加入，當天下午就改成預設開啟；而這個工具檔案在 v2.2.2 到 v2.2.5 四個版本裡內容完全相同。換句話說，公告發出的當下，功能已經出廠一天，而且中間經過了一個修補版本。

Pin

官方文件也還沒跟上。說明文件的內建工具頁列了 bash、edit、read、webfetch 等十多個工具，看不見這個生圖工具；供應商文件頁同樣找不到 Claude Agent。這不代表功能是空的，原始碼與版本紀錄都查得到，只代表文件、版本紀錄與公告三者目前不同步。這種快速修訂期的產品，安裝或升級前比對當下的版本紀錄，比追社群公告可靠。

Pin

生圖怎麼跑：背景任務、一張一次、模型自動選

從固定在 v2.2.3 的工具原始碼看，這個工具的名字叫 experimental_image_generate，行為有幾個固定邊界。

它以背景任務執行。代理啟動生成後會立刻拿到工作編號，工具描述明確要求代理不要輪詢進度、不要重複送出同一個請求，完成或失敗時會收到附上儲存路徑的通知。生成最長等三十分鐘，超時視為失敗。每次呼叫只產生一張圖，要多張就分多次呼叫，把一次啟動當成整批素材已完成會誤判進度。

參考圖的限制寫在輸入規格裡：一到八張，接受 PNG、JPEG、WebP 與 GIF 四種格式，每張上限 20 MiB。來源可以是工作階段目錄裡的本機路徑，也可以是 http 網址，遠端下載超過三十秒就放棄。

模型選擇是自動的，而且偏好不等於保證。設定檔裡指定的影像模型只是偏好，當這個模型不在可用清單、或不接受圖片輸入時，工具會自動改用其他可用模型，並在回覆裡註明換了哪個；如果一個可用的影像模型都沒有，直接回報「沒有可用的影像模型」。這對需要維持風格一致的專案很重要：同一句提示換到不同模型，結果可能不同，要重做相近版本就得記下完成通知裡的模型來源，不能只記檔名。

這個工具也內建了防濫用的護欄。工具描述明確要求代理只在使用者開口要求生圖或改圖時才呼叫它；如果代理「覺得」有張圖會有幫助但使用者沒提，正確行為是先問，不該擅自生成。10 月 29 日當天有一個提交專門在修這件事，把「沒人要求的生成」擋在前面。工作結束的通知有三種狀態：完成會附上實際路徑、失敗會附錯誤訊息、取消也會明說，工作的結果文字會被保留下來，程式重開後仍能拿到結論。

要關掉這個工具，官方支援的方式是權限系統：在設定裡把對應的工具名稱設為拒絕或要求批准，與 bash、edit 等其他工具同一套語法。早期實驗階段的 experimental.image_generate: false 設定仍被尊重，但官方已把它定位為相容用途。

哪些影像模型實際出現在清單裡，取決於帳號連接了哪些供應商。公告提到的 OpenAI、Gemini、Grok 是官方口徑，實際組合每個帳號不同；這個工具也只在至少有一個影像模型可用時才會註冊進代理的工具清單，模型目錄變動時會跟著重新評估。

可以生成，不代表可以覆蓋任何檔案

生成出來的圖怎麼落地，是這個工具最值得看懂的部分，因為每一步都有獨立的存取檢查。

指定輸出路徑時，路徑會先通過檔案寫入授權與 edit 權限的雙重檢查；不指定時，預設存到工作階段的暫存資料夾，不會碰既有檔案。副檔名跟著實際格式走：就算你要求存成 .png，供應商回傳的如果是 JPEG，檔案會存成 .jpg。完成通知會給出真正的路徑，程式要引用通知指出的檔案，而不是沿用提示裡猜的檔名。

比較細的是格式改變引發的第二層檢查。如果實際存檔路徑和原本要求的不同，而那個不同的路徑上已經有檔案，覆蓋它需要另一次批准；只有新檔案會略過這一步，僅檢查是否被規則明確拒絕。也就是說，你同意代理更新封面圖，不等於同意它順手換掉另一張剛好同名的素材。

讀參考圖同樣有界線。本機檔案要走讀取授權；http 網址則套用與 webfetch 工具相同的網頁存取權限，專案如果拒絕存取某個遠端來源，把圖片網址餵進來也會被同一條規則擋下。圖片網址不是繞過網路限制的另一條路。

實際運用時比較穩的做法，是讓代理先把新素材輸出成新檔，確認頁面呈現沒問題後再替換引用，而不是讓生成步驟直接覆蓋正在使用的檔案。這樣比較容易回復，也比較容易比對前後差異。

Claude Agent 連接是另一條軸：登入可以沿用，額度不能共用

同一天版本紀錄裡的 Claude Agent，解決的是另一個環節的問題。連接流程是官方寫死的三步：先在機器上安裝 Claude Code，終端機執行 claude auth login 登入，再到 OpenCode 的 /connect 選單選擇 Claude Agent。之後程式代理就能用你的 Claude Code 登入與模型，Claude 的各種登入方式（訂閱、API 金鑰、雲端帳號）都能沿用。如果 claude 執行檔不在標準路徑，環境變數 OPENCODE_CLAUDE_PATH 可以指定位置。

從設計筆記與合併紀錄看，這條連接的信任邊界畫得相當清楚。OpenCode 透過 Claude Agent SDK 執行你自己的 claude 程式，不讀 Claude Code 既有的設定檔與個人設定（~/.claude、CLAUDE.md、hooks 等），也不繼承 Claude Code 的自動記憶、離線摘要這類功能。Claude Code 自帶的內建工具會全部關閉，模型改用 OpenCode 的工具與單一權限系統；如果 OpenCode 的工具給不進去，請求會直接失敗，不會退回 Claude Code 的工具。它也不經手 Claude 與 Anthropic 之間的連線。

Pin

工作階段的運作方式也有幾個實際影響體驗的細節。每個對話背後是一個常駐的 claude 程式，閒置五分鐘後停止，下則訊息再從保存的工作階段接上；工具清單或連線設定改變時程式會重啟。工具呼叫採序列執行，一次只跑一個，因為外掛一次只記得一個呼叫編號。切換模型時，OpenCode 的歷史紀錄是唯一依據：Claude 沒看過的部分會打包成一則使用者訊息補送給它，切回 Claude 時只補它漏掉的部分。另外要注意，這條連接不支援溫度、top-p 這類取樣參數，也不適用於託管版的 OpenCode 與遠端工作區，因為它必須在本機啟動 claude 程式；設計文件也註明需要 Claude Code 2.1.248 或更新版本。名字上還有個小細節：它叫 Claude Agent 而不叫 Claude Code，是因為 SDK 的品牌規範不允許把 Claude Code 當產品名使用。

費用歸屬要看登入類型。設計文件寫到：訂閱登入因為涵蓋使用量，顯示為 0 元；API 金鑰或雲端帳號則按模型牌價計費；自訂端點顯示 0 元，因為帳單在閘道那一端。而 Claude 訂閱透過 SDK 呼叫時會不會比直接用 Claude Code 消耗更快，設計文件明言有這類網路回報、但未經證實，訂閱用戶值得留意的已知未知。

把這條軸和生圖擺在一起，就會出現這波更新最常見的誤解：程式對話正常，不代表生圖可用。代理能回話只證明程式模型的連接沒問題；生圖要另外看影像模型的供應商連接、資格與計費。兩個能力各自檢查，也各自計費。這種「入口相通、授權不相通」的安排，在 Claude 的企業連接器生態也看得到：加得上連接器，不代表拿到資料授權。

升級前要檢查的兩個破壞性變更

v2.2.3 的版本紀錄列了兩個破壞性變更，團隊升級前值得逐項對照。

終端介面外掛現在要求 OpenTUI 0.8 或更新版本。OpenTUI 0.8 把 ScrollBox 的結構改成 facade 物件、自訂 RenderContext 必須實作 clock 與 onAnimationTick，維護自訂外掛的人要跟著更新相依版本，版本對不上時外掛的安裝或執行可能直接失敗。

管理政策則把四種存取來源拆開。以前一條泛用的 integration.use 規則可以涵蓋整合帳號、MCP 伺服器、Skills 與外掛；現在 integration.use 只管整合帳號，MCP、Skill 與外掛分別由新的 mcp.use、skill.use、plugin.use 控制。舊的資源前綴規則會自動轉換，但單獨一條 integration.use 不再延伸涵蓋其他三類，等於過去靠一條規則擋全部的團隊，升級後會出現三個沒有被蓋住的缺口。

有固定版本與測試流程的團隊，可以先在能回復的環境裡確認這兩項變更的影響範圍，再安排全員升級；依賴自訂外掛越深，越值得把驗證往前挪。

桌面版另外修了一批穩定性問題：長對話的串流渲染負荷降低、側欄頁籤修復（前一版 2.2.2 的回歸）、重複出現的 Session not found 提示、以及網頁版透過 HTTP 開檔。這些是延續 2.2 開放桌面外掛實驗之後的收尾工程，屬於維持工作連續性的修正，官方沒有提供可以套用到每個人的量化數字。

現在怎麼判斷，以及還沒確定的事

已在 OpenCode 裡寫程式、又經常需要補介面素材或概念圖的人，這波更新最有感，少切一次工具、少搬一次檔案；經常在多個代理之間切換的人，也可以把 OpenCode 納入遠端監看 Claude Code 與其他代理的工作流。工作以文字與資料處理為主的人，效益有限，生圖工具放在那裡也不會打擾你。

幾件事目前沒有答案：各供應商的影像模型在自己的帳號上實際出現哪些（要連接後看模型清單）；官方文件何時補上這個工具與 Claude Agent 的條目；Claude 訂閱經 SDK 呼叫的用量疑慮是否屬實。這家專案兩天出了四個版本，任何「現在最新」的說法很快會過期，安裝前回到版本紀錄確認，是唯一不會踩空的做法。

11 月底值得回頭確認三件事：文件是否補齊、OpenTUI 0.8 的外掛生態跟上了沒、以及 SDK 用量議題有沒有官方說法。若這段期間又出現破壞性變更，版本紀錄仍是第一手依據。