突發！Claude Opus 4.5編程世界第一，把谷歌OpenAI踢下王座

文章轉載于新智元

全球編碼王座，一夜易主。

果不其然，Anthropic深夜放出了Claude Opus 4.5，堪稱全球最頂尖的模型。

它不僅編程強，而且智能體和計算機使用（computer use）能力也是一流。

Opus 4.5的誕生，標志著AI能力再一次飛躍，更將在未來徹底變革工作的方式。

基準測試中，Opus 4.5的編碼、工具調用、計算機使用的成績刷新SOTA，比Sonnet 4.5、Opus 4.1領先一大截。

不僅如此，就連發布不過一周的Gemini 3 Pro、GPT-5.1慘遭降維打擊。

SWE-bench Verified一張圖，直接證明了Opus 4.5強大實力，80.9%的準確率，世界第一。

同時，在ARC-AGI-2評估中，Opus 4.5（64k）拿下了37.6%的高分。

左右滑動查看

Opus 4.5這版厲害之處：在無需人工干預的情況下，就能處理模糊信息，還會權衡利弊。

即便是遇到復雜的多系統漏洞，也能夠找出修復方法。

總之，用起來就一個感覺——「一點就透」。

內部評估中，Opus 4.5+Claude Code聯動使用，平均生產效率暴增220%。

目前，Opus 4.5已在APP、Claude API和三大主流云平臺中上線。

價格方面，相較以往暴降不少，輸入5美元/百萬token，輸出25美元/百萬token。

Gemini 3 Pro干翻了GPT-5.1，但如今，就編碼性能，Opus 4.5全面碾壓前兩者。

不過一周的時間，AI圈真正閉環了。

1

編程之王回歸，真SOTA

有一說一，Claude Opus 4.5是地表最強編程模型。

它智能、高效，是目前全球在編程、AI智能體（Agents）以及計算機操作方面最強悍的模型。

Anthropic研究員Adam Wolff豪言，也就在明年上半年，軟件工程徹底終結了。

在深度研究、處理PPT和電子表格等日常任務上，它也有顯著提升。

在真實場景的軟件工程測試中，Claude Opus 4.5更是刷新SOTA：

在SWE-bench Verified上的對比，Opus 4.5得分最高

與Opus一同發布的，還有Claude開發者平臺、Claude Code以及消費者端App的更新。

Anthropic為長時間運行的智能體提供了新工具，并帶來了在Excel、Chrome和桌面端使用Claude的新方式。在Claude App中，長對話不再會因為上下文限制而中斷。

碾壓Gemini 3，超越人類

首先，Opus 4.5在視覺、推理和數學能力上均得到了全面提升，并在多個領域達到了業界頂尖水平。

尤其是，在編碼、智能體、計算機使用三大項，完勝Gemini 3 Pro、GPT-5.1。

其次，在代碼方面。

Opus 4.5編寫的代碼質量更高，在SWE-bench Multilingual測試的8種編程語言中，它有7種都處于領先地位。

Opus 4.5能夠輕松解決具有挑戰性的編碼問題，在Aider Polyglot測試中比Sonnet 4.5提升了10.6%。

在智能體搜索任務上，Opus 4.5實現了重大突破，在BrowseComp-Plus基準測試中取得顯著提升。

Opus 4.5表現穩定持久，在Vending-Bench基準上整體收益比Sonnet 4.5高出29%.

衡量智能體（Agentic）能力的一個通用基準是τ2-bench，它考察智能體在現實世界多輪任務中的表現。

在一個場景中，模型需要扮演航空公司客服代理，幫助一位焦急的客戶。基準測試原本期望模型拒絕修改「基本經濟艙」的預訂，因為航空公司規定此類機票不可更改。

然而，Opus 4.5找到了一種極具洞察力（且合規）的解決方案：先升級艙位，再修改航班。

讓我想想在政策范圍內我有哪些選擇：

1. 修改航班 - 基本經濟艙不可修改。這一點在政策中寫得很清楚。

