Muse Wonder 和 Claude Opus 5.5 的价格一样：每百万输入 Token 4 美元，每百万输出 Token 20 美元。所以对小组来说，在两者之间做选择不是预算问题，而是一条路由规则。Meta 的模型卡显示，Wonder 在衡量长时编程的基准上领先（SWE-Marathon，53.1 对 46.3），Opus 则在终端任务（59.6 对 52.0）、通用智能（独立指数 58 对 52）和知识（46 对 25）上领先。这四个数字描述的是两种不同的 Agent，用它们来路由任务的看板，会比选一个默认模型的看板从两边都拿到更多。
本文把数字变成指派：哪些任务交给 Muse Wonder Agent，哪些留在 Opus 5.5，各自会怎样影响审查队列，以及一周后如何判断规则是否有效。把 Muse Wonder 接入工作流的步骤另有说明。
路由时真正重要的数字
把这张表读成两份画像。Wonder：有持续性，因为输出简洁，单任务成本更低；回忆能力弱；接受视频和音频输入。Opus：整体更聪明，在 shell 里更强，知道得更多，单任务成本更高。没有哪份画像更好，它们适合不同的任务。
| 指标 | Muse Wonder | Claude Opus 5.5 | 来源 |
|---|---|---|---|
| SWE-Marathon（长时编程运行） | 53.1 | 46.3 | Meta 模型卡 |
| DeepSWE 1.1 | 78.8 | 74.2 | Meta 模型卡 |
| Terminal-Bench 4.0 | 52.0 | 59.6 | Meta 模型卡 |
| AA-Omniscience（知识） | 25 | 46 | Artificial Analysis |
| 幻觉率 | 27% | 更低，按 Artificial Analysis 排名 | Artificial Analysis |
| 智能指数 | 52 | 58 | Artificial Analysis |
| 编程 Agent 指数 | 63 | 66（Claude Code） | Artificial Analysis |
| 每个指数任务的成本 | $4.52 | $5.98 | Artificial Analysis |
| 输入 | 文本、图片、视频、音频 | 文本、图片、PDF | 厂商文档 |
适合交给 Muse Wonder Agent 的任务
共同点是「长，而且有阻塞」。Meta 训练这个模型时强调一种叫 Active Focus 的能力：尝试不同路径，穿过障碍继续工作，SWE-Marathon 就是为衡量这一点建立的基准。
- 要一直保持测试通过的多文件重构。步骤多，每一步都可检查，失败后需要尝试第二种、第三种办法。
- 依赖和框架迁移。经典长跑：升级、报错、修复、再来；模型的工作就是不要在第十一步放弃。
- 针对不稳定测试套件的修复与验证循环。这类运行需要区分是代码自己的 bug，还是测试套件的问题。
- 带视频或音频输入的任务。一段报 bug 的录屏，一段带需求的通话录音。Opus 5.5 接不了这些输入。
把验收标准写成运行自己能检查的形式。Wonder 最擅长的任务会说「packages/api 里的所有测试都通过，并且 changelog 有记录」；最不擅长的是自己判断什么叫「完成」。
适合留在 Opus 5.5 的任务
- 重终端的工作。基础设施脚本、部署流水线，以及任何让 Agent 长时间待在 shell 里的工作。Terminal-Bench 上七分半的差距是真实的。
- 任何依赖「知道」的任务。Omniscience 25 对 46 意味着 Wonder 漏掉一个事实的可能性约高一倍。对于它没见过的库 API、冷门错误码或领域知识，Opus 能凭记忆回答，Wonder 则要查询，或者猜。
- 审查席。读另一个 Agent 的 diff 并判断对不对的 Agent，应该是你手里最聪明的那个。综合指数上是 Opus，混合模型小组的既有模式也是把昂贵模型放在那里。
- 短而锋利的任务。DeepSWE 上两者很接近，通用智能上 Opus 领先。如果一次运行只要十分钟，持续性优势根本来不及出现。
各自对审查队列的影响
路由会改变落到审查者面前的东西，而那是真实成本。
Wonder 跑长任务会留下更长的路径：更多尝试、更多被回退的方案、更多提交。这是模型在正常工作，也意味着 diff 不是故事的全部。审查者需要运行日志，所以 Agent 指令里应当要求它持续记录尝试过什么。「人审才是瓶颈」在这里尤其成立：一个强调持续性的模型，每个任务会产生更多待审内容，而不是更少。
Wonder 的知识缺口会表现为「自信但错误的细节」：不存在的参数、两个版本前就改掉的方法。它的幻觉率在同级里算低，Artificial Analysis 的测量是 27%，但 27% 不是零。要求 Agent 对任何不确定的事都在仓库里确认，确认不了就明说；让审查者专门抽查这些行。
同一个任务交给 Opus，通常会走出更短、更果断的路径，但单任务账单更高。每次运行的审查更轻。不过当任务很长、阻塞很多时，Opus 更可能中途停下，于是队列里会出现另一种东西：一个做到一半、需要重新定范围的任务。
三个任务的路由示例
具体例子能让规则在派活时更好用。
「把各服务的 ORM 从 v5 升到 v7，所有集成测试通过。」交给 Wonder。几十个步骤，测试套件会在每个阶段以新方式失败，而且终点清楚。模型的持续性是资产，运行自己就能检查验收标准。
「写新预发环境的 Terraform 并应用。」交给 Opus。重 shell、需要基础设施知识，而且动作有后果。Terminal-Bench 指向 Opus；影响范围则要求 Agent 在执行 apply 前停下来问人，无论用哪个模型。
「解释支付 webhook 为什么触发两次，并提出修复方案。」解释交给 Opus，因为这依赖对提供方重试语义的了解，也就是回忆。若修复方案会变成带测试的多文件改动，后续任务可以交给 Wonder。
模式是：由终点定义的任务交给 Wonder，由「你需要知道什么」定义的任务交给 Opus。一个任务同时具备两者时，拆开。HiFox 正是为这种拆分而建：每个 Agent 在每个通道一条任务，交接记录在看板上，而不是留在某个人脑子里。
两边都跑，再读结果
把规则放在看板上跑一周，让任务来裁决。
- 创建 Muse Wonder Agent，保留 Opus 5.5 Agent。两个 Agent 的指令都要求它在报告顶部写出模型 id，因为 HiFox 不显示它。
- 按上面的规则指派，而不是按偏好指派。长且阻塞多的交给 Wonder，终端和知识型交给 Opus，审查交给 Opus。
- 一周后，拉出每个 Agent 关掉的任务，数三件事：有多少是带着问题回来的，而不是带着结果；有多少需要第二次运行；每个任务引出了多少条审查评论。
如果 Wonder 的长任务以更少的重跑完成，而 Opus 的终端任务以更少的修正完成，规则就是对的。如果 Wonder 的任务引出的审查评论比它省下的重跑更多，就收窄交给它的范围。表里的数字是基准上的平均值；你的任务才是最终测试。
这些都不会进入 HiFox 的账单。模型用量走电脑上配置的 Meta 和 Anthropic key；在目录价格相同的情况下，唯一的成本差异是每次运行里 usage 块报告的那一项。
这个月换的是模型。从请求到发布，上下文、进度、阻塞、结果和人审都保持可见。你可以自己用 worktree 搭这套东西，也可以用 HiFox 管理工作流。
HiFox
