「全部用 Opus」和「全部用 Sonnet」都不是最佳解，混著用才是正解。

先講版本：Anthropic 持續在更新 Opus 與 Sonnet 系列，這篇比較會以「最新 Opus vs 最新 Sonnet」的角度切入；你帳號當下實際可切到哪個型號，還是以 Claude 介面或 Claude Code 的 /model 顯示為準。

能力差異

推理能力

Opus 跟 Sonnet 差距最明顯的就是推理。Opus 系列的定位就是主打複雜 coding 與 agentic 任務，官方一直把它擺在處理最難推理工作的位置。

複雜的邏輯推理、多步驟分析、需要同時考慮多個因素的決策，Opus 的差距特別明顯。例如要在幾百行程式碼裡找隱蔽的 race condition、競態條件、權限漏洞，Opus 找得比較深，Sonnet 容易只抓到表層。

指示遵循

長 prompt 與規則密集的任務上，Opus 的服從度明顯高一截。同樣一份風格指南（避用詞列表、語氣設定、結構要求），Opus 的初稿要修改的幅度通常比 Sonnet 少很多。

速度

Sonnet 快很多。體感大概是 Opus 的 2-3 倍。

問一個簡單問題，Sonnet 通常 2-3 秒就回完，Opus 可能要 5-8 秒。對話量大的時候，這個差距會明顯感受到。

長文維持

寫長文時兩者的差距最大。

Sonnet 寫到 2000 字左右，風格容易開始漂移，會慢慢回到它的預設語氣。Opus 寫到 3000 字以上還能維持設定的風格。

長文寫作（部落格、newsletter、報告）一律走 Opus 是常見選擇。

模型能力差異

比較表

比較項目Opus（旗艦級）Sonnet（主力級）
推理能力頂尖，長鏈推理穩定中上，效能接近前代 Opus
速度慢快（體感 2-3 倍）
指示遵循極好好
長文品質3000 字以上仍穩定2000 字後容易漂移
成本（API）高低
中文品質頂尖好
適合場景策略、分析、長文、安全審查日常、coding、批次、Agent 執行

速度品質平衡

使用場景推薦

用 Opus 的場景

長文寫作：超過 1500 字的文章，Opus 的品質差距很明顯。

複雜分析：技術架構評估、安全審計、多面向的比較分析。Opus 能同時考慮更多因素，結論更站得住。

策略規劃：需要權衡利弊、做取捨判斷的場景。Opus 給的建議比 Sonnet 細膩。

審計和 review：讓 Opus 審 Sonnet 的輸出。Sonnet 先做、Opus 檢查的這個組合，品質平均比單跑任一模型穩。

用 Sonnet 的場景

日常問答：查語法、寫程式。用 Opus 是殺雞用牛刀，會想太多。

程式碼撰寫：一般的 function、API endpoint、CRUD 操作，Sonnet 寫出來的品質跟 Opus 差不多。

格式轉換：JSON 轉 CSV、Markdown 轉 HTML 這種機械性操作，Sonnet 速度快又穩。

批次處理：需要跑 20 個相似任務的時候，Sonnet 的速度優勢讓總時間差很多。

使用場景分工

API 定價

API 的價格差距不小，具體數字以 Anthropic 官方 pricing 頁面 為準。

API 使用者若把所有東西都丟 Opus 跑，帳單會跳得很快。分清楚哪些任務需要 Opus 的品質、哪些 Sonnet 就夠用，帳單可以砍掉很多。

訂閱方案：Pro $20/月、Max 5x $100/月、Max 20x $200/月。Pro 以上都能用 Opus，差在用量上限。Max 5x 的用量是 Pro 的 5 倍，Max 20x 是 20 倍。主要在網頁版切模型用的人不需要管 API 定價，直接按需求選模型即可。

API 成本比較

多 agent 分工策略

把 Opus 和 Sonnet 放進同一個 agent 系統，常見的分工是：

  • Opus 當策略層：判斷、審查、長文寫作、架構設計
  • Sonnet 當執行層：跑機械任務、寫 code、批次處理、格式轉換

具體的工作分配：

  • 寫文章初稿 → Opus
  • 修改格式、調整排版 → Sonnet
  • 程式碼 review → Opus
  • 寫 code → Sonnet（Opus 只做架構討論）
  • 摘要和翻譯 → Sonnet
  • 安全審計 → Opus

這套分工跑久了會發現好處：Opus 的 context window 保留給真正需要它的任務，不會被日常瑣事佔掉。Sonnet 跑得快，整體吞吐量明顯提升。

Opus 與 Sonnet 分工流程

Sonnet 做完的事如果沒有經過 Opus 審，偶爾會有品質問題溜出去。對外發布的內容讓 Opus 過一眼是穩妥做法，速度慢一點但品質有保障。

小企鵝的經驗

小企鵝的多 agent 工作流就是 Opus + Sonnet + Codex 的組合，再加上其他角色（資料、自動化、媒體）分支出去。實際分工接近上面講的：策略和審查丟 Opus、執行和批次丟 Sonnet、寫 code 走 Codex 系列；對外發布的內容讓 Opus 收尾把關。多 agent 架構的細節可以看 OpenClaw 多 Agent 架構。

實務選型心得

建這套系統最痛的環節是記憶與檔案結構：怎麼讓不同 agent 在切換之間維持上下文、避免重工，比挑模型更燒精神。整理好核心檔案、把規則寫精簡，讓檔案結構自己當記憶，是目前小企鵝覺得最有用的訣竅。

延伸閱讀