突发！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 在管理子智能体团队方面也非常高效，能够构建复杂、协调良好的多智能体系统。

测试显示，结合所有这些技术，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%。