← 文章 / 行业与公司动态
Hacker News 55分钟前 · 2026-09-23 15:16:34 · 0 阅读

Anthropic 发布 Claude Opus 5.5:性能媲美前旗舰,成本降低 40%

我们推出 Claude Opus 5.5,这是全新 Claude 5.5 系列中的第一款模型。在大多数任务上,其性能媲美 Claude Fable 5.1,而运行成本比 Opus 5 降低 40%。

Claude Opus 5.5 是我们在倡导“ pacing the frontier” 理念后的首次发布。发布前,它已接受外部评估机构的测试,包括 Frontier DesignMETR。在我们最为全面的对齐测试——自动化行为审计中,Opus 5.5 是目前表现最强的模型。同时,它也配备了我们针对最强大模型开发的安全保障措施。

以下是 Opus 5.5 的一些主要改进:

性能。 Opus 5.5 较 Opus 5 有了显著飞跃,成为新的领先模型。早期测试者在最复杂的任务中看到了巨大的性能提升。一位测试者在一天内完成了 68 万行代码的迁移——这项工程团队通常需要数周才能完成的工作。它在发现并修复软件低效方面表现优异:当我们要求它缩短 Web 应用中所有页面的加载时间时,Opus 5.5 在 40 次尝试中成功 39 次,而 Opus 5 虽有所改进,但也改变了应用的行为。另一位测试者让多个 Claude 模型仅凭一条提示构建游戏;在画面质量和完成度方面,Opus 5.5 的评分高于其他所有模型。

安全性。 在我们的自动化行为审计中,Opus 5.5 创下了目前所有模型的最佳得分。该测试套件通过对数千个模拟场景的检验来评估 Claude 的对齐程度。与近期模型相比,它更不容易采取难以逆转的行动,也不容易超出既定边界行事;同时,它比 Opus 5 更具抗提示注入能力。我们还扩展了对齐测试范围,涵盖更长任务、不可能完成的任务以及基于真实事件建模的场景,尽管仍存在局限。评估的完整细节见 Opus 5.5 系统卡片

由于 Opus 5.5 在生物和网络安全领域的能力与 Claude Mythos 5.1 相当,我们对其部署了与 Claude Fable 5.1 类似的 safeguards。经过审核的组织现在即可申请加入我们的生命科学验证计划,从而使用 Opus 5.5 进行生物学研究。未来几周,我们还将扩大对网络安全验证计划的访问权限,经过认证的网络安全从业者将能够使用 Opus 5.5 开展工作。

成本与速度。 Opus 5.5 的运行算力需求低于 Opus 5,定价也随之下调。我们的测试显示,在默认设置下,处理典型任务时 Opus 5.5 的成本比 Opus 5 低 40%。每百万输入和输出 token 的价格分别为 4 美元和 20 美元,比 Opus 5 低 20%。缓存读取(通常占 agent 和编码任务成本的大头)每百万 token 仅 0.20 美元,比 Opus 5 低 60%。此外,Opus 5.5 的生成速度比 Opus 5 快 30% 以上。

除了降价,我们还提高了 Pro、Max、Team 和基于席位的 Enterprise 计划中五小时使用限额。同时,我们为订阅用户提供了速率限制重置功能,你可以随时保存并在需要时使用。

沟通。 Opus 5.5 比之前的模型更擅长自然交流。早期测试者发现其写作更清晰、更易懂,回应了我们对 Opus 5 收到的一些常见反馈。它将最重要的信息前置,其风格使其在长会话中成为更好的工作伙伴。正如一位早期测试者所说:“它的写法和我一样。”在我们自己的使用中,这使得 Opus 5.5 的工作成果更易于跟踪和检查——这既是安全收益,也是实用优势。

未来几周,Claude Sonnet 5.5 和 Claude Haiku 5.5 也将陆续发布,带来许多性能、效率和安全方面的改进。

性能与成本效益

在我们的基准测试中,Claude Opus 5.5 在 agent 编码、计算机操作和知识工作上名列前茅。不过,在这个能力层级,我们发现基准测试的差距已不太能准确反映实际差异。在内部使用中,Opus 5.5 与 Claude Fable 5.1 的差距比分数显示的更小。

Opus 5.5Fable 5.1 Opus 5GPT-6 AstraGPT-5.6 Sol
智能体编程 Terminal-Bench 4.0¹
智能体编程 Terminal-Bench 4.0¹66.4%55.8%52.3%57.9%37.3%
智能体编程 FrontierCode v1.1 (Main)
智能体编程 FrontierCode v1.1 (Main)54.4%50.3%48.0%53.3%47.5%
智能体编程 CursorBench 4.0
智能体编程 CursorBench 4.057.8%51.8%46.6%41.7%
知识型工作 GDPval-AA v2.1
知识型工作 GDPval-AA v2.118461735170815421588
业务流程自动化 AutomationBench²
业务流程自动化 AutomationBench²40.0%31.4%26.9%41.4%28.8%
多学科推理 Humanity's Last Exam
多学科推理 Humanity's Last Exam67.7%(使用工具)65.6%(使用工具)63.6%(使用工具)57.2%(使用工具)
智能体科学研究 Terminal-Bench-Science 0.1³
智能体科学研究 Terminal-Bench-Science 0.1³58.7%52.6%29.0%64.6%22.4%
计算机操作 OSWorld 2.0
计算机操作 OSWorld 2.081.8%(部分)80.7%(部分)74.0%(部分)
图表视觉识别 Chartography
图表视觉识别 Chartography89.0%(使用工具)88.4%(使用工具)83.4%(使用工具)

