Opus 4.7 正在吸收你的 Harness

Opus 4.7 正在把过去需要外部 Harness 承担的一部分规划、验证和上下文管理能力吸进模型内部。问题不是要不要 Harness，而是哪些部分该交给模型。

Opus 4.7 正在吸收你的 Harness

自我验证、差异化能力削减，以及 Anthropic 这次发布真正留给构建者的问题

Anthropic 刚刚发布了 Claude Opus 4.7。更值得注意的不是它“变强了什么”，而是官方在发布说明里反复提醒：它在某些能力上其实不如另一款暂不公开发布的模型。

读到这里应该停一下——一家模型公司开发布会，结果不断指向一款被锁在保险库里的“更好模型”。这已经不是普通的产品更新，而是一个战略信号。

Opus 4.7 本身当然很强：基准测试可信、合作伙伴背书亮眼、能力增益也能量化。但比起模型内部的分数，更重要的是这次发布背后的结构变化。因为有两类原本属于你代码层的决策，正在被模型权重和训练流程接管。

在开始之前 🦸🏻‍♀️

如果这篇文章能帮助你构建更好的 AI 系统：

TL;DR

• Opus 4.7 的主要变化： 指令理解更字面化、视觉分辨率提升约 3 倍、推理循环里加入自我验证、新增 xhigh effort 档位、任务预算进入 beta、行为风格更直接、分词器更新后同样输入会映射成更多 token。
• 战略信号： Anthropic 在训练阶段刻意削弱了该模型的网络安全能力，这是生产级发布里首次明确承认“差异化能力削减”。
• 架构信号： 模型现在会在给出结果前先检查自己的输出。以前需要外部 harness 才能实现的一部分行为，现在开始内生到模型里。
• 统一模式： 这两类变化都把行为决策从运行时迁移到训练时：从构建者控制，转向模型公司控制。
• 对构建者的建议： 可以把模型自我验证视作第一道廉价过滤器，但不要交出最终验证权。便利是真实的，权威不能让渡。

第一节：到底变了什么

Opus 4.7 于 2026 年 4 月 16 日发布，距离 Opus 4.6 大约两个月。价格表没有变化：每百万输入 token 5 美元，每百万输出 token 25 美元。它不是一个全新层级，而是对 Opus 4.6 的直接替换，成为新的默认 Opus。

这些都很常规。真正不常规的，是下面这七点变化——其中至少两点看似只是“产品细节”，本质上其实是架构层变化。

指令更字面化，而且比以前更严格

Opus 4.7 更像“按条款执行合同”，而不像“会读空气的同事”。以前你写一句“把输出格式整理好”，Opus 4.6 往往会自动把这种要求推广到整段、整列表、整份输出；Opus 4.7 则更可能只严格执行你明确写出来的那一部分。

这既是升级，也是迁移痛点。

• 升级在于： 精细设计的 prompt 会得到更可预测的结果。
• 痛点在于： 过去依赖模型“脑补你的真实意图”的 prompt，如今会显得像坏掉了一样。

修复方式很简单，但也很枯燥：把范围写清楚。比如“把这个格式应用到每一节，而不只是第一节”。你需要少把它当成会心领神会的同事，多把它当成逐条执行条款的合同系统。

推理循环中的自我验证

这是本次发布里最值得架构师关注的变化。

Opus 4.7 不只是“计划 → 执行 → 汇报”，而是“计划 → 执行 → 自检 → 汇报”。这个验证步骤是新的。

Vercel 的工程团队说，它会在开始动手之前先对系统代码做证明；Hex 发现它在数据缺失时更愿意诚实承认，而不是编造一个“听起来合理”的兜底答案；Cognition 则观察到，它能持续工作数小时，并在难题前继续推进而不是轻易放弃。

这些现象，本质上都指向同一件事：过去要靠外部 harness 模拟的那类行为——重试、输出验证、完整性检查——现在有一部分开始驻留在模型内部了。

视觉分辨率提升到原来的约 3 倍

最大图像分辨率从长边 1568 像素提升到 2576 像素，约从 1.15 MP 提升到 3.75 MP。这个变化非常具体：计算机使用型 Agent 现在更容易读懂信息密集的截图，更可靠地从复杂图表中提取信息，也能以更接近 1:1 的像素坐标工作，省掉很多过去不得不做的缩放换算。