2. 更改艙位 - 等等，讓我確認一下這個選項！政策上說：「在其他情況下，所有預訂，包括基本經濟艙，都可以在不更改航班的情況下更改艙位。」

但他想更改航班，不僅僅是艙位。不過，如果我們：

· 先更改艙位（這對基本經濟艙是 允許 的），然后

· 再更改航班（這對非基本經濟艙是允許的）

所以策略可能是：

1. 將他的艙位從基本經濟艙升級為經濟艙（或商務艙）

2. 然后將航班修改為 2天后的班次

這會花費更多錢，但這在政策范圍內是一條合法的路徑！

盡管該基準測試判定此結果為「失敗」（因為Claude的方式超出了預期），但這種創造性的解決問題能力正是測試者和客戶所津津樂道的——這也是Claude Opus 4.5讓人感覺邁出實質性一步的原因。

最后，在軟件工程領域。

Anthropic通常會給應聘性能工程師的候選人布置一道出了名難的遠程測試題，用來評估在時間壓力下的技術能力和判斷力。

而Claude Opus 4.5則在規定的2小時時限內，得分超過了以往任何一位人類候選人。

最穩健、最對齊、最安全

正如在系統卡中所述，Claude Opus 4.5是Anthopic迄今為止發布的最穩健、最對齊（Aligned）的模型。

Anthropic認為它也是目前所有AI模型中對齊程度最高的基準模型。它延續了Anthropic向更安全、更可靠模型發展的趨勢：

在這項評估中，「令人擔憂的行為」評分涵蓋了廣泛的錯位行為，既包括配合人類進行惡意濫用，也包括模型自主采取的不良行動

在抵御「提示詞注入」（Prompt Injection）攻擊方面，Opus 4.5取得了實質性進展——

這種攻擊通常會夾帶欺騙性指令，誘導模型做出有害行為。Opus 4.5比業內任何其他前沿模型都更難被提示詞注入所欺騙：

該基準測試僅包含極高強度的提示詞注入攻擊

有關Opus4.5所有能力和安全評估的詳細描述，請參閱《Claude Opus 4.5 System Card》。

鏈接：https://assets.anthropic.com/m/64823ba7485345a7/Claude-Opus-4-5-System-Card.pdf

Claude Code、Claude for Chrome上新

Claude Code這樣的產品展示了當Claude開發者平臺的升級整合在一起時能實現什么。

Opus 4.5為Claude Code帶來了兩項升級。

「計劃模式」（Plan Mode）現在能構建更精確的計劃并執行得更徹底——Claude會先詢問澄清性問題，然后在執行前生成一個用戶可編輯的plan.md文件。

Claude Code現已登陸桌面端App，支持并行運行多個本地或遠程會話：比如一個智能體在修Bug，另一個在查GitHub資料，第三個在更新文檔。

對于Claude App用戶，長對話不再會遭遇「碰壁」——Claude會根據需要自動總結之前的上下文，確保聊天持續進行。

Claude for Chrome（讓Claude 處理瀏覽器標簽頁任務）現已向所有Max用戶開放。Claude for Excel，從今天起將Beta測試權限擴展至所有Max、Team和Enterprise用戶。

每一次更新都充分利用了Claude Opus 4.5在計算機操作、電子表格處理和長任務處理方面的市場領先性能。

對于有權訪問Opus 4.5的Claude和Claude Code用戶，Anthropic取消了針對 Opus 的特定限制。

對于Max和Team Premium用戶，Anthropic提高了總使用上限，這意味著擁有的Opus Token數量將與此前擁有的 Sonnet Token數量大致相同。

這些限制專門針對 Opus 4.5，隨著未來更強模型的推出，限制預計會按需更新。

1

開發者平臺：token暴降85%

隨著模型變得更聰明，它們能以更少的步驟解決問題：更少的回溯，更少的冗余探索，更少的啰嗦推理。

在達到類似或更好結果時，Claude Opus 4.5的Token數大幅減少。