除非另有说明,所有 Claude Opus 5.5 的成绩均采用最大努力档的自适应思考模式。Terminal-Bench 4.0 的成绩中,Claude Opus 5.5 为 xhigh 努力档,GPT-6 Astra 为 high 努力档(数据来自 OpenAI 报告),均为各模型的最高分。Claude Opus 5.5 在开启生产环境安全防护的情况下进行评测。当安全防护介入时,网络安全任务由 Claude Opus 4.8 完成,生物学和前沿 LLM 研发任务由 Claude Opus 5 完成。这可能会拉低 Claude Opus 5.5 在这些基准上的表现。

1 Terminal-Bench 4.0:Claude Opus 5.5 的标准误差为 ±2.6 分,其他 Claude 模型为 ±1.6–2 分。公开排行榜(每项任务 5 次试用,Claude Code 测试环境)报告 Claude Opus 5 得分为 51.8%;我们的设置复现得分为 52.3%,在噪声范围内。GPT-6 Astra 和 GPT-5.6 Sol 的数据来自 OpenAI 的官方报告。

2 AutomationBench:AutomationBench 的测试由 Zapier 运行并报告。这些测试未使用后备模型,因此安全干预被视为失败——这导致得分低于 Claude Opus 5.5 在实际应用中能达到的水平。Claude Opus 5.5 的结果来自 Zapier 在早期访问期间的自行评估。Opus 5、GPT-5.6 Sol 和 GPT-6 Astra 的结果来自 Zapier 的公开排行榜。

3 Terminal-Bench-Science 0.1:每个模型的标准误差为 ±3.5–5 分。公开排行榜(每项任务 3 次试用,Claude Code 测试环境)报告 Claude Opus 5 得分为 30.0%;我们的设置复现得分为 29.0%,在噪声范围内。GPT-6 Astra 的数据来自 OpenAI 的官方报告。

Opus 5.5 的优势在效率上表现得尤为明显。相比 Opus 5,它的单 Token 成本更低,且每项任务消耗的 Token 更少,综合下来成本降低了 40%。

定价

每百万 Token 价格Claude Opus 5.5Claude Opus 5
缓存读取$0.20$0.50
输入 Token$4$5
输出 Token$20$25
缓存写入$5$6.25

Opus 5.5 的快速模式也在 Claude Code 和 Claude 平台上可用,速度最高可达 2.5 倍。每百万输入 Token 收费 $8,每百万输出 Token 收费 $40。

编程

Opus 5.5 擅长处理如代码库范围的迁移和审计等长且复杂的任务。一位早期测试者用它审计并修复了一个包含 20 万行代码的代码库,耗时不到 3 小时;而 Opus 5 花费了超过 20 小时,且 Token 消耗是前者的 2.5 倍。在一项内部测试中,我们要求 Opus 5.5 和 Fable 5.1 将 HAProxy(一款广泛用于在服务器之间平衡 Web 流量负载的软件)从 C 语言翻译为 Rust。两者的重写都通过了 HAProxy 自身几乎所有的回归测试,但 Opus 5.5 耗时 9.5 小时,而 Fable 5.1 耗时 12 小时,且成本减少了 51%。

Opus 5.5 在 Agentic coding 领域达到了前沿水准,且成本极低。在 FrontierCode 基准测试中,以默认 effort 水平运行时,其表现优于 GPT-6 Astra,而每个任务的成本仅为后者的约 20%。在 Terminal Bench 4.0 上,它匹配 Astra 的表现,成本约为其 40%;而在 CursorBench 上,它以约三分之一的成本,比 GPT-5.6 Sol 高出 11 分。

Agentic terminal codingAgentic coding: FrontierCodeAgentic coding: CursorBenchAgentic terminal codingAgentic coding: FrontierCodeAgentic coding: CursorBench
Terminal-Bench 4.0准确率 vs 成本
  • Opus 5.5
  • Fable 5.1
  • Opus 5
  • GPT-6 Astra
  • GPT-5.6 Sol

Terminal-Bench 4.0 评估模型在命令行界面中完成复杂多步骤专业任务的能力。Opus 5.5 在默认 effort 下的表现,超过了 Opus 5 在最大 effort 下的表现,而成本仅为后者的五分之一。它匹配 GPT-6 Astra 的表现,成本约为其 40%。

FrontierCode v1.1, 主集准确率 vs 成本
  • Opus 5.5
  • Fable 5.1
  • Opus 5
  • GPT-6 Astra
  • GPT-5.6 Sol

