Opus 5.5规划、Haiku 5.5执行：100K Token处40倍价差崩塌

一个理论上成立两年、实践中却一直崩溃的分层架构，终于有了能用的执行层。但账单上藏着陷阱。

文章主题配图

问题：执行层为何长期缺位

“贵模型规划、便宜模型执行”这个思路已经流传两年了。它反复失败在一个不起眼的地方：便宜模型根本执行不了。把任务拆干净、把步骤传下去，执行层到第三步就塌了。于是团队做了最合理的选择——全放到贵的那层跑。

Anthropic公布了一个直接回应这一痛点的数字：Claude Haiku 5.5在Terminal-Bench 4.0上达到39.2%，而上一代Haiku 4.5是0.0%。

零。不是“弱一些”，不是“简单场景勉强可用”。上一代小模型完全无法完成这类任务。从0.0跳到39.2不是渐进式增益，而是一项能力越过了阈值——整套设计模式一直在等这一刻。

不过在核对官方文档时，还有第二个数字几乎不见于报道，而且它恰恰站在这个架构的对立面。

Terminal-Bench 4.0 是一个面向命令行代理（agentic CLI）的评测集，任务要求模型在真实终端环境中完成多步操作——读取文件、运行脚本、根据中间输出调整指令、修复报错。它考察的不是单次问答质量，而是长程执行中的连贯性与自纠错能力。这正是分层架构最脆弱的一环：规划层只需输出一次任务拆解，执行层却要在几十轮工具调用中保持一致。因此该基准上从 0.0% 到 39.2% 的跃升，某种意义上等同于“执行层是否可用”的开关被打开。

测试环境

项目	值
核对日期	2026-10-14
端点	`https://api.crazyrouter.com/v1`（OpenAI兼容）
模型ID	`claude-opus-5-5`、`claude-haiku-5-5`

两个模型ID都是不带日期后缀的固定快照，不会悄悄切换到更新权重——升级必须改代码。

值得留意的是两者在规格表上的相似程度：都是1M token上下文、128K输出、知识截止2026年6月、都支持图像输入和工具调用。Haiku 4.5还停留在200K上下文和64K输出。**在这一代，选择便宜层级不再意味着牺牲容量。**剩下只有价格和延迟档位（Moderate对Fastest）的区别。

迁移步骤

**第一步：确认可用性。**动手改造前先确认路由承载两个层级。2026-10-14查询时，claude-opus-5-5、claude-haiku-5-5和claude-haiku-4-5都在列表中。相同的base URL和请求形式不代表每个依赖的参数都会被透传——这需要单独验证。

**第二步：做拆分。**机械层面改动很小，只有model字段在规划调用和执行调用间不同。内容层面才是真正的工作：规划意味着同时权衡多条候选路径并在不确定下决策；执行意味着把一个已确定的步骤精确做对。单模型兼顾两者，就是在两个不同的能力画像之间求平均。

**第三步：迁移时注意思考模式。**这是最常见的坑。手动Extended Thinking（thinking.type: "enabled"加budget_tokens）在Opus 4.6和Sonnet 4.6上已标记过时，新模型完全不接受。现在由effort参数控制，两个模型默认都是medium。Opus 5.5的思考模式还无法关闭。

验证与排查：隐藏的计费陷阱

分层架构的效果是可测的。Cognition直接测试过：以Haiku 5.5作为执行副手、Opus 5.5作为规划者，团队在Devin Fusion中报告FrontierCode值达到66.2，同时每任务成本和延迟都有下降。

这是特定配置下的客户报告。没有可比的Opus 5.5单独值，无法据此推断组合超过任一单模型。

然后是那个看不见的错误。

Haiku 5.5是当前价目表中唯一按提示长度计费的Claude模型。10万输入token以下：每百万输入0.10美元、输出0.50美元。超过后：0.50美元和2.50美元——五倍费率，且适用于整个请求，输出和缓存都算在内。阈值按单次请求评估。10万token还在便宜档，100001就不是了。

想想执行子代理实际在做什么：它在累积。每一轮都带着此前的历史、读过的文件、工具返回。正是这个模型被宣传要承担的负载，最容易无声漂过边界——而响应中没有任何东西透露正在按哪档计费。

我算过一次：每天500个任务、22个工作日、每个8万输入token加2千输出token——Haiku 5.5约99美元/月，Opus 5.5约3960美元。输入涨到11万token，前者变成约660美元；Opus 5.5在同样11万输入下是5280美元——同等负载下价差缩到8倍。

官方节省计算也系于这个阈值：约90%的Haiku 4.5请求在10万token以下。Anthropic还提到平均运营成本低约75%。这个数字无法仅凭请求占比算出，缺token权重。它描述的是旧的流量模式，不是你想构建的代理循环。

对策不是选模型，而是上下文纪律：精简每个子代理携带的内容，发送前预估，拆分接近上限的任务。一段预检就能做到：

SCHWELLE = 100_000
PUFFER = 0.9  # 留出安全距离
def waehle_modell(eingabe_token: int) -> str:
    if eingabe_token > SCHWELLE * PUFFER:
        return "claude-opus-5-5"   # 或：先拆任务
    return "claude-haiku-5-5"

放弃这一步，就会落进只便宜8倍的档位——而你已经向财务报了40倍。

另一点排查提示：缓存折扣因模型而异。Opus 5.5缓存读取为基础输入价的5%，Haiku 5.5是10%，Fable 5.1只有2.5%。长期测算不能套用统一系数。

上下文累积为何会撑爆阈值：在代理循环中，每一轮请求通常都会把此前所有对话、文件片段和工具返回重新塞进输入。假设单轮新增 8K token，到第 13 轮时输入就已接近 10 万 token——即使原始任务本身很小。这与“单次问答”模式的直觉完全相反：越接近任务尾声，越可能触发高价档。由于计费档位不会回传，监控只能靠客户端自行累计 token，或在每轮前用 tokenizer 预估。

关于基准测试的定位

Anthropic在Opus 5.5的资料中明确写道，在当前能力水平上，基准差距已不再是实践中差异的可靠指标。Terminal-Bench 4.0的标准误差为±2.6分；Opus 5的51.8%复现为52.3%，Anthropic称之为噪声。

实用规则：**读数量级，别读小数位。**39.2%对0.0%是数量级，足以支撑重构流水线。两个顶级模型间两分的差距什么也说明不了。

边界依然存在：Anthropic仍将Sonnet 5.5和Opus 5.5定位为复杂代理编程的更好选择，把Haiku 5.5描述为适合“轮廓更明确的任务”。Terminal-Bench上是39.2%对70.6%。长时间编程不属于便宜层级——把开放式问题交给分层架构，只会失败得更便宜。

一个判断规则

我现在向下传步骤的规则是：**只有当程序能报告某步骤失败时，该步骤才可降级。**字段存在且格式正确、指标可追溯到源文档、枚举值在允许集合内。如果写不出这种检查，步骤就留在上层——因为便宜模型很少因拒绝而失败，而是因自信的错误答案失败，而这恰恰是人工抽样会漏掉的。

在你的流水线里，哪个步骤最难自动校验？经验上，真正的分层界限就在那里。

参考来源

Claude Haiku 5.5 — Anthropic
Claude Opus 5.5 — Anthropic