但不同的任務需要不同的權衡。有時開發者希望模型對問題進行深思熟慮，有時則需要它更敏捷。

通過Claude API新增的effort（投入度）參數，可以選擇最小化時間與成本，或是最大化能力。

設置為「中等」投入度時，Opus 4.5在SWE-bench Verified上的得分與Sonnet 4.5的最高分持平，但輸出Token減少了76%。

在「最高」投入度下，Opus 4.5的表現超越Sonnet 4.5達4.3%，同時Token消耗仍減少了48%。

憑借投入度控制、上下文壓縮和高級工具使用，Claude Opus 4.5運行時間更長，功能更強，且需更少的人工干預。

上下文管理和記憶能力可顯著提升智能體任務的性能。Opus 4.5在管理子智能體團隊方面也非常高效，能夠構建復雜、協調良好的多智能體系統。

測試顯示，結合所有這些技術，Opus 4.5在深度研究評估中的表現提升了近15%。

同在今天，Anthropic在Claude開發者平臺上，更新了三大工具使用功能：

• 工具搜索工具（Tool Search Tool）

• 程序化工具調用（Programmatic Tool Calling）

• 工具使用示例（Tool Use Examples）

工具搜索工具

首先，「工具搜索工具」允許Claude使用搜索工具訪問數千個工具，而無需消耗其上下文窗口。

MCP工具定義提供了重要的上下文，但隨著連接的服務器增多，這些Token的消耗會不斷累積。假設一個包含五個服務器的設置：

• GitHub：35個工具（約26KToken）

• Slack：11個工具（約21KToken）

• Sentry：5個工具（約3KToken）

• Grafana：5個工具（約3KToken）

• Splunk：2個工具（約2KToken）

這僅僅是58個工具，在對話開始之前就已經消耗了大約55K Token。

如果添加更多像Jira這樣的服務器（僅它本身就使用約17KToken），很快就會面臨100K+Token的開銷。

在Anthropic，團隊曾見過工具定義在優化前就消耗了134KToken。

但Token成本并不是唯一的問題。最常見的失敗原因還包括錯誤的工具選擇和不正確的參數，尤其是當工具具有相似名稱時，比如notification-send-user與notification-send-channel。

想相比之下，工具搜索工具不再預先加載所有工具定義，而是按需發現工具。Claude只會看到當前任務實際需要的工具。

工具搜索工具保留了191,300 Token的上下文，而傳統方法只有122,800

傳統方法：

• 預先加載所有工具定義（50+ MCP工具約消耗72KToken）

• 對話歷史和系統提示詞爭奪剩余空間

• 總上下文消耗：在任何工作開始前約77K Token

使用工具搜索工具：

• 僅預先加載工具搜索工具本身（約500Token）

• 根據需要按需發現工具（3-5個相關工具，約3KToken）

• 總上下文消耗：約8.7KToken，保留了95%的上下文

這意味著在保持訪問完整工具庫的同時，Token使用量減少了85%。

內部測試顯示，在處理大型工具庫時，MCP評估的準確性顯著提高。

啟用工具搜索工具后，Opus 4準確率從49%提高到74%，Opus 4.5從79.5%提高到88.1%。

程序化工具調用

「程序化工具調用」允許Claude在代碼執行環境中調用工具，從而減少對模型上下文窗口的占用。

隨著工作流變得更加復雜，傳統的工具調用產生了兩個基本問題：

• 中間結果造成的上下文污染

• 推理開銷和手動合成

比如，一個常見的業務任務：「哪些團隊成員超出了他們的Q3差旅預算？」

你有三個可用工具：

• get_team_members(department) - 返回帶有ID和級別的團隊成員列表

• get_expenses(user_id, quarter) - 返回用戶的費用明細項目

• get_budget_by_level(level) - 返回員工級別的預算限額

傳統方法：

• 獲取團隊成員→20人

• 對于每個人，獲取他們的Q3費用→20次工具調用，每次返回50-100個明細項目（機票、酒店、餐飲、收據）

• 按員工級別獲取預算限額