XBOW 报告称，他们依赖视觉能力的自主渗透测试工作，在内部视觉基准上从 54.5% 提升到 98.5%。这不是“略有改进”，而是“原来还不够上生产的能力，现在终于能上生产了”。

新的 xhigh effort 档位

effort 参数现在有五档：low、medium、high、xhigh、max。新增的 xhigh 位于 high 和 max 之间，也是 Claude Code 目前的默认计划档位。

Hex 的 CTO 甚至表示，低 effort 的 Opus 4.7 大致已经接近中 effort 的 Opus 4.6。也就是说，底线被抬高了。对于编码和 Agent 场景，Anthropic 建议至少从 xhigh 开始：它比 high 更有推理深度，又没有 max 那么高的延迟和成本。

任务预算进入 beta

新的 API 特性允许你为每个任务设置 token 上限。模型会在这个预算之内自行分配思考和行动。

这几乎是对 Agent 工作负载成本失控问题的正面回应：当模型可以连续跑几个小时，如果没有预算上限，你通常只会在账单出来以后才知道发生了什么。

行为风格变了

Opus 4.7 比 Opus 4.6 更直接，也更少“求认同感”。它用更少的 emoji，更少的迎合式措辞，也更愿意在技术讨论里明确反驳用户。

这未必是坏事。Replit 的总裁就说，他喜欢 Opus 4.7 在技术讨论里“会顶回来”，因为那能帮助他做出更好的决定。

但如果你以前做的是面向客户的对话产品，并且高度依赖 Opus 4.6 那种更温和、更安抚式的风格，那么迁移后你一定会感到差异。这不是 bug，而是系统 prompt 层面的重新调音。

新的分词器

价格没有变，但同一份输入，在新分词器下可能会变成原来的 1.0 到 1.35 倍 token 数。再叠加更高 effort 档位下更深的推理过程，实际成本很可能是“隐性上涨”的。

Anthropic 自己也在迁移文档里提醒：不要凭感觉切换，要拿真实流量测。

按设计削弱网络安全能力

这是整篇文章后半部分最关键的引子。

Opus 4.7 在 CyberGym 上的成绩略低于 Opus 4.6。Anthropic 公开承认，他们在训练阶段尝试了“差异化地削弱这些能力”。

这句话非常值得反复读：一家前沿实验室在发布旗舰模型时，明确告诉你，它刻意让模型在某项能力上变弱，而且这个干预发生在训练时，而不是运行时过滤器里。

这是一个全新的信号。

第二节：你的 Harness 正在被“吸收”

表面上看，Opus 4.7 有两项彼此独立的更新：

• 自我验证： 模型会在输出前先检查自己。
• 差异化能力削减： 模型被训练得在某些特定技能上更弱。

但如果从架构视角看，它们其实是同一个决定的两种外观。

以前，行为决策主要发生在运行时，也就是你自己的代码里。你想验证输出，就自己写 validator；你想限制模型参与某类高风险任务，就在 runtime 写分类器、policy check 或 prompt filter。

现在不一样了。验证逻辑的一部分进了模型权重里；能力边界的一部分也进了模型权重里。换句话说：模型公司正在替你做更多行为层的决定，而你自己代码里能决定的部分在变少。

这就是“吸收”。

我想强调的核心论点是：差异化能力削减和自我验证，是同一轮迁移的两个面向。前者在减能力，后者在加判断；它们都在收缩你对模型行为的控制权。

这并不意味着所有吸收都是坏事。有些真的有用；有些则是在错误的层级，由错误的角色替你做决定。真正的工作，是把这两类分开。

第三节：自上而下的吸收——那款他们不发布的模型

要理解为什么 Opus 4.7 的网络安全能力被刻意削弱，你得先知道另一件事：Anthropic 其实手里还有一款没公开放出的模型。

Claude Mythos Preview，按 Anthropic 自己的说法，是他们能力最强的模型。Opus 4.7 发布前一周，Anthropic 宣布了 Project Glasswing：围绕 Mythos 搭建的网络安全合作计划，首批就拉了 AWS、Apple、Cisco、Google、Microsoft、Nvidia、Palo Alto Networks 等多家机构参与。

