文章轉(zhuǎn)載于新智元

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

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

它不僅編程強(qiáng)，而且智能體和計(jì)算機(jī)使用（computer use）能力也是一流。

Opus 4.5的誕生，標(biāo)志著AI能力再一次飛躍，更將在未來(lái)徹底變革工作的方式。

基準(zhǔn)測(cè)試中，Opus 4.5的編碼、工具調(diào)用、計(jì)算機(jī)使用的成績(jī)刷新SOTA，比Sonnet 4.5、Opus 4.1領(lǐng)先一大截。

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

SWE-bench Verified一張圖，直接證明了Opus 4.5強(qiáng)大實(shí)力，80.9%的準(zhǔn)確率，世界第一。

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

左右滑動(dòng)查看

Opus 4.5這版厲害之處：在無(wú)需人工干預(yù)的情況下，就能處理模糊信息，還會(huì)權(quán)衡利弊。

即便是遇到復(fù)雜的多系統(tǒng)漏洞，也能夠找出修復(fù)方法。

總之，用起來(lái)就一個(gè)感覺(jué)——「一點(diǎn)就透」。

內(nèi)部評(píng)估中，Opus 4.5+Claude Code聯(lián)動(dòng)使用，平均生產(chǎn)效率暴增220%。

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

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

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

不過(guò)一周的時(shí)間，AI圈真正閉環(huán)了。

1

編程之王回歸，真SOTA

有一說(shuō)一，Claude Opus 4.5是地表最強(qiáng)編程模型。

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

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

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

在真實(shí)場(chǎng)景的軟件工程測(cè)試中，Claude Opus 4.5更是刷新SOTA：

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

與Opus一同發(fā)布的，還有Claude開(kāi)發(fā)者平臺(tái)、Claude Code以及消費(fèi)者端App的更新。

Anthropic為長(zhǎng)時(shí)間運(yùn)行的智能體提供了新工具，并帶來(lái)了在Excel、Chrome和桌面端使用Claude的新方式。在Claude App中，長(zhǎng)對(duì)話不再會(huì)因?yàn)樯舷挛南拗贫袛唷?/p>

碾壓Gemini 3，超越人類(lèi)

首先，Opus 4.5在視覺(jué)、推理和數(shù)學(xué)能力上均得到了全面提升，并在多個(gè)領(lǐng)域達(dá)到了業(yè)界頂尖水平。

尤其是，在編碼、智能體、計(jì)算機(jī)使用三大項(xiàng)，完勝Gemini 3 Pro、GPT-5.1。

其次，在代碼方面。

Opus 4.5編寫(xiě)的代碼質(zhì)量更高，在SWE-bench Multilingual測(cè)試的8種編程語(yǔ)言中，它有7種都處于領(lǐng)先地位。

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

在智能體搜索任務(wù)上，Opus 4.5實(shí)現(xiàn)了重大突破，在BrowseComp-Plus基準(zhǔn)測(cè)試中取得顯著提升。

Opus 4.5表現(xiàn)穩(wěn)定持久，在Vending-Bench基準(zhǔn)上整體收益比Sonnet 4.5高出29%.

衡量智能體（Agentic）能力的一個(gè)通用基準(zhǔn)是τ2-bench，它考察智能體在現(xiàn)實(shí)世界多輪任務(wù)中的表現(xiàn)。

在一個(gè)場(chǎng)景中，模型需要扮演航空公司客服代理，幫助一位焦急的客戶(hù)?；鶞?zhǔn)測(cè)試原本期望模型拒絕修改「基本經(jīng)濟(jì)艙」的預(yù)訂，因?yàn)楹娇展疽?guī)定此類(lèi)機(jī)票不可更改。

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

讓我想想在政策范圍內(nèi)我有哪些選擇：

1. 修改航班 - 基本經(jīng)濟(jì)艙不可修改。這一點(diǎn)在政策中寫(xiě)得很清楚。

2. 更改艙位 - 等等，讓我確認(rèn)一下這個(gè)選項(xiàng)！政策上說(shuō)：「在其他情況下，所有預(yù)訂，包括基本經(jīng)濟(jì)艙，都可以在不更改航班的情況下更改艙位?！?/p>

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

· 先更改艙位（這對(duì)基本經(jīng)濟(jì)艙是 允許 的），然后

· 再更改航班（這對(duì)非基本經(jīng)濟(jì)艙是允許的）

所以策略可能是：

1. 將他的艙位從基本經(jīng)濟(jì)艙升級(jí)為經(jīng)濟(jì)艙（或商務(wù)艙）

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

這會(huì)花費(fèi)更多錢(qián)，但這在政策范圍內(nèi)是一條合法的路徑！

