【新智元導讀】深夜,Claude Opus 4.5重磅出世,程式設計實力暴擊Gemini 3 Pro、GPT-5.1。才一周的時間,AI圈就完成了一次閉環式迭代。全球編碼王座,一夜易主。果不其然,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圈真正閉環了。程式設計之王回歸,真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.pdfClaude 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,隨著未來更強模型的推出,限制預計會按需更新。開發者平台: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%。大受好評在發佈前,Anthropic內部對模型進行了測試,反饋出奇一致。測試者指出,在處理模糊指令和權衡利弊時,Claude Opus 4.5無需過多指引。當面對複雜的多系統Bug時,Opus 4.5 能精準定位並修復。幾周前對於Sonnet 4.5來說還近乎不可能的任務,現在已觸手可及。總而言之,測試者的評價是:Opus 4.5是真的「行家」。 (新智元)