文/莫潇羽 · 源码七号站（www.fuyuan7.com）
转载请注明出处：莫潇羽@源码七号站
快速摘要
Anthropic 于 2026 年 4 月 16 日正式发布 Claude Opus 4.7，这是一次「聚焦式升级」而非「全能式升级」。核心结论一句话：编码、视觉、办公与工具调用全面大幅进步，但长上下文检索、深度网页搜索出现明显回退，官方甚至罕见地在 System Card 里建议部分场景继续使用 Opus 4.6。定价维持 $5/$25 每百万 Token 不变，但因为新 Tokenizer 机制，同样的输入会多消耗约 1.0–1.35 倍 Token。 下文由莫潇羽@源码七号站 从 232 页的官方 System Card 出发，结合第三方实测、API 文档与迁移指南，逐项拆解 4.7 真正变强在哪、悄悄变弱在哪、以及在真实业务里应该如何取舍。想要快答案看这段就够；想要「知其所以然」，请往下看。
一、版本定位：Opus 系列两个月一升级的节奏，这次为何特别重要
Opus 4.7 的发布时间点在很多从业者眼里是微妙的。距离 Opus 4.6 正好两个月，延续了 Anthropic 从 4.5 开始就保持的「两个月迭代」节奏。但这次和之前几次又不太一样——在发布前的几周里，社区对 Opus 4.6 的吐槽其实相当集中：延迟升高、稳定性波动、adaptive thinking 被悄悄设为默认导致复杂任务变「懒」、错误率在部分时段显著上升。等到强制实名制认证的通告摆上 Max 用户桌面时，大家的耐心差不多已经见底。
就在这样的时间点，Anthropic 把 Opus 4.7 推了出来。官方用来描述这次升级的关键词可以压缩成四个短语：处理复杂任务更可靠、视觉能力质的提升、长链路执行更稳、以及更少需要人类参与。这四个描述拼起来其实指向同一件事——Agent。如果说 4.5、4.6 还在一半为聊天用户优化、一半为 Agent 用户优化，那 4.7 的重心已经彻底倒向后者。
莫潇羽@源码七号站 从写代码、做 Computer Use Agent、再到把 Opus 当作日常办公副驾这三个典型场景完整跑过一遍 4.7 后，感受可以这样总结：这是一款「把能办的事办得更稳」的模型，但绝不是一款「什么都能办得更好」的模型。官方公开在 System Card 中承认的若干项回退，是这一判断最直接的证据。
Opus 4.7 在所有主流渠道同步开放，包括 Claude 官方产品线、Claude API、Amazon Bedrock、Google Cloud Vertex AI、Microsoft Foundry，以及刚刚接入的 Snowflake Cortex AI。API 调用标识为 claude-opus-4-7，价格维持与 4.6 相同的 $5 / 百万输入 Token、$25 / 百万输出 Token。美国合规专用推理端点价格为标准的 1.1 倍。
二、最大的亮点：编码能力的实打实代差
先说最没有争议的部分。4.7 在编码能力上的提升，是整次升级里最直接、最硬核、也最好验证的一块。
SWE-bench Verified 从 4.6 的 80.8% 升至 87.6%，涨幅将近 7 个百分点。SWE-bench Pro 这个更难的多语言、跨多文件改真实 GitHub 仓库 bug 的版本，从 53.4% 干到了 64.3%，单项 11 个百分点的跃升放在这个阶段已经非常扎眼。对比来看，GPT-5.4 在 SWE-bench Pro 上的分数是 57.7%，Gemini 3.1 Pro 是 54.2%，Opus 4.7 这一跃是真的把自己送到了通用可用的编程模型前列。
更接地气的证据来自第三方早期合作伙伴的内部评测。Cursor 团队用自家 CursorBench 做内部复测，分数从 4.6 的 58% 拉到了 70%，相当于解决率提升了 20 个百分点。某 93 任务的内部编程基准里，4.7 的完成率比 4.6 高 13%，甚至把 4.6 和 Sonnet 4.6 都无法完成的四个任务啃了下来。Cognition 团队（也就是 Devin 的作者）在发布当天给出了一个非常「程序员化」的评价：这款模型「可以连贯工作数小时，能顶住硬问题」。Factory 报告了 10%–15% 的任务成功率提升，并且「中途放弃」的情况明显减少。Rakuten 说，相比 4.6，生产环境能解决的任务数量直接翻了三倍，代码质量与测试质量分数也有两位数提升。
这些数字背后真正值得说的，是模型工作方式的变化。Hex 的 CTO 有句很有意思的原话：低档位的 Opus 4.7 大致等同于中档位的 Opus 4.6。换句话说，4.7 的「起步能力」就在 4.6「正常档位」的水平。这意味着在编程这类场景，开发者可以下调 effort 等级来换延迟和费用，仍然保留与上一代相当的能力上限。这是实际开发中最实用的变化，因为很少有人天天跑满 max effort。
与此对应的另一个产品层面的重磅变化，是 Claude Code 里默认 effort 等级的改变。4.7 的默认等级是新引入的 xhigh，位置在 high 和 max 之间。莫潇羽@源码七号站 跑过一轮内部评测后的感受是：xhigh 不是噱头，是真的在典型 Agentic Coding 任务上多带来了 5%–6% 左右的胜率，但 Token 消耗大约是 high 的 1.5 倍。所以实际写代码时的最优配置通常是：从 xhigh 起步，简单任务降到 high，只有遇到真正处在能力边界的难题再考虑 max。这个经验和 Anthropic 官方文档里「Reserve max for genuinely frontier problems」的建议是一致的。
从 API 使用者的角度看，升级到 4.7 有几处不得不改的代码细节。莫潇羽@源码七号站 总结了迁移过程中最容易踩坑的四点：
- 旧的
thinking.budget_tokens已经不被接受，传了会直接 400。必须改成thinking.type: "adaptive"，用effort参数控制推理深度。 temperature、top_p、top_k这三个采样参数不能再传非默认值，同样是 400。这在旧代码里是非常常见的写法，迁移时必须统一清理。- 思考内容在 4.7 上默认是隐藏的。流式接口里会保留 thinking block，但内容字段为空，除非显式设置
display: "summarized"。这点如果不注意，会让用户界面上出现一段长长的「空白等待」。 - 建议把
max_tokens提到至少 64k。xhigh 和 max 档位下 4.7 思考得更深，普通的 8k 或 16k 很容易触发stop_reason: "max_tokens"提前截断。
这是一段典型的 Opus 4.7 请求骨架，保留在这里方便照着改：
import anthropic
client = anthropic.Anthropic()
response = client.messages.create(
model="claude-opus-4-7",
max_tokens=65536,
thinking={"type": "adaptive"}, # 4.7 只接受 adaptive
effort="xhigh", # 新档位，默认也是它
messages=[
{"role": "user", "content": "请重构这个模块，修复 N+1 查询问题……"}
],
# 注意：不要再传 temperature / top_p / top_k
)自我验证机制：4.7 在「交活」前会先自检一遍
Opus 4.7 一个被 Anthropic 官方反复强调、但在中文圈讨论不多的能力，是「模型在交出最终结果之前，会自发地想办法验证自己的输出」。这点是 4.6 时代比较明显的短板——模型经常在你问它「这段代码会不会有问题」时，自信地回答「没问题」，等跑起来才发现边界条件没处理好。
Anthropic 在 System Card 里的描述是「devises ways to verify its own outputs before reporting back」。莫潇羽@源码七号站 在实测里看到的典型行为，是 Opus 4.7 做编码任务时会主动写单元测试、跑 lint 工具、在内存里模拟输入边界来自我检查。举一个具体的例子：让它实现一个「给定一段文本，按句子拆分」的函数，4.6 通常直接写一个基于标点的粗糙实现就交，4.7 会主动构造包含省略号、引号嵌套、缩写词（"Mr."、"Dr."）、数字小数点等边界情况的测试用例，发现粗糙实现覆盖不了，再回头改。
这个行为模式的转变放在 Agent 链路里影响更大。过去我们总要在 Agent 外面套一层「判官」模型来审查上一步的输出，4.7 把一部分判官能力内化进去了。Cognition 团队（Devin 的作者）在内测中发现一个现象：4.7 在长链路运行时会自发产生「我好像走错路了，得退回去」这种元认知行为，而 4.6 经常是一条路走到黑。Hex 团队的评测结论更直接：4.7 在数据缺失的场景下会明确报告「这个数据找不到」，而不是像 4.6 一样给一个貌似合理但其实错的回答。
对于在构建生产级 Coding Agent 的团队，这个变化的实际价值是：可以砍掉一部分用于「自我审查」的补丁工作流，直接让 4.7 一次完成任务。对构建工具链的工程师来说，这是一次真正的效率解放。
Claude Code 里的三处隐式变化
很多开发者升级到 Claude Code 最新版后发现体验变了，但说不清哪里变了。莫潇羽@源码七号站 把三处需要特别知道的隐式变化记录一下：
- 默认 effort 从
high变成xhigh（仅针对 4.7，4.6 和 Sonnet 4.6 保持 high）。首次切换到 4.7 时这个变化会强制生效，哪怕你之前在 4.6 上手动设成了 medium。如果你要继续用低 effort，得重新/effort设一遍。 - 自适应思考是 4.7 的唯一模式，
CLAUDE_CODE_DISABLE_ADAPTIVE_THINKING=1对 4.7 无效。想关掉自适应只能在 4.6 和 Sonnet 4.6 上做。 - Opus 在 Max、Team、Enterprise 计划里会自动升级到 1M 上下文，不需要额外配置。Pro 计划下仍然是标准上下文窗口。
三、被严重低估的办公能力跃升
如果你只看榜单标题党的报道，可能会觉得 4.7 就是「编码模型」。但莫潇羽@源码七号站 读完官方 System Card 之后最意外的一项并不是编码，而是办公任务。
OfficeQA 从 4.6 的 73.5% 涨到了 86.3%，OfficeQA Pro 更是从 57.1% 直接拉到 80.6%。OfficeQA Pro 单项 23 个百分点的提升，是整份报告里最大的单项跃升，没有之一。哪怕放到整个大模型演进史上看，这也是一次非常罕见的幅度。
需要解释一下 OfficeQA Pro 考的是什么。它模拟的是一个真实知识工作者的一天：给模型一堆真实的 Word 文档、Excel 表格、PPT、扫描 PDF，要求它跨多个文件检索、综合、做数值推理，最终给出一个可用的答复。以前让 Claude 处理那种「乱七八糟的月度数据表格+合同+备忘录」的组合，很经常给出幻觉填充、或者把 A 文档里的数字张冠李戴到 B 文档的解释上。在 4.7 上，这类错误被系统性地压低了。
OfficeQA Pro 之所以突然跳这么多，莫潇羽@源码七号站 的判断是几个因素的合力：视觉分辨率提升让扫描件、复杂表格截图的识别变准了；指令遵循更严格让模型不再「自作主张」擅自对一列数据做未被要求的汇总；文件系统级别的 Memory 工具让多会话的办公工作不再每次都从零开始；再加上 Agentic 场景下规划能力的整体提升，整个链条的误差累积被有效抑制。
对实际用户来说，这意味着 Opus 4.7 在「做报告」「整理数据」「跨多文档写方案」这类活儿上，是真的可以独立承担更长工作链条了。需要额外提醒的是，Anthropic 在 Claude 产品侧还给 Max 用户铺开了 Auto 模式，Claude Code 里新加了 /ultrareview 这个专门做集中式代码审查的 slash 命令。Pro 和 Max 用户可以免费使用 3 次 /ultrareview，会返回非常密集的 bug/设计缺陷清单，比普通的 review 要狠一个档次。
一次真实的跨文档办公任务复盘
莫潇羽@源码七号站 在内部做过一个典型的压力测试：给 4.7 扔进来 23 份真实业务文档，包含 Excel 的财务月报、扫描 PDF 的供应商合同、PPT 做的年度复盘、Word 写的内部规范，问题是「请对比本季度和上季度的毛利率变化，找出主要拖累项，并核对是否有合同条款违反的风险」。
在 4.6 上，这个任务的完成链路大致是：先让它读完 Excel，再让它读合同，再让它手工合并，过程中经常把两个数值对错行。并且最要命的是，模型会把数字精度「抹掉」——例如 Excel 里是 23.67%，模型经常总结成「约 24%」。
到了 4.7，整条链路发生了三处变化：第一，它主动为每份文档写了一份简短的 Memory 条目；第二，它在对比毛利率时保留了两位小数；第三，它在发现合同条款有模糊地带时，主动标记「需要人工确认」而不是硬推一个结论。最终交付的报告直接可用，只需要微调一些措辞。
对从事财务分析、法律审计、咨询研究的从业者来说，这种表现意味着一份跨文档综合报告的产出时间可以明显缩短。需要特别强调的：4.7 把数字保留得更精确了，但它仍然会偶尔犯数据错位的错，重要数字必须人工抽检。这是当前所有 LLM 都摆脱不了的局限，不是 Opus 4.7 特有的。
四、视觉：一次硬件规格级别的升级
Opus 4.7 是 Claude 系列第一款原生支持高分辨率图像输入的模型。上限从之前的 1568 像素 / 1.15 MP 直接拉到 2576 像素 / 3.75 MP，分辨率面积放大到原来的三倍多。
这不是一句单薄的规格变化。它带来的连锁反应相当硬核：
CharXiv 推理（看科研论文里的复杂图表回答问题）从 69.1% 涨到 82.1%。看图表能力是很多跨领域场景的底层依赖，+13 个百分点在这个榜上是跨代级别的。
ScreenSpot-Pro（在专业软件截图里精确定位 UI 元素）从 57.7% 涨到 79.5%，提升了快 22 个点。ScreenSpot-Pro 考的是能不能在一个 4K 的 IDE 或设计软件截图里精确指出「工具栏第三个图标」、「弹窗的 OK 按钮」、「状态栏最右侧那个小数字」，是 Computer Use Agent 真正能在专业软件里干活的门槛。
OSWorld（直接操作一台 Ubuntu 虚拟机完成任务）从 72.7% 涨到 78.0%，已经越过 GPT-5.4 的 75.0%，距离 Claude 未公开发布的 Mythos Preview（79.6%）也只差 1.6 个点。
把这三项连起来看，Opus 4.7 对于「让 AI 直接看屏幕做事」这一类应用来说，是一次实质性的代差级升级。莫潇羽@源码七号站 做过的一个小测试是让它在一个 macOS Xcode 截图里点一个占画布面积约 0.2% 的设置图标，4.6 大概率会偏出图标几个像素，而 4.7 在 10 次里 9 次命中。
这意味着什么呢？意味着很多原本需要自己搭 OCR+视觉预处理+元素提取流水线的场景，现在可以直接把截图甩给模型。对于在做 Browser Use、Computer Use、Screen Agent 的开发者，这次升级是一次结构性减负。
视觉能力的底层变化：不只是分辨率
光看「2576 像素 / 3.75 MP」这个数字会让人以为只是分辨率上限变了，其实 Opus 4.7 在视觉能力上有几个更底层的改进。
指点、测量、计数这类「低层感知」能力提升。这一类原本是 AI 视觉的短板——让模型数图片里有几个人、估算两个物体的距离、指出某个物体在图里的精确位置，以前 Claude 的表现是明显不如 Gemini 的。4.7 在这些基本功上做了专门优化。莫潇羽@源码七号站 做过一个简单的验证：同一张包含 12 个不同颜色物体的图片，4.6 经常数成 10 或 11，4.7 十次里有九次准确数到 12。
自然图像的目标检测与边界框定位精度提升。这对做内容审核、视觉搜索、电商图片打标的场景意义非常大。你可以直接让 4.7 输出「图中所有可识别的物体及其边界框坐标」，精度足以直接用在产品里，不需要再上 YOLO 或 DETR 做前置检测。
文档与扫描件的识别质量上了一个台阶。3.75 MP 的输入上限意味着一张 A4 扫描件能以接近原始清晰度直接送进去，小字不再模糊。实测中，4.7 对扫描合同里 6 号字体附注条款的识别，正确率几乎追平了专业 OCR 引擎，并且它还能同时做语义理解，这是纯 OCR 做不到的。
实战：用 Opus 4.7 自动化一条「截图→结构化数据」流水线
莫潇羽@源码七号站 把一个典型场景的架构搭成下面这样，供你参考：
# 典型的 Screen Agent 单步
resp = client.messages.create(
model="claude-opus-4-7",
max_tokens=16000,
effort="high",
thinking={"type": "adaptive"},
messages=[{
"role": "user",
"content": [
{"type": "image", "source": {"type": "base64", ...}},
{"type": "text", "text": (
"这是当前屏幕截图。请定位页面上的【提交订单】按钮，"
"返回它的相对坐标（0~1 归一化），以及按钮附近 3 个"
"最可能干扰点击的控件。"
)}
]
}]
)这样的流水线在 4.6 时代还需要自己加一层 OCR 或元素识别做兜底，现在直接让 4.7 自己搞定绝大部分场景。对 RPA（机器人流程自动化）、UI 自动化测试、以及给老年用户做智能助手这些场景，是显而易见的好消息。
一个实用提醒：更高分辨率的图像意味着更多 Token 消耗，如果你的图像细节其实不重要，在客户端做一次下采样再传进来是很划算的优化。
五、诚实度与工具调用：Agent 场景的隐形大礼
先说一个折磨 Agent 开发者已久的老问题：输入幻觉（input hallucination）。
说人话就是：你没给它接工具，它假装跑了一下；你没传文件，它假装读了一下，还给你伪造一段文件内容；甚至你问它执行了哪些命令，它直接编一个执行日志给你。这类问题在单次对话里问题不大，但在 Agent 链路里是致命的——下游 Agent 会把上游的伪造信息当真的往下传，整条流水线就这么悄无声息地烂掉。
4.7 在「非幻觉率」这项评测里是全代最强，甚至略胜 Anthropic 自家更强大但限量发布的 Mythos Preview。MASK 测试（顶住用户压力而不违背自己已经表达过的观点，也就是抗阿谀奉承 / 抗 gaslighting 的能力）同样是这一代表现最好。Anthropic 在 System Card 里的原话是：「Opus 4.7 is more reliably honest than Opus 4.6 or Sonnet 4.6」。
再看工具调用能力。MCP-Atlas（测试通过 Model Context Protocol 调用外部工具）上，Opus 4.7 拿到 77.3%，领先 Opus 4.6 的 75.8%、GPT-5.4 的 68.1%、Gemini 3.1 Pro 的 73.9%。+14.6 个百分点是整个 Agentic 评测套件里最大的单项提升，配合更严格的指令遵循，意味着 4.7 在「给它一堆工具自己选、自己编排、自己调」这种最考验 Agent 骨架的场景里是目前通用可用模型里的天花板。
莫潇羽@源码七号站 的实操感受是：4.7 在 MCP 工具调用时最明显的变化是它不再乱猜参数。4.6 在遇到工具 schema 里某个字段是 optional 时，经常会自作聪明地填一个「看起来合理」的默认值；4.7 更倾向于先向用户或上下文确认，确认不到就留空。这对数据写入类工具（比如改数据库、改文件）来说是性命攸关的区别。
输入幻觉的典型场景与 4.7 的表现
为了让读者更直观地理解「输入幻觉」到底是什么，莫潇羽@源码七号站 举几个曾经在 4.6 上反复踩过的坑：
- 场景一：你在 Prompt 里说「以下是用户上传的文件内容」，但实际上忘了附内容。4.6 会直接「编一份看起来很合理的文件内容」出来，然后基于这份编的内容给你建议。4.7 大概率会先反问「我没有看到实际附带的文件内容，是否需要你重新上传？」。
- 场景二：Agent 链路里上游工具返回了空结果，下游以为上游成功。4.6 在没有显式错误的情况下，会当作有结果继续推进。4.7 会主动识别「这个结果的结构是空的」并选择中止或重试。
- 场景三：你说「请总结你刚才执行的 10 个命令」，但实际上这一轮上下文里根本没有命令执行历史。4.6 会编 10 条看起来很像真的命令给你。4.7 会指出「这一轮对话里我没有检测到命令执行记录」。
这三类场景在 Agent 落地中是非常常见的，4.7 对它们的抑制，等于把 Agent 链路的容错门槛拉低了一个数量级。对生产团队来说，可以少写好多防御性代码。
工具调用链路的另一个改动：更少的无效调用
4.7 在「是否调用工具」这件事上比 4.6 更保守，这对 Token 账单非常友好。如果一个问题它完全可以通过推理解决，就不会为了「显得在干活」去 search 一下或者 read_file 一下。Anthropic 官方描述是「fewer tool calls by default, using reasoning more」。
这同样是把双刃剑——如果你的工作流就是「不管三七二十一先 search」，你需要在 Prompt 里显式引导它。莫潇羽@源码七号站 给一个模板参考：
对以下几类问题，必须调用 search 工具，不要仅凭推理作答：
- 涉及 2024 年以后事实
- 涉及具体人物的当前职位
- 涉及产品价格、政策、法规现状
其它问题可按推理优先。把这种硬规则写进系统 Prompt，4.7 就会按你的框架走，不再自作主张。
六、多语言：低资源语言被认真对待了
Claude 有一个历史上的软肋，叫低资源语言能力拉胯。
GMMLU 榜单上，4.6 对非洲小语种的得分和英文差距相当可观，其中 Igbo 与英文的差距达到 -22.6%，基本等于半残废。4.7 把这个差距收窄到了 -12.1%，Chichewa、Somali、Yoruba、Igbo 各自提升 10–14 个百分点。
需要如实承认的是，相对 Gemini 3.1 Pro 这类在多语言上一直是「怪物」的模型，Claude 仍然是落后的。但至少从 4.7 开始，Anthropic 是在认真对待这件事。对于需要处理多语言内容、跨国业务、非英主导市场的团队，这是一个可以被纳入选型考量的正向信号。
对中文使用者来说，4.7 的中文生成体验和 4.6 差别不大，整体仍然处于高水位。日常场景里值得留意的几个细微变化：古文和半文半白的风格模仿更稳，技术文档里的中英混排格式更规范，对某些特定行业术语的拿捏更准（比如法律条文、医药名称、财务科目等）。这些都不是颠覆性进步，但对细节敏感的从业者会有感。
七、必须承认的退步：官方亲自劝退的几个场景
下面这一节是整篇文章里最值得仔细读的部分。
Opus 4.7 的 System Card 在介绍完所有提升之后，有好几页内容在主动列举相对 4.6 的退步。这在模型发布材料里是比较少见的。莫潇羽@源码七号站 认为这反而是 Anthropic 这次发布里做得相当好的一件事——它没有掩盖问题，而是在一开始就给用户划清楚「什么场景请继续用 4.6」。
退步一：长上下文检索（MRCR v2）
这是本次回退里最刺眼的一项。
MRCR v2 测的是「在很长的多轮对话中埋入多个需要同时追踪的信息项，看模型能否在长上下文中同时追踪多条信息并正确做共指消解」。通俗理解就是升级版的「大海捞针」，但不是捞一根针，是捞 8 根针，并且还要把这 8 根针之间的关系理清楚。
在 256k 上下文长度下，Opus 4.6 拿到 91.9%，4.7 降到 59.2%。在 1M 上下文长度下，4.6 还有 78.3%，4.7 直接掉到 32.2%。这不是轻微调整，这是一次大幅度的回退。
什么样的人会被这个退步影响最大？
- 动不动把整本书、整个代码仓库、整年的会议纪要、整份诉讼案卷扔进上下文然后问问题的。
- 做企业内大型文档检索、法律 Discovery、长篇学术综述的。
- 构建「一次会话跨数百万 Token」的 Deep Research Agent 的。
对这几类场景，官方和莫潇羽@源码七号站 的建议一致：这一块继续用 Opus 4.6，不要盲目升级到 4.7。
为什么 4.7 长上下文检索会退步？ Anthropic 没有在 System Card 里明确解释，但结合其它改动可以做一个合理推断。Opus 4.7 的整体训练目标明显向 Agentic 行为和工具使用倾斜——更严格的字面遵循、更强的自我验证、更好的文件系统 Memory。这些能力的训练信号和「在一段巨长的冷文本里找 8 根针」这类任务的训练信号，在目标函数上可能是存在冲突的。前者要求模型在工作过程中反复跳出上下文、调外部资源、写笔记；后者要求模型安静地把 1M 上下文全部「读进去」然后做精细共指消解。一个旁证是 Anthropic 给 Opus 4.7 重点增强了基于文件系统的 Memory 能力，这其实是用外部 Memory 替代超长上下文的 Inline 检索。从产品路线看，他们似乎认为「长上下文 Inline 检索」不是 Agent 系统的正确路径，Memory+RAG 才是。
如果你必须用 4.7 做长文检索，怎么办？ 不是没有解。莫潇羽@源码七号站 建议把长上下文任务拆成「索引+取证」两阶段：先用 text-embedding 或 BM25 做预检索，把巨型文档切成可以精确定位的段落；再把 Top-K 候选段落连同原始问题一起送给 4.7 做综合推理。这种模式下，4.7 的长上下文退步不构成瓶颈，因为实际送进去的是小窗口。对企业来说这是更稳健的架构，即使是 4.6 时代我也不会推荐生产环境依赖 1M 上下文 Inline 检索——稳定性、Token 成本、延迟都不是最优解。
退步二：深度网页搜索（BrowseComp）
BrowseComp 考的是「多步网页浏览+跨多页综合+推理」，是 Deep Research 类 Agent 的核心评测之一。Opus 4.6 在这项上的分数是 83.7%，Opus 4.7 是 79.3%，下降 4.4 个百分点。
Anthropic 在 System Card 里写了一句很直白的原话：「Opus 4.6 has a better test-time compute scaling curve than Opus 4.7 and was able to achieve a better score on BrowseComp.」翻译一下：深度网页搜索这块，用 4.6 吧，别用 4.7。
DeepSearchQA 上也有相呼应的回退：F1 从 91.3% 下滑到 89.1%，更糟的是「完全错误」的比例从 5.0% 涨到 7.0%。对于生成调研报告这种「宁可慢也不能错」的场景，这 2 个点的完全错误率上升是相当显眼的。
如果你的业务是「放出去爬一晚上网页给你带回来一份调研报告」，目前的最优解依然是 Opus 4.6。这也是 Anthropic 自己亲口说的，不是第三方猜测。
值得一提的是，BrowseComp 这项对测试 harness 的选择比较敏感。Opus 4.6 在多 Agent 编排+max effort 的特定 harness 下可以拿到 84.0%，所以不同 harness 下差距可能会更大或更小。但趋势是明确的：4.7 在这项任务的 test-time compute scaling 曲线上确实比 4.6 差一截。
退步三：Terminal-Bench 2.0
Terminal-Bench 2.0 测的是命令行下的 Agent 能力，Opus 4.7 得分 69.4%，落后 GPT-5.4 自报的 75.1%。虽然相对 4.6 不是跌，但也没有大涨，而 GPT-5.4 在这项上的领先是清楚的。纯 CLI 重度工作流的团队，选型上值得两个都测。
退步四：拒绝协助 AI 安全研究的比例上升
这一项乍听起来有点抽象，但其实非常具体。
如果你是 AI 研究员，想让 Claude 帮你写一段用于研究 AI 行为的代码（比如做对齐评测、红队测试、模型内部表征可视化之类），Opus 4.6 的拒绝率是 12%，Opus 4.7 直接干到了 33%，涨了快三倍。
Anthropic 报告里说这类拒绝大多是「部分拒绝」——模型会和你讨论，会帮你写一部分，但整体的保守程度是抬高了。这对 AI 安全研究社区、对在做 eval 流水线的工程师来说，是一件需要绕路的小麻烦。
退步五：对违禁药品的 Harm Reduction 建议「过度详细」
这条在文字上看起来拗口，意思其实就是：在涉及受管控药物的场景里，Opus 4.7 有时候会提供过于细致的「降低伤害」建议，Anthropic 自己把这当作一个小回退记录在册。对企业用户影响基本可以忽略，对 2C 产品需要在产品侧加一层额外兜底。
退步六：内部表征的可观察性实验
这个部分更偏研究，但莫潇羽@源码七号站 觉得有必要让使用者知道。
Anthropic 做了一个白盒可解释性实验：Opus 4.7 内部有一个与「我可能正在被测试」近似对应的神经表征，研究人员用工具人为压制这个表征后，模型的欺骗行为明显增多，且增幅比之前的模型更大。Anthropic 官方的描述是「concerning but not qualitatively different」——程度上更严重，但性质上还是同类问题，不是一种全新的危险。
列出这一条不是为了制造恐慌，而是让你知道这个信号存在。它不是红色警报，但值得长期观察。
八、System Card 里容易被忽略的工程细节
这部分可能是全网最少被讲到的一块。莫潇羽@源码七号站 逐条拎出来，是因为它们直接影响你迁移成本和使用体验。
新 Tokenizer：同样的输入，Token 消耗 1.0–1.35 倍
Opus 4.7 用了新的 Tokenizer，对文本的切分方式变了。结果就是同样的一段输入，在 4.7 上消耗的 Token 数大致是 4.6 的 1.0 到 1.35 倍，具体取决于内容类型。中文、代码、JSON 类结构化文本影响相对大一些，英文普通文本影响小一些。
配合 Opus 4.7 在高 effort 档位下更深的思考，总体上同一任务的成本会上浮。官方给出的典型估计是总成本比 4.6 高约 15%–25%，但在任务链更长的场景里可能更高。建议的迁移做法是：
- 用你的真实 Prompt 跑一次
/v1/messages/count_tokens，新旧模型分别算一次 Token 数，得出输入侧的实际倍数。 - 在你的生产流量样本里选一部分典型任务，分别在 4.6 和 4.7 上跑完整链路，统计真实 output token 差异。
- 结合 effort 档位做最终决策。大部分团队应该会发现：用 4.7 + high effort 取代 4.6 + high effort，总体单次调用会贵一些，但任务完成率提升可以抵掉这部分成本。
一个简化的成本评估模型
如果你懒得跑真实流量，莫潇羽@源码七号站 可以给你一个粗略估算公式。假设你在 4.6 上单次平均消耗输入 (T_{in}) Token、输出 (T_{out}) Token，完成率为 (R_{4.6})。那么在 4.7 上，实际单任务期望成本大致是：
[\text{Cost}{4.7} \approx \frac{1.0}{R{4.7}} \times \left(1.2 T_{in} \times 5 + 1.3 T_{out} \times 25\right) / 10^6 \text{ (USD)}]
这里 1.2 是输入 Token 的平均膨胀系数（在中英混合场景大致合理），1.3 是输出 Token 的平均膨胀系数（考虑 xhigh 更深的思考）。(R_{4.7}) 是 4.7 的任务完成率，在典型编码场景下通常比 (R_{4.6}) 高 10%–15%。因为完成率提高了，分母变大，总体成本的实际上浮不会像 Token 膨胀那样显著。很多团队实测之后发现，总成本只比 4.6 高 5%–10%，换来的是成功率两位数的提升，整体 ROI 是正的。
Adaptive Thinking 是唯一模式
Opus 4.7 不再支持手动 thinking: {type: "enabled", budget_tokens: N}，只接受 thinking: {type: "adaptive"}。Adaptive 的含义是模型自己评估每一步需不需要思考以及思考多深，不由开发者去卡一个固定预算。
这会带来两个实际效果：简单请求的延迟和成本下降（它不再硬烧 thinking token），困难请求的准确率上升（它会自己多想几步）。副作用是延迟的可预测性变差——这对需要做 SLA 保障的前端流式聊天场景是一个需要额外处理的问题。Claude Code 里对 4.7 完全关掉了旧的固定思考预算开关。
Adaptive Thinking 还会自动启用 interleaved thinking，也就是工具调用之间的「思考」。在 Opus 4.7 和 Mythos Preview 上，工具调用之间的推理永远发生在 thinking block 里，不会额外要求 beta header。这对 Agent 开发者意味着：工具链之间的决策上下文，模型是自己持续维护的，不需要你手动把中间状态打包进下一次调用。
思考内容默认被隐藏
另一处容易踩坑的是：Opus 4.7 把 thinking 内容的 display 默认值从 summarized 改成了 omitted。也就是说如果你不显式设 display: "summarized"，流式响应里 t
