Claude Opus 5.5 遷移指南：5 個可能讓 Agent 工作流程出錯的變化
真正要遷移的是 thinking、工具呼叫、computer use 與對話歷史。
Anthropic 在 2026 年 9 月 22 日釋出了 Claude Opus 5.5。表面看，這是一次“更強、更快、更便宜”的模型更新；真正影響 Agent 工作流的，卻是 thinking、工具呼叫、computer use 和會話歷史的介面變化。
只看榜單，容易漏掉遷移成本。只看 token 單價，也會漏掉重試、工具迴圈失敗和人工稽核的成本。
先看結論
Anthropic 將 Opus 5.5 定位為面向長時間 Agent 程式設計和知識工作的模型，API model ID 是 claude-opus-5-5。它有 100 萬 token 上下文、最多 12.8 萬輸出 token，並且 adaptive thinking 始終開啟，不能關閉。
| 變化 | Claude Opus 5.5 | Claude Opus 5 | 團隊真正要驗證什麼 |
|---|---|---|---|
| 標準輸入價 | 每百萬 token 4 美元 | 5 美元 | 加上檔案、工具和重試後的總輸入 |
| 標準輸出價 | 每百萬 token 20 美元 | 25 美元 | thinking 與可見輸出都佔輸出預算 |
| Cache read | 每百萬 token 0.20 美元 | 0.50 美元 | 長會話裡的真實命中率 |
| 預設 effort | medium | high | 預設檔是否已經夠用 |
| Thinking | 始終開啟 | 部分 effort 可關閉 | 現有請求與響應處理是否相容 |
| 上下文 | 100 萬 token | 100 萬 token | 工具結果和保留 thinking 後還剩多少 |
Anthropic 表示，Opus 5.5 在預設設定下的典型工作負載成本比 Opus 5 低 40%，輸出速度快 30% 以上。這是廠商基於其測試給出的估算，不是所有工作流都能直接兌現的折扣。Prompt 結構、effort、快取、工具呼叫和重試率都會改變結果。
最大變化不在 benchmark
一個 Agent 工作流不只有模型。Harness 決定放入什麼上下文、開放哪些工具、執行什麼許可權、如何回傳工具結果，以及任務要拿出什麼證據才算完成。
Opus 5.5 改了其中幾個關鍵介面。
Thinking 不能再關
Adaptive thinking 始終開啟。你可以用 effort 控制深度，但傳送 thinking: {"type":"disabled"} 會報錯。
如果現有工作流為了節省成本或相容舊解析器而關閉 thinking，就必須重測。Thinking token 即使不展示給使用者，也會按輸出 token 計費，並計入 max_tokens。遷移時既要看費用，也要看是否更容易被截斷。
Opus 5.5 預設使用 medium effort。為了追求釋出頁上的最高分，一上來就把所有任務調到 max，並不是穩妥做法。先從預設檔開始，只有驗收測試證明質量確實不夠時，再提高 effort。
強制工具呼叫可能直接報錯
Opus 5.5 不接受強制 any 或指定工具名稱的 tool_choice。Anthropic 建議使用 auto，配合 strict tool definition 或 structured output。
如果現有迴圈假設“這一輪必須呼叫某個工具”，遷移測試必須覆蓋這條路徑。不要等到定時 Agent 在生產環境連續返回 400 才發現。
Computer use 要切換到新 toolset
在 Claude API 和 Google Cloud 上，Opus 5.5 不接受舊的 computer_20251124，需要使用 computer_toolset_20260801。
這是請求協議相容性，不是 Prompt 寫得好不好。Benchmark 也無法替你檢查瀏覽器或 computer harness 用的是哪一版工具。
Thinking block 變成會話完整性的一部分
Opus 5.5 使用 preserved thinking。簽名 thinking block 之前的 system instructions、tools 和 messages 必須保持不變。隨意重建、改寫舊會話歷史，可能讓 block 失效。
長時間執行的 Agent 應儘量把歷史當作 append-only 資料，或者使用 Anthropic 支援的 context management 機制。狀態會更明確，但“為了省 token 手工改一下舊訊息”會更危險。
進度文字可能突然消失
預設 display: "omitted" 時，工具呼叫之間的進度更新可能進入 thinking block，但文字為空。原來依賴這些中間文字展示“Agent 正在做什麼”的介面，看起來會像卡住。
Anthropic 提供了 beta 的 updates display mode，讓產品只顯示面向使用者的進度，不暴露 reasoning summary。這是產品整合問題，不是模型分數問題。
釋出說明證明了什麼，又沒證明什麼
Anthropic 報告 Opus 5.5 在 Agent 程式設計、computer use、知識工作和業務流程上提升明顯，也表示它在自動行為審計中的表現好於 Opus 5，並在一項邊界測試裡更少嘗試越過 containment boundary。
這些是有價值的一手證據，但不能推出“所有工作流都更安全、更準確”。Anthropic 自己也提醒，前沿模型之間的 benchmark 差距越來越難直接對映到真實使用；釋出頁裡不少結果來自高 effort 或 max effort，部分評測還會受 safeguard fallback 影響。
真正的問題不是“它贏了幾個榜單”，而是“在我們的工具、許可權、資料和驗收標準下，它能不能產生更多被接受的結果”。
一次公平的遷移測試
找一個已經有 Opus 5 穩定基線的工作流。可以是倉庫修改、帶來源的研究報告，或者從表格到簡報的交付。固定輸入檔案、工具、時限、許可權和驗收清單。
先用 Opus 5.5 預設 medium effort 執行。記錄總輸入、總輸出、cache read、工具次數、重試次數、總耗時和稽核修改量。只有沒過驗收時，再提高 effort。
稽核人要檢查產物，而不是相信模型說“完成了”。程式碼任務看 diff、測試和日誌；研究任務核對關鍵數字與引用；業務文件檢查結構、事實和模板是否真的滿足要求。
有效的結論不是“新模型感覺更聰明”，而是“透過率提高、稽核時間下降，或每個被接受產物的總成本下降，同時嚴重錯誤沒有增加”。
為什麼工作流層仍然重要
Buda 把檔案、瀏覽器、終端、tool calls 和最終 artifact 放在同一個可檢查的 workspace 中。這樣評測模型時，團隊比較的是透過驗收的結果、失敗迴圈和稽核成本，而不是排行榜。
FAQ
Opus 5.5 比 Opus 5 便宜嗎？
Anthropic 的標準 API 目錄價從 Opus 5 的輸入每百萬 token 5 美元、輸出 25 美元，降至 Opus 5.5 的 4 美元和 20 美元。單價降低 20%；具體任務還要把快取、思考輸出、重試和工具迴圈算進去。
Opus 5.5 的上下文更大嗎？
沒有。Anthropic 當前文件中，兩者都是 100 萬 token。5.5 的重點更偏向效率、行為和整合介面，而不是擴大上下文數字。
所有 Opus 5 工作流都該立刻升級嗎？
不該。先驗證請求格式、工具迴圈、computer-use 版本、歷史處理、成本和最終產物，再決定是否遷移。
在 Buda 中使用 Opus 5.5
Buda 使用者可以直接在 Agent 模型選擇器中選擇 Claude Opus 5.5，正式模型 ID 為 claude-opus-5-5。此前儲存的 Opus 5 模型選擇會自動升級為 Opus 5.5，不需要重建 Agent，也不會移除現有檔案。上文的 API 遷移規則針對直接接入 Anthropic 的開發者，不是每位 Buda 使用者都要額外執行的配置步驟。