盡管該基準(zhǔn)測(cè)試判定此結(jié)果為「失敗」（因?yàn)镃laude的方式超出了預(yù)期），但這種創(chuàng)造性的解決問(wèn)題能力正是測(cè)試者和客戶(hù)所津津樂(lè)道的——這也是Claude Opus 4.5讓人感覺(jué)邁出實(shí)質(zhì)性一步的原因。

最后，在軟件工程領(lǐng)域。

Anthropic通常會(huì)給應(yīng)聘性能工程師的候選人布置一道出了名難的遠(yuǎn)程測(cè)試題，用來(lái)評(píng)估在時(shí)間壓力下的技術(shù)能力和判斷力。

而Claude Opus 4.5則在規(guī)定的2小時(shí)時(shí)限內(nèi)，得分超過(guò)了以往任何一位人類(lèi)候選人。

最穩(wěn)健、最對(duì)齊、最安全

正如在系統(tǒng)卡中所述，Claude Opus 4.5是Anthopic迄今為止發(fā)布的最穩(wěn)健、最對(duì)齊（Aligned）的模型。

Anthropic認(rèn)為它也是目前所有AI模型中對(duì)齊程度最高的基準(zhǔn)模型。它延續(xù)了Anthropic向更安全、更可靠模型發(fā)展的趨勢(shì)：

在這項(xiàng)評(píng)估中，「令人擔(dān)憂(yōu)的行為」評(píng)分涵蓋了廣泛的錯(cuò)位行為，既包括配合人類(lèi)進(jìn)行惡意濫用，也包括模型自主采取的不良行動(dòng)

在抵御「提示詞注入」（Prompt Injection）攻擊方面，Opus 4.5取得了實(shí)質(zhì)性進(jìn)展——

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

該基準(zhǔn)測(cè)試僅包含極高強(qiáng)度的提示詞注入攻擊

有關(guān)Opus4.5所有能力和安全評(píng)估的詳細(xì)描述，請(qǐng)參閱《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這樣的產(chǎn)品展示了當(dāng)Claude開(kāi)發(fā)者平臺(tái)的升級(jí)整合在一起時(shí)能實(shí)現(xiàn)什么。

Opus 4.5為Claude Code帶來(lái)了兩項(xiàng)升級(jí)。

「計(jì)劃模式」（Plan Mode）現(xiàn)在能構(gòu)建更精確的計(jì)劃并執(zhí)行得更徹底——Claude會(huì)先詢(xún)問(wèn)澄清性問(wèn)題，然后在執(zhí)行前生成一個(gè)用戶(hù)可編輯的plan.md文件。

Claude Code現(xiàn)已登陸桌面端App，支持并行運(yùn)行多個(gè)本地或遠(yuǎn)程會(huì)話：比如一個(gè)智能體在修Bug，另一個(gè)在查GitHub資料，第三個(gè)在更新文檔。

對(duì)于Claude App用戶(hù)，長(zhǎng)對(duì)話不再會(huì)遭遇「碰壁」——Claude會(huì)根據(jù)需要自動(dòng)總結(jié)之前的上下文，確保聊天持續(xù)進(jìn)行。

Claude for Chrome（讓Claude 處理瀏覽器標(biāo)簽頁(yè)任務(wù)）現(xiàn)已向所有Max用戶(hù)開(kāi)放。Claude for Excel，從今天起將Beta測(cè)試權(quán)限擴(kuò)展至所有Max、Team和Enterprise用戶(hù)。

每一次更新都充分利用了Claude Opus 4.5在計(jì)算機(jī)操作、電子表格處理和長(zhǎng)任務(wù)處理方面的市場(chǎng)領(lǐng)先性能。

對(duì)于有權(quán)訪問(wèn)Opus 4.5的Claude和Claude Code用戶(hù)，Anthropic取消了針對(duì) Opus 的特定限制。

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

這些限制專(zhuān)門(mén)針對(duì) Opus 4.5，隨著未來(lái)更強(qiáng)模型的推出，限制預(yù)計(jì)會(huì)按需更新。

1

開(kāi)發(fā)者平臺(tái)：token暴降85%

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

在達(dá)到類(lèi)似或更好結(jié)果時(shí)，Claude Opus 4.5的Token數(shù)大幅減少。

但不同的任務(wù)需要不同的權(quán)衡。有時(shí)開(kāi)發(fā)者希望模型對(duì)問(wèn)題進(jìn)行深思熟慮，有時(shí)則需要它更敏捷。

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

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

在「最高」投入度下，Opus 4.5的表現(xiàn)超越Sonnet 4.5達(dá)4.3%，同時(shí)Token消耗仍減少了48%。