FrontierCode 衡量 Agent 的代码变更是否会被合并。在默认 effort(中等)设置下,Opus 5.5 得分为 54.6%,高于所有其他模型,以每个任务约五分之一的成本,超越了 GPT-6 Astra 的最高分(53.3%)。

CursorBench 4.0准确率 vs 成本
  • Opus 5.5
  • Fable 5.1
  • Opus 5
  • GPT-5.6 Sol

CursorBench 基于真实的 Cursor 会话中的模糊、多文件任务,评估编码 Agent。在默认 effort(中等)设置下,Opus 5.5 得分为 52.5%,而 Fable 5.1(最大 effort)为 51.8%,Opus 5(最大 effort)为 46.6%。它以每个任务约三分之一的成本,比 GPT-5.6 Sol 的最高分(41.7%)高出 11 分。



我们的早期测试者也报告了类似的效率和智能提升:

GitHub、Clio、Lovable、Quantium、Spotify、Optiver、Column、Kiro

“开发者需要的是能真正承担软件工作并把它做完的智能体。在 GitHub Copilot CLI 和 VS Code 的测试中,Claude Opus 5.5 的 token 消耗和步骤数在我们测过的模型里都是最少的之一。在 VS Code 上,它用不到 Opus 5 一半的步骤解决了更多的终端任务。它不只是让单个任务更高效,更让开发者的大项目变得可以完成了。”

公司:GitHub 作者:Mario Rodriguez,首席产品官

“我把一个横跨我们六个代码仓库的大型工程任务交给 Claude Opus 5.5,让它无人值守地跑了一整夜。它持续工作了超过 18 个小时,先定义了我们的服务之间如何通信,再逐一实现各服务的对接。和 Opus 5 相比,它更快达成各阶段目标,返工极少。代码注释简短实用,而不是冗长啰嗦。我几乎挑不出任何毛病。”

公司:Clio 作者:Sean Heintz,资深软件开发工程师

“对 Lovable 的用户来说,Opus 5.5 意味着在保持同等质量的前提下更快完成构建,无论你是从零开始还是在开发一个已上线的应用。它一次性收集上下文,编辑次数更少且更完整,不会陷入反复重试,完成任务的步骤减少了三分之一到一半,token 消耗也显著降低。”

公司:Lovable 作者:Fabian Hedin,CTO 兼联合创始人

“我们在 Chat、Cowork 和 Claude Code 上全面测试了 Claude Opus 5.5,覆盖了团队所有的工作方式。一个过去需要 38 次提示、耗时四天的复杂编码任务,现在只用 11 次提示、三个小时就完成了,产出更接近可上线状态,返工也更少。对于需要快速解决复杂问题的团队来说,这意味着花在迭代上的时间更少,花在推敲上的时间更多:验证假设、压力测试产出,为客户提供最优方案。”

公司:Quantium 作者:Harley Barnes,AI 技术执行经理

“在我们的内部评估中,Claude Opus 5.5 的 token 效率有明显提升——同样的任务,我们花得更少、跑得更快。”

Spotify Aleksandar Mitic,高级工程师 评价

“我们使用真实的工程交易任务来测试模型。在我们的智能体编码任务中,Claude Opus 5.5 仅用约一半的轮次、时间和输出 Token 数,就达到了 Opus 5 的质量水平,将该工作负载的成本降低了 40 到 50%。它在某个交易台的交易支持套件上取得了我们记录的最高分,通过了一些此前 Claude 模型未能完成的任务,并在我们的分析任务中领先于所有八个模型。”

Optiver Noyan Tokgozoglu,全球 AI 工程负责人 评价

“Claude Opus 5.5 在委派子智能体方面更高效,并以极具创意的方式自我校验。自我验证循环更易于搭建。它在我们云端账单中发现了此前模型遗漏的节省空间;在代码审查中,它通过查阅第三方集成的外部文档,捕捉到了一个在几个提交前就被我们错误建模的 Bug。”

Column Mitch Fierro,工程团队 评价

智能体的每一次调用,都是开发者感受到的时间和成本。在一项基于真实命令行任务的公开基准测试中,Claude Opus 5.5 在调用次数减少约 40%、Token 消耗减半的情况下,解决了比 Opus 5 更多的任务。对于使用 Kiro 开发的开发者而言,这意味着无论是常规任务还是复杂挑战,智能体会话都更快、更经济。Opus 5.5 即将登陆 Kiro。”

Kiro Deepak Singh,智能体 AI 副总裁

最安全的编码智能体

在系统内部使用智能体的企业需要确认这些智能体按预期运行,尤其是在它们自主运行数小时的情况下。Opus 5.5 具备一个分类器,能在每个动作运行前进行筛选;拥有供安全团队审计的开源沙箱;以及能在合并前捕捉漏洞的代码审查功能。

