2026 年 9 月 23 日

1 / 3

Claude Opus 5.5 与 GPT-6 Sol/Luna 同日发布：厂商 benchmark 已经越来越难脱离 effort、harness 和成本单独阅读

9 月 22 日，Anthropic 发布 Claude Opus 5.5，几小时后 OpenAI 发布 GPT-6 Sol 和 GPT-6 Luna。两家公司这次都把重点放在同一个问题上：能力继续提升的同时，减少完成一项真实任务需要付出的推理成本。Anthropic 给 Opus 5.5 的 API 定价是每百万 token 4 美元输入、20 美元输出，比 Opus 5 的 5/25 美元低 20%；cache read 从 0.50 美元降到 0.20 美元。公司称在默认设置下，典型 workload 的总成本下降约 40%，输出速度提高超过 30%。Anthropic 发布说明

OpenAI 的降价更大：GPT-6 Sol 为 2 美元输入、10 美元输出，Luna 为 0.10/0.50 美元，相比 GPT-5.6 对应层级的促销价格均下降约 50%。Sol 和 Luna 已进入 API、Codex 和 ChatGPT Work；OpenAI 同时把 GPT-6 的 cached input 折扣维持在约 90%，并加入 cache diagnostics 和显式 breakpoint，让长 Agent trajectory 可以更主动地复用 prompt prefix。OpenAI 发布说明 API Changelog

真正有意思的是两份发布材料放在一起以后，benchmark 表格开始出现一种很典型的现象：同一个 benchmark 上的“模型成绩”越来越难被视为一个固定值。Anthropic 在 Terminal-Bench 4.0 报告 Opus 5.5 xhigh effort 为 66.4%，Fable 5.1 为 55.8%，Opus 5 为 52.3%，并引用 OpenAI 报告的 GPT-6 Astra high-effort 57.9%。Anthropic还给出了标准误：Opus 5.5 约 ±2.6 个百分点，其他 Claude 模型约 ±1.6–2 个百分点。其测试使用 Claude Code harness；生产 safeguards 保持开启，如果安全系统介入，部分 cyber、biology 和 frontier-LLM-development 任务会由较弱模型接手。

OpenAI 的发布材料则大量把 effort 和 cost-per-task 一起纳入比较。在 AutomationBench 1.0.6 上，GPT-6 Sol xhigh 为 33.2%，而 Claude Opus 5 max 为 26.9%；OpenAI 估算前者每任务成本 0.27 美元，约为后者的 9%。但同一张表还注明，Claude Fable 5.1 的公开成本没有计入约 40% 任务发生的 Opus 5 fallback，因此这个成本数字本身也不完全可比。OpenAI GPT-6 Sol/Luna

更有意思的是 AutomationBench 在 Anthropic 自己的发布页上出现了另一组数字：Opus 5.5 为 40.0%，GPT-6 Astra 为 41.4%，Opus 5 为 26.9%。Anthropic说明这些结果由 Zapier 执行，Opus 5.5 没有使用 fallback；safeguard 一旦介入就直接计失败。这里并不存在简单的“谁的数据是真的”问题。不同模型的 effort、fallback、safeguard、生产版本、token budget 和 harness 组合已经成为被测系统的一部分。Anthropic Opus 5.5 benchmark 说明

这对模型评测有一个很实际的变化：过去 leaderboard 常把 model_name → score 当作基本数据结构，现在更合理的单位越来越接近 model + effort + harness + tools + safeguards + fallback policy + runtime version → score, cost, latency。尤其是 Agent benchmark，同一底模通过不同 harness、缓存策略和工具调度方式运行，测出来的已经是不同系统配置。

Opus 5.5 自己也给出了一个值得注意的反例。Anthropic 在发布文中主动写道，在当前能力水平上，benchmark margin 已经越来越难预测真实使用差异；虽然 Opus 5.5 在不少表格上超过 Fable 5.1，公司自己的使用体验却认为两者实际差距比 benchmark 显示的小。这不是独立验证，但至少说明模型厂商自己也开始遇到“几个百分点的 leaderboard 差距究竟有多少实际意义”的问题。

两家公司这次同时强调 cost-per-task，也使一个过去经常作为附属信息的指标变得更重要。对于长时间 coding 或 business Agent，一次任务可能产生数十万甚至数百万 token；模型单 token 便宜、trajectory 更短、cache hit 更高都能降低最终成本。因此比较 Agent 时，只报 success rate 或只报 API token price 都会丢失一部分真实差异。更完整的评测至少需要把 success、token usage、wall-clock time 和最终 task cost 放在同一个实验记录里。

