何時該在工作中使用 Claude Opus 4.6

資料來源#

資料時效提醒（2026-07-16）。 本文於 2026 年 4 月針對 Opus 4.6 編寫。此後已推出兩代模型：Claude Opus 4.7 和 Claude Opus 4.8（2026-05-28，現為 Anthropic 的一般供應前沿模型），以及 Claude 5 系列。附錄中「在取得 4.7 的測量結果前，繼續使用 4.6」的建議已不再適用——當時 4.7 才推出幾天，4.6 仍是現行預設；如今兩者都已不是如此。

底層實驗（AgentOpt、Hakim）從未在 4.7 或 4.8 上重跑，因此規則 #1–#5 是對現行模型尚未重新測試的假設，並非對它們測得的事實。與模型無關的是其機制——依規模而異的過度思考——以及兩種緩解方法：改走其他路徑，或限制輸出。這些做法可視為持久有效；數字則只反映 4.6 時期。

問題#

工作中何時最適合使用 Opus 4.6？

答案#

維基中的兩篇實證論文提供了具體指引：AgentOpt（Hua et al. 2026）和 Hakim（2026）。兩者都指出大型模型的過度思考是主要失敗模式，表現形式分別是多代理程式路由失敗和提示敏感度失敗。以下部署規則直接根據這些發現制定。

1. 將 Opus 4.6 用作解題者，而非規劃者／路由器#

根據用戶端代理程式最佳化：在 HotpotQA 的 81 種組合中，Opus 4.6 是最差的規劃者——它會繞過下游解題者的搜尋工具，直接憑參數化知識作答。若搭配在其前方、成本低且服從指令的規劃者，它則是最佳解題者。

Ministral 3 8B（規劃者）+ Opus 4.6（解題者）→ 74.27%
Opus 4.6（規劃者）+ Opus 4.6（解題者）→ 31.71%

規則：在多步驟代理程式管線中，讓 Opus 負責執行工作（綜合整理、根據檢索內容進行深入推理、生成最終答案）。將路由、工具選擇和任務分解交給較小型、能可靠地交接工作的模型。

2. 在詳細闡述不可或缺的任務中使用 Opus 4.6#

根據依規模而異的提示敏感度：在 7.7% 的標準基準問題中，大型模型因過度闡述而比小型模型低 28.4 個百分點。具診斷意義的例外是 BoolQ——跨句整合文章內容——簡潔度限制會讓大型模型表現變差。在這種情況下，詳細闡述確實有助益。

規則：若任務本身的推理過程就是成果，Opus 4.6 值得其成本——例如跨文件綜合整理、整合分析、長上下文摘要、細膩寫作、開放式設計取捨，以及涵蓋多個檔案的程式碼審查。若是獨立的簡答題，過度闡述會累積錯誤，它的表現就較差。

3. 對成本敏感的結構化任務，別預設使用 Opus 4.6#

根據 AgentOpt 的帕雷托前緣：在 BFCL 上，Qwen3 Next 80B 以低 32 倍的成本達到與 Opus 4.6 相同的準確率。在 MathQA 上，準確率相近的組合之間，成本差距可達 24 倍。對於工具呼叫和結構化輸出等正確性標準明確的工作負載，較便宜的模型更具優勢。

規則：決定在某個工作負載中採用 Opus 4.6 前，先確認是否有較便宜的模型能達到相同準確率。「使用最強的模型」是可衡量的錯誤，不是安全的預設選項。

4. 若在容易引發過度思考的問題上使用 Opus 4.6，就限制輸出#

Hakim（2026）的因果介入結果：簡潔度限制（數學題少於 50 字、閱讀理解少於 10 字）讓大型模型提升 26.3 個百分點，並完全扭轉 GSM8K（小型模型 +13.1 個百分點 → 大型模型 −7.7 個百分點）和 MMLU-STEM（小型模型 +27.3 個百分點 → 大型模型 −15.9 個百分點）的表現排序。僅靠簡潔度限制，Llama-3.1-405B 在反向縮放問題上的成績就從 41.5% 升至 67.2%。

規則：若要讓 Opus 4.6 處理簡答任務，請設定字數上限或指定直接作答的輸出格式。成本與能力可同時改善——使用更少 token，準確率更高。

5. 上下文預算的推論（特別適用於 Claude Code）#

根據 Claude Code Best Practices：上下文視窗是 Claude Code 最主要的稀缺資源。Opus 一貫冗長的回答會更快耗盡預算，進一步凸顯簡潔度限制的必要，也說明應把大量探索工作交給子代理程式或較便宜的模型，再以摘要交接成果。

