Opus 4.7 先用 xhigh 跑代码和 Agent 长任务、用 high 做大多数高质量工作,并把目标、验收标准和验证步骤写清楚;从 4.6 迁移时不要依赖模型“自行补全”遗漏要求。
适合的任务:多步编码、代码审查、重复工具调用、长时间 Agent 运行、需要自检的复杂任务。
不适合的任务:简单分类、短问答、高吞吐低延迟任务;这些任务应先评估 low/medium。
适用的模型版本:claude-opus-4-7。
适用的客户端、Agent 或 API:Claude API、Claude Code,以及支持 effort 的 Anthropic 平台。
推荐的推理档位和参数:代码/Agent 从 xhigh 开始;一般高智力任务至少 high;成本敏感用 medium;max 只在自己的 eval 证明有增益时使用。xhigh/max 建议给足 max_tokens,官方文档建议可从 64K 起调。
以下是依据 Anthropic 官方 effort 和迁移说明组合的可复用模板(不是 Anthropic 逐字发布的完整 system prompt)。把尖括号字段替换为真实任务:
你是负责交付的实现 Agent。
目标:<用一句话说明最终可验收结果>
上下文:<仓库、输入文件、现有实现、相关约束>
硬约束:<不能改动的接口、文件、依赖、权限或时间限制>
验收标准:
1. <可观察的功能结果>
2. <必须通过的测试或检查>
3. <输出/文件格式要求>
请先检查现状并选择最小可行方案,然后执行任务。完成前逐项运行验收标准;
如果遇到工具失败、缺失数据或不确定假设,请明确指出并修复或请求补充,
不要用看似合理的占位结果替代验证。最后报告:改动、验证命令、结果、未解决风险。
This task involves multistep reasoning. Think carefully before responding.如果使用 API,按请求设置 output_config.effort(例如 "xhigh");如果同一长会话依赖 prompt cache,官方建议不要在缓存前缀中途改变 effort。
用同一组代表性任务分别跑 high 与 xhigh,记录成功率、工具调用数、token、延迟和人工返工量。
将 4.6 时代的 prompt 原样跑一遍,标注“旧模型遗漏而新模型严格执行”的行为差异。
按模板补全目标、硬约束、验收和失败处理,再重复相同任务。
对代码 Agent 保留工作树快照、测试日志和最终 diff;不要只根据模型自述判断完成。
若 xhigh 的质量增益不足以覆盖成本,逐步降到 high/medium,不要以 max 作为默认兜底。
Anthropic effort 文档:Opus 4.7 API 默认 high;代码与 Agent 推荐从 xhigh 开始,high 是大多数 intelligence-sensitive 工作的最低起点;medium 用于节省成本;max 留给真正的 frontier 问题。
官方发布页:Opus 4.7 的 xhigh 位于 high 和 max 之间;Claude Code 默认提高到 xhigh;公开 beta 的 task budgets 可引导长任务 token 使用。
官方文档还说,Opus 4.7 比 4.6 更严格地遵守 effort,尤其是 low/medium;若低档位的复杂任务过浅,应提高 effort,而不是用提示绕开模型行为。
从 4.6 迁移时,官方报告新 tokenizer 可能使同样输入映射为约 1.0–1.35× token,且高档位后续 Agent turn 可能思考更多;应在真实流量上测成本。
上述模板是基于官方原则的组合模板,不是 Anthropic 官方完整 prompt;需要按产品和工具 schema 改写。
effort 控制整次响应的 token 使用,包括工具调用和 thinking(启用时),不等于可见答案长度控制;需要更短输出时另写长度要求。
max 在多数工作负载上可能只带来较小质量增益,却显著增加成本;必须以自己的 eval 决定。
4.7 变得更“按字面执行”后,旧 prompt 中依赖模型自行补全的隐含约束可能失效。
官方 effort 建议是 “Start with xhigh for coding and agentic use cases”;发布页还提醒旧 prompt 和 harness 应重新调校,因为新模型会更严格地按指令执行。
Claude Opus 4.7