该模型本身也具有更强的防御能力。在提示注入攻击方面,我们在所有测试场景(包括编码、工具使用、计算机使用和网页浏览)中,发现 Opus 5.5 的表现持平或优于 Opus 5。在 AI 安全公司 Gray Swan 进行的基准测试中,Opus 5.5 与 Fable 5.1 并列,拥有所有受测模型中最低的提示注入成功率。

知识工作

Opus 5.5 是一款可靠且熟练的研究助手。在一项内部测试中,我们让 Opus 5.5、Fable 5.1 和 Opus 5 仅基于网上难以找到的财报发布内容,撰写一份关于某公司季度业绩的报告。自动评分器将每项数据和引语与来源进行了核对。在不同努力程度设置下,Opus 5.5 提交的 18 份报告中有 16 份达到了我们的质量标准,该标准要求任何捏造的数据或引语都会导致不及格。而 Fable 5.1 和 Opus 5 在所有尝试中均未达到这一标准。

它在财务分析和商务工作中也表现出色。投资机构 Walleye Capital 作为早期测试方反馈称,Opus 5.5 在最低设置下基本解决了他们的评估套件;在较高设置下表现更佳,甚至发现了评估指令中的错误并进行了修正。此前没有其他模型能发现这一错误。

在另一项测试中,我们让 Opus 5.5 和 Opus 5 分析两家虚构的人力资源公司之间的拟议合并案。两者均在 Excel 中构建了财务模型,并将其转化为一份关于该交易价格是否合理的行政演示文稿。两个模型得出了相同的结论,但 Opus 5.5 的模型更为详尽,演示文稿也更容易阅读,而 Opus 5 的模型存在细微错误。Opus 5.5 用时 63 分钟完成,而 Opus 5 需 93 分钟,且 Opus 5.5 的生成成本降低了 50%。

在知识工作评估中,Opus 5.5 的性能优于其他模型,同时使用的 token 数量更少。在涵盖 44 种职业的真实工作测试 GDPval-AA v2.1 中,Opus 5.5 的 Elo 分数为 1846,领先于 Fable 5.1 和 Opus 5。在默认努力程度(中等)下,Opus 5.5 以大约 GPT-6 Astra 最大努力程度五分之一的单任务成本,胜过对方。它在衡量业务流程和大规模数据收集的基准测试中也表现优于其他模型。

GDPval-AA v2.1AutomationBenchWANDRGDPval-AA v2.1AutomationBenchWANDR
GDPval-AA v2.1 Elo 分数 vs 成本
  • Opus 5.5
  • Fable 5.1
  • Opus 5
  • GPT-6 Astra
  • GPT-5.6 Sol

Artificial Analysis 的 GDPval-AA v2.1 基准在 44 种职业的真实专业工作上评估智能体。在 max effort 档位下,Opus 5.5 取得 1846 Elo,Fable 5.1 为 1735,Opus 5 为 1708。而在默认 effort(medium)下,Opus 5.5 就能击败 max effort 的 GPT-6 Astra,且每个任务的成本只有其约五分之一。

AutomationBench 准确率与成本
  • Opus 5.5
  • Opus 5
  • GPT-6 Astra
  • GPT-5.6 Sol

Zapier 打造的 AutomationBench 测试智能体能否在多个互联应用之间完成真实的业务工作流。在所有 effort 档位下,Opus 5.5 的得分都高于 Opus 5 和 GPT-5.6 Sol。

WANDR 准确率与成本
  • Opus 5.5
  • Fable 5.1
  • Opus 5

Perplexity 的 WANDR 基准衡量智能体在大规模数据采集任务上的表现。Opus 5.5 的表现优于 Fable 5.1 和 Opus 5,且每个任务成本更低4

4WANDR:Claude 模型运行时使用了离线版的 web search 和 web fetch 工具、programmatic tool calling、代码执行,以及 980k token 的任务预算。这与 Perplexity 公布的设置不同,两者分数不可直接比较,我们只展示在相同条件下评测的模型。



客户的实际使用反馈也印证了这些结果。以下是他们与这款模型合作的体验:

Deloitte Consulting LLPRogoLexisNexis Legal & ProfessionalWalleye CapitalHexThomson Reuters LabsHebbiaViktorDeloitte Consulting LLPRogoLexisNexis Legal & ProfessionalWalleye CapitalHexThomson Reuters LabsHebbiaViktorQuote

“即便在最低 effort 档位,Claude Opus 5.5 在我们的代码审查中也能发现 72% 的已知 bug,而高 effort 的 Opus 5 只有 56%,同时误报更少、输出量更小。在美国咨询分析任务上,低 thinking effort 的表现与其更高档位持平,而输出量只有一半,并通过了我们的质量检查。当更多低 thinking effort 档位投入生产时,意味着以更高效率交付达到客户标准的成果。”

公司:德勤咨询公司 作者:Carl Bennett,首席信息官 引述:

“金融机构需要的输出必须始终正确。在我们的 BigFinance Bench 基准测试中,Claude Opus 5.5 在最低投入设置下击败 Opus 5 的高投入设置,且输出 Token 数量减少约 60%。其答案更简洁、结构更好,生成的幻灯片也更密集,更符合行业标准。”

