點樣用 Claude Opus 4.7 API

Lena 嚟咗。4 月 16 號發佈之後，我將官方文檔同遷移材料過咗一次，本以為大部分內容都會好熟。確實大部分係。但入面有夠多嘅結構性變化——三個 breaking 嘅 API 改動、一個新嘅 effort 系統、一個會改變 token 計數嘅 tokenizer——如果你將呢次升級當成「換下 model ID 咁簡單」，會出事。

以下係我自己行咗一次之後睇到嘅嘢。

Claude Opus 4.7 API 包含咩

Model ID、上下文窗口、output 上限同工具

先將基本嘢講清楚，因為呢啲值得直講。

​**Model ID：​claude-opus-4-7**​。根據 Anthropic 官方 models overview，佢喺標準 API 定價下支援 1M token 上下文窗口，冇長上下文溢價；喺同步嘅 Messages API 上 最多 128k output token。喺 Message Batches API 上，用 output-300k-2026-03-24 beta header，Opus 4.7 可以跑到 300k output token。

成套工具由 Opus 4.6 繼承：bash、code execution、computer use、text editor、web search、web fetch、MCP connector、memory tools 第一日全部可用。vision 支援全面存在——而且有實質升級，下面我會回嚟講。

喺 Claude API、Amazon Bedrock、Google Cloud Vertex AI 同 Microsoft Foundry 上都可用——而且 喺 GitHub Copilot 上面向 Copilot Pro+、Business 同 Enterprise 用戶推出。定價：每百萬 input token $5、每百萬 output token $25——同 Opus 4.6 一樣冇變。

相比 Opus 4.6 有咩新嘢

喺 API 層面上，真正新嘅嘢有三件：

Adaptive thinking 係唯一嘅 thinking 模式。 舊嘅 {"type": "enabled", "budget_tokens": N} 寫法已經冇咗。而家咁發送會返回一個 ​400 錯誤​。Opus 4.7 用 {"type": "adaptive"}——模型根據任務複雜度動態決定要推理幾多。adaptive thinking 預設係熄嘅；如果你想個模型諗嘢，必須顯式開。

​xhigh​ effort level。 佢位於 high 同 max 之間，係 coding 同 agentic 用例新嘅推薦起點。API 預設仍然係 high；你要透過 output_config 顯式設成 xhigh。結構我下面會寫出嚟。

Task budgets（beta）。 一個新機制，俾模型一個針對成個 agentic 循環嘅 token 目標——thinking、tool call、tool result、最終 output 全部加埋計。模型會睇到一個倒數，用佢嚟排優先級，並喺預算用完時優雅收場。

同時移除：​非預設嘅 sampling 參數​。將 temperature、top_p、top_k 設成任何非預設值，而家都會返回 400 錯誤。如果你之前用 temperature=0 求確定性輸出，要留意佢其實從來冇真正保證過輸出一樣——遷移指南建議索性唔好發呢啲參數。

一個最小嘅 Claude Opus 4.7 API 設置

第一條請求嘅結構

Opus 4.7 最小可運行嘅請求係咁：

import anthropic

client = anthropic.Anthropic()

message = client.messages.create(
    model="claude-opus-4-7",
    max_tokens=4096,
    messages=[
        {"role": "user", "content": "Explain the tradeoffs between BFS and DFS for a graph with cycles."}
    ]
)

print(message.content[0].text)

呢條請求冇啟用 thinking。個模型會直接答。對大部分任務嚟講，呢個就係啱嘅起點——只有喺你有理由嘅時候先加複雜度。

揀 Adaptive Thinking 同 Effort Level

當你希望模型喺答之前先推理，加埋 thinking 配置，並顯式設 effort：

message = client.messages.create(
    model="claude-opus-4-7",
    max_tokens=16384,
    thinking={"type": "adaptive"},
    output_config={"effort": "xhigh"},
    messages=[
        {"role": "user", "content": "Review this pull request for security vulnerabilities..."}
    ]
)

根據 Anthropic 官方嘅 effort 文檔，關於 effort level 有幾件嘢值得知：

• high 係 API 預設。用嚟處理複雜推理、微妙分析或者困難嘅 coding 問題，質量優先。
• xhigh 係新級別——推薦用喺 coding 同 agentic 任務。Claude Code 已經喺所有方案上將預設提到 xhigh。
• max 提供最深嘅推理、冇 token 約束。只對當前 session 生效（除非透過環境變量設），唔會持久化。
• low​ 同 ​​**medium** 用精度換速度同成本。適合高吞吐分類或路由，嗰種邊際質量差異唔值得花錢嘅場景。

有個細節我回頭讀咗兩次：​Opus 4.7 比 Opus 4.6 更嚴格咁尊重 effort level​，尤其喺 low 同 medium。如果你喺一個複雜任務上面觀察到推理偏淺，正確做法係將 effort 提上去——而唔係喺 prompt 外面加搭架。文檔對呢點好明確。

