當團隊決定把現有用 Opus 5 的系統搬到 Opus 5.5，導入前真正要回答的不是「它強不強」，而是幾件很具體的事：既有程式會不會壞、成本會變怎樣、輸出品質有沒有退、跑分能信幾分。 這篇把導入前該檢查與該改的項目逐一列出，補上幾個官方不會主動講、但團隊一定會踩到的坑，並附一次可重現的實測當驗收樣本。

先看對照：Opus 5 與 5.5

• Opus 5（claude-opus-5）：1M 脈絡、128K 輸出，約 5/25 美元（輸入／輸出每百萬 token），快取讀取約 0.50 美元，預設 effort 為 high。
• Opus 5.5（claude-opus-5-5）：同樣 1M／128K，但便宜約 20%（4/20 美元）、快取讀取降到 0.20 美元（降約 60%）、輸出快 30% 以上、預設 effort 由 high 降到 medium，且 thinking 無法關閉。1M 脈絡不另外加價。

下面每一節都圍繞這些變化，給出導入前要做的具體動作。

一、相容性：四個報錯點 ＋ 一條容易漏的回退鏈

在 Opus 5 跑得好的程式，搬到 5.5 可能回 400，先改這四處：

1. 關閉 thinking 會報錯。 送 {"type":"disabled"} 或 budget_tokens 現在每個 effort 檔都回 400。拿掉它們，改用 effort 控制深淺：

   # 舊：thinking={"type":"disabled"}  → 400
   output_config={"effort": "low"}   # thinking 一直開著，用 effort 收斂
   

2. 強制工具呼叫被取消。 tool_choice 送 any 或 tool 會回 400（連 token 計數端點也是）。改用 auto 加提示詞點名工具，或在工具上設 strict: true，或改用結構化輸出。

3. computer use 換了工具代號。 在 Claude API 與 Google Cloud 上只收 computer_toolset_20260801；舊的 computer_20251124 回 400（Bedrock 仍收舊的）。

4. preserved thinking（容易忽略）。 防蒸餾機制：thinking 區塊綁定模型與對話，2026-08-31 之後建立的帳號，重送被改寫過的歷史會回 400。harness 要只追加；工具迴圈裡要依型別讀 content block、並把 thinking 區塊原樣回傳。

一條最容易漏的回退鏈陷阱：thinking 區塊綁定「產生它的模型」。Opus 5.5 讀得懂 Opus 5 及更早的 Opus／Sonnet／Haiku 的 thinking 區塊（所以「先 Opus 5 後切 5.5」的對話能保留推理）；但反方向只有 Fable 5.1／Mythos 5.1 讀得懂 Opus 5.5 的 thinking 區塊。如果團隊的系統有「主力 Opus 5.5、出錯自動降級到 Sonnet／Haiku」的回退鏈，那條路徑會丟掉推理脈絡，導入後務必單獨重測。

另外，安全分類器變廣（新增 bio）：被拒的請求是 HTTP 200 加 stop_reason: "refusal"，讀 content 前先判斷它。

二、用法也要跟著改（不只改程式）

• 重新測 effort，別照搬。 同一個檔名在不同模型「想的量」不一樣。官方說 Opus 5.5 在 medium 已追平甚至超過 Opus 5 的 high，所以別反射性把團隊預設全調回 high；xhigh／max 留給測出確有提升的工作，且 max_tokens 從 64k 起步。
• 刪掉舊的提示詞習慣。 「think step by step」「仔細思考」這類已無必要，它本來就先推理再答；官方測試刪掉後回覆更快、品質不降。想更短更快就降 effort，而不是在提示詞裡加限制。
• 別叫它輸出內部推理。 這類請求可能被拒（reasoning_extraction），改成「先給答案，再給三個主要理由」。
• 長任務的進度回報要先定義。 Opus 5.5 有時會以一份進度報告結束當前回合；明確告訴它進度回報該打斷工作還是邊做邊報。
• 視覺可省掉舊輔助。 它直接讀圖表、截圖、PDF 的準確度，低檔就勝過 Opus 5 最高檔，之前為讀圖搭的機制可以重新評估。

三、effort 與快取的交互：一個會讓帳單變怪的坑

這點對靠快取省錢的團隊特別重要：在請求之間更改頂層 effort 會使 prompt cache 失效。 在一段依賴快取命中的對話裡，若中途改頂層 effort，快取會被清掉、下一次要重新計費寫入。

兩個做法：

• 一段對話內選定一個 effort 檔位別動，要變化就在不同工作負載之間變。
• 確需對話中途改檔又要保住快取，用 逐條訊息 effort（per-message，beta，請求標頭 mid-conversation-output-config-2026-07-01）。Opus 5.5 支援在對話中途改 effort 且保留快取（Amazon Bedrock 上僅 Fable 5.1／Mythos 5.1／Opus 5.5 可用）。

在 Claude Code 裡同理：在已有會話內改設定會清掉其快取對話，下一次請求可能多一次快取寫入。

四、成本：會省，但「單價一半 ≠ 每題一半」

快取讀取降 60% 對 agent 帳單影響最大。算個例子：一個 agent 每天 1 萬次呼叫、每次讀約 5k token 脈絡（多數命中快取），光快取讀取一項，Opus 5.5 約 10 美元／天，Opus 5 約 25 美元／天——一個月差幾百美元。