公司:Rogo 作者:Strib Walker,产品负责人 引述:

“评估新模型是 LexisNexis 法律智能引擎多模型方法的核心。在初步评估中,Claude Opus 5.5 持续识别出高度相关的引文,表现出在法律条文方面的优势,并围绕核心法律框架和关键问题组织其答案。正是这些能力,帮助我们客户通过 Lexis+ with Protégé 实现更多目标。”

公司:LexisNexis 法律与专业服务 作者:Min Chen,首席 AI 官 引述:

“在量化研究中,一个错误的假设可能会颠覆结果。在最低投入设置下,Claude Opus 5.5 基本解决了我们的评估任务。在更高设置下,它更进一步:它检测到我们指令中的分钟级索引存在偏差,并进行了修正,同时指出这会导致评分时扣分。它是正确的,我们测试过的任何模型之前都没有发现并处理过这一问题。”

公司:Walleye Capital 作者:Frank Corrao,中央股票量化研究工程负责人 引述:

“随着模型在数据处理方面变得更加熟练,我们看到越来越多听起来令人信服但缺乏数据支持的结论。Claude Opus 5.5 坚持挖掘第一个看似合理答案之外的信息。我们 DataBench 基准测试中的一个任务询问包裹是迟到了还是只是跟踪缓慢。Opus 5 检查了送达确认,认为跟踪正常。Opus 5.5 发现包裹确实迟到了,且跟踪也存在问题。我们正在将其引入 Hex agent 用于此类工作。”

CompanyHex AuthorIzzy Miller, AI Engineer Quote

“CoCounsel 结合多个模型与我们自身的内容和专业知识来处理复杂的法律工作。在使用 Claude Opus 5.5 后,我们在专家评审和内部基准测试中均看到了更好的表现,同时在速度和 token 效率上也取得了提升。我们期待客户能在使用 CoCounsel 作为“思维碰撞伙伴”、权衡证据并梳理思路的过程中,亲身感受到这种差异——这些细微之处往往是基准测试无法完全捕捉到的。”

CompanyThomson Reuters Labs AuthorOmar Bari, VP Applied Research Quote

“在依据专家标准对端到端金融工作流进行评分时,Claude Opus 5.5 覆盖了我们关注点的 86.6%,而 Opus 5 仅为 60.3%。在检索评估中,它实现了有史以来最佳的引用召回率,且 token 效率优于 Opus 5,这有助于我们控制每次研究任务的成本。”

CompanyHebbia AuthorAabhas Sharma, CTO Quote

“Viktor 是一名驻留在 Slack 和 Microsoft Teams 中的 AI 员工,因此它的每一步操作都会体现在我们的成本中。在做同样工作量时,Claude Opus 5.5 完成每项任务所需的步骤和工具调用次数都比 Opus 5 更少,成本几乎减半,但解决我们最难题目的正确率却是前者的两倍。”

CompanyViktor AuthorPeter Albert, Co-Founder

沟通

我们大幅提升了 Opus 5.5 的写作和沟通方式,这也是用户关于 Opus 5 最常见的反馈领域之一。其输出信息现在更易于快速理解,测试人员表示这在长时间工作场景中很有帮助。它会优先展示最关键的信息,更少使用专业术语或独特短语,并严格遵循用户提供的写作规则。我们发现,这使得 Opus 5.5 成为了一个明显更出色的协作伙伴。以下是两个模型的并排对比:

解释 bug 总结线程 解释设计变更 Opus 5 Opus 5.5
Claude Opus 5

请向我解释这个问题。

我的发现

多出来的那个点不是免费版的问题,而是 0552feb 引入的一个回归缺陷(该提交为“将计费周期边界提取到 periods.py”,标签为“无行为变更”)。

该 bug

aggregate.monthly_usage 之前使用半开区间:

start, end = month_start(year, month), next_month_start(year, month)
if start <= e.ts < end:

现在它执行的是:

if period.contains(e.ts)

以及 periods.py 中:

@property
def last_day(self) -> datetime:
    return next_month_start(...) - timedelta(days=1)   # 2026-08-31 00:00:00 UTC

def contains(self, ts):
    return self.first_day <= ts <= self.last_day

last_day 是一个零点时刻的 datetime,并不代表一整天。从 9 月 1 日 00:00 减去一天,得到的是 8 月 31 日 00:00,而比较又是闭区间,所以这个周期实际上在 31 日的第一个瞬间就结束了。凡是时间戳在月末最后一天零点之后的事件,都被静默丢弃了——相当于每个账户每月损失约一天的用量数据。

新的 test_periods.py 没能发现这个问题,因为它只检查了 last_day.date()(这个值确实是 2026-08-31,没问题),而测试 contains 时用的是 8 月 1 日 00:00、8 月 15 日 12:00、7 月 31 日 23:59 和 9 月 1 日 00:00——从没在 31 日当天内部取过点。

Claude Opus 5.5

请给我解释一下这个问题。

