深度解析Anthropic新发布的Claude Opus 4.5：技术亮点与评测揭秘！

在美国当地时间11月24日，人工智能初创公司Anthropic在他们的官网上宣布了一项令人兴奋的消息：他们推出了最新的AI模型“Claude Opus 4.5”。

据说这个模型智能又高效，表现优异，特别是在编码、智能代理以及计算机应用方面，简直是当今最强的模型。它在深度研究、处理幻灯片和电子表格等常见任务上也明显超越了其它模型。

值得一提的是，Opus 4.5是Anthropic在短短两个月内发布的第三个重大版本。早在9月下旬，他们就推出了Sonnet 4.5，接着在10月又发布了Haiku 4.5。这也真是让人感叹AI行业发展的速度之快。

大家可能听说过，Anthropic最出名的就是他们的Claude系列AI模型，其中最大的被称为Opus，中等的叫Sonnet，最小的则是Haiku。之前的Opus模型是在今年8月发布的，名为Opus 4.1。

Scott White，Anthropic旗下Claude.ai的产品负责人，最近在采访中表示：“我们推出产品的速度以及得到的反馈让人感到兴奋。”

他还提到，Opus 4.5特别适合那些专业的软件开发者，以及金融分析师、顾问、会计师等知识工作者。同时，那些“想要激发创造力、创造新事物、扩展职业边界”的朋友也会发现这个模型非常实用。

在“代理式编程”方面，Opus 4.5达到了顶尖水平。根据衡量AI编程能力的SWE-bench测试集，Opus 4.5的表现超过了谷歌上周发布的Gemini 3 Pro和OpenAI的GPT-5.1。

Anthropic还透露，Opus 4.5曾参加过一项极具挑战性的闭卷测验，这种测验通常用于选拔优秀的软件工程师，而这个模型的得分超过了所有历史上的人类候选者。

根据新闻稿，Opus 4.5将会在所有平台上线，成为Anthropic的Pro、Max和Enterprise（企业版）产品的默认模型。除了推出新模型，Anthropic还发布了多项产品和功能的更新。

他们表示，Claude可以在不同的浏览器标签之间执行操作的扩展工具Claude for Chrome现已向所有Max用户开放；同时能够理解和编辑电子表格的Claude for Excel也已经向所有付费用户推出。

此外，Anthropic还将Claude Code引入到其桌面应用中，并为开发者平台增加了一些新功能。

同时，售价也大幅下降，单位输出的Token消耗也显著降低。

能否部分替代Sonnet 4.5呢？

我个人觉得，有两个技术创新的意义甚至超越了Opus 4.5本身，对Agent的影响非常重要：

• Tool Search Tool
• Programmatic Tool Calling

Tool Search Tool是一个管理工具的工具，而Programmatic Tool Calling则是一种全新的架构。根据我的测试，在一些复杂的案例中，token的消耗减少了将近千倍。

PTC实际上彻底改变了Agent执行的模式：

ReAct循环：

发出指令->执行->结果加入上下文，返回->发出指令->执行->结果加入上下文，返回…

在100轮执行中，需要发送100轮递增工具调用结果的上下文，缺少TODO列表的情况下，缺乏长程规划能力。

PTC循环：

写好脚本->执行->完成/失败才返回

即使在测试时我特意使用了Grok4.1 Fast这样的非旗舰模型，大部分20轮的中等任务也能一次性完成。

目前大多数Agent还是采用ReAct模式：

一步一步，观察结果，再进行下一步

虽然这种方式纠正能力很强，但消耗的费用实在太高，每返回一次结果都需要把完整的上下文一起发送回去，真是很贵。想想某些简单的小操作也要给LLM发送一次甚至几次完整的200k上下文，我真是感到无奈(︶︹︶)

后来有人提出了ReWOO和Plan and Execute等架构（其实差不多，大家天天造名词…），即提前写好计划，先做什么再做什么，然后让程序执行，不需要每次都发回LLM。我也尝试过这个架构，效果确实不错，对钱包也比较友好，但在实际生产中并不总是那么简单，列个清单就能让程序按顺序执行的情况并不多见，所以ReWOO这类的想法也逐渐消失了。

后来，有人意识到这个问题，提出了LLMCompiler，通过有向无环图（DAG）来进行规划，然后再执行。几乎90%的任务都可以用DAG进行编排，虽然实现起来稍微复杂了一点，需要DAG编译器，还要用prompt教LLM写DAG并进行串并行混合执行。

不过，我个人觉得LLMCompiler有些奇怪，为什么不直接用现成的CPython呢？它是图灵完备的，控制流没有上限，而用LLM编写Python比用一套DSL写DAG强太多了。

11月4日，Anthropic发布了一篇名为Code Execution with MCP的博客，我按照文章中的描述实现了Scripting Tool Calling架构（当时A社还没有命名，我自己随便起了个名字），实际效果超乎我的预期，甚至我觉得A社可能低估了这个架构的潜力。如果使用足够强大的LLM，甚至能一次性写好流程脚本，程序能够一次性完成许多任务！有几个60多轮的案例竟然被一次性搞定，省下了1000倍的token！（没错，1000倍）

今年，各大公司在Coding和Agent领域竞争激烈，模型的长程规划与编码能力确实在快速提升，像Scripting Tool Calling这样的架构，过去只能是构想，现在已经有工程实现的可能，省时省钱，具备图灵完备的控制流。

因此，当A社正式推出Programmatic Tool Calling（居然跟我之前胡乱起的名字差不多）时，我第一时间就去试了一下，功能已经非常完善，希望能尽快集成到Claude Code中。

至于Tool Search Tool，因为没有开源，我自己做了个Toolset试了一下，token的消耗确实显著降低。此外，我觉得这个工具还有很多潜力，比如自己编写工具，使用时再发现，左脚踩右脚，提升效率。

总之，A社现在确实在深入研究Agent这项技术，要是能把Claude Code开源就好了。