何時該在工作中使用 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 系列。Addendum 中「在取得 4.7 的測量結果前繼續使用 4.6」的建議已被取代——那是在 4.7 發布僅數日、4.6 仍是現行預設模型時撰寫的；如今兩者皆非如此。

底層實驗（AgentOpt、Hakim）從未在 4.7 或 4.8 上重新執行，因此規則 #1–#5 是對目前模型尚未重新測試的假說，而不是對它們測得的事實。與模型無關的是其機制——依規模而異的過度思考——以及兩種緩解方式：繞開它，或限制輸出。請將這些視為持久有效的原則；數字則應視為 4.6 時代的結果。

問題#

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

答案#

wiki 中的兩篇實證論文提供了具體指引：AgentOpt（Hua et al. 2026）與 Hakim（2026）。兩者都指出大型模型的過度思考是主要失敗模式——一篇將其呈現為多代理路由失敗，另一篇則呈現為提示敏感度失敗。以下部署規則直接由此推導而來。

1. 將 Opus 4.6 用作 solver，而非 planner/router#

在 Client-Side Agent Optimization 中：在 HotpotQA 的 81 種組合裡，Opus 4.6 是最差的 planner——它會繞過下游 solver 的搜尋工具，直接以參數知識作答。若讓一個便宜且服從指令的 planner 位於其前方，Opus 4.6 則是最佳 solver。

Ministral 3 8B（planner）+ Opus 4.6（solver）→ 74.27%
Opus 4.6（planner）+ Opus 4.6（solver）→ 31.71%

規則：在多步驟代理管線中，將 Opus 指派給執行角色（綜整、基於檢索內容的深度推理、最終答案生成）。將路由、工具選擇與任務分解交給較小、能可靠交接工作的模型。

2. 在詳細闡述承載重要功能的地方使用 Opus 4.6#

在 Scale-Dependent Prompt Sensitivity 中，標準基準測試有 7.7% 的問題，大型模型因過度闡述而比小型模型低 28.4 個百分點。診斷上的例外是 BoolQ——跨句子的篇章整合——在這裡，簡潔限制反而會傷害大型模型。此時詳細闡述具有功能性。

規則：Opus 4.6 在推理本身就是產品的任務上值得其成本——跨文件綜整、整合式分析、長上下文摘要、細膩寫作、開放式設計取捨，以及跨越多個檔案的程式碼審查。對於過度闡述會累積錯誤的自包含短答案問題，它的表現較差。

3. 不要在成本敏感的結構化任務上預設使用 Opus 4.6#

根據 AgentOpt 的 Pareto frontier：在 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？	證據來源
位於廉價 planner 後方的 solver/synthesizer	是——已有文件記錄的最佳角色	AgentOpt HotpotQA（74.27% 對 31.71%）
跨文件綜整、整合式寫作、長上下文推理	是	Hakim（2026）中的 BoolQ 例外
多步驟代理管線中的 planner/router	否——同類中最差	AgentOpt HotpotQA 全組合掃描
短答案數學／科學／常識題	不預設使用；若使用，套用簡潔限制	Hakim GSM8K／MMLU-STEM 逆轉結果
工具呼叫、結構化輸出（類 BFCL）	先檢查 Pareto frontier	Qwen3 Next 80B 以低 32 倍成本達到相同表現
Claude Code 中的程式碼審查、架構分析、最終答案生成	是，但要管理上下文預算	Claude Code 最佳實務

兩種底層機制#

兩種失敗模式——Opus 作為 planner，以及 Opus 作為短答案 solver——共享同一個機制：依規模而異的過度思考。AgentOpt 將它呈現為路由失敗（Opus 直接回答而不委派）；Hakim 則將它呈現為提示工程失敗（Opus 詳細闡述而不下結論）。目前有兩種可用的緩解方式：

繞開它——組合選擇只讓 Opus 擔任其冗長表達與效用相符的角色
限制輸出——在 system prompt 中使用簡潔提示、結構化 schema、長度上限

production 部署應結合兩者。

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

Claude Opus 4.7 是 4.6 的直接升級版，價格相同（$5/$25）；在有人於 4.7 上重新執行實驗前，上述五項規則仍是最有辯護力的預設。但 4.7 的數項變更直接觸及這些規則背後的機制，因此請將每項規則視為有待重新測試的假說，而非已確立的事實：

規則	4.7 上可能改變的地方	原因
#1 Opus 作為 solver，而非 planner	planner 模式的失敗可能縮小	4.7 的「字面指令遵循」應能減少已記錄的失敗模式：Opus 作為 planner 時繞過下游 solver 的工具
#2 在詳細闡述承載重要功能的地方使用	不變或更強	更好的指令遵循 + 檔案系統記憶，讓綜整／整合任務更成為其最佳適用範圍
#3 不要在成本敏感的結構化任務上預設使用	4.7 上可能更差	tokenizer 膨脹（1.0–1.35 倍）+ 更高 effort 下更多輸出 token，會提高同一準確率下的有效成本。投入前重新檢查 Pareto
#4 在容易過度思考的任務上使用簡潔限制	可能仍有價值；彈性可能改變	4.7 在代理情境下「於更高 effort 時思考更多」。字面指令遵循可能讓簡潔限制更有效（模型會遵守上限），但同時也要對抗一個如今預設會更詳細闡述的模型
#5 Claude Code 中的上下文預算推論	4.7 上更緊繃	tokenizer 膨脹 + xhigh 預設值（Claude Code 的新預設）+ 更多思考 token 會疊加影響。逐字重用 4.6 時代的提示與 CLAUDE.md 可能更快耗盡預算

對持續進行中的工作的實際含義：若 production 工作負載目前是根據這些發現以 Opus 4.6 調校，請繼續使用 4.6，直到取得 4.7 的測量結果。遷移成本並非零（token 膨脹、字面提示解讀、預設 effort 提升）。Anthropic 自身的指引建議在真實流量上進行測量，而不是相信一般性的淨正面宣稱。

待解決問題已移至 Claude Opus 4.7。

資料來源#

Client-Side Agent Optimization — 組合最佳化、逐角色模型指派、Opus 的 planner 失敗模式
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