多扣的部分是账单重构引入的 bug

免费层调整只能解释 acme 八月减少的 $1.50,剩下的 $9.92 来自 commit 0552feb 中的一个 bug。这个 commit 的说明写着“不改变行为”,但实际上它让系统停止统计每月最后一天的用量。

改动在哪

合并之前,aggregate.py 用的是左闭右开区间:

start <= e.ts < next_month_start(year, month)    # [8月1日 00:00, 9月1日 00:00)

重构后这段逻辑被挪到了 Period.contains 里,而且把区间错改成了在错误的边界上闭合:

last_day = next_month_start(...) - timedelta(days=1)    # = 2026-08-31T00:00:00Z
return self.first_day <= ts <= self.last_day

last_day 是零点的那个时刻,不是一整天。因此 2026-08-31T00:00:00Z 之后的所有事件都被排除在外。而 9 月的周期从 9 月 1 日才开始,也不会接住这些事件。这些用量没有被算到别的月份,而是彻底没被计费。

Claude Opus 5

请为我的经理总结这段 Slack 对话,生成三点: [09:41] Dana Osei:我会告知他们。我也会确认其他人不读取周五的文件。 [09:43] Marcus Webb:我可以调整时间表,只需更改一行 cron 设置。但要等 Dana 确认后再操作。 [10:02] Dana Osei:财务说周五的文件仅用于周一。周日晚间没问题。

周五订单导出 — #data-platform,周二

  • 问题:周五订单导出再次超时(本月第二次故障),该查询在数据仓库运行 2 小时后失败;夏季促销后订单量增长约 40%。财务周一早 9 点的评审错过了周末数据,且这两次故障直到周一才被发现。
  • 同日修复:周六运营仪表盘的组件改为读取实时表而非导出数据(Sam 负责),财务确认周五文件仅用于周一(Dana 确认),故障告警现在会呼叫值班频道(Priya 负责),导出任务从下周一开始改到周日晚 10 点,周五的任务被取消(Marcus)。还升级了一次约 300 美元的数据仓库配置作为临时方案,以覆盖本周五。
  • 进行中:Ji-woo 负责重写查询,改为增量执行(重新扫描最近 3 天的数据以捕捉晚到的订单),预计可将运行时间从小时级缩短到分钟级——设计文档周四发布,包含测试在内的总耗时约两周。在此期间,时间表调整可争取时间。
Claude Opus 5.5

请为我的经理总结这段 Slack 对话,生成三点: [09:41] Dana Osei:我会告知他们。我也会确认其他人不读取周五的文件。 [09:43] Marcus Webb:我可以调整时间表,只需更改一行 cron 设置。但要等 Dana 确认后再操作。 [10:02] Dana Osei:财务说周五的文件仅用于周一。周日晚间没问题。

  • 问题:本月周五订单导出已两次失败。数据仓库查询在运行 2 小时后超时,原因是夏季促销后订单量增长约 40%。因此,财务周一早 9 点的评审缺少周末数据。
  • 即时修复:下周起,导出任务改至周日晚上 10 点,周五的运行将被取消(Marcus)。财务已确认此方案可行(Dana)。依赖周五文件的运维仪表盘组件现改为从实时表读取(Sam,已完成)。新增的故障告警现已推送至值班频道(Priya,已完成并测试通过)。仅针对本周五,Marcus 将临时增加仓库配额作为一次性应急措施(约 300 美元),已获 Dana 批准。
  • 长期方案:Ji-woo 将重构查询逻辑,仅处理新订单,并回溯扫描过去 3 天数据以捕获迟到的记录。这将把运行时间从数小时缩短至分钟级。包括测试在内,预计耗时约 2 周,设计文档需在周四前提交评审。
Claude Opus 5

编写 Python 代码,读取国际象棋局面(FEN 格式),列出正被攻击的棋子。请使用 TensorFlow 加速。以下是我的设计思路:构建 8x8 的张量棋盘,根据各棋子的移动模式生成攻击范围图,并标记位于被攻击格点的敌方棋子。请修改你认为有问题的部分,并在最终总结中说明每处改动及其原因。

tf.math.cumsum 替代了位扫描。几何结构被展开为 ray_targets[square, direction, step],即沿射线向外有序遍历。在 step 轴上执行独占累积求和(exclusive cumsum),统计每个 step 严格之前的阻挡数;因此,射线上第一个阻挡点即是那个“阻挡数为 1 且之前阻挡数为 0”的 step。这正是位盘引擎使用的位扫描的向量化形式。我也检查过 bitwise_ops 以实现真正的 64 位位盘——虽然 population_count 存在,但处理双线性曲线(hyperbola-quintessence)需要字节翻转原语,而 TensorFlow 未提供该功能,因此最终仍会退回到按方向循环处理。

Claude Opus 5.5

编写 Python 代码,读取国际象棋局面(FEN 格式),列出正被攻击的棋子。请使用 TensorFlow 加速。以下是我的设计思路:构建 8x8 的张量棋盘,根据各棋子的移动模式生成攻击范围图,并标记位于被攻击格点的敌方棋子。请修改你认为有问题的部分,并在最终总结中说明每处改动及其原因。