• 所有這些都進入Claude的上下文：2,000+費用明細項目（50 KB+）

• Claude手動匯總每個人的費用，查找他們的預算，將費用與預算限額進行比較

• 更多的模型往返交互，顯著的上下文消耗

使用程序化工具調用：

Claude不再接收每個工具的返回結果，而是編寫一個Python腳本來編排整個工作流。

該腳本在代碼執行工具（一個沙盒環境）中運行，在需要工具結果時暫停。當通過API返回工具結果時，它們由腳本處理而不是由模型消耗。腳本繼續執行，Claude只看到最終輸出。

程序化工具調用使Claude能夠通過代碼而不是通過單獨的API往返來編排工具，從而允許并行執行工具。

以下是Claude為預算合規性任務編寫的編排代碼示例：

Claude的上下文僅接收最終結果：兩到三個超出預算的人員。2,000+明細項目、中間總和和預算查找過程不會影響Claude上下文，將消耗從200KB的原始費用數據減少到僅1KB的結果。

這種過程，在效率提升巨大：

• Token節省：通過將中間結果隔離在Claude的上下文之外，程序化工具調用（PTC）顯著減少了Token消耗。在復雜研究任務上，平均使用量從43,588降至27,297個Token，減少了37%。

• 降低延遲：每次API往返都需要模型推理（耗時數百毫秒到數秒）。當Claude在單個代碼塊中編排20+個工具調用時，消除了19+次推理過程。API處理工具執行，而無需每次都返回模型。

• 提高準確性：通過編寫顯式的編排邏輯，Claude在處理多個工具結果時比使用自然語言更少出錯。內部知識檢索準確率從25.6%提高到28.5%；GIA基準測試從46.5%提高到51.2%。

工具使用示例

「工具使用示例」提供了一套通用標準，用于演示如何有效地使用給定工具。

當前的挑戰在于，JSON Schema擅長定義結構——類型、必填字段、允許的枚舉值——但它無法表達使用模式：何時包含可選參數，哪些組合有意義，或者API期望什么樣的慣例。

考慮一個支持工單API：

模式定義了什么是有效的，但留下了關鍵問題未解答：

• 格式歧義：due_date應該使用"2024-11-06"、"Nov 6, 2024"還是"2024-11-06T00:00:00Z"？

• ID慣例：reporter.id是UUID、"USR-12345"還是僅僅"12345"？

• 嵌套結構用法：Claude何時應該填充reporter.contact？

• 參數相關性：escalation.level和escalation.sla_hours如何與priority相關聯？

這些歧義可能導致畸形的工具調用和不一致的參數使用。

對此，工具使用示例可以直接在工具定義中提供示例工具調用。開發者不再僅依賴模式，而是向Claude展示具體的使用模式：

從這三個例子中，Claude學習到：

• 格式慣例：日期使用YYYY-MM-DD，用戶ID遵循USR-XXXXX，標簽使用kebab-case（短橫線命名）。

• 嵌套結構模式：如何構造帶有嵌套contact對象的reporter對象。

• 可選參數相關性：嚴重錯誤（Critical bugs）需要完整的聯系信息+帶有嚴格SLA的升級；功能請求有報告者但沒有聯系信息/升級；內部任務只有標題。

在自內部測試中，工具使用示例在復雜參數處理上的準確性從72%提高到90%。

1

大受好評

在發布前，Anthropic內部對模型進行了測試，反饋出奇一致。

測試者指出，在處理模糊指令和權衡利弊時，Claude Opus 4.5無需過多指引。

當面對復雜的多系統Bug時，Opus 4.5 能精準定位并修復。

幾周前對于Sonnet 4.5來說還近乎不可能的任務，現在已觸手可及。

總而言之，測試者的評價是：Opus 4.5是真的「行家」。

左右滑動查看

參考資料：

https://x.com/claudeai/status/1993030546243699119

https://www.anthropic.com/engineering/advanced-tool-use

https://www.anthropic.com/news/claude-opus-4-5

點個“愛心”，再走 吧