Lena 来了。4 月 16 日发布之后，我把官方文档和迁移材料过了一遍，本以为大部分内容都会很熟。确实大部分是。但里面有足够多的结构性变化——三个 breaking 的 API 改动、一个新的 effort 系统、一个会改变 token 计数的 tokenizer——如果你把这次升级当成"把 model ID 换一下"那么简单，会出事。

以下是我自己走了一遍之后看到的。

Claude Opus 4.7 API 包含什么

Model ID、上下文窗口、output 上限和工具

先把基础说清楚，因为这些值得直说。

**Model ID：claude-opus-4-7**。根据 Anthropic 的官方 models overview，它在标准 API 定价下支持 1M token 上下文窗口，没有长上下文溢价；在同步的 Messages API 上 最高 128k output token。在 Message Batches API 上，使用 output-300k-2026-03-24 beta header，Opus 4.7 可以跑到 300k output token。

整套工具从 Opus 4.6 继承：bash、code execution、computer use、text editor、web search、web fetch、MCP connector、memory tools 在第一天就全部可用。vision 支持全面存在——而且有实质性升级，下面我会回来讲。

在 Claude API、Amazon Bedrock、Google Cloud Vertex AI 和 Microsoft Foundry 上都可用——并在 GitHub Copilot 上向 Copilot Pro+、Business 和 Enterprise 用户推出。定价：每百万 input token $5，每百万 output token $25——和 Opus 4.6 一样没变。

相比 Opus 4.6 有哪些新东西

在 API 表面上，真正新的东西有三个：

Adaptive thinking 是唯一的 thinking 模式。 旧的 {"type": "enabled", "budget_tokens": N} 写法没了。现在这样发送会返回一个 400 错误。Opus 4.7 用 {"type": "adaptive"}——模型根据任务复杂度动态决定要推理多少。adaptive thinking 默认是关的；如果你想让模型思考，必须显式开。

xhigh effort level。 它位于 high 和 max 之间，是 coding 和 agentic 用例新的推荐起点。API 默认仍是 high；你要通过 output_config 显式设成 xhigh。结构我下面会写出来。

Task budgets（beta）。 一个新机制，给模型一个针对整个 agentic 循环的 token 目标——thinking、tool call、tool result、最终 output 全加在一起算。模型会看到一个倒计时，用它来排优先级，并在预算用完时优雅收尾。

同时移除：非默认的 sampling 参数。把 temperature、top_p、top_k 设成任何非默认值，现在都会返回 400 错误。如果你之前用 temperature=0 求确定性输出，需要注意它其实从来没真正保证过相同输出——迁移指南建议干脆不要发这些参数。

一个最小的 Claude Opus 4.7 API 设置

第一条请求的结构

Opus 4.7 最小可运行的请求长这样：

Python

import anthropic

client = anthropic.Anthropic()

message = client.messages.create(
    model="claude-opus-4-7",
    max_tokens=4096,
    messages=[
        {"role": "user", "content": "Explain the tradeoffs between BFS and DFS for a graph with cycles."}
    ]
)

print(message.content[0].text)

这条请求没启用 thinking。模型会直接回答。对大部分任务来说，这就是正确的起点——只有在你有理由的时候才加复杂度。

选 Adaptive Thinking 和 Effort Level

当你希望模型在回答前先推理，加上 thinking 配置，并显式设置 effort：

Python

message = client.messages.create(
    model="claude-opus-4-7",
    max_tokens=16384,
    thinking={"type": "adaptive"},
    output_config={"effort": "xhigh"},
    messages=[
        {"role": "user", "content": "Review this pull request for security vulnerabilities..."}
    ]
)

根据 Anthropic 官方的 effort 文档，关于 effort level 有几件事值得知道：

high 是 API 默认。适合复杂推理、微妙分析或困难的 coding 问题，质量优先。
xhigh 是新的级别——推荐用于 coding 和 agentic 任务。Claude Code 已经在所有方案上把默认提到 xhigh。
max 提供最深的推理、没有 token 约束。只对当前 session 有效（除非通过环境变量设置），不会持久化。
low 和 **medium** 用精度换速度和成本。适合高吞吐分类或路由，其中边际质量差异不值得花钱。

有个细节我回头读了两遍：Opus 4.7 比 Opus 4.6 更严格地尊重 effort level，尤其是在 low 和 medium。如果你在一个复杂任务上观察到推理偏浅，正确的做法是把 effort 提上去——而不是在 prompt 外面加搭架子。文档对这一点很明确。