被阻挡的线路(象、车、后)。固定的掩码无法表达“停在被挡住的第一枚棋子”。我增加了一层掩码,标记同一行上任意两格之间的所有格子。用棋盘占用情况做一次矩阵乘法,就能一次性统计出每条线路上的阻挡棋子数,计数为零时攻击才成立。马和单步移动之间没有中间格子,所以这一条规则覆盖了所有棋子。

Opus 5Opus 5.5


客户的反馈印证了这些结论:

RampStripeBoxChicago Trading CompanyFactoryRampStripeBoxChicago Trading CompanyFactoryQuote

“前沿模型输出的啰嗦、难读一直是我最大的痛点,Claude Opus 5.5 解决了这个问题。它写得像一位好同事,还遵守我们的写作规范。它生成的设计文档几乎不用改就能直接用,重写我们的一条 prompt 后,我更喜欢它的版本。它优化我们的测试套件时,推理过程清晰易懂,我可以放心地把改动上线。”

CompanyRampAuthorJohn Ruelas,Staff Software EngineerQuote

“我每天都在进行长时间的 Claude Code 会话。一次为期多天、涉及 40 个堆叠 pull request 的 rebase 中,一场 Claude Opus 5.5 会话指挥了另外十几个会话,并把每个冲突都清清楚楚地列了出来。在它接手的通话里,它的表述非常清晰,即使隔了几个小时我也能几分钟内给出答复。第二天下午,全部 40 个都通过了 CI。相比 Opus 5 是一次重大升级。”

CompanyStripeAuthorCristian Rivera,Staff Software EngineerQuote

“我们的客户在 Box AI 上处理海量内容,速度和成本是头等大事。在我们的评测中,Claude Opus 5.5 的 token 消耗只有 Opus 5 的三分之一,回答精简了 40%,准确率却没有下降。对于在金融服务、公共部门等领域用 agent 批量处理内容的团队来说,这一点意义重大。”

CompanyBoxAuthorYashodha Bhavnani,AI Products VPQuote

“一晚上时间,Claude Opus 5.5 自主处理了我们 Lakehouse 服务层的一个 bug,那是我一直没时间排查的问题。它自己调查、设计修复方案并完成实现。到早上,改动已经完成并通过了我们的测试套件。它的表达清晰易读,比 Opus 5 更连贯。我们的 pull request 和面向用户的文档几乎不需要再编辑。”

芝加哥交易公司 作者:奥斯顿·托梅克,首席工程师

“Claude Opus 5.5 是我们默认首选的中等算力模型。测试结果显示,在同等高算力需求下,其表现媲美 Opus 5,但输出 token 消耗减少了 20% 至 25%。在处理冗长且复杂的调查任务时,它总能给出清晰、可执行的答案。这意味着客户能以更低成本完成更多工作。”

Factory 公司 作者:李自木,技术人员

安全

前沿发展的节奏

上周,我们的首席执行官达里奥·阿莫迪(Dario Amodei)指出,AI 的进步需要保持适当节奏,以确保安全实践始终领先于模型能力。这种“节奏控制”是在保持对中国的竞争力、实现 AI 收益(尤其是在生物学和医学领域)的同时,确保 AI 安全的方法。

我们已充分理解当前模型带来的风险,并有能力进行管理。然而,随着能力提升,更严重的风险可能迅速出现,我们需要提前做好准备。因此,我们的安全工作同时关注两个时间维度:

针对当前模型的安全实践。 当前一代模型依赖一套成熟的标准流程:包括广泛的对齐测试、由 METR 和 Frontier Design 等外部机构进行的发布前评估,以及针对网络安全和生物学等高风险领域、与模型能力相匹配的安全保障措施。我们每次发布都会优化这些流程。我们相信,这些措施已能应对当前模型最坏情况下的风险,并为我们提供了一幅广泛(虽非完美)的严重风险图谱。

此外,我们持续监测训练和评估对齐模型的能力,并依据负责任扩展政策——这是我们管理先进 AI 系统灾难性风险的自愿框架——发布涵盖公开和内部模型的风险报告。

为未来模型做准备。 我们正提前调整训练和评估流程,以迎接更高级模型的到来。我们正在收紧强化学习环境的筛选标准,因为有缺陷的环境是导致模型行为失配的主要原因之一。此外,我们还在优化对齐奖励机制,并开发自动化流程来生成用于安全训练的新颖多样化场景。同时,我们正在加强安全与监控体系,其中包括一项旨在提升基于可解释性的监控与评估效果的专项工作。我们希望这些技术手段能减少对模型“思维链”(即模型在工作过程中写出的推理过程)进行人工审计的依赖。