真正省錢的關鍵是選型分層：日常程式開發交給半價的 Sonnet 5.5，高頻小任務交給 Haiku 5.5，把 Opus 5.5 留給判斷力是瓶頸的難題。各型號單價對照可參考 Anthropic 模型總覽，Opus 5 各渠道價格見 Claude Opus 5 價格。但這裡有個團隊最常算錯的地方：

單價一半，不代表每題成本一半。 Sonnet 5.5 單價是 Opus 5.5 的一半（2/10 對 4/20），可是模型做同一件事用的 token 不同。有一組實測口徑顯示：兩款都開到 max effort 時，Sonnet 5.5 每題約 7.60 美元，反而比 Opus 5.5 的 5.98 美元貴 27%——因為 Sonnet 在高檔下為追平品質吐更多 token。所以團隊做成本模型時，要用**「完成一件工作的總成本」**來估，而不是單價表；在高 effort 的難任務上，別想當然認為 Sonnet 一定便宜。

其他團隊要知道的：趕時間可用 Fast mode（約 2.5 倍速、價格翻倍 8/40，須在會話開頭開）；結構化輸出在 Amazon Bedrock 上不支援，需改用系統提示詞；Opus 5.5 的輸出帶文字浮水印，不影響品質也不加 token；量大又不趕時間的離線工作可用 Batch（約標準價一半）。

五、品質有沒有退：跑分要看，但要看懂水分

Anthropic 的數據很亮眼：Terminal-Bench 4.0 從 Opus 5 的 52.3% 跳到 66.4%（xhigh），SWE-bench 類也報了大幅提升。但導入評估要提醒團隊三件事：

• 獨立複測更保守。 Artificial Analysis 複測的 Terminal-Bench 4.0 只有約 59.6%，和 GPT-6 Astra 幾乎打平，低於官方的 66.4%。
• 領先裡可能摻了「回退灌水」。 Vals AI 複測發現 Opus 5.5 名義 65.15%，但 198 次任務有 22 次其實由 Opus 5／4.8 代答（供應商側 fallback）；按失敗計算後掉到 58.08%，反而低於 Sonnet 5.5 與 Astra。
• SWE-bench Pro 的 89.9% 非官方數。 來自第三方聚合榜，Anthropic 發布頁並未報 SWE-bench Pro，應視為未證實。

公允地說，Opus 5.5 在 Artificial Analysis 的綜合 Intelligence Index 上以 58 分居首（Astra 53、Fable 5.1 53、Opus 5 51），個別項（如 SciCode）也實打實領先。結論：跑分當方向，導入驗收以自家任務的實測為準。

六、導入前的驗收：用可重現的實測

我用「畫一隻騎腳踏車的鵜鶘（SVG）」測一次成形能力，兩代經同一網關各跑一次：

預設下 5.5 快近 3 倍、畫得更簡潔；把兩者都設成 high 後，5.5 的細節補上來且仍較快（5.5 約 16.8 秒、5 約 22.3 秒）。我也讓它們算一道有唯一答案的數學題，兩代都答對、耗時幾乎相同——簡單推理沒有代差，差距只在長而複雜的生成。所以驗收要挑貼近團隊實際工作型態的題目，耗時含網關、建議每題多跑幾次取代表值。

導入檢查清單

• [ ] 四個報錯點改完（thinking／tool_choice／computer use／只追加歷史）。
• [ ] 回退鏈重測：若有降級到 Sonnet／Haiku 的路徑，確認推理脈絡與行為沒壞。
• [ ] 提示詞清理：刪掉「仔細思考」類舊句、重測 effort、進度回報行為已定義。
• [ ] effort 顯式設定；需要中途改檔就用 per-message effort（beta）以保快取，別改頂層值。
• [ ] 成本模型用「每件工作總成本」估，不要只看單價；高 effort 任務別預設 Sonnet 一定便宜。
• [ ] 選型分層：日常 Sonnet 5.5、高頻 Haiku 5.5、難題才用 Opus 5.5。
• [ ] 工具環境確認：Claude Code 升到 v2.1.280 以上；Bedrock 上改用系統提示詞做結構化輸出。
• [ ] 若走第三方網關：確認資料流與合規，並回讀模型名、用固定題目驗真偽。
• [ ] 建立固定回歸測試，換模型／供應商／線路後都重跑。

小結

導入 Opus 5.5 多半是機械工：先修四個破壞性變更、補測回退鏈、清理提示詞、重新決定 effort、把 harness 改成只追加，再用一組固定測試驗收。做完這些，團隊換到的是同樣脈絡預算下更便宜、更快的模型——但記得把日常工作留給 Sonnet 5.5，別讓旗艦價吃掉省下來的錢，也別被官方跑分的水分帶著走。

規格與價格為 Anthropic 官方文件截至 2026-10 的口徑，使用前請再核對；官方跑分為廠商數據、未獨立重現，獨立評測（Artificial Analysis、Vals AI）更保守，文中已分別標注；鵜鶘與數學題為經網關的單次實測（端到端耗時，非純模型速度），僅作驗收示例。本文由作者整理，並以 AI 協助撰寫。