官方给出的理由是：Mythos 已经能在主流操作系统、浏览器和关键基础软件里发现大量零日漏洞。这种能力太危险，不适合广泛发布。所以他们选择受限开放：只向特定合作伙伴提供研究预览，并通过配套机制逐步验证风险控制是否足够。

Opus 4.7 就活在这个决策的阴影里。Mythos 不能全面放出来，于是 Anthropic 选择发布一个加了更多护栏、并在训练期对网络安全能力做过削减的版本。

这不是一次普通发布，更像一次彩排。

差异化能力削减到底意味着什么

它的新意不在于“加了限制”，而在于限制被写进了训练过程。Anthropic 试图保留模型的通用智能，同时只削弱特定高风险能力。结果就是：编码更强、视觉更强、知识工作更强，但网络安全这条能力线被单独压低。

这是一把手术刀，而不是一把锤子。

你没法关闭它，也没法检查到底削弱了哪些子能力、削弱了多少，更没法在正当场景里自行恢复，除非去申请 Anthropic 的 Cyber Verification Program。也就是说，模型本来“可以拥有”的那一层能力，最终要不要开放给你，由模型公司决定。

如果把范围限定在前沿网络安全能力，这种做法未必不合理。Mythos 级别的漏洞链能力，一旦落到错误的人手里，确实会带来真实危险。

更难的问题

真正更难的问题不是“这一次削得对不对”，而是：这个机制未来会不会泛化到其他能力上。

Anthropic 决定削什么、削多少、谁能申请恢复、什么才算正当用途——这些判断全在黑箱里。你看不到边界，也很难测试它的盲点。

当目标明显符合公共安全时，我们很容易接受；可如果下一次被削的是某种商业上不方便的能力，或者政治上敏感的能力，或者因为模型公司签了某个你完全不知道的合同呢？机制还是同一个，只是目标换了。

所以问题不是“差异化能力削减是不是技术上做得到”，而是“它该由谁来治理”。目前的答案基本还是：由模型公司自己判断。

第四节：自下而上的吸收——会自我验证的 Agent

如果说能力削减是“自上而下的吸收”，那自我验证就是“自下而上的吸收”。原本属于构建者的事情，如今开始由模型接手，而且它带来的便利足够真实，所以你不能简单地把它一口回绝。

到底变了什么

Opus 4.7 在自己的推理循环里插入了一个验证步骤：计划、执行、验证、汇报。

这意味着模型在把答案说出口之前，会先尽量抓住自己能够发现的错误。Vercel、Hex、Cognition、Genspark 等团队的反馈，描绘的是同一类能力：它更能在提交前发现问题，而不是把问题甩给下游。

便利的一面

自我验证是真的有用。

如果模型能在输出前就抓住错误，你就少了一次往返：不需要先生成错误答案，再由外部 validator 打回重来。延迟更低、token 更省、harness 代码也会更简洁。一些过去只是为了防守“常见幻觉”的模板式检查，的确可以减少。

同权重问题

但难点也非常明显：生成步骤和验证步骤，用的是同一套权重。

如果模型在某一类 API 响应、某一类风险判断、某一类领域知识上存在系统性偏差，那么它的自我验证往往会继承同样的偏差。生成器会觉得答案“合理”，验证器也很可能觉得它“看起来没问题”。

这不是多写一句“请认真检查你的工作”就能彻底解决的事，而是结构性限制。

谁来定义“算验证过了”

退一步说，就算模型的自检能力很强，还有第二个问题：当模型说“我已经验证过了”，这句话到底意味着什么？

验证从来都不是通用操作，而是领域操作。

• 医疗系统要验证剂量，得看体重、肾功能、药物相互作用和过敏史。
• 法律系统要验证条款，得看法域先例、律所政策和客户风险偏好。
• 金融系统要验证模型输出，得看监管要求和机构内部阈值。

而通用模型的自我验证，最多只能保证“结构看上去合理”“算术没出错”“内部逻辑通顺”。这远远不等于你的领域里真正需要的验证。

所以，模型自我验证是必要条件，但不是充分条件。

模式其实和前面是同一个

差异化能力削减与自我验证，看似一个在“删能力”，一个在“加判断”，但本质上都是：模型公司在训练阶段替你预先决定了一部分行为边界。

前者决定模型不能做什么，后者决定模型应该检查什么。两个决定都被固化在你无法审计的权重里。