跑 xhigh 或 max 嗰陣，將 ​max_tokens​ 設成至少 64k，俾個模型喺 subagent 同 tool call 之間有空間去諗同行動。由 64k 起步再調，係 Anthropic 自己嘅建議。

對長時段 agent 真正重要嘅 feature

高解像度 vision、xhigh effort 同 tool workflow

vision 升級係對 agent 開發者最具體嘅能力提升。正如 Vellum AI 對 Opus 4.7 嘅 benchmark 分析 所記錄，OSWorld-Verified（computer use）由 Opus 4.6 嘅 72.7% 升到 78.0%——5 個點嘅提升，疊加解像度升級，實質咁改變咗 UI 自動化嘅經濟學。

Opus 4.7 係 ​第一款支援高解像度圖像嘅 Claude 模型​：最大解像度由 1,568 像素（約 1.15MP）提到 2,576 像素（約 3.75MP）長邊。像素預算多咗三倍以上。對嗰啲讀取密集 UI、基於截圖嘅 workflow、或者文檔理解 pipeline 嘅 computer-use agent 嚟講，呢個係一個有分量嘅變化。關鍵係，坐標而家同實際圖像像素 1:1 映射——以前做坐標抽取要計嘅縮放因子冇咗。

一條帶 vision 嘅請求：

message = client.messages.create(
    model="claude-opus-4-7",
    max_tokens=4096,
    messages=[
        {
            "role": "user",
            "content": [
                {
                    "type": "image",
                    "source": {"type": "url", "url": "https://example.com/diagram.png"}
                },
                {"type": "text", "text": "List every service shown and the connections between them."}
            ]
        }
    ]
)

如果某個任務並唔需要嗰啲額外解像度，發送前先降採樣——高解像度圖片會產生更多 token，對成本敏感嘅工作負載嚟講，呢個會累積。

對工具密集嘅 agentic 循環，提高 effort 會增加 tool call 嘅頻率同深度。關係係直接嘅：effort 越低 → tool call 越少、推理鏈越淺；effort 越高 → tool 互動越徹底。呢樣都可以透過 prompt 去引導，但 effort 參數係更乾淨嘅槓桿。

面向生產嘅成本同延遲控制

Task budgets 係控制長 agentic 循環開銷嘅新機制。用 beta header 啟用：

response = client.beta.messages.create(
    model="claude-opus-4-7",
    max_tokens=128000,
    output_config={
        "effort": "high",
        "task_budget": {"type": "tokens", "total": 128000}
    },
    messages=[
        {"role": "user", "content": "Review the codebase and propose a refactor plan."}
    ],
    betas=["task-budgets-2026-03-13"]
)

個模型會睇到呢個倒數，用佢嚟排優先級同優雅收場。冇 task budget 嘅情況下，預設行為係「按需花」——喺一個 xhigh 下嘅複雜 agentic 任務上，呢個可能意味住比你從單輪請求預期到嘅多好多嘅 output token。

對異步工作負載——評估 run、每晚總結、批量分析——Batch API 俾 50% 折扣，同埋將實時流量從 rate-limit 壓力中抽出嚟。prompt caching 仍然可用，對嗰啲有穩定 system prompt 或大段靜態前綴嘅工作負載，可以將重複嘅 input 成本減最多 90%。

要避開嘅遷移錯誤

假設 4.6 嘅 prompt 可以原樣搬過嚟

呢個係我不停睇到冒出嚟嘅一個。

Opus 4.7 比 Opus 4.6 更字面咁遵循指令。佢唔再「讀字裡行間」，亦唔再靜靜由一個 case 泛化到另一個。軟措辭——「try to」、「if possible」、「roughly」——而家真係有更大嘅分量。嗰啲依賴 4.6 解讀彈性嘅 prompt 有時會以唔同方式運作，而且唔一定係你預期嘅方向。

三個 breaking 嘅 API 變化需要改代碼，唔只係改 prompt：

1. 將 thinking: {type: "enabled", budget_tokens: N} 換成 thinking: {type: "adaptive"}
2. 將 temperature、top_p、top_k 完全由請求入面移除
3. 審計 max_tokens——新 tokenizer 對同一段文本最多會映射到 ​1.35× 更多 token​，所以以前夠用嘅上限可能會將回覆截斷

關於語氣：Opus 4.7 比 4.6 更直接、更有主見——emoji 更少、少咗嗰種「驗證先行」嘅措辭。如果你個產品依賴一種按 4.6 嗰種更溫暖風格調過嘅聲線，喺推到生產之前，先將你嘅 style prompt 針對新基線重新評估一次。

Anthropic 嘅 Opus 4.7 發佈公告 直接 link 到完整嘅遷移 checklist，Claude Code 用戶可以跑 /claude-api migrate 喺一個 codebase 上自動完成 model ID 替換同 breaking 參數改動。