跑 xhigh 或 max 时，把 max_tokens 设成至少 64k，给模型在 subagent 和 tool call 之间思考和行动的空间。从 64k 开始再往上调，是 Anthropic 自己的建议。

对长时段 agent 真正重要的 feature

高分辨率 vision、xhigh effort 和 tool workflow

vision 升级是对 agent 开发者最具体的能力提升。正如 Vellum AI 对 Opus 4.7 的 benchmark 分析所记录的，OSWorld-Verified（computer use）从 Opus 4.6 的 72.7% 升到 78.0%——5 个点的提升，叠加分辨率升级，实质性地改变了 UI 自动化的经济学。

Opus 4.7 是 第一款支持高分辨率图像的 Claude 模型：最大分辨率从 1,568 像素（约 1.15MP）提高到 2,576 像素（约 3.75MP）长边。像素预算涨了三倍多。对那些读取密集 UI、基于截图的 workflow、或者文档理解 pipeline 的 computer-use agent 来说，这是一个有分量的变化。关键是，坐标现在和实际图像像素 1:1 映射——以前做坐标抽取时需要算的缩放因子没了。

一条带 vision 的请求：

Python

message = client.messages.create(
    model="claude-opus-4-7",
    max_tokens=4096,
    messages=[
        {
            "role": "user",
            "content": [
                {
                    "type": "image",
                    "source": {"type": "url", "url": "https://example.com/diagram.png"}
                },
                {"type": "text", "text": "List every service shown and the connections between them."}
            ]
        }
    ]
)

如果某个任务并不需要那额外分辨率，发送前先降采样——高分辨率图片会产生更多 token，对成本敏感的工作负载，这个会累积。

对工具密集的 agentic 循环，提高 effort 会增加 tool call 的频率和深度。关系是直接的：effort 越低 → tool call 越少、推理链越浅；effort 越高 → tool 交互越彻底。这也可以通过 prompt 来引导，但 effort 参数是更干净的杠杆。

面向生产的成本和延迟控制

Task budgets 是控制长 agentic 循环开销的新机制。用 beta header 启用：

Python

response = client.beta.messages.create(
    model="claude-opus-4-7",
    max_tokens=128000,
    output_config={
        "effort": "high",
        "task_budget": {"type": "tokens", "total": 128000}
    },
    messages=[
        {"role": "user", "content": "Review the codebase and propose a refactor plan."}
    ],
    betas=["task-budgets-2026-03-13"]
)

模型会看到这个倒计时，用它来排优先级并优雅地收尾。没有 task budget 的情况下，默认行为是"按需花"——在一个 xhigh 下的复杂 agentic 任务上，这可能意味着比你从单轮请求里预期的多得多的 output token。

对异步工作负载——评估 run、每晚汇总、批量分析——Batch API 给 50% 折扣，并把实时流量从 rate-limit 压力里拿掉。prompt caching 仍然可用，对那些有稳定 system prompt 或大段静态前缀的工作负载，可以把重复的 input 成本降最多 90%。

要避开的迁移错误

假设 4.6 的 prompt 可以原样搬过来

这是我反复看到冒出来的一个。

Opus 4.7 比 Opus 4.6 更字面地遵循指令。它不再"读字里行间"，也不再悄悄从一个 case 泛化到另一个。软措辞——"try to"、"if possible"、"roughly"——现在真的有更大的分量。那些依赖 4.6 解读弹性的 prompt 有时候会以不一样的方式工作，而且不总是往你期望的方向。

三个 breaking 的 API 变化需要改代码，不只是改 prompt：

把 thinking: {type: "enabled", budget_tokens: N} 换成 thinking: {type: "adaptive"}
把 temperature、top_p、top_k 完全从请求里移除
审计 max_tokens——新 tokenizer 对同一段文本最多会映射到 1.35× 更多的 token，所以以前够用的上限可能会把回复截断

关于语气：Opus 4.7 比 4.6 更直接、更有主见——emoji 更少，少了那种"验证先行"的措辞。如果你的产品依赖一种按 4.6 那种更温暖风格调过的嗓音，在推到生产之前，先把你的 style prompt 针对新基线重新评估一次。

Anthropic 的 Opus 4.7 发布公告直接链接到完整的迁移 checklist，Claude Code 用户可以跑 /claude-api migrate 在一个 codebase 上自动完成 model ID 替换和 breaking 参数改动。

把长上下文当成持久记忆

我在文档里读到这段时停下来了，因为两者确实容易混淆。

1M token 的上下文窗口不是持久记忆。 它的意思是你可以在一条请求里塞进 100 万 token。当那条请求结束——session 关掉、agent 崩了、新对话开始——那段上下文就没了。下一条请求从零开始。