憑借投入度控制、上下文壓縮和高級(jí)工具使用，Claude Opus 4.5運(yùn)行時(shí)間更長(zhǎng)，功能更強(qiáng)，且需更少的人工干預(yù)。

上下文管理和記憶能力可顯著提升智能體任務(wù)的性能。Opus 4.5在管理子智能體團(tuán)隊(duì)方面也非常高效，能夠構(gòu)建復(fù)雜、協(xié)調(diào)良好的多智能體系統(tǒng)。

測(cè)試顯示，結(jié)合所有這些技術(shù)，Opus 4.5在深度研究評(píng)估中的表現(xiàn)提升了近15%。

同在今天，Anthropic在Claude開(kāi)發(fā)者平臺(tái)上，更新了三大工具使用功能：

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

• 程序化工具調(diào)用（Programmatic Tool Calling）

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

工具搜索工具

首先，「工具搜索工具」允許Claude使用搜索工具訪問(wèn)數(shù)千個(gè)工具，而無(wú)需消耗其上下文窗口。

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

• GitHub：35個(gè)工具（約26KToken）

• Slack：11個(gè)工具（約21KToken）

• Sentry：5個(gè)工具（約3KToken）

• Grafana：5個(gè)工具（約3KToken）

• Splunk：2個(gè)工具（約2KToken）

這僅僅是58個(gè)工具，在對(duì)話開(kāi)始之前就已經(jīng)消耗了大約55K Token。

如果添加更多像Jira這樣的服務(wù)器（僅它本身就使用約17KToken），很快就會(huì)面臨100K+Token的開(kāi)銷(xiāo)。

在Anthropic，團(tuán)隊(duì)曾見(jiàn)過(guò)工具定義在優(yōu)化前就消耗了134KToken。

但Token成本并不是唯一的問(wèn)題。最常見(jiàn)的失敗原因還包括錯(cuò)誤的工具選擇和不正確的參數(shù)，尤其是當(dāng)工具具有相似名稱(chēng)時(shí)，比如notification-send-user與notification-send-channel。

想相比之下，工具搜索工具不再預(yù)先加載所有工具定義，而是按需發(fā)現(xiàn)工具。Claude只會(huì)看到當(dāng)前任務(wù)實(shí)際需要的工具。

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

傳統(tǒng)方法：

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

• 對(duì)話歷史和系統(tǒng)提示詞爭(zhēng)奪剩余空間

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

使用工具搜索工具：

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

• 根據(jù)需要按需發(fā)現(xiàn)工具（3-5個(gè)相關(guān)工具，約3KToken）

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

這意味著在保持訪問(wèn)完整工具庫(kù)的同時(shí)，Token使用量減少了85%。

內(nèi)部測(cè)試顯示，在處理大型工具庫(kù)時(shí)，MCP評(píng)估的準(zhǔn)確性顯著提高。

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

程序化工具調(diào)用

「程序化工具調(diào)用」允許Claude在代碼執(zhí)行環(huán)境中調(diào)用工具，從而減少對(duì)模型上下文窗口的占用。

隨著工作流變得更加復(fù)雜，傳統(tǒng)的工具調(diào)用產(chǎn)生了兩個(gè)基本問(wèn)題：

• 中間結(jié)果造成的上下文污染

• 推理開(kāi)銷(xiāo)和手動(dòng)合成

比如，一個(gè)常見(jiàn)的業(yè)務(wù)任務(wù)：「哪些團(tuán)隊(duì)成員超出了他們的Q3差旅預(yù)算？」

你有三個(gè)可用工具：

• get_team_members(department) - 返回帶有ID和級(jí)別的團(tuán)隊(duì)成員列表

• get_expenses(user_id, quarter) - 返回用戶(hù)的費(fèi)用明細(xì)項(xiàng)目

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

傳統(tǒng)方法：

• 獲取團(tuán)隊(duì)成員→20人

• 對(duì)于每個(gè)人，獲取他們的Q3費(fèi)用→20次工具調(diào)用，每次返回50-100個(gè)明細(xì)項(xiàng)目（機(jī)票、酒店、餐飲、收據(jù)）

• 按員工級(jí)別獲取預(yù)算限額

• 所有這些都進(jìn)入Claude的上下文：2,000+費(fèi)用明細(xì)項(xiàng)目（50 KB+）

• Claude手動(dòng)匯總每個(gè)人的費(fèi)用，查找他們的預(yù)算，將費(fèi)用與預(yù)算限額進(jìn)行比較

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

使用程序化工具調(diào)用：

Claude不再接收每個(gè)工具的返回結(jié)果，而是編寫(xiě)一個(gè)Python腳本來(lái)編排整個(gè)工作流。

