📌 本文重點
- Opus 5 從 demo 模型躍升為可上線的 production 主力
- 建議採「Opus 做腦、Sonnet 做手」的雙模型架構
- 強化安全、RAG、tool 使用與多模型編排的最佳實務
第一件事：Opus 5 把「最強模型只能當 demo」這個痛點，往「真的能丟進 production」推了一大步。在 ARC-AGI-3 這種新型問題解決基準上，Opus 5 拿到 30.2% 分數，同等級模型（例如 Fable 系列）大概一半 token 價格；同時又補上多模態、工具調用、安全控制等企業級能力。對開發者來說，最大的價值是：
💡 關鍵： Opus 5 在 ARC-AGI-3 拿到 30.2%，以約半價 token 成本提供接近頂級旗艦的推理與企業級能力。
- 在編碼、RAG、Agent 這三大主流場景，可以更直接地拿來替換或混用現有 GPT / Claude 舊版
- 用 一套 API 和安全機制，把合規、幻覺控制、tool 使用統一到一個模型族群
- 在 成本 vs 能力 的拉扯中，有更清晰的「Opus / Sonnet / 本地模型」分工
重點說明：模型能力、費率與企業級特性
1. 模型族群與費率結構：怎麼排兵布陣
Anthropic 典型組合是：
- Claude 5 Opus：高推理、長上下文、多模態、最強工具使用能力。用在：複雜規劃、關鍵決策、Agent orchestrator、關鍵碼審查。
- Claude 5 Sonnet：中高性能、成本更低。用在：高頻次對話、一般程式生成、RAG 回答層。
- Claude 5 Haiku / 本地模型：超高頻、可接受誤差場景。用在：query rewrite、embedding 前處理、粗篩分類。
Opus 5 的定位：
- 接近頂級旗艦（文中對標 Fable 5），但 token 價格約半價
- 在 coding、知識工作和複雜推理上可當「主力高端模型」，不再只適合作為偶爾叫一次的 premium 模型
💡 關鍵： Opus 5 的策略是用約半價的 token 成本，承擔高推理、高風險任務，讓旗艦模型能真正進入日常 production 流程。
實務建議：
- 新專案：直接採 「Opus 做腦、Sonnet 做手」 的雙模型架構
- 既有 OpenAI / Claude 3 專案：先把高風險、高價值的步驟換成 Opus 5，再慢慢 rollout 其他部分
2. 安全性與企業級：如何設計 prompt / 架構控風險
Anthropic 的強項一直是 安全 / 合規 / 可控行為，Opus 5 延續這點並加強：
- 更嚴格遵守系統層指令（system message）→ 適合用來實作公司級「行為政策」
- 內建對 敏感話題、個資、濫用 的拒答與降階描述能力
- 系統卡（system card）說明了其對安全邊界的設計與限制
設計上建議：
- 系統層明確寫「允許做什麼、不允許做什麼」，而不是只寫風格
- 對於高風險 domain（醫療、財務、法律）採用 「模型 + 規則引擎/審核人」 的二階段架構
- RAG 場景強制：「只能根據提供的文件回答，無法回答就說不知道」，並在系統層寫死
簡化示意：
{
"model": "claude-5-opus-2026-07-25",
"messages": [
{
"role": "system",
"content": [
{
"type": "text",
"text": "你是企業內部助理，**所有回答必須符合以下規則**：\n1. 僅可根據提供的檔案與 tool 回傳資料作答。\n2. 若資訊不足，請明確回答『我無法根據現有資料回答』，不得自行推測。\n3. 涉及個資或敏感資料時，優先隱去或模糊處理。"
}
]
},
{
"role": "user",
"content": [
{
"type": "text",
"text": "說明這份合約的付款條款重點"
}
]
}
]
}
這樣可以大幅降低幻覺與合規風險，尤其在內部文件 RAG、決策輔助類應用。
3. 接 Claude API 的多模態 / 長上下文 / function calling
Opus 5 支援：
- 多模態：文字 + 圖像輸入
- 長上下文：適合大型文件 / 多輪 Agent 對話
- tool / function calling：結構化叫用後端服務
API 型式與 Claude 5 系列一致，用 /v1/messages，關鍵參數：
model：claude-5-opus-2026-07-25（假設版號）tools：宣告可用 tool schematool_choice：控制是否自動選工具max_output_tokens：記得設上限避免爆成本
實作範例：從簡單調用到多模型編排
1. 多模態 + 長上下文基本調用
以下用 Node.js 示意（Python 也幾乎同樣）：
import Anthropic from "@anthropic-ai/sdk";
const client = new Anthropic({ apiKey: process.env.CLAUDE_API_KEY });
const res = await client.messages.create({
model: "claude-5-opus-2026-07-25",
max_output_tokens: 800,
messages: [
{
role: "user",
content: [
{
type: "text",
text: "看這張錯誤截圖，說明 build 為什麼失敗，並給出修正 steps"
},
{
type: "image",
source: {
type: "base64",
media_type: "image/png",
data: screenshotBase64
}
},
{
type: "text",
text: longBuildLog // 可是一整段 build log，利用長 context
}
]
}
]
});
console.log(res.content[0].text);
實際好處：
- debug pipeline 時，不用自己剪 log + 截圖分別丟，Opus 5 能直接在圖 + log 裡找因果
- 利用長上下文，把整段 build log 喂進去，少做複雜 chunking
2. Function calling：由 Opus 5 當 orchestrator agent
假設有兩個後端工具：查用戶資料、創建 Jira ticket，由 Opus 5 自動決定何時調用。
const tools = [
{
name: "get_user_profile",
description: "依 user_id 取得使用者資訊",
input_schema: {
type: "object",
properties: { user_id: { type: "string" } },
required: ["user_id"]
}
},
{
name: "create_jira_ticket",
description: "建立 Jira bug ticket",
input_schema: {
type: "object",
properties: {
summary: { type: "string" },
description: { type: "string" },
priority: { type: "string", enum: ["Low", "Medium", "High"] }
},
required: ["summary", "description"]
}
}
];
const res = await client.messages.create({
model: "claude-5-opus-2026-07-25",
tools,
tool_choice: "auto", // 讓模型自行決定是否呼叫工具
messages: [
{
role: "user",
content: [
{
type: "text",
text: "幫我檢查 user_123 的帳號狀態，如果真的有 bug 就開一張高優先的 Jira"
}
]
}
]
});
for (const block of res.content) {
if (block.type === "tool_call") {
const { name, input } = block;
// 在這裡實際呼叫你的後端，再把結果做成新的 assistant/tool 回合
}
}
實際好處：
- 讓 Opus 5 做決策與規劃，例如先查 user，再視需要開 ticket
- 在多 step 任務中，比較能處理模糊指令（”如果真的有 bug 就…”）
相較 Sonnet / 本地模型，Opus 5 在：
- 正確選用對的 tool、傳對參數 的成功率明顯更高
- 多步推理（先查再判斷再執行）時較少「跳步」或忘記驗證條件
3. 多模型編排：Opus + Sonnet + 本地模型
典型 production 架構可以長這樣：
graph TD
U[使用者] -->|query| R[Router]
R -->|簡單 Q&A / 高頻| S[Claude 5 Sonnet]
R -->|複雜規劃 / 新任務| O[Claude 5 Opus]
R -->|極高頻前處理| L[本地模型]
S --> B[Business Logic]
O --> B
L --> S
簡易 routing 示意（Node + 手寫 rules）：
function routeModel(intent: "simple" | "complex" | "preprocess") {
switch (intent) {
case "preprocess":
return "local";
case "simple":
return "claude-5-sonnet-2026-07-25";
case "complex":
return "claude-5-opus-2026-07-25";
}
}
何時用 Opus、何時退回 Sonnet / 本地？
- Opus：
- 要跨多文件 / 多步驟整合推理（合約比較、架構選型、長鏈式工具調用）
- 產出錯誤成本高（法律、財務建議，CI/CD pipeline 生成、關鍵 infra IaC）
- Sonnet：
- 常規 coding assistant、一般 RAG 問答、標準客服問答
- 允許小錯但需要高吞吐
- 本地模型：
- 簡單分類 / metadata 抽取 / prompt rewrite / query expansion
建議與注意事項：遷移坑與最佳實踐
1. 從舊 Claude / OpenAI 遷移的常見坑
- 上下文長度變長 ≠ 可以亂餵
- Opus 5 支援更長 context，但：
- token 成本會線性上升
- 太長反而容易導致模型抓錯重點
-
建議：保留 chunking + ranking，只是在「最終 candidate 合併」時可以放更多片段
-
tool schema 的差異
- Claude 使用
tools+input_schema，與 OpenAI 的functions+parameters類似但格式略不同 -
遷移時要注意：
- JSON Schema 的
type、required、enum要嚴格 - 工具名稱 保持穩定且語義明確，模型會用名稱來推理用途
- JSON Schema 的
-
行為差異造成回歸
- Opus 5 對 system message 服從度較高，可能導致：
- 原本模糊的 system 設計 → 在新模型下變成過度保守或拒答
- 建議：
- 把原本的 system 重新整理成清楚的「允許 / 禁止列表」
- 遷移前先在 staging 跑 regression prompt test（可以用 Claude Cookbook 裡的測試框架範例改）
2. 降低幻覺與合規風險的模式
- RAG 必備：
- system 固定句：「如果資料不足，請回答『我不知道』，不得自行補完。」
- user prompt 裡標出：
[來源文件開始]... [來源文件結束] -
回答時要求
"citation": [doc_id, ...]結構化輸出 -
敏感領域：
- Opus 5 做 reasoning + 初版草稿
- 交由規則引擎（關鍵字、正則）+ 人工審核做最後關卡
3. 成本優化實務
- 一開始刻意過度使用 Opus 收集資料，記錄：
- 哪些 query 類型其實 Sonnet / 本地就夠
- 哪些工具調用失敗是因為 prompt / schema 設計不好
- 之後用這些 log 寫 routing 規則或訓練 classifier，把 60-80% 流量導回 Sonnet / 本地
💡 關鍵： 先用 Opus 全覆蓋收集真實流量，再用資料驅動的 routing 把 60–80% 較簡單請求轉回更便宜模型，是實務上的成本優化路徑。
總結：
- Claude Opus 5 適合做「系統的大腦」而不是「所有事情都自己做」
- 把它放在複雜推理、Agent orchestrator、關鍵決策點，其餘交給 Sonnet 或本地模型
- 遷移時要特別檢查：上下文策略、tool schema、system prompt 行為差異，避免隱性回歸
善用 Anthropic 提供的 Claude Cookbook 做 prompt / tool 設計模板，可以大幅縮短從 PoC 到 production 的時間。
🚀 你現在可以做的事
- 實際用
claude-5-opus-2026-07-25在沙箱環境替換現有高風險、高價值步驟，觀察效果與成本- 參考 Claude Cookbook，為自家場景重寫一版明確的 system prompt 與 tool schema
- 從現有 log 中標註「簡單 / 複雜 / 前處理」intent，實作最基本的 Opus / Sonnet / 本地模型 routing 規則
