全球编码王座，一夜易主。
果不其然，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圈真正闭环了。
有一说一，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中，长对话不再会因为上下文限制而中断。
首先，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开发者平台的升级整合在一起时能实现什么。
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，随着未来更强模型的推出，限制预计会按需更新。
随着模型变得更聪明，它们能以更少的步骤解决问题：更少的回溯，更少的冗余探索，更少的啰嗦推理。
在达到类似或更好结果时，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是真的「行家」。
