Claude Opus 4.7 是什么？
Anthropic 的 Claude Opus 4.7 于 2026 年 4 月 16 日发布，有一个定位声明值得所有工程团队关注：这是 Anthropic 迄今为止发布的最高能力的通用可用（GA）模型，定位仅次于需要 Glasswing 合作伙伴资格才能访问的受限模型 Mythos Preview。
仔细想一下这句话。一款被 Anthropic 称为"最强 GA 版本"的模型，不是增量改进。这是 frontier 已经移动的信号。
定价印证了这一点。Opus 4.7 维持了 Opus 4.6 建立的价格体系：每百万 token 输入 $5 / 输出 $25。能力大幅提升，价格纹丝不动。如果你之前还在犹豫要不要上 Opus，现在成本收益比已经明显向部署侧倾斜了。
技术规格方面变化不大：100 万 token 上下文窗口、128K 最大输出、2026 年 1 月训练截止日期。但真正重要的变化不在这些 headline 规格里——而在四个行为维度上，这四个维度重塑了 Opus 4.7 处理真实工程工作的方式。
在深入这些细节之前，先看 benchmark 成绩单，这是所有分析的基础。
完整 Benchmark 成绩单
数据来自 Anthropic 官方公告，每个数字都经过验证。有些数字相当惊人。
编程基准
| 基准 | Opus 4.7 | Opus 4.6 | 变化 | 备注 |
|---|---|---|---|---|
| SWE-bench Verified | 87.6% | 80.8% | +6.8 | 最重要的编程基准 |
| SWE-bench Pro | 64.3% | 53.4% | +10.9 | 全链路 agent 环境 |
| Terminal-Bench 2.0 | 69.4% | 65.4% | +4.0 | GPT-5.4 以 75.1% 领先 |
Agent 工具使用基准
| 基准 | Opus 4.7 | Opus 4.6 | 变化 | 备注 |
|---|---|---|---|---|
| MCP-Atlas | 77.3% | 62.7% | +14.6 | 本次最大单次提升 |
| OSWorld-Verified | 78.0% | 72.7% | +5.3 | 计算机使用环境 |
| Finance Agent v1.1 | 64.4% | 60.7% | +3.7 | 专业领域 agent |
| HLE (w/ tools) | 54.7% | 53.1% | +1.6 | 增量提升 |
| BrowseComp | 79.3% | 83.7% | -4.4 | 退步 |
视觉基准
| 基准 | Opus 4.7 | Opus 4.6 | 变化 | 备注 |
|---|---|---|---|---|
| CharXiv-R (w/ tools) | 91.0% | 77.4% | +13.6 | 文档理解 |
| CharXiv-R (no tools) | 82.1% | 68.7% | +13.4 | 纯视觉推理 |
| XBOW Visual Acuity | 98.5% | 54.5% | +44.0 | 幅度最大的提升 |
推理基准
| 基准 | Opus 4.7 | Opus 4.6 | 变化 | 备注 |
|---|---|---|---|---|
| GPQA Diamond | 94.2% | 91.3% | +2.9 | 专家级推理 |
网络安全
| 基准 | Opus 4.7 | Opus 4.6 | 变化 | 备注 |
|---|---|---|---|---|
| CyberGym | 73.1% | 73.8% | -0.7 | 可忽略 |
Opus 4.7 的三个制胜数字
有三个数字应该在你们的规划讨论中占据核心位置：
SWE-bench Pro +10.9 分。 S WE-bench Pro 不是玩具版本。它让 Claude 运行在完整的 agent 环境中，模型必须规划、执行、使用工具、处理错误、验证多步软件工程任务的结果。在这个环境中提升 10.9 分，意味着 Opus 4.7 作为自主编程 agent 的能力大幅增强。如果你正在构建 Claude 驱动的开发工具，这个数字就是升级的理由。
MCP-Atlas +14.6 分。 这是本版本中最大的单次基准提升。MCP-Atlas 测试模型配合 Model Context Protocol 工具的能力——这是整个 Claude 生态使用的工具调用标准。从 62.7% 到 77.3%，意味着 Opus 4.7 处理基于工具的工作流比前身好得多。如果你的 Claude 集成使用了工具，MCP 性能直接影响你的系统表现。
XBOW Visual Acuity +44.0 分。 这不是笔误。XBOW 从 54.5% 跳到 98.5%，提升了 44 分。XBOW 用棋盘游戏和卡牌游戏的截图测试视觉敏锐度。这个跃升说明 Opus 4.7 处理视觉信息的方式发生了根本性变化。对于任何 Claude Code Computer Use 工作流、任何视觉文档理解流程、任何涉及截图、图表或视觉产物的流程，这都有直接影响。
Opus 4.7 退步的地方
有一个基准倒退了，值得给一个诚实的解释，而不是直接忽略。
BrowseComp 下降了 4.4 分，从 83.7% 到 79.3%。 BrowseComp 测试网络搜索和信息检索性能。下调是真实的。
为什么会这样？最合理的解释是：Opus 4.7 改进了指令遵循行为，不再那么倾向于通过缓存或猜测的信息走捷径。Opus 4.6 可能会从有限的上下文中外推一个看似合理的答案，而 Opus 4.7 更倾向于通过实际搜索进行验证。在那些奖励"自信的错误答案"的基准上， literal verification 看起来就像退步。
应对方法很简单：如果 BrowseComp 性能对你的具体应用很重要，在迁移前用实际用例测试 Opus 4.7。合成基准上的退步不一定会在你的生产环境中复现。许多真实世界的搜索工作负载会从改进的指令遵循行为中受益。
四个真正重要的变化
基准数字告诉你发生了什么变化。行为变化告诉你为什么。
自验证行为
Opus 4.7 最重要且最实际的变化，是 Anthropic 所描述的增强型自验证。模型现在实现了「计划 → 执行 → 验证 → 报告」的循环，这在 Opus 4.6 中不够稳定。
具体来说：Opus 4.7 生成代码时，更倾向于在呈现结果之前根据给定的需求检查代码；使用工具时，更倾向于验证工具输出后再传递给下一步；完成多步推理任务时，更倾向于对最终结论进行合理性检查。
这不是单次 prompt 中能看到的戏剧性行为变化。它出现在多步骤 agent 工作流中——Opus 4.6 有时会交接部分完成的工作或遗漏错误条件，Opus 4.7 更稳定地关闭了这些缺口。
对 Claude Code 用户来说，这意味着 Agent 产出看起来合理但遗漏关键需求的案例会减少。自验证循环不能消除所有错误，但能减少因交叉检查不足导致的错误类别。
Literal 指令遵循
Opus 4.7 比 Opus 4.6 更 literal 地接受指令。这听起来像是不言而喻的改进，但有一个微妙的含义：如果你给 Opus 4.6 的指令它做了超出字面含义的泛化，Opus 4.7 可能不会应用同样的泛化。
举个例子，如果 system prompt 说"总结要点"，Opus 4.6 有时会根据上下文预期你所说的"关键"是什么意思，Opus 4.7 更可能采用更 literal 的"要点"解释。模型的可预测性更强，但读心能力更弱。
这对于构建了复杂指令集的 prompt 工程师来说是一个重要考量。审查你的 system prompts，找出关于模型如何泛化指令的隐性假设。Literal 指令遵循奖励精确语言，惩罚投机取巧。
高分辨率视觉
Opus 4.7 的视觉系统得到了硬件级别的重大升级。最大分辨率从 1568 像素提升到 2576 像素，相当于在相同输入下多了约 3.3 倍像素。
实际意义不只是 Opus 4.7 能看到更大的图像。而是像素与坐标的映射现在是 1:1 的——输入中的一个像素直接映射到模型内部表示中的一个像素。这消除了高分辨率图像被压缩到之前限制时产生的混叠和信息损失。
对于 Claude Code Computer Use 工作流，这直接相关。现代高 DPI 显示器的截图在之前的模型中会丢失细节，现在可以全分辨率处理。对于涉及图表、图示或密集文本布局的文档理解任务，1:1 映射保留了之前在压缩中丢失的信息。
CharXiv-R 基准的提升（无论是否使用工具都是 13+ 分）证实了文档理解大幅改善。XBOW 的跃升证实了对于游戏状态和类似精细视觉解析任务，视觉敏锐度的改善更为显著。
xhigh 努力级别与任务预算
Opus 4.7 文档中出现了一个新概念：xhigh 努力级别，现在是 Claude Code 的默认设置。这在之前的高努力级别之上，还附带了 token 预算 advisory 系统。
实际含义：当给 Claude Code 一个任务时，模型现在对在这个任务上投入多少工作有一个明确的预算，并根据检测到的复杂度管理该预算。看起来简单的任务得到高效处理；看起来复杂的任务得到更彻底的调查。
Claude Code 的 Auto 模式随 Opus 4.7 一起推出，根据检测到的任务复杂度自动选择努力级别。Agent 系统正在朝这个方向演进：不只是执行指令，而是推理每个指令应该投入多少精力。
同样是新出现的 /ultrareview 命令，利用 xhigh 努力级别进行更彻底的代码审查。如果你正在使用 Claude Code 进行开发工作流，xhigh 默认值加上 /ultrareview 的组合意味着你的基础代码审查质量在没有任何配置更改的情况下就得到了提升。
Tokenizer 的坑：同样的价格，不同的账单
这个细节会让很多团队措手不及：Opus 4.7 使用了与 Opus 4.6 不同的 tokenizer，tokenization 比率已经改变。
每百万 token 的 headline 价格不变。但根据你处理的内容，实际的 token 消耗量会不同。以下是实际比率：
| 内容类型 | 相对 Opus 4.6 的 token 倍数 | 实际影响 |
|---|---|---|
| 英文 prose | ~1.05x | 小幅增加 |
| 代码 | ~1.10x | 对代码密集型工作流有显著影响 |
| CJK（中文、日文、韩文） | ~1.30x | 对多语言内容影响很大 |
| JSON / 结构化数据 | ~1.20x | 对 API 密集型应用很重要 |
对于典型的英文 prose 工作负载，增加约 5%。对于代码密集型开发工作，同样内容预计多消耗约 10% 的 token。如果你的应用处理大量 JSON 或结构化数据，计划增加 20%。
这对成本规划很重要。如果你基于 Opus 4.6 的 token 数量做预算，迁移到 Opus 4.7 后你的实际支出会增加。每 token 价格相同，但每单位内容的 token 数量增加了。
对于国内开发者的特殊提示：如果你在处理中文内容——无论是中文文档理解、中文代码注释、还是中文 prompt——CJK 的 1.30x 影响意味着你的成本增加会比英文用户更明显。在计算预算时要把这个系数考虑进去。另外，通过 AWS Bedrock 或 Google Vertex AI 调用 Opus 4.7 的开发者，也需要留意云厂商的定价可能另有附加条件。
这不是 bug。它反映了 Opus 4.7 的 tokenizer 在更广泛的语料库上训练，其中包含更多作为独立 token 的 CJK 字符。但会让以为 Claude 各版本 token 数量大致相当的团队感到意外。
破坏性 API 变更
Opus 4.7 引入了会破坏现有代码的 API 变更。以下是你需要知道的。
Temperature、top_p、top_k：400 错误
如果你在 Messages API 中传入 temperature、top_p 或 top_k 参数，现在会收到 400 错误。这些参数不再被接受。
替代方案是 Anthropic 尚未完全文档化的另一种采样机制。如果你的代码显式设置了 temperature，迁移到 Opus 4.7 之前需要删除这些参数。
这是一个激进的破坏性变更。大多数处理采样的代码库至少有一个设置 temperature 的地方。升级前审查你的所有 API 调用点。
Adaptive Thinking 取代手动预算
之前的 thinking budget 参数（max_tokens、thinking）已被弃用，取而代之的是 adaptive thinking。不再指定模型应该想多少，而是指定你希望模型思考什么，然后模型根据任务复杂度分配自己的思考资源。
这是从资源规范到意图规范的概念转变。你描述问题；模型决定投入多少精力去思考。
对于大多数用例，这会产生更好的配置和结果。对于需要可预测 thinking 行为的场景（例如，需要一致响应时间的延迟敏感型应用），你可能需要在 prompt 中添加显式的复杂度指标来引导模型的思考分配。
Thinking 默认隐藏
在 Opus 4.6 中，thinking block 在 API 响应中默认可见。在 Opus 4.7 中，thinking 默认隐藏。如果你想看模型的推理 trace，需要显式请求。
这是生产应用的正确默认设置——你不想向终端用户暴露内部推理。但这意味着任何依赖从响应中解析 thinking block 的代码都会出错。检查你的响应解析逻辑。
Prefill 被移除
允许用部分文本 seed 模型响应的 prefill 机制已被移除。如果你的应用使用 prefill 来引导响应格式或用部分答案 priming 模型，那些代码需要重写。
迁移指南：什么会坏，如何修复
从 Opus 4.6 迁移到 Opus 4.7 的可操作检查清单：
| 问题 | 如何发现 | 修复方法 |
|---|---|---|
| Temperature/top_p/top_k 参数 | API 调用返回 400 | 从 API 调用中删除所有采样参数 |
| Thinking block 解析 | 读取 thinking 的代码返回空响应 | 在请求中添加 thinking: { type: "enabled" } |
| Prefill 使用 | prefill 请求返回 400 | 从请求体中删除 prefill |
| Token 数量估算 | 预算计算错误 | 用新比率重新计算 token 预算（prose ~1.05x，code ~1.10x，JSON ~1.20x，CJK ~1.30x） |
| 隐式指令泛化 | 边缘情况下的行为变化 | 审查 system prompts 中的非 literal 指令模式 |
| BrowseComp 依赖 | 潜在性能回退 | 迁移前用你的具体搜索用例测试 |
在推送到生产环境之前，在 staging 环境中测试每个破坏性变更。Token 数量问题尤其不会显示为错误——它会以意想不到的更高账单的形式出现。
Opus 4.7 vs GPT-5.4 vs Gemini 3.1 Pro：何时选什么
以下是基于已发布基准数据和我们对每个模型定位的了解所做的决策矩阵。
| 指标 | Opus 4.7 | GPT-5.4 | Gemini 3.1 Pro |
|---|---|---|---|
| SWE-bench Verified | 87.6% | 未知 | 未知 |
| SWE-bench Pro | 64.3% | 未知 | 未知 |
| Terminal-Bench 2.0 | 69.4% | 75.1% | 未知 |
| MCP-Atlas | 77.3% | 未知 | 未知 |
| OSWorld | 78.0% | 未知 | 未知 |
| 视觉 | 出色（XBOW 98.5%） | 强 | 强 |
| 定价 | $5/$25 | 更高 | 更低 |
| 上下文 | 100万 | 100万 | 100万 |
| 工具使用 | 优秀（MCP +14.6） | 良好 | 良好 |
| API 灵活性 | 高 | 中等 | 高 |
| Claude Code 原生 | 是 | 否 | 否 |
选择 Opus 4.7 当： 你在构建 Claude Code 集成、优先考虑工具使用性能、需要最佳编程 agent 基准分数、想要 Claude Code 原生体验，或者你已经全押在 Anthropic 生态上。
选择 GPT-5.4 当： Terminal-Bench 2.0 性能是你的主要基准（GPT-5.4 以 75.1% 对 Opus 4.7 的 69.4% 领先）、你在 Microsoft 生态系统中构建且有深度 Azure OpenAI 集成，或者你的团队有现有的 GPT-5.x prompt 库，迁移成本很高。
选择 Gemini 3.1 Pro 当： 成本是主要约束、你在 Google Cloud 上构建且有 Vertex AI 需求，或者你需要 Google 生态系统的集成（Workspace、Search 等 Google 服务）。
Terminal-Bench 差距是真实的，值得直接承认。GPT-5.4 在 Terminal-Bench 2.0 上领先 Opus 4.7 5.7 分。如果你的主要用例是基于终端的 agent 工作流，而且该基准是你的生产性能代理指标，GPT-5.4 有优势。在实际编码 agent 场景中，对于其他所有重要的事情，Opus 4.7 的 MCP-Atlas 领先（+14.6）和 SWE-bench Pro 领先（+10.9）更具代表性。
Mythos Preview 问题：等待还是现在部署？
Anthropic 已经明确表示 Mythos Preview 是他们真正的 frontier 模型，在所有有对比数据的基准上都比 Opus 4.7 得分更高。但 Mythos Preview 仅限于 Glasswing 合作伙伴——一小部分经过批准的企业客户。
对于大多数团队来说，实际问题不是"Mythos 还是 Opus 4.7？"而是"Opus 4.7 还是竞争对手？"
诚实的答案是：如果你需要 Anthropic 提供的最佳模型，而且你不是 Glasswing 合作伙伴，Opus 4.7 就是你部署的对象。相对 Opus 4.6 的基准提升非常实质性的，从 4.6 升级到 4.7 绝对值得。Opus 4.7 与 Mythos Preview 之间的差距是未来的问题，不是现在的问题。
如果你现在用的是 Opus 4.6，升级计算很简单。SWE-bench Pro 提升（+10.9 分）本身就证明了任何构建编码 agent 的团队都值得迁移。MCP-Atlas 提升（+14.6 分）证实了基于工具的工作流已经大幅改善。Tokenization 变化是大多数用例都能接受的适度成本增加。
多模型架构模式
生产级 Claude 系统的 emerging pattern 不是"选一个模型"，而是"把任务路由到正确的模型"。以下是基于 Opus 4.7 定位的有意义的架构模式。
Opus 4.7 用于规划。 复杂的多步推理、架构决策、安全敏感操作和初始任务分解，都受益于 Opus 4.7 的自验证行为和指令遵循精度。在你需要模型谨慎思考后再行动时使用 Opus 4.7。
Sonnet 4.6 用于执行。 一旦有了计划，Sonnet 4.6 以 Opus 1/5 的成本处理执行工作，且在编程和计算机使用基准上接近持平。Sonnet 4.6 在 SWE-bench Verified 上得分 79.6%，Terminal-Bench 59.1%，MCP-Atlas 61.3%，OSWorld 72.5%，GPQA 74.1%。对于"执行计划"的所有事情，Sonnet 4.6 是理性选择。
Haiku 4.5 用于审查。 高吞吐量、低成本的审查任务——如初始分类、基本验证和针对已知模式的模式匹配——非常适合 Haiku 的速度和成本配置。当你需要快速处理大量条目且可以接受较低的每条目推理深度时，使用 Haiku。
决定哪个模型处理哪个步骤的路由标准：
- 复杂度阈值：如果任务需要超过 N 个工具调用步骤或涉及模糊需求，路由到 Opus 4.7。如果是直接执行，路由到 Sonnet 4.6。
- 成本阈值：如果任务量大且每条价值低，Haiku 做分类，带有升级到 Sonnet 或 Opus 的标准。
- 风险阈值：如果错误输出可能造成伤害（安全、财务、医疗），即使 Sonnet 能处理主要任务，也路由到 Opus 4.7 进行验证。
- 延迟阈值：如果响应必须是实时的，Sonnet 4.6 或 Haiku 4.5。如果可以接受异步，Opus 4.7 的 thinking 时间是值得的。
这种多模型路由方法是生产系统同时实现质量和成本效率的方式。你不需要在能力和成本之间选择，因为你可以适当地路由。
关于 Sonnet 4.6 能力的更深入分析以及它何时比 Opus 更好的选择，请参阅我的 Claude Sonnet 4.6 深度解析。
Claude Code 发生了什么变化
如果你使用 Claude Code，Opus 4.7 带来了几个影响你日常工作流的变化。
xhigh 现在是默认努力级别。 这意味着 Claude Code 默认更努力地理解你的需求并验证其输出。对于大多数任务，这是一个纯粹的改进。你无需更改编写 prompt 的方式就能获得更好的结果。
/ultrareview 命令 利用 xhigh 努力级别进行超出表面检查的代码审查。如果你一直在使用 Claude Code 进行审查，反馈质量应该会明显提升。
Max 订阅者的 Auto 模式 根据检测到的任务复杂度自动选择努力级别。这是 Claude Code 的发展方向：不只是执行指令，而是推理每个指令应该值得多少投入。
实际总结：如果你在 Sonnet 4.6 上对 Claude Code 满意，升级到 Opus 4.7 作为复杂任务的默认模型是无缝的。你无需更改工作流就能获得更好的结果。
设计人格的坑
这是前端团队在部署任何涉及设计输出的 Claude 驱动功能之前需要知道的。
Claude Design 于 2026 年 4 月 17 日（Opus 4.7 发布后的第二天）发布，使用 Opus 4.7，并具有持久的默认美学：暖奶油色背景、衬线字体和陶土色强调色。这在 API 级别不可配置。这是 Claude Design 在让你创建视觉产物时的默认设计人格。
如果你正在构建使用 Claude Design 或任何生成设计输出的 Opus 4.7 驱动功能的产品，默认美学会渗透出来，除非你明确覆盖它。这对于有既定品牌指南的产品团队很重要。
坑在于：默认设计人格在会话之间是持久的。如果你的应用依赖 Claude 生成的设计产物，而你没有在 prompt 中明确指定设计约束，暖奶油/衬线/陶土美学就会出现。对于某些产品这没问题；对于其他产品，它会与品牌要求冲突。
在每个涉及视觉输出的 prompt 中明确指定设计约束。不要依赖模型来推断你的美学偏好。
Sonnet 4.6 交叉参考：何时 Sonnet 是更好的选择
在新旗舰模型上把一切路由到它的诱惑是错误的本能。
Sonnet 4.6 每百万 token $3/$15，是 Opus 4.7 $5/$25 的成本的 1/5。对于大多数生产工作负载，成本能力平衡有利于 Sonnet 4.6。
具体来说，Sonnet 4.6 在以下情况下是更好的选择：
日常驱动开发。 对于构成大多数开发者一天工作的常规编码工作，Sonnet 4.6 在 SWE-bench Verified 上的 79.6% 与 Opus 4.7 的 87.6% 在射程范围内。8 分差距对最难的 10% 任务很重要，但不足以证明将所有工作路由到 Opus 是合理的。
高容量工具使用。 Sonnet 4.6 在 MCP-Atlas 上的 61.3% 与 Opus 4.7 的 77.3% 对于大多数工具使用场景足够接近。差距在绝对值上很大，但 Sonnet 的成本优势更大。
计算机使用任务。 Sonnet 4.6 在 OSWorld 上 72.5% 对比 Opus 4.7 的 78.0% 是 5.5 分差距。对于常规浏览器自动化和文档处理，考虑到 Sonnet 的成本优势，这个差距是可以接受的。
当你需要速度时。 Sonnet 4.6 在等效 prompt 长度下比 Opus 4.7 延迟更低。如果你的应用有实时要求，Sonnet 是默认选项。
把 Opus 4.7 留给 Sonnet 4.6 真正挣扎的任务：复杂的多步推理、安全敏感操作，以及自验证循环能产生可衡量差异的最难编码问题。
FAQ
Claude Opus 4.7 多少钱？
Opus 4.7 通过 Anthropic API 定价为每百万 token 输入 $5，输出 $25。它也可以通过 AWS Bedrock 和 Google Vertex AI 获得，定价结构相同。消费级访问包含在 Pro（$20/月）和 Max（$100-200/月）计划中。
Opus 4.7 的上下文窗口是多少？
Opus 4.7 支持 100 万 token 的上下文窗口，与 Opus 4.6 相同。每次请求最大输出 128K token。
Opus 4.7 与 Opus 4.6 相比如何？
Opus 4.7 在几乎每个基准上都优于 Opus 4.6。关键提升：SWE-bench Verified +6.8 分（87.6% vs 80.8%），SWE-bench Pro +10.9 分（64.3% vs 53.4%），MCP-Atlas +14.6 分（77.3% vs 62.7%），XBOW Vision +44 分（98.5% vs 54.5%）。唯一退步是 BrowseComp -4.4 分。
什么是 Mythos Preview？
Mythos Preview 是 Anthropic 的真正 frontier 模型，能力在 Opus 4.7 之上。它仅限于 Glasswing 合作伙伴客户，不可通过标准 API 访问。已发布的基准分数显示 Mythos Preview 在所有有对比数据的基准上都优于 Opus 4.7。
我应该从 Opus 4.6 升级到 Opus 4.7 吗？
是的——如果你用 Claude 做编程 agent 工作、基于工具的工作流或任何视觉相关任务。SWE-bench Pro 提升（+10.9）、MCP-Atlas 提升（+14.6）和 XBOW 提升（+44）共同代表了生产 agent 系统最重要能力的实质性改进。Tokenization 增加（取决于内容类型约 5-10%）是为这些提升付出的适度成本。
Opus 4.7 引入了哪些破坏性 API 变更？
三个重要的破坏性变更：temperature/top_p/top_k 参数现在返回 400 错误，必须删除；thinking 默认隐藏，必须显式请求；prefill 已被完全移除。还有新的 tokenization 比率，会根据内容类型将 token 数量增加 5-30%，影响成本计算。
BrowseComp 退步是否意味着 Opus 4.7 在搜索方面更差？
对您的用例不一定。BrowseComp 退步（-4.4 分）可能反映了 Opus 4.7 在合成基准上更 literal 的指令遵循和更少的捷径。在你的具体应用中测试 Opus 4.7，然后再假设退步适用于你的用例。
Opus 4.7 如何处理视觉任务？
Opus 4.7 处理图像的分辨率高达 2576 像素，而 Opus 4.6 为 1568 像素，采用 1:1 像素坐标映射，消除了混叠。这在视觉基准上产生了显著的改进，包括 XBOW（98.5%，从 54.5% 提升）、CharXiv-R with tools（91.0%，从 77.4% 提升）和 CharXiv-R without tools（82.1%，从 68.7% 提升）。
建议
现在升级如果： 你在用 Opus 4.6 且正在构建编程 agent、基于工具的工作流或任何使用视觉的应用。基准提升是真实且实质性的。API 迁移需要删除采样参数、调整 token 预算和更新响应解析。所有这些都是一次性修复，会立即获得回报。
等待如果： 你在用 Opus 4.6 且主要做简单的文本生成，没有 agent 组件、工具使用和视觉。升级的提升在这个场景中不那么明显，迁移工作可能还不值得。但要注意你的下一个项目何时需要 Opus 4.6 挣扎的东西，在那个决策点升级。
架构层面： 从一开始就将多模型路由构建到你的系统中。Opus 4.7 用于规划和验证，Sonnet 4.6 用于执行，Haiku 4.5 用于分类。不是把所有东西都路由到旗舰模型能节省大量成本，而且各层之间的能力差异足够窄，基于复杂度进行路由比默认使用最强大模型能产生更好的成本能力比。
基准数据清楚地说明了这一点。Opus 4.7 不是边际改进。它是生产级 AI 工程工作重要能力的实质性一步。问题不是是否升级，而是你能以多快的速度安全迁移。
关于 Anthropic 完整产品策略的其他背景，请参阅 Anthropic 2026 年完整产品栈。关于大规模部署这些模型相关的 信任但验证：Meta 配置安全 模式，请参阅我对 Meta 配置安全方法的分析。