别信Muse Wonder跑分，用你的代码库实测对比Opus 5.5

Meta的图表显示Muse Wonder在长周期编码任务上击败Claude Opus 5.5：DeepSWE得分78.8对74.2，SWE-Marathon得分53.1对46.3。而独立评测机构Artificial Analysis给出的Intelligence Index中，Wonder仅得52分，Opus 5.5则高达58分。两套数据并不矛盾——它们测量的是不同维度，而且没有一个跑分是在你的代码库上运行的。

Meta在2026年10月发布了Muse Wonder。Hacker News讨论帖中，一位评论者做了图像转HTML测试后称它"比Opus 5.5差得多"。但那只是一个prompt。本文提供的不是Muse Wonder的结论，而是一套方法论：把同一张工单交给两个agent、在独立的git worktree中运行，并用一个脚本给两者打分。

为什么两套跑分各说各话

在Meta自己公布的14项基准测试中，Wonder赢了5项，主要集中在长周期编码、法律agent任务和Meta内部记忆测试。它输掉了9项，包括ProgramBench——Opus以70.5对50.0大幅领先。

Meta的脚注本身也说明了单行数据的可信度边界。对于内部运行的竞品测试，Meta承认"在可行处使用通用设置，但仍是尽力而为：prompt、工具和运行时可能未针对专有模型优化"。模型卡的限制部分也写道："性能可能因量化、服务配置、prompt、工具和agent harness而变化。"

没有任何排行榜能为你的环境固定prompt、工具和harness，但在自己的代码库上做一场bake-off恰好能做到这一点。

SWE-bench、SWE-Marathon与Intelligence Index这类基准的差异：SWE-bench系列基于GitHub真实issue-修复对，衡量的是单次、边界清晰的问题解决能力；SWE-Marathon则将任务拉长到数十甚至上百步的连续编辑，考验agent在长上下文里的不迷失能力。而Artificial Analysis的Intelligence Index是一个综合套件，混合了推理、知识问答、指令遵循等多类任务，权重并不偏向agentic coding。因此同一个模型在一套测试中强、在另一套中弱，往往不是数据造假，而是任务分布与评测协议不同。理解这一点，才能明白为什么Meta在内部长周期测试上占优，却在独立综合指数上落后。

准备工作：一张工单，一个API Key

选一张真实的工单，要求有一个当前失败的测试（或者先写一个）、修复涉及几个文件、结果可判断。把prompt保存到仓库外的文件中，确保每个agent拿到完全相同的文字，并在其中指明测试命令。"让 npm test -- slug 通过且不修改测试"给agent和你自己划定了同一条终点线。

接下来创建Meta Model API的密钥，按Meta编码agent文档中的名称导出。API模型ID为 muse-wonder-1.0。注意API不提供Muse Wonder Full——那是Muse Code订阅用户专属。

export MODEL_API_KEY="your-key-here"

会话A：Claude Code运行Opus 5.5

在Hermes IDE中按⌘N（Windows/Linux为Ctrl+Shift+N），在agent选项中选择Claude Code，模型选择Opus 5.5，粘贴prompt后回车。Claude Code使用其常规登录方式。任务会从当前分支切出，在独立的git worktree和新的 hermes/<task> 分支上启动。

会话B：同一Claude Code运行Meta模型

Meta文档定义了三个环境变量将Claude Code指向其API：ANTHROPIC_BASE_URL、ANTHROPIC_AUTH_TOKEN 和 ANTHROPIC_MODEL。文档还要求将Opus、Sonnet和Haiku别名及子agent模型设为同一ID，"确保没有请求回退到Claude模型"。跳过这一步，部分请求会使用Claude模型ID而非Muse Wonder，会话B就不再是纯净的Muse运行。

七个变量拼成一条长命令，建议做成wrapper脚本保存为 claude-muse 放在 PATH 中：

