2026 年 9 月 23 日

1 / 3

GPT-6 Sol/Luna 与 Claude Opus 5.5 同日发布：模型价格正在从“每 token 多贵”转向“一项任务最终花多少钱”

9 月 22 日 OpenAI 和 Anthropic 几乎同时更新主力模型线，表面上是一轮熟悉的模型发布，细看两家公司选择展示的数据，会发现价格比较正在发生变化。OpenAI 给 GPT-6 Sol 的输入/输出价格定为每百万 token 2/10 美元，Luna 为 0.10/0.50 美元；Anthropic 给 Opus 5.5 定价 4/20 美元。单看 token price 已经可以看到明显降价，但两家公司发布材料都花了相当多篇幅讨论另一种单位：完成一个任务的成本。OpenAI GPT-6 Sol/Luna Anthropic Opus 5.5 报道

原因在 Agent 场景尤其明显。一次长任务的成本大致取决于 token 单价、trajectory 长度、reasoning effort、失败重试以及缓存命中情况。一个每 token 更贵的模型，如果能用更短 trajectory 一次完成任务，最终可能反而更便宜；一个便宜模型如果不断重试，也可能迅速吃掉价格优势。因此 OpenAI 在 AutomationBench 上同时报告 score 和 cost per task：GPT-6 Sol 在 xhigh effort 下报告 33.2%、每任务约 0.27 美元；Claude Opus 5 max 在同一张表中为 26.9%，估算成本约为前者 11.1 倍。这里的数字属于 OpenAI 报告的测试结果，并不能脱离它采用的模型版本、effort 与 harness 单独理解。

这种条件依赖在同一发布页上就能看出来。OpenAI 明确注明，AutomationBench 中 Claude Fable 5.1 约 40% 的任务触发 Opus 5 fallback，而公开成本数字没有完整计入这部分费用；在 OSWorld 2.0 offline 上，GPT-6 Sol xhigh 报告 60.5%，Claude Opus 5 medium 为 60.3%，但 OpenAI强调前者估算 task cost 低约 80%。这里比较的实际上已经是 model + effort + fallback policy + harness + pricing 形成的运行配置。OpenAI benchmark 说明

缓存又进一步改变了这笔账。GPT-6 的 cached input 读取价格折扣达到 90%，OpenAI 这次还允许在不破坏既有 cache prefix 的情况下改变 reasoning effort 或启停工具，并提供显式 breakpoint 控制缓存前缀。GitHub 向 OpenAI 提供的数据称，这类改进过去数月让 Copilot 数十亿次 OpenAI 模型请求中需要重新处理的 prompt token 比例下降超过 50%。这属于 GitHub/OpenAI 报告的生产数据，并没有告诉我们所有 Agent workload 都能获得同样收益，但它解释了为什么长上下文 Agent 的经济性越来越取决于 cache architecture，而不只是模型报价。

因此今天看模型价格表，最值得保留的至少有两层数据：API 的 input/output/cached-input 单价是一层；在固定任务、固定 harness 和固定 effort 下测出来的 success、token consumption、latency、retry 与最终 cost-per-successful-task 是另一层。后者更接近真正部署一个 Agent 要支付的成本，也更容易揭示一个看起来便宜的模型究竟是真的高效，还是只是 token 标价低。

这也解释了为什么今天两家公司的 benchmark 很难简单横向抄成一张排行榜。厂商自报成绩仍然有信息价值，但模型越来越像一个可配置系统：effort 可以变化，工具和 fallback 可以变化，缓存会改变成本，安全系统甚至可能改变某些任务最终由哪个模型执行。要理解发布带来的实际变化，模型名称已经只是实验条件中的一个字段。

2 / 3

Cache-to-Cache：多模型系统开始尝试绕过文本，直接传递 KV Cache 中的内部表示

今天重新进入技术讨论视野的一项工作是清华大学等团队的 Cache-to-Cache（C2C）。论文最初在 2025 年提交、2026 年 3 月更新并被 ICLR 2026 接收，因此研究本身不是今天的新论文；这次的新变化来自项目团队 9 月更新的工程路线：他们计划在现有开源实现基础上加入 agent-managed KV-Cache 及相应 serving system。它值得关注的原因，是它针对多模型系统中一个非常具体的成本来源：模型之间为什么一定要“用文字聊天”。C2C 论文 项目仓库

传统 multi-agent 或 model routing 系统中，模型 A 做完一部分工作，会生成文本交给模型 B。这个过程对人类很自然，对模型却意味着一次信息压缩：A 内部已经形成的表示必须经过 token generation 变成文字，B 再把这些 token 做 embedding 和 attention，重新构建自己的内部表示。中间文本既增加 autoregressive generation latency，也可能丢失没有被语言明确表达出来的信息。