2 / 3

补报（9 月 21 日）：AWS Strands Harness 把“Agent 框架”进一步拆成可替换的模型、工具、上下文与运行时

AWS 在 9 月 21 日开源 Strands Harness。它和 Strands Agents SDK 的关系可以理解为：SDK 提供构建 Agent 的组件，Harness 则提供一个已经组装好的、可以直接执行任务的 Agent runtime。项目以 Apache 2.0 发布，Python 和 TypeScript 都可使用，并明确支持不同模型和云环境，而不是绑定单一 Bedrock 模型。Strands Harness GitHub

这类 harness 最值得看的地方通常不是“支持多少工具”，而是它怎样管理不断增长的 trajectory。一个 coding 或 research agent 连续运行几十轮以后，context 中会累积文件内容、shell 输出、tool result、计划、失败尝试和历史消息。如果每一步都把全部内容重新塞给模型，成本和延迟会持续增长；如果压缩过度，又可能丢掉完成任务需要的状态。

Strands Harness 因此把 context management 做成运行层的一等组件，并把 model、tool、memory、hook、event loop 等拆开。AWS 报告的内部实验称，在相近准确率条件下，其默认 harness 相比测试中的其他配置可减少约 28% token cost；这个数字目前主要来自项目方自己的 benchmark，并不足以证明换到不同模型、任务或工具集合后仍保持同样收益。项目仓库与说明

这个设计与近几个月 Agent eval 中不断出现的 harness sensitivity 是同一个问题的工程侧版本。Agent 的最终表现已经不只来自底模：什么时候截断 observation、哪些历史进入 context、失败后是否自动 retry、tool schema 怎样表达、是否允许 subagent、何时压缩 memory，都会改变 trajectory。对于一个能力相对有限的小模型，这些差异尤其可能决定任务最终能不能完成。

因此比较 Agent 模型时，harness 最好像 tokenizer、sampling parameters 一样成为正式实验元数据。更进一步，可以固定 model 后交换 harness，再固定 harness 后交换 model，形成二维实验。前一组告诉我们运行框架能把同一个模型推到什么程度，后一组才更接近“模型能力差异”。如果两种排序明显不同，本身就是很有价值的结果：说明 benchmark 正在测量 model × harness interaction，而非一个可以脱离运行环境存在的单一模型能力。

3 / 3

Snorkel 的业务转向：RL 时代的数据产品开始从“样本”变成环境、任务与 grader

Snorkel AI 9 月 22 日披露的新融资首先是一条公司新闻，但它的业务结构比估值本身更值得看。公司成立时的核心产品是 programmatic labeling：让专家写 labeling functions，用弱监督批量生成训练标签。现在 CEO Alex Ratner 向 Reuters 描述的主要需求已经明显变化——frontier labs 要的不只是带标签的静态 dataset，还包括 reinforcement-learning environments、任务设计和 grading rubrics。Reuters

这和当前 post-training 的数据形态变化有关。SFT 可以把训练单位理解为 input → desired response；Agent RL 需要的单位更接近一个可运行问题：初始状态是什么，模型能够调用哪些工具，环境怎样响应，什么状态算成功，失败怎样评分。生成一万条“答案”与生成一万个能够稳定运行、自动判分的任务环境，工程性质完全不同。

Snorkel 现在的做法是让 coding、法律、医学等领域专家主要负责 scenario、task 和 rubric，再让大量专用 AI 系统承担部分生成和 QA。Ratner 的说法很明确：可预见时期内，有价值的训练数据仍会包含人类输入，但要达到需要的复杂度和规模，又必须大量使用 synthetic 与 automated approaches。这一判断来自公司自身业务观察，不等于已经有公开实验说明某种人机比例最优。

对于 Eval 团队，这种变化其实很熟悉，因为 benchmark 和 RL environment 的生产正在逐渐使用相似的基础设施：都需要任务、工具、环境状态、reference behavior、grader 和质量控制。区别主要在用途。Eval 要尽可能避免训练污染并保持测量稳定；RL environment 则希望模型反复进入环境、产生 trajectory，再把 reward 反馈用于学习。同一个高质量任务如果既进入训练又进入最终评测，后者的解释力就会迅速下降。

因此未来讨论“训练数据规模”时，仅统计 token 或样本数会越来越不完整。对于 Agent post-training，更有解释力的单位可能是独立环境数量、可验证任务数量、trajectory diversity、grader reliability，以及模型能够产生多少真正不同的状态访问路径。Snorkel 的业务变化至少提供了一条产业侧证据：这些东西已经开始成为可以单独出售的数据产品。