能力更强的模型——例如那些能够完全自动化 AI 研究工作本身的模型——需要更高的安全标准。我们此前呼吁控制发展节奏,很大程度上是因为预计这类模型即将出现。对于这类模型,我们认为上述措施单独使用不足以达到所需的安全标准。随着 AI 能力不断增强,公共政策应发挥更大作用,以确保人们依赖的系统是安全的。这种能力的建设需要时间,我们已开始搭建相关基础设施以提供支撑,相关内容详见《我们必须控制前沿》以及我们与 Accenture 发布的最新公告;我们预计很快就会分享更多关于这些努力的细节。我们还将继续参与政府与行业的政策讨论,包括关于监管方式和国际协调的路径探讨。

对齐情况

在我们主要的评估套件中,这是一项自动化行为审计,涵盖了近 2000 个场景。在这项测试中,Opus 5.5 在几乎每一项衡量失配行为的指标上,表现均优于近期发布的其他 Claude 模型。在绝大多数诚实度指标上,它也是我们迄今表现最强的模型。

值得一提的是,近期导致多起网络安全事件的若干行为中,Opus 5.5 相比之前的模型都有明显改善,包括带有偏见或动机的推理、试图逃离沙箱、以及在判定自己处于模拟环境后采取有害行动。在一项专门测试模型突破隔离边界倾向的新评估中,Opus 5.5 尝试绕过边界的频率比 Opus 5 或 Claude Mythos 5.1 低了约 85%,且它仅有的几次尝试都属于低严重程度,并主动上报了。对于在代码库和系统上无人值守运行 Claude 的团队来说,这一点与模型能力本身同样重要。

不过,正如我们在最近的对齐评估报告中所说的,构建能在部署前可靠捕获所有失效行为的评估,至今仍是一个未解难题。我们观察到,Opus 5.5 经常怀疑自己正在被评估,这让我们难以判断它在实际部署中面对的各种真实场景下会有怎样的表现。随着部署场景不断扩展、模型能力持续提升,如果可解释性研究没有进展,这一挑战只会越来越大。尽管我们相信 Opus 5.5 在可测量的领域都有广泛改进,我们仍将自身的对齐工作与下述防护措施相结合。

防护措施

随着模型日益强大,更严格的防护措施是防止新能力被滥用的手段之一。Opus 5.5 是首个在网络安全、生物和蒸馏保护方面配备与 Fable 5.1 同级别防护措施的 Opus 模型,所有这些防护都会透明地回退到另一个模型。

网络安全。由于 Opus 5.5 拥有极强的网络攻击能力,我们为其配置了与 Fable 5.1 类似的网络安全防护。用户在常规软件开发流程中识别和修复代码 bug 不受影响,但大多数网络安全任务将被转由 Opus 4.8 处理。

面向网络安全防御场景,我们即将把 Opus 5.5 纳入网络安全验证项目。新方案设有三个权限层级,信任度越高、可访问的能力越强,其中包括使用 Claude Mythos 模型的权限。Claude Security 目前已上线,支持访问 Claude Mythos 5.1。

生物学。Opus 5.5 在生物学领域表现强劲,多项任务超过 Opus 5,并在许多方面达到或超越 Claude Mythos 5.1。例如,在与 Dyno Therapeutics 合作开展的一项长周期分子预测与设计评估中,Opus 5.5 取得了显著进展;专业红队评估员认为其科学新颖性与他们测试过的最强模型相当。

因此,Opus 5.5 沿用了与 Fable 5.1 相同的生物学安全限制。若用户因这些限制无法开展研究或开发工作,可申请加入全新的生命科学验证项目。经审查通过后,学术实验室、初创公司及制药企业等机构将可访问覆盖完整生物学研究场景的定制化安全策略。意向机构可在此提交申请

蒸馏

蒸馏攻击指攻击者利用数千个虚假账号,在工业级规模上提取模型能力,从而带来安全与国家安全层面的风险。通过蒸馏,恶意行为者能够构建出强大模型,却绕开我们在 Claude 中内置的安全防护机制。2026 年 9 月威胁情报报告 详细披露了我们迄今发现并处置的非法蒸馏活动。

Opus 5.5 发布时即搭载了我们在 Fable 5.1 中引入的“保留思考”防蒸馏保护机制。该机制可阻止 API 用户篡改 Claude 的上下文,从而防止他们借此提取 Claude 的推理过程。此机制适用于 2026 年 8 月 31 日及之后创建的 Fable 5.1 和 Opus 5.5 API 账户。我们的帮助中心文章详细解释了这一变更,而“保留思考”文档则演示了如何测试和更新现有集成。

数据保留与合规

与以往的 Opus 模型一样,Opus 5.5 支持零数据保留。

延续 Fable 5.1 的做法,Opus 5.5 同样配备了水印措施以符合《欧盟人工智能法》(EU AI Act)的要求,详见此处。此外,如本文所述,目前不再支持关闭“思考”模式。

可用性

Claude Opus 5.5 现已在所有平台上线,包括 Amazon Web Services、Google Cloud 和 Microsoft Azure。在 Claude Platform 上,开发者可以通过claude-opus-5-5快速上手

原始来源: Hacker News

评论 (0)