C2C 的办法是利用 Transformer 推理过程中本来就存在的 KV Cache。KV Cache 保存 attention 层此前 token 的 key/value 表示，使模型生成下一个 token 时无需重新计算整个上下文。研究团队训练一个较小的 projector，把 source model 的 KV Cache 映射到 receiver model 的表示空间，再通过可学习的 gating 决定哪些目标层应该融合这些表示。训练时 source 和 target 模型本身保持冻结，只更新这个中间 projector。C2C GitHub

这件事技术上并不像“把一个模型的 cache 文件复制给另一个模型”那么简单。不同模型可能有不同 hidden dimension、层数、attention head 数量和 tokenizer，因此它们的 KV 表示并不天然兼容。C2C 的 projector 实际承担了一个跨模型语义翻译层。项目目前公布的预训练组合包括 Qwen3-0.6B 接收来自 Qwen2.5-0.5B、Llama-3.2-1B、Qwen2.5-Math-1.5B、Qwen3-4B 等模型的信息，也包含 Qwen3-8B 与 Qwen2.5-7B 的组合。

论文报告，在其测试组合和任务上，C2C 相比单模型平均准确率提高 6.4%—14.2%，相比 text communication 高约 3.1—5.4 个百分点，同时平均 latency speedup 约 2.5 倍。这些数字来自作者实验，目前不能外推到任意 frontier model 或生产 Agent；尤其 projector 本身需要针对模型组合训练，因此它不像普通文本协议那样可以让任意两个闭源 API 临时协作。arXiv 论文

但项目下一步计划加入 agent-managed KV-Cache 和 serving system，使这个思路从一次性的模型融合实验开始靠近 Agent runtime：Agent 可以决定何时保留、共享或转移某段内部 cache，而不是每次都把状态重新写成文字。如果这一方向能够扩展到更大的异构模型，它会改变 multi-agent architecture 中一个长期默认的假设——模型之间的通信协议未必必须等同于人类可读语言。

这同时带来新的工程和安全问题。文本 handoff 天然可记录、可审计，也容易让开发者检查 Agent A 究竟告诉了 Agent B 什么；latent representation 的传递则更难解释。跨模型 cache 的生命周期、访问权限、显存占用以及污染后的状态恢复，也会成为 serving layer 的新问题。所以 C2C 当前最有价值的地方，还不是证明未来 Agent 都应该放弃文本，而是把“模型间通信层”本身变成了一个可以单独优化和实验的系统组件。

3 / 3

Meta Muse 的“human concierge”：个人 Agent 的完成率开始依赖隐藏在模型之外的执行层

Meta 9 月 8 日推出 Muse 时，把它描述为能够主动完成购物、沟通等事务的 personal AI agent。官方介绍尤其强调基础设施：每位用户的 Muse 运行在专门的 Secure VM 中，未来还计划推出由用户密钥保护、Meta 本身也无法读取内容的 Confidential VM。这种设计把个人 Agent 描述成一个持续拥有用户上下文、可以代表用户行动的软件系统。Meta Muse 发布说明

Reuters 今天披露的内部测试给这个产品增加了一个很有意思的执行层：Muse 某些电话任务并非完全由 AI 完成，而是会路由给人类承包商充当“human concierge”。例如用户要求 Agent 打电话完成某项现实事务，最终真正与商家通话的人可能是后台工作人员。报道依据 Meta 内部帖子，因此这里能够确认的是 Meta 测试过这种机制，并不能据此推断 Muse 的所有电话任务都依赖人工。Reuters

这件事的重要性不只在于“AI 后面还有人”。现实世界 Agent 面临一个软件 Agent 很难完全控制的长尾：电话无人接、对方口音难识别、商户提出计划外问题、网站验证码、线下身份验证、付款异常。产品团队可以选择让 Agent 失败，也可以在低置信度状态下切换到另一模型、另一工具，最终甚至切换到人类。

于是所谓“Agent task success rate”开始包含一组不同性质的能力。一个系统可能有 80% 的任务完全由模型和工具完成，15% 通过人工 fallback 完成，5% 最终失败；另一个系统可能有 85% 全自动完成、15% 失败。如果只报告最终 95% 对 85% 的完成率，用户体验层面的前者确实更可靠，但它不能直接证明前者的模型或 Agent policy 更强。

Muse 还把另一个问题带到台前：用户需要知道谁在执行任务。Meta 官方对 Muse 的宣传重点之一是 privacy-preserving infrastructure，而 Reuters 报道称，公司内部对 human concierge 也出现了隐私顾虑。对于能够接触个人通信、行程、购买意图甚至代替用户打电话的 Agent，人工 fallback 是否发生、人工能够看到什么上下文、哪些信息会被暴露，都会成为产品架构的一部分。

