Anthropic 于 2026 年 2 月 5 日发布 Claude Opus 4.6，官方强调更强的编程、长时间代理任务、代码审查与调试，并为 Opus 级模型提供 1M token 上下文测试能力，同时引入 adaptive thinking、effort 控制和 compaction。本文不会把官方 benchmark 排名重复成独立结论；真正值得关注的是这些能力是否能在自己的仓库里减少遗漏、保持任务状态并交付可验证修改。

长上下文不是把仓库全部塞进去

更大的窗口降低了“关键文件根本放不下”的限制，却没有取消检索和信息组织。把整个仓库、构建产物、重复日志和 vendor 代码一次提交，会增加成本、延迟和注意力竞争。先用符号、依赖图、搜索和测试失败定位候选文件，再给模型可解释的相关上下文。

建立长上下文评测时，不只放一个隐藏字符串让模型找。要求它跨多个文件追踪接口、找出相互矛盾的约束、修改正确位置并解释未改文件。随着上下文从小到大，记录召回、错误引用、无关修改、延迟与 token。1M 是 beta 容量声明，不是每个位置具有相同可靠性的承诺。

代理编程要按完整闭环评分

代码生成漂亮不等于任务完成。一个真实样例包含理解 issue、读取规范、最小修改、运行测试、解释失败和展示 diff。评分应包括：是否修复目标、是否引入回归、是否遵守仓库约束、测试证据是否真实、遇到不确定性是否停下。将“第一次回复正确率”和“允许工具迭代后的最终成功率”分开。

长时间任务需要 checkpoint。每完成一个阶段，保存计划状态、已修改文件、运行命令、失败与下一步。compaction 可以帮助控制上下文，但压缩后的摘要仍需通过可观察事实校验；文件、Git diff 和测试输出才是权威状态，不能让摘要覆盖磁盘现实。

Effort 应按风险分配

官方指出 Opus 4.6 在困难任务上更深入思考，同时简单任务可能增加成本与延迟。分类、格式化和明确小修复可从较低 effort 评测；跨模块迁移、复杂调试和安全审查再提高。不要把最高 effort 设为所有请求默认值，也不要在没有本地评测时把 adaptive thinking 当作成本自动优化器。

建立路由规则时记录任务类别、选择的 effort、结果和人工纠正。若高 effort 只让回复更长而成功率不变，就降低；若它减少多轮返工，应计算完整任务成本，而不是只比较单次 token。

多代理增加协调风险

官方公告提到 agent teams 等产品能力，但多代理是否有效取决于任务可分解性。独立研究或测试可并行；多个代理同时改相同核心文件会制造冲突。每个子任务需要输入、输出、权限和停止条件，一个协调者负责合并与最终验证。

代理不得从网页、issue 或代码注释接受扩大权限的指令。默认工作区内最小写权限，安装依赖、网络访问、发布和删除需要单独政策。模型能力更强只会提高它完成已授权操作的能力，并不会自动判断业务授权。

建立自己的对照组

选取 30–50 个代表性任务，冻结仓库提交、工具、prompt 与允许时间。对比当前模型与 Opus 4.6，在相同 harness 中多次运行。报告任务级分布、失败类型和人类复核时间，不只报告一个平均分。官方 system card 用于了解模型测试范围与限制，本地评测负责产品选择。

隐私、数据保留、地区可用性和价格应按实际账户与当前文档核对。模型别名可能变化，生产评测记录具体 model id、配置和日期。

结论

Opus 4.6 值得关注的不是“窗口更大”这一行参数，而是长上下文检索、工具迭代与验证能否形成更稳定的工程闭环。保持选择性上下文、按风险分配 effort、用磁盘与测试作为状态真相，并在同一 harness 做对照。只有当失败率和人工纠正真实下降，代理能力提升才转化成生产价值。