Opus 4.7 确实包含改进的基于文件系统的记忆：模型会在多 session 工作中读写 notes 文件，agent 使用这种模式时行为明显更可靠。但那是你配置出来的工具。它不会自动从长上下文窗口里长出来。

对任何在搭"跨 run 能记住东西"的 agent 的人来说，这个区别很重要。1M 窗口在 session 内部有帮助。跨 session 的记忆需要显式架构。

API 仍然没解决的事

能力复用和被验证过的修复历史

这一段我觉得放进一份 API 指南里没那么整齐，但我觉得值得说。

当 Opus 4.7 在 planning 阶段抓到一个逻辑错误——发布材料把这个描述成一个真实的能力——那个推理发生在 session 内部。它抓到那个错误这件事、以及它怎么修正的这件事，不会自动作为一个可复用 pattern 持久下来给下次用。下一次同一类问题再出现时，模型还是从零推理。

根据 2026 年初发表的一篇关于 AI agent 可靠性的研究论文，大多数模型是按平均准确率而不是跨 run 一致性来做 benchmark——这意味着一个模型可以在 benchmark 上得分漂亮，同时在同一类任务上的不同时刻还是会不可预测地失败。Opus 4.7 在 Opus 4.6 的基线上有改进。这是真的。但 session 内纠正和跨 session 能力继承是两个不同的问题，API 解决了第一个，没解决第二个。

对在跑生产 agent 的构建者来说，这意味着搭可靠系统的工程工作——评估 harness、repair 文档、监控——仍然坐在模型之外。API 给你的是一个更强的模型。怎么把这种能力随时间利用起来，仍然坐在你的架构上。

FAQ

Q：Opus 4.7 正确的 model ID 是什么？

A：claude-opus-4-7。这是跨 Claude API、Amazon Bedrock、Google Cloud Vertex AI 和 Microsoft Foundry 的稳定 model 字符串。

Q：adaptive thinking 默认是开的吗？

A：不是。在 Opus 4.7 上 adaptive thinking 默认是关的。必须显式设 thinking: {"type": "adaptive"} 才能启用。不带 thinking 字段的请求不会思考。

Q：如果我发了 temperature 或 budget_tokens 会怎样？

A：两者在 Opus 4.7 上都会返回 400 错误。把 temperature、top_p、top_k 从所有请求里删掉。把 budget_tokens 换成 output_config: {"effort": "..."} 和 thinking: {"type": "adaptive"}。

Q：什么时候用 xhigh，什么时候用 high？

A：把 xhigh 作为 coding 和 agentic 任务的起点——Claude Code 在所有方案上的默认现在就是它。大多数对智能度敏感的任务用 high。当延迟或成本比推理深度更重要时降到 medium 或 low。如果你在一个复杂任务上、在更低级别上观察到浅输出，把 effort 提上去，而不是在 prompt 外面加搭架子。

Q：1M 上下文窗口是不是意味着 agent 会在 session 之间记住东西？

A：不是。上下文窗口是在一条请求内生效的。session 结束，那段上下文就没了。多 session 记忆需要显式工具——基于文件的记忆、外部存储或者类似的架构。

如果你想理解为什么模型升级其实降不了系统成本：Claude Opus 4.7 vs Reliability: Why Better Models Don't Fix Agent Systems
如果你想理解真实成本藏在 token 定价之外的哪里：Harness Engineering: The Hidden Layer Behind Agent Cost and Reliability
如果你在评估什么时候 Opus 相对 Sonnet 的溢价才真的值：Claude Managed Agents: When You Should Actually Use Opus vs Sonnet
如果你在搭 agent 系统、需要同时控制行为和花费：Agent Superpowers: Behavior Constraints as a Cost Control Layer
如果你在想把 agent 用量扩展到单个工作流之外：Best MCP Servers for Claude Code: Real Production Use Cases

如何使用 Claude Opus 4.7 API

Claude Opus 4.7 API 包含什么

Model ID、上下文窗口、output 上限和工具

相比 Opus 4.6 有哪些新东西

一个最小的 Claude Opus 4.7 API 设置

第一条请求的结构

选 Adaptive Thinking 和 Effort Level

对长时段 agent 真正重要的 feature

高分辨率 vision、xhigh effort 和 tool workflow

面向生产的成本和延迟控制

要避开的迁移错误

假设 4.6 的 prompt 可以原样搬过来

把长上下文当成持久记忆

API 仍然没解决的事

能力复用和被验证过的修复历史

FAQ

Previous Posts

相关文章