因此个人 Agent 真正走向现实任务以后，“模型能力”只是最终产品能力的一层。模型之上还有 orchestration、tool access、retry、verification、human fallback 和权限控制。Muse 今天提供的案例很具体：当 Agent 从回答问题走向代表用户办事，最终交付的是一条完整执行链，而这条链可能同时包含模型、软件工具和人。

1 / 1

IFEval：为什么“指令遵循”可以不用 LLM Judge 来打分

IFEval 是一个很适合作为 Eval 入门坐标的 Benchmark。它在 2023 年由 Google Research 等团队提出，问题很明确：我们经常说一个模型“更听指令”，但如果让人工逐条评价，成本高且难复现；如果再找一个大模型来判断，又把结果绑定到了 Judge 的偏差和能力上。IFEval 因此主动缩小问题范围，只测试那些能够用程序客观验证的 instruction。原论文整理了 25 类可验证约束，构造约 500 个 prompt；当前 EvalScope 的实现记录为 541 个样本。↗ ↗ IFEval 原论文

所谓“可验证”，指的是答案出来以后，不需要判断文章写得漂不漂亮，只要运行一个确定的 checker 就能知道有没有做到。例如要求“至少写 300 个词”“不能出现逗号”“必须出现指定关键词”“必须包含三个特定格式的章节”。官方代码的输入很简单：一边是带有 instruction ID 和约束参数的 prompt，一边是模型 response，然后由对应规则执行检查。原注 Google Research IFEval 代码与数据

这带来一个很重要的评分设计。常见实现会同时报告 prompt-level 和 instruction-level，并各有 strict / loose 两种口径。prompt_level_strict 要求一道题里的所有约束全部满足，少一条整题就失败；inst_level_strict 则把每一条 instruction 分开计分。Loose 版本会给予一些格式上的容忍。以一个沿用真实 IFEval 任务结构的简化例子来说：题目要求“300 词以上、不要使用逗号、至少有三个指定格式的小节”，模型完成了长度和小节要求，却用了逗号，那么 instruction-level 可以表现为三条满足两条，而 prompt-level strict 直接记为失败。EvalScope 当前也把 prompt_level_strict 作为主要指标。↗ EvalScope 的 IFEval 实现说明

这两个粒度回答的是不同问题。Instruction-level 更适合诊断：模型究竟在哪类约束上失手。Prompt-level strict 更像一次完整交付：假如五条都是硬性要求，满足四条并不等于业务可以使用。这也是为什么看同一个 IFEval 结果时，不能只说“准确率多少”，还要先问报告的是哪一种 aggregation。一个模型可能大部分单项约束都会做，但随着一道题叠加更多要求，完整通过率明显下降。

IFEval 的另一个优点是 evaluator 很透明。没有隐藏 Judge 的审美，也没有“GPT-4 认为这篇回答是 7 分”的随机性；同一 response 交给同一个 checker，原则上应该得到同一结果。这对于比较小模型尤其有用，因为模型间只有几个百分点的差异时，评价器本身如果具有较强噪声，会直接干扰排序和后训练判断。IFEval 将评价器的不确定性压得很低，同时给出了很容易自动扩展的任务形态。

但它测量的范围也需要看得很窄。通过 IFEval 说明模型能够遵守一些显式、可程序验证的语言约束，并不能推出模型已经理解了真实业务规则，更不能推出最终产物有业务价值。例如一篇答案可能恰好 300 词、没有逗号、格式完全正确，但事实全部错误；IFEval 的 checker 仍然可能认为这些 instruction 已经满足。反过来，很多真实要求——“不要改变原意”“证据是否真的支持判断”“这个摘要够不够完整”——很难写成这样的确定性规则。

这也是后来扩展工作的方向。Multi-IF 把 IFEval 式的 instruction following 延伸到多轮和多语言，构造了 4,501 个三轮对话，覆盖英语之外的 7 种语言。作者发现，模型随着轮次增加更容易违反要求，例如论文报告的 o1-preview 平均准确率从第一轮的 0.877 降到第三轮的 0.707，而且中文、俄语、印地语等非拉丁文字语言的错误率整体更高。这里改变的已经不只是“多几个约束”，而是旧要求需要跨轮持续有效：评测单元从一次 response 开始向 trajectory 靠近。↗ Multi-IF 论文

IFEval 还有一个很实际的使用提醒：自动评分并不意味着 Benchmark 本身没有数据质量问题。2026 年 Google Research 仓库里仍有人报告 prompt 与实际 kwargs 不一致的样本，例如文字要求至少 400 词而参数记录成 336，以及要求三个关键词但 checker 参数只保存两个。这类问题会造成一种很隐蔽的 Eval 错误：模型实际上按照题面做对了，却被错误的机器规则判错，或者反过来。因此复现一个公开 Benchmark 时，版本、数据快照和 checker 代码应一起锁定；“我们跑的是 IFEval”本身还不足以说明两组成绩完全可比。↗ Google Research IFEval 数据问题记录