一个比较稳妥的立场

更平衡的答案不是拒绝自我验证，而是把它放到正确的层里去理解。

• 把模型自检当成最内层：它负责抓显而易见的错误、遗漏、算术失误和连贯性问题。
• 在外面包一层 harness 验证：检查你在生产里见过的系统性错误、领域规则、输出 schema。
• 再外面是业务逻辑验证：合规、政策、监管阈值、机构内部规则。

每一层都负责抓住内层漏掉的东西。模型自检已经成为系统的一部分，但绝不是系统的全部。

第五节：这对你的技术栈意味着什么

如果你今天就在用 Claude，或者正计划从 Opus 4.6 迁移过来，最重要的是把问题想实一点。

如何选 effort 档位

对于编码和 Agent 场景，优先从 xhigh 开始。Claude Code 默认就是这一档，很多官方和合作伙伴展示出来的“自我验证”特征，也主要是在这一档上体现出来的。

对于分类、抽取、路由等结构化工作，high 基本是智能敏感任务的下限。再往下，你省下的是 token，但失掉的往往正是你为 4.7 付费的那部分推理深度。

max 适合留给那些你已经试过 xhigh 仍然不够的任务，因为它带来的不仅是成本跳升，还有明显的延迟增加。

如何面对真实成本

标价没变，不代表实际任务成本没变。新分词器会让相同输入映射到更多 token，更高 effort 又让模型更愿意花 token 深想，所以你最好为同等工作量预留更高预算。

task budget 这时就非常关键了：给每个任务设上限，让模型在上限内自行调度。尤其是长时间运行的 Agent，没有预算约束时，真正的成本常常要到账单出来你才知道。

迁移时哪些地方最容易坏

有几类风险最值得先测：

• 宽泛 prompt 会坏。 以前靠模型自行补足意图的写法，现在更容易失效。
• 对话语气会变冷。 面向用户的聊天产品如果依赖旧风格，需要显式写清语气、emoji 和认同策略。
• 工具调用变少，可能被误判成“卡住”。 监控逻辑最好从“只看工具调用频率”改成“连推理输出一起看”。
• token 成本会悄悄上升。 不要只看单价，必须看真实流量下的任务级成本。
• 更长运行需要更长超时。xhigh 和 max 会想得更久，基础设施参数要跟着调。

你的验证姿态

无论你最后选哪个 effort 档位、走哪条迁移路径，有一件事都最好别放弃：保留你自己的验证层。

把 Opus 4.7 的自我验证看成一层内环，让它便宜地抓掉容易犯的错误；再用你自己的 harness 验证和业务验证，把那些真正影响你领域风险的规则握在自己手里。

一个非常值得做的实验是：拿你最难的真实工作负载，同时跑 Opus 4.7 xhigh 和你现有的验证层，记录三组数字：

1. 模型自己抓到多少错误；
2. 模型没抓到、但被 harness 抓到多少；
3. 两层都漏掉多少。

第一组告诉你“吸收”带来了多少便利，第二组告诉你现有 harness 还有多大价值，第三组则告诉你防线还缺在哪里。

第六节：回顾，以及下一步

最后带走三件事。

第一，Opus 4.7 真正重要的不是它的 benchmark，而是它的架构方向：模型开始吸收一部分原本属于你代码的职责，而模型公司也开始吸收一部分原本属于你的行为决策。

第二，这种吸收有两张脸：一张在减能力，一张在加判断。它们都在把权威从运行时挪向训练时，从构建者手里挪向模型公司手里。

第三，一个更稳妥的位置不是“全面拒绝吸收”，而是“接受它，但分层使用它”。让模型负责它擅长且便宜的那部分判断；把真正关乎你业务边界的控制权，继续留在自己的代码里。

这周最值得做的具体动作也许很简单：拿最难的一类真实任务，跑一轮 Opus 4.7 xhigh，保留现有验证层，然后把“模型自抓 / harness 抓到 / 全部漏过”的比例统计出来。那才是你该向团队汇报的数字，而不是单纯的 benchmark。

更大的问题则更难回避：一旦 Mythos 级能力最终进入开放模型，差异化能力削减就不再是开源社区能否选择的问题。Anthropic 在 Opus 4.7 上做的许多事情，更像是在为那一刻提前彩排。