決策摘要#

情境	使用 Opus 4.6？	證據來源
在低成本規劃者之後擔任解題者／綜合整理者	是 — 有紀錄支持的最佳角色	AgentOpt HotpotQA（74.27% 對 31.71%）
跨文件綜合整理、整合式寫作、長上下文推理	是	Hakim（2026）中的 BoolQ 例外
在多步驟代理程式管線中擔任規劃者／路由器	否 — 同類中表現最差	AgentOpt HotpotQA 全組合測試
簡答數學／科學／常識題	不預設使用；若使用，應採用簡潔度限制	Hakim 的 GSM8K／MMLU-STEM 表現逆轉
工具呼叫、結構化輸出（類似 BFCL）	先檢查帕雷托前緣	Qwen3 Next 80B 以低 32 倍的成本達到相同表現
在 Claude Code 中進行程式碼審查、架構分析、生成最終答案	是，但要管理上下文預算	Claude Code 最佳實務

兩種底層機制#

兩種失敗模式——Opus 擔任規劃者，以及 Opus 處理簡答題——其實有共同機制：依規模而異的過度思考。AgentOpt 將其呈現為路由失敗（Opus 自行作答而非交辦）；Hakim 則將其呈現為提示工程失敗（Opus 詳細闡述而非下結論）。可採用兩種緩解方法：

改走其他路徑 — 透過組合選擇，只在 Opus 的冗長程度符合效用的角色中使用它
限制輸出 — 在系統提示中要求簡潔回答、指定結構化格式，或設置字數上限

正式環境部署應同時採取這兩種做法。

附錄：Opus 4.7（2026-04-17）#

Claude Opus 4.7 是 4.6 的直接升級版，價格相同（$5/$25）；在有人於 4.7 上重跑實驗前，上述五項規則仍是最站得住腳的預設做法。不過，4.7 的幾項變更直接影響這些規則背後的機制，因此每項規則都應視為有待重新驗證的假設，而非定論：

規則	4.7 可能有哪些變化	原因
#1 Opus 擔任解題者，而非規劃者	規劃者模式的失敗可能減少	4.7「依字面遵循指令」的能力，理應減少已記錄的失敗模式：Opus 擔任規劃者時繞過下游解題者的工具
#2 在需要詳細闡述的任務中使用	不變或更適合	更好的指令遵循能力，加上檔案系統記憶，讓綜合整理／整合任務更符合其優勢
#3 對成本敏感的結構化任務，別預設使用	4.7 上可能更不划算	tokenizer 膨脹（1.0–1.35×）加上高推理力度時輸出 token 增多，會提高達到特定準確率的實際成本。採用前應重新檢查帕雷托前緣
#4 對容易引發過度思考的任務施加簡潔度限制	很可能仍有用；效果幅度可能改變	4.7 在代理程式情境中「推理力度越高，思考越多」。依字面遵循指令的能力可能讓簡潔度限制更有效（模型會遵守上限），但同時模型預設會做更多闡述，與此相互拉扯
#5 Claude Code 中的上下文預算推論	4.7 上的限制更嚴格	tokenizer 膨脹、xhigh 預設值（Claude Code 的新預設），以及更多思考 token 會層層累加。原封不動重用 4.6 時期的提示和 CLAUDE.md，可能更快耗盡預算

對進行中工作的實際影響：如果正式環境工作負載目前是根據這些發現針對 Opus 4.6 調校，在取得 4.7 的測量結果前，請繼續使用 4.6。遷移並非毫無成本（token 膨脹、提示依字面解讀、預設推理力度提高）。Anthropic 自身的建議是根據實際流量進行測量，而非相信泛化的整體利多說法。

未解問題已移至 Claude Opus 4.7。

資料來源#

Client-Side Agent Optimization — 組合最佳化、依角色分配模型、Opus 的規劃者失敗模式
Scale-Dependent Prompt Sensitivity — 過度思考機制、簡潔度介入、表現排序逆轉、BoolQ 例外
Claude Code Best Practices — 上下文視窗限制、驗證準則、工作階段管理
Claude Opus 4.7 — 2026-04-17 附錄；可能改變各項規則效果幅度的 token 經濟性與指令遵循能力變化
AgentOpt v0.1 Technical Report: Client-Side Optimization for LLM-Based Agent
Brevity Constraints Reverse Performance Hierarchies in Language Models
Best Practices for Claude Code
Introducing Claude Opus 4.7