新智元报道

编辑：编辑部

深夜，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

秒追ASI

⭐点赞、转发、在看一键三连⭐

点亮星标，锁定新智元极速推送！