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

　　新智元报道

　　编辑：编辑部

　　【新智元导读】深夜，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.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，随着未来更强模型的推出，限制预计会按需更新。

　　开发者平台：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是真的「行家」。

　　参考资料：

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

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

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