#!/usr/bin/env bash
export ANTHROPIC_BASE_URL="https://api.meta.ai"
export ANTHROPIC_AUTH_TOKEN="$MODEL_API_KEY"
m="muse-wonder-1.0"
export ANTHROPIC_MODEL="$m"
export ANTHROPIC_DEFAULT_OPUS_MODEL="$m"
export ANTHROPIC_DEFAULT_SONNET_MODEL="$m"
export ANTHROPIC_DEFAULT_HAIKU_MODEL="$m"
export CLAUDE_CODE_SUBAGENT_MODEL="$m"
exec claude "$@"

base URL不含 /v1，key放在 AUTH_TOKEN 而非 API_KEY。在Hermes中再按⌘N，选择Custom agent，命名为 Claude Code · Muse Wonder，命令设为 claude-muse，粘贴同一prompt即可。

此时会话A和B使用相同的harness处理同一张工单，唯一变量是模型及其背后的API——这才是受控的common-harness对比。Meta自己也在脚注中承认其SWE-Marathon行"不是受控的common-harness比较"。

不用Hermes？纯git同样可行

隔离部分每个agent只需一条命令：

git worktree add -b bakeoff/opus ../bakeoff-opus
git worktree add -b bakeoff/muse ../bakeoff-muse

然后在 ../bakeoff-opus 中运行 claude（用 /model 选择Opus 5.5），在 ../bakeoff-muse 中运行 claude-muse，各自独立终端。代价是失去统一观察界面和后续的审查步骤。

为什么指向第三方API需要重设这些环境变量：Claude Code默认走Anthropic官方端点，并把模型别名（Opus/Sonnet/Haiku）映射到Anthropic自家模型ID。当 ANTHROPIC_BASE_URL 被改写为Meta端点后，请求虽然发往Meta，但如果没有同步替换别名和子agent模型变量，harness内部仍会按Claude的模型名构造请求，导致部分调用被Meta端点拒绝或悄悄回退到Anthropic。这就是文档要求把七个变量设为同一ID的根本原因——只有让所有路径都解析到 muse-wonder-1.0，才能保证整场会话是纯粹的Muse运行。

可选会话C：Meta自家的muse CLI

会话B测试的是模型在Anthropic harness中的表现。如果想同时测试Meta的harness，安装Muse Code——安装器会在 ~/.local/bin 创建名为 muse 的命令：

curl -fsSL https://dev.meta.ai/install.sh | bash

再加一个Custom agent，命令设为 muse。Muse Code是订阅制，Power Usage套餐每月$50，包含Wonder Full。Meta产品页列出macOS和Windows支持。但早期有一份负面报告：同一Hacker News帖中，一位评论者称Muse Code沙箱"在Mac和Linux上从未正常工作过"。付费前请先在自己机器上验证。

用脚本给两个worktree打分

两个agent都表示完成后，用相同方式评分。脚本接收base分支、测试命令和任意数量的worktree路径，对每个输出分支名、测试是否通过、改动了多少文件、相对base的增删行数：

#!/usr/bin/env bash

**git worktree与分叉点diff的语义**：`git worktree` 允许同一个仓库在不同目录检出不同分支，共享 `.git` 对象库，因此两个agent互不干扰。脚本用 `git merge-base` 找到base分支与当前HEAD的公共祖先（即分叉点），再把工作区与分叉点做 `diff --numstat`。相比直接与base分支HEAD对比，这样能排除base自身在测试期间的新提交带来的噪声，更精确地反映agent的净改动。未跟踪文件不计入numstat，所以脚本单独用 `ls-files -o` 统计。理解这套diff逻辑，才能在结果异常时判断是agent没干活还是脚本口径问题。
# usage: compare-worktrees.sh BASE "TEST COMMAND" WORKTREE...
set -u

base=$1
test_cmd=$2
shift 2