該腳本在代碼執(zhí)行工具（一個(gè)沙盒環(huán)境）中運(yùn)行，在需要工具結(jié)果時(shí)暫停。當(dāng)通過(guò)API返回工具結(jié)果時(shí)，它們由腳本處理而不是由模型消耗。腳本繼續(xù)執(zhí)行，Claude只看到最終輸出。

程序化工具調(diào)用使Claude能夠通過(guò)代碼而不是通過(guò)單獨(dú)的API往返來(lái)編排工具，從而允許并行執(zhí)行工具。

以下是Claude為預(yù)算合規(guī)性任務(wù)編寫(xiě)的編排代碼示例：

Claude的上下文僅接收最終結(jié)果：兩到三個(gè)超出預(yù)算的人員。2,000+明細(xì)項(xiàng)目、中間總和和預(yù)算查找過(guò)程不會(huì)影響Claude上下文，將消耗從200KB的原始費(fèi)用數(shù)據(jù)減少到僅1KB的結(jié)果。

這種過(guò)程，在效率提升巨大：

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

• 降低延遲：每次API往返都需要模型推理（耗時(shí)數(shù)百毫秒到數(shù)秒）。當(dāng)Claude在單個(gè)代碼塊中編排20+個(gè)工具調(diào)用時(shí)，消除了19+次推理過(guò)程。API處理工具執(zhí)行，而無(wú)需每次都返回模型。

• 提高準(zhǔn)確性：通過(guò)編寫(xiě)顯式的編排邏輯，Claude在處理多個(gè)工具結(jié)果時(shí)比使用自然語(yǔ)言更少出錯(cuò)。內(nèi)部知識(shí)檢索準(zhǔn)確率從25.6%提高到28.5%；GIA基準(zhǔn)測(cè)試從46.5%提高到51.2%。

工具使用示例

「工具使用示例」提供了一套通用標(biāo)準(zhǔn)，用于演示如何有效地使用給定工具。

當(dāng)前的挑戰(zhàn)在于，JSON Schema擅長(zhǎng)定義結(jié)構(gòu)——類(lèi)型、必填字段、允許的枚舉值——但它無(wú)法表達(dá)使用模式：何時(shí)包含可選參數(shù)，哪些組合有意義，或者API期望什么樣的慣例。

考慮一個(gè)支持工單API：

模式定義了什么是有效的，但留下了關(guān)鍵問(wèn)題未解答：

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

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

• 嵌套結(jié)構(gòu)用法：Claude何時(shí)應(yīng)該填充reporter.contact？

• 參數(shù)相關(guān)性：escalation.level和escalation.sla_hours如何與priority相關(guān)聯(lián)？

這些歧義可能導(dǎo)致畸形的工具調(diào)用和不一致的參數(shù)使用。

對(duì)此，工具使用示例可以直接在工具定義中提供示例工具調(diào)用。開(kāi)發(fā)者不再僅依賴(lài)模式，而是向Claude展示具體的使用模式：

從這三個(gè)例子中，Claude學(xué)習(xí)到：

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

• 嵌套結(jié)構(gòu)模式：如何構(gòu)造帶有嵌套contact對(duì)象的reporter對(duì)象。

• 可選參數(shù)相關(guān)性：嚴(yán)重錯(cuò)誤（Critical bugs）需要完整的聯(lián)系信息+帶有嚴(yán)格SLA的升級(jí)；功能請(qǐng)求有報(bào)告者但沒(méi)有聯(lián)系信息/升級(jí)；內(nèi)部任務(wù)只有標(biāo)題。

在自?xún)?nèi)部測(cè)試中，工具使用示例在復(fù)雜參數(shù)處理上的準(zhǔn)確性從72%提高到90%。

1

大受好評(píng)

在發(fā)布前，Anthropic內(nèi)部對(duì)模型進(jìn)行了測(cè)試，反饋出奇一致。

測(cè)試者指出，在處理模糊指令和權(quán)衡利弊時(shí)，Claude Opus 4.5無(wú)需過(guò)多指引。

當(dāng)面對(duì)復(fù)雜的多系統(tǒng)Bug時(shí)，Opus 4.5 能精準(zhǔn)定位并修復(fù)。

幾周前對(duì)于Sonnet 4.5來(lái)說(shuō)還近乎不可能的任務(wù)，現(xiàn)在已觸手可及。

總而言之，測(cè)試者的評(píng)價(jià)是：Opus 4.5是真的「行家」。

左右滑動(dòng)查看

參考資料：

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

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

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

點(diǎn)個(gè)“愛(ài)心”，再走 吧