Claude Opus 4.7 的 100 万 token 上下文窗口，最好不要理解成一种“让所有提示词都更强”的开关。更准确的说法是：它给模型提供了一个很大的工作空间，可以在同一会话里容纳更多源代码、技术文档、工具结果、日志和任务历史。
Anthropic 的迁移指南显示，Opus 4.7 支持 1M token 上下文窗口，按标准 API 价格计费，没有额外的长上下文溢价；同时它还支持 128k 最大输出 token、prompt caching、Files API、PDF、视觉、工具调用和 memory 等能力 [16]。所以真正要问的不是 1M 上下文会不会让所有任务都更好，而是：你的任务是否真的有大量相关信息值得放进同一个工作流里。
先给结论
如果只能选一个最值得用 1M 上下文的方向，那就是大型代码库上的软件工程，尤其是多步的智能体式编程，也就是 agentic coding。
原因很直接：Anthropic 将 Claude Opus 4.7 定位于专业软件工程和复杂智能体工作流 [4]。Claude API 文档也把生产级代码生成、调试、在复杂代码库中进行对话式查询列为典型用例，并明确提到 1M 上下文可用于大型文档和庞大代码库 [
13]。
需要加一句限定：现有资料并没有给出一个官方榜单，证明 1M 上下文的“第一任务”一定是某个具体场景。把大型代码库和 agentic coding 视为最强候选，是基于 Anthropic 对模型和用例的官方描述做出的谨慎判断 [4][
13]。
为什么大型代码库最容易受益
真实的软件项目里，一个 bug、一次重构或一次安全审查，很少只涉及一个函数。它可能牵扯多个模块、测试用例、配置文件、数据库 schema、接口文档、运行日志，以及前几轮修改留下的上下文。
当这些信息都相关时，1M 上下文的价值就很明显：模型可以在同一个会话里保留更多证据，而不是频繁依赖压缩摘要或人为来回补充。这与 Claude 文档中对 complex codebases 和 extensive codebases 的描述直接对应 [13]。
对 agentic coding 来说，这种优势更突出。一个智能体式编程流程可能包括：读取文件、调用工具、接收测试输出、修改代码、再次运行测试、分析日志，然后继续迭代。Claude 的上下文窗口文档说明，在包含思考与工具调用的配置中，输入 token 和输出 token 都会影响上下文窗口限制 [14]。而迁移指南也列出了 Opus 4.7 支持的工具调用、Files API、prompt caching 和 memory 等能力 [
16]。换句话说，流程越长、中间产物越多、上下文越相关，1M token 的工作空间就越有意义。
哪些任务最适合 1M 上下文？
| 适配度 | 任务 | 为什么 1M 上下文有用 |
|---|---|---|
| 很高 | 大型代码库调试、重构、代码审查 | Claude 文档提到生产级代码、调试、复杂代码库中的查询，以及 1M 上下文用于庞大代码库 [ |
| 很高 | 多步 agentic coding 和工具流 | Opus 4.7 被定位于复杂智能体工作流；工具调用、Files API、prompt caching 和 memory 让长会话更有发挥空间 [ |
| 高 | 长文档、PDF、多文件分析 | Claude 文档提到 1M 上下文用于大型文档；迁移指南也列出 PDF 支持和 Files API [ |
| 中高 | 经过筛选后的 RAG 或研究型工作流 | 1M 上下文可以容纳更多已筛选来源；关于 1M 上下文的开发者分析也常把它放在 RAG pipeline 和长时运行 agent 任务中讨论 [ |
| 低 | 短聊天、短文案、修改单个小文件 | 如果任务本身没有多少相关上下文需要保留，大上下文通常不是决定性优势；输入、输出和工具相关 token 仍然要计入上下文限制 [ |
三个容易误解的地方
1M 上下文不等于 1M 输出
迁移指南显示，Claude Opus 4.7 的上下文窗口是 1M token，但最大输出是 128k token [16]。如果你的目标是一次性生成超长文档，输出上限仍然要单独考虑。
大上下文不代表不用管理 token
没有长上下文溢价，并不等于可以不看 token 预算。Anthropic 说明，Opus 4.7 的新 tokenizer 在处理文本时，可能会使用约 1x 到 1.35x 的 token 数量，具体取决于内容；count_tokens 端点在 Opus 4.7 上返回的 token 数也可能与 Opus 4.6 不同 [1]。对于长工作流，最好重新核算 token，而不是默认旧 prompt 的规模和成本完全不变。
不要把所有数据都塞进 prompt
1M 上下文的意义，是让你能放入更多“相关”信息，而不是把整个仓库、全部日志或未筛选资料一股脑倒进去。使用工具时，输入、输出以及与工具调用相关的内容仍会影响上下文窗口 [14]。在 RAG 场景下，更合理的用法通常是放入更多经过筛选的高质量来源，而不是绕过检索和过滤步骤 [
3]。
一个快速判断方法
如果你的任务符合下面任意一种情况，就值得考虑 Claude Opus 4.7 的 1M 上下文：
- 需要模型阅读、比较或修改大型代码库的多个部分，尤其是改动会跨模块、测试和技术文档 [
13]。
- 智能体需要执行多轮步骤，调用工具、读取文件、分析测试或日志结果，然后继续改代码 [
14][
16]。
- 需要在同一会话中分析多个长文档、PDF 或已筛选文件 [
13][
16]。
- 如果把任务历史压缩成摘要会丢掉关键细节，你希望模型在决策前保留更多原始上下文。
反过来说，如果只是问一个简短问题、写一段普通文案，或修改一个很小的文件，1M 上下文通常不是选择 Opus 4.7 的核心理由。更稳妥的理解是：它是一张给大型代码库、长文档和长时间 agent 工作流准备的“大工作台”，而不是每个 prompt 都必须打开的默认模式。