for wt in "$@"; do
  branch=$(git -C "$wt" rev-parse --abbrev-ref HEAD)
  fork=$(git -C "$wt" merge-base "$base" HEAD)
  new=$(git -C "$wt" ls-files -o --exclude-standard | grep -c .)
  (cd "$wt" && bash -c "$test_cmd") >/dev/null 2>&1
  code=$?
  if [ "$code" -eq 0 ]; then result=PASS; else result=FAIL; fi
  stats=$(git -C "$wt" diff --numstat "$fork")
  files=$(printf '%s' "$stats" | grep -c .)
  added=$(printf '%s\n' "$stats" | awk '{s+=$1} END {print s+0}')
  removed=$(printf '%s\n' "$stats" | awk '{s+=$2} END {print s+0}')
  echo "== $wt"
  echo "   branch:  $branch"
  echo "   tests:   $result (exit $code)"
  echo "   files:   $files changed, $new untracked"
  echo "   lines:   +$added -$removed vs $base"
done

脚本将工作树与分叉点做diff，因此能计入agent做了但未提交的改动。git尚未追踪的新文件出现在"untracked"计数中而非行数总计。该计数在测试运行前采集，避免测试产生的文件虚增数字。

填写评分卡

脚本覆盖前三行，其余在观察中记录：测试是否通过、增删行数、改动文件数、完成所需墙钟时间、成本、合入前需要多少审查意见。

墙钟时间。 Artificial Analysis测得Wonder首token时间为19.27秒，同类模型中位数为5.52秒。一个agent任务会发起多次调用，这个差距会显现。

成本。 Meta文档警告，指向自定义提供商的agent常显示$0成本，因为缺少定价元数据。不要从会话B终端读取成本，而应根据输入、缓存和输出token数手动计算：输入百万数×$4，缓存输入百万数×$0.20，输出百万数×$20。单token价格与Opus 5.5相同，但每任务成本仍可能不同。Artificial Analysis统计Wonder运行其index消耗了130M输出token，中位数为85M。

在Hermes中审查并合并胜者

按⌘G（Windows/Linux为Ctrl+Shift+G）打开Review Desk，切换到By turn模式。你可以逐轮审查每个agent的工作，而非一次性看最终diff。风险标记会标出lockfile、CI工作流、密钥、新二进制文件以及agent对自身配置的修改。

行内评论会返回给写该行的agent。统计这些评论数——那就是评分卡的最后一行。Hermes对Custom agent的了解少于内置agent，如果会话B的轮次看起来单薄，改用By file模式阅读，或退回脚本数据加针对base分支的普通 git diff。

从Land面板合并胜者：提交、开PR或本地合并，之后可撤销。然后关闭另一个会话，手动移除失败方worktree：git worktree remove ../bakeoff-muse。

单次bake-off的局限

一张工单只是一个轶事。在得出结论前，用三到五张不同形态的工单测试，因为一个在重构中胜出的模型可能在bug猎取中落败。

Hermes目前对Custom agent没有状态信号，不知道命令的审批模型，注意力收件箱无法判断会话B或C是否在等待你。需要盯着它们的终端。会话A保留完整状态。

你测试的是Muse Wonder而非Wonder Full。API不提供Full，只有包含它的套餐上的会话C才能触及。会话B是Anthropic的harness运行Meta的模型：对比较模型是公平的，但可能不是Meta调优Wonder的方式——这正是会话C存在的理由。

量化、服务配置与harness对模型表现的影响：同一模型在API、订阅端和不同推理框架下可能运行不同量化版本，权重精度、批处理策略、上下文截断阈值都会改变输出质量。Meta模型卡明确列出这一点，意味着你在bake-off里测到的Muse Wonder，未必等于Wonder Full或Meta内部优化后的形态。这也是为何跨厂商对比必须固定harness——如果两个agent使用不同的工具调用格式、重试策略和系统提示，得分差异可能来自脚手架而非模型本身。

立即开始bake-off

选一张你这周本来就要交给agent的工单，在两个会话中跑一遍，合并你更愿意再次审查的那个结果。模型之间的争论不该由别人的跑分来裁决——你自己的代码库才是最终的裁判。