將長上下文當成持久記憶

我喺文檔入面讀到呢段嗰陣停咗一下，因為兩樣真係好容易撈埋。

1M token 嘅上下文窗口唔係持久記憶。 佢嘅意思係你可以喺一條請求入面塞入 100 萬 token。當嗰條請求完——session 關咗、agent crash、新對話開始——嗰段上下文就冇咗。下一條請求由零開始。

Opus 4.7 確實包括改進咗嘅、基於文件系統嘅記憶：模型會喺多 session 工作中讀寫 notes 文件，用呢種 pattern 嘅 agent 行為明顯更可靠。但嗰個係你自己配置嘅工具。佢唔會由一個長上下文窗口自動長出嚟。

對任何喺搭「跨 run 記住嘢」agent 嘅人嚟講，呢個區別好重要。1M 窗口喺 session 入面有幫助。跨 session 記憶需要顯式架構。

API 仍然冇解決嘅嘢

能力複用同被驗證過嘅修復歷史

呢段我覺得放入一份 API 指南入面冇咁齊整，但我覺得值得講。

當 Opus 4.7 喺 planning 階段抓到一個邏輯錯誤——發佈材料將呢個形容為一個真實嘅能力——嗰個推理發生喺 session 入面。佢抓到嗰個錯誤呢件事、同佢點樣修正呢件事，唔會自動作為一個可複用 pattern 持久低落畀下次用。下一次同一類問題再出現嗰陣，模型仲係由零推理。

根據 2026 年初發表嘅一篇關於 AI agent 可靠性嘅研究論文，大部分模型係按平均準確率而唔係跨 run 一致性嚟做 benchmark——呢個意味住一個模型可以喺 benchmark 上分數靚，同時喺同一類任務嘅唔同時刻仲會不可預測咁失敗。Opus 4.7 喺 Opus 4.6 嘅基線上有改進。呢個係真嘅。但 session 內嘅修正同跨 session 嘅能力繼承係兩個唔同嘅問題，API 解決咗第一個，冇解決第二個。

對喺跑生產 agent 嘅構建者嚟講，呢個意味住搭可靠系統嘅工程工作——評估 harness、repair 文檔、監控——仍然坐喺模型之外。API 俾你嘅係一個更強嘅模型。點樣將呢種能力喺時間上用起嚟，仍然坐喺你嘅架構上。

FAQ

Q：Opus 4.7 正確嘅 model ID 係咩？

A：claude-opus-4-7。呢個係跨 Claude API、Amazon Bedrock、Google Cloud Vertex AI 同 Microsoft Foundry 嘅穩定 model string。

Q：adaptive thinking 預設係開嘅咩？

A：唔係。喺 Opus 4.7 上 adaptive thinking 預設係熄嘅。必須顯式設 thinking: {"type": "adaptive"} 先至會啟用。唔帶 thinking 欄位嘅請求唔會諗嘢。

Q：如果我發咗 ​temperature​ 或者 ​budget_tokens​ 會點？

A：兩個喺 Opus 4.7 上面都會返回 400 錯誤。將 temperature、top_p、top_k 從所有請求入面刪走。將 budget_tokens 換成 output_config: {"effort": "..."} 同 thinking: {"type": "adaptive"}。

Q：幾時用 xhigh、幾時用 high？

A：將 xhigh 作為 coding 同 agentic 任務嘅起點——Claude Code 喺所有方案上嘅預設而家就係佢。大部分對智能度敏感嘅任務用 high。當延遲或成本比推理深度更重要嗰陣降到 medium 或 low。如果你喺一個複雜任務上、喺更低級別上面觀察到淺輸出，將 effort 提上去，而唔係喺 prompt 外面加搭架。

Q：1M 上下文窗口係咪意味住 agent 會喺 session 之間記住嘢？

A：唔係。上下文窗口係喺一條請求入面生效嘅。session 完咗，嗰段上下文就冇咗。多 session 記憶需要顯式工具——基於文件嘅記憶、外部 store 或者類似嘅架構。

Previous Posts

• 如果你想理解點解模型升級其實減唔到系統成本：Claude Opus 4.7 vs Reliability: Why Better Models Don't Fix Agent Systems
• 如果你想理解真實成本藏喺 token 定價之外嘅邊度：Harness Engineering: The Hidden Layer Behind Agent Cost and Reliability
• 如果你喺評估幾時 Opus 相對 Sonnet 嘅溢價先至真係值得：Claude Managed Agents: When You Should Actually Use Opus vs Sonnet
• 如果你喺搭 agent 系統、需要同時控制行為同花費：Agent Superpowers: Behavior Constraints as a Cost Control Layer
• 如果你喺諗將 agent 使用量擴展到單個 workflow 之外：Best MCP Servers for Claude Code: Real Production Use Cases