共计 2691 个字符，预计需要花费 7 分钟才能阅读完成。
在当地时间 11 月 24 日，美国的人工智能初创公司 Anthropic 在其官方网站上发布了最新的 AI 模型“Claude Opus 4.5”。
据该公司介绍，这一模型在智能性和效率上都表现出色，称其为全球在编码、智能代理及计算机应用领域表现最卓越的模型。同时，它在深度学习、幻灯片处理和电子表格等日常工作任务上也大幅领先于同类模型。
值得注意的是，Opus 4.5 是 Anthropic 在短短两个月内推出的第三个重要模型版本。早在 9 月下旬，该公司就推出了 Sonnet 4.5，紧接着在 10 月发布了 Haiku 4.5。这一连续的发布反映了人工智能行业的迅速发展。
Claude 系列模型是 Anthropic 最知名的产品，其中最大的模型被称为 Opus，中等规模的命名为 Sonnet，而最小的则是 Haiku。之前的 Opus 版本为 Opus 4.1，于今年 8 月发布。
在接受媒体采访时，Anthropic 的产品负责人 Scott White 表示：“我们向市场推出产品的快速节奏及由此产生的反馈循环让我感到非常兴奋。”
White 还提到，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 呢？
我个人认为，有两个技术尝试的意义甚至超越了 4.5 Opus 本身，对 Agent 的影响极为重要：
- 工具搜索工具（Tool Search Tool）
- 程序化工具调用（Programmatic Tool Calling）
工具搜索工具是一种管理工具的元工具，而程序化工具调用则是一种全新的架构。在我自己的测试中，一些复杂案例的 Token 消耗降低了近千倍。
程序化工具调用实际上彻底改变了 Agent 的执行范式：
ReAct 循环：
发出指令 -> 执行 -> 结果加入上下文，返回 -> 发出指令 -> 执行 -> 结果加入上下文，返回 …
在需要进行 100 轮执行的情况下，必须发送 100 轮递增的工具调用结果的上下文。如果没有待办事项列表，缺乏长程规划能力。
PTC 循环：
写好脚本 -> 执行 -> 完成 / 失败才返回
即使在测试中，我特意降级使用 Grok 4.1 Fast 这类非旗舰模型，大多数中等任务的 20 轮也可以一次完成。
目前各大 Agent 大多数依然采用 ReAct：
一步一步，查看结果，再做下一步
虽然这种方式的纠正能力强，但过于耗费资源，每次返回结果都需要将完整上下文一并发送，成本极高，60 轮的调用就意味着 60 轮递增的上下文。当想到某些简单操作也需要给 LLM 发送一轮甚至几轮完整的上下文时，实在让人感到困扰。
后来有些人提出了 ReWOO 和计划与执行（Plan and Execute）等架构（实际上相似，天天造名词 …），先制定计划表，按照顺序执行，而不必每次都返回 LLM。我也尝试过这种架构，效果确实不错，对用户友好，但在实际生产中并不适用，不是所有事情都能简单地通过列出清单让程序顺利执行，因此 ReWOO 等方案的声音逐渐减弱。
此后，有人意识到这一问题，提出了LLMCompiler，使用有向无环图（DAG）进行规划，然后程序执行。几乎 90% 的任务都可以通过 DAG 进行编排，尽管实现上复杂了一些，需要 DAG 编译器，并用提示教 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 中。
至于工具搜索工具，由于没有开源，我自己尝试了一个工具集，的确明显减少了 Token 的开销。此外，我觉得这个工具还有很多潜力，比如自定义工具、使用时再发现等，左脚踩右脚的提升。
总之，Anthropic 现在确实在深入研究 Agent 技术，如果能够将 Claude Code 开源就更好了。
