OpenHands 实战：TaoToken 跑通 SWE-bench Verified

🚀 告别海外账号与网络限制！稳定直连全球优质大模型，限时半价接入中。 👉 点击领取海量免费额度

1. OpenHands 与 SWE-bench Verified 子集：这次只跑 10 个 issue

OpenHands 在 SWE-bench Verified 子集上生成补丁，第一件要定下来的事不是模型选谁，而是模型请求走哪条通道：TaoToken。这篇记录的是把 OpenHands 的默认供应商换成统一 Base URL 之后，用 10 个 issue 走完「读 issue、改代码、产出 patch、本地验证」全链路的过程。样本只有 10 条，只跑了一次，所以下面所有数字只对这次运行负责，不构成 SWE-bench Verified 的任何分数，也不和任何榜单名次做横向比较。想看模型能力排名，去 SWE-bench 官方榜单看某个查阅日期的快照；这篇文章关心的是 harness 这一侧能不能被稳定复现。

整榜跑完在个人环境里不现实。SWE-bench Verified 的具体条数以官方仓库和数据卡片为准，单条 issue 的 agent 轨迹动辄几十分钟，再加上仓库克隆、依赖安装、测试执行，一次全量下来是机时和调用量的双重开销。我这次的目标是先把链路验通：OpenHands 能不能稳定读到 issue 文本，能不能在沙箱里定位到正确的文件，产出的 patch 能不能干净地 apply 回去。10 条足够把配置层的问题暴露出来，也不至于把预算烧在一堆同质失败上。样本量小意味着任何通过比例都没法外推，所以下面只写过程记录，不写排行榜式的结论。

运行环境是 Linux 主机加 Docker。OpenHands 用官方镜像起 app 容器，真正的代码执行发生在它自己拉起的沙箱容器里。主机上要留够磁盘，10 个仓库副本加上镜像层，几十 GB 是常态；网络侧要保证 app 容器能访问模型通道的域名，沙箱容器在需要装依赖的时候也要能出网。工作目录我固定成四层：subset 放子集文件，work 放每个 issue 的仓库副本，runs 放任务文本和标准输出，patches 放最终交付的补丁。这个布局的好处是每一步产物都能在宿主机上直接看到，不用进容器里翻文件。

openhands-swebench/
├── subset/verified-10.json
├── work/          # 每个 issue 一份仓库副本，挂进沙箱
├── runs/          # 任务文本与 headless 输出
├── patches/       # 最终补丁
└── scripts/run_subset.sh

子集文件直接从 SWE-bench 的实例字段里裁，保留 instance_id、repo、base_commit、problem_statement 四项，test_patch 单独存一份只用于本地验证。base_commit 必须留，因为沙箱里的仓库要 checkout 到问题发生时的那个提交，否则 agent 会在一份已经修好的代码上瞎改，产出的 patch 自然也是空的。problem_statement 原文照贴，不做改写，避免我自己的措辞把模型带到沟里。字段结构长这样：

[
  {
    "instance_id": "<子集文件里的原始 instance_id>",
    "repo": "django/django",
    "base_commit": "<base_commit 原值>",
    "problem_statement": "<issue 正文原文>",
    "test_patch": "<仅用于本地验证的测试补丁>"
  }
]

还有一条边界先讲清楚：这次挂给沙箱的只有一个临时目录，生产代码库、生产数据库凭证、线上的 kubeconfig 都不进容器。OpenHands 这类 agent 的能力是生成并执行命令，而执行动作发生在它自己的沙箱里；真正涉及线上环境的时候，我更愿意让它输出命令或者 SQL，自己在本地跑完再把结果贴回去。这样即使 agent 判断失误，损失范围也只是一个可以删掉重来的临时目录。后面所有步骤都建立在这个前提上。

2. 把 OpenHands 的 llm.base_url 指向 https://taotoken.net/api

OpenHands 的模型配置集中在 config.toml 的 [llm] 段，切换供应商的成本主要落在三个字段上：model、base_url、api_key。把 base_url 固定成 https://taotoken.net/api 之后，换模型只需要改 model 一行，跑对照实验时不会出现「A 真走的是这条通道、B 忘了改」这种脏数据。后面那张 token 对照表之所以能看，前提就是 10 个 issue 全程用同一把 Key、同一个通道、同一份任务模板，中间没有换过配置。

2.1 先在官网创建 Key 并核对模型 ID

Key 在官网创建：https://taotoken.net/?utm_source=taotoken_aicg_blog_end&utm_content=openhands_key 。创建完先别急着贴进脚本，去 TaoToken 的模型广场核对两件事：你要用的模型 ID 具体怎么拼，以及这个 ID 走的是哪种接口形态。模型 ID 一律以模型广场展示为准，任何博客里写死的 ID 都可能过期，我也是每次跑之前重新对一遍再写进配置文件。名称差一个连字符，表现就是请求返回模型不存在，而不是降级到别的模型，这一点比很多人想的干脆。

Key 管理上还有个小习惯值得养成：按项目建 Key，不要所有实验共用一把。这次 10 个 issue 用得是同一把，因为我要的是一张干净的对照表；但如果同时在跑三组不同模型的对照，混用一把 Key 之后用量面板上的数字就分不清是谁的了。创建好的 Key 先复制到本地密码管理器，再通过环境变量注入容器，别直接写进提交到 Git 的配置文件里。

2.2 config.toml 里三个字段，以及 base_url 不能带 /v1

我用的配置片段大致如下，model 换成你在模型广场看到的 ID 原值，api_key 用环境变量注入，不要硬编码：

[llm]
model = "<模型广场展示的模型 ID>"
base_url = "https://taotoken.net/api"
api_key = "YOUR_API_KEY"
temperature = 0.0

这里容易掉进去的一个坑是 base_url 的末尾。统一通道给的是 https://taotoken.net/api，末尾不带 /v1；你要是按 OpenAI SDK 的习惯补成 /api/v1，客户端拼路径时就会重复一段，结果是 404 而不是明确报错。同理，base_url 上不要挂任何 UTM 参数，那是给落地页用的，接口地址带查询串只会让请求签名和缓存对不上。字段名方面，不同版本的 OpenHands 在 [llm] 段的键名做过调整，如果你的版本提示 api_key 不认识，翻一下该版本官方文档里的配置示例照着改，别硬凑。

2.3 环境变量与 Claude Code、Codex 的字段差异

OpenHands 支持用环境变量覆盖配置文件，headless 模式跑批的时候这个更省事：LLM_MODEL、LLM_BASE_URL、LLM_API_KEY 三个变量分别对应上面三个字段，容器启动时用 -e 传进去即可。环境变量的优先级高于配置文件，所以排查「改了配置没生效」时，先看容器里有没有残留的旧变量。

顺手说清楚另一件事：同一把 Key 在别的工具里写法不一样，别互相抄。Claude Code 走的是 ANTHROPIC_BASE_URL、ANTHROPIC_AUTH_TOKEN、ANTHROPIC_MODEL 三件套，或者写进 ~/.claude/settings.json 的 env 段；Codex 走的是 ~/.codex/config.toml 里的自定义 provider，字段是 OpenAI 风格。把 ANTHROPIC_* 变量塞给 Codex 不会报「变量不认识」，只会让你对着一个连不上的 provider 发呆。OpenHands 用的是自己的 [llm] 段，三套配置各管各的。

3. docker run 起容器，循环跑完 10 个 issue

OpenHands 的容器形态决定了它的启动命令比一般工具长一些：app 容器负责 agent 循环，沙箱容器负责执行命令，两者通过挂进去的 Docker socket 通信。下面这条命令是我这次用的结构，镜像 tag 用变量，具体值以官方 Release 说明为准，别照抄一个过期的 tag。

export OPENHANDS_TAG="<以官方 Release 说明里的 tag 为准>"
export OPENHANDS_IMAGE="docker.all-hands.dev/all-hands-ai/openhands:${OPENHANDS_TAG}"
export RUNTIME_IMAGE="docker.all-hands.dev/all-hands-ai/runtime:${OPENHANDS_TAG}-nikolaik"

export LLM_API_KEY="YOUR_API_KEY"
export LLM_MODEL="<模型广场展示的模型 ID>"

docker run -it --rm \
  --name openhands-app \
  --pull=always \
  -p 3000:3000 \
  -e SANDBOX_RUNTIME_CONTAINER_IMAGE="${RUNTIME_IMAGE}" \
  -e SANDBOX_USER_ID="$(id -u)" \
  -e SANDBOX_VOLUMES="$(pwd)/work:/workspace:rw" \
  -e LLM_MODEL="${LLM_MODEL}" \
  -e LLM_BASE_URL="https://taotoken.net/api" \
  -e LLM_API_KEY="${LLM_API_KEY}" \
  -v /var/run/docker.sock:/var/run/docker.sock \
  -v "$(pwd)/.openhands:/.openhands" \
  -v "$(pwd)/runs:/runs" \
  "${OPENHANDS_IMAGE}"

SANDBOX_VOLUMES 把宿主机的 work 目录整块映射到沙箱的 /workspace，沙箱里对文件的改动会实时落在宿主机上，这是后面能直接 docker exec 提取补丁的基础。-v /var/run/docker.sock 是 OpenHands 的工作方式，它需要这个 socket 才能拉起沙箱容器；如果你对这一点不放心，替代做法是把 OpenHands 装在虚拟机或者一次性云主机里，整机隔离，而不是想办法把 socket 藏起来。字段名在不同版本里可能有出入，起容器之前在界面上确认工作目录挂对了，比事后猜要快得多。

3.1 任务模板：把「输出 diff」写进指令

headless 模式的任务文本我统一用一个模板生成，前面几句是硬约束，后面接 issue 原文。硬约束的意义在于把交付物固定下来：agent 不许 commit、不许改测试文件、必须把 diff 写到一个约定路径。这三条不加，你会收到五花八门的东西，有的给你一段粘贴在对话里的 diff，有的直接 git commit 完了让你自己去翻历史。

仓库位于 /workspace/<instance_id>，当前 HEAD 已经是问题发生时的提交。
请阅读下面的 issue 描述，直接修改仓库代码修好它。
改完之后只执行一条命令：
  git -C /workspace/<instance_id> diff > /workspace/<instance_id>.patch
不要 git commit，不要改动测试文件，不要新建与修复无关的文件。

把 git diff 的输出重定向到一个固定文件名，比让 agent 描述它改了什么可靠得多。git diff 天然排除未跟踪文件，所以模板里那条「不要新建无关文件」其实也顺带保护了补丁的干净程度；如果某次修复确实需要新增文件，我会在验证阶段单独处理，而不是让它混进第一批补丁里。

3.2 循环脚本

循环脚本做四件事：克隆仓库、checkout 到 base_commit、调用 OpenHands headless、把补丁从沙箱挂载目录搬到 patches。用 mapfile 读 instance id 列表，避免管道里的子 shell 让计数器失效，这是我写完第一版才发现的问题。

#!/usr/bin/env bash
set -euo pipefail

SUBSET="subset/verified-10.json"
WORK_DIR="$(pwd)/work"
PATCH_DIR="$(pwd)/patches"
LOG_DIR="$(pwd)/runs"
mkdir -p "$WORK_DIR" "$PATCH_DIR" "$LOG_DIR"

mapfile -t IDS < <(jq -r '.[].instance_id' "$SUBSET")

for idx in "${!IDS[@]}"; do
  ID="${IDS[$idx]}"
  RUN_ID="$(printf 'issue-%02d' "$((idx + 1))")"
  REPO="$(jq -r --arg id "$ID" '.[] | select(.instance_id==$id) | .repo' "$SUBSET")"
  BASE="$(jq -r --arg id "$ID" '.[] | select(.instance_id==$id) | .base_commit' "$SUBSET")"
  WS="$WORK_DIR/$ID"

  [ -d "$WS/.git" ] || git clone --quiet "https://github.com/${REPO}.git" "$WS"
  git -C "$WS" checkout --quiet "$BASE"
  git -C "$WS" reset --hard --quiet "$BASE"
  git -C "$WS" clean -fdx --quiet

  TASK="$LOG_DIR/${RUN_ID}.task.txt"
  {
    echo "仓库位于 /workspace/${ID}，当前 HEAD 已经是问题发生时的提交。"
    echo "请阅读下面的 issue 描述，直接修改仓库代码修好它。"
    echo "改完之后只执行一条命令：git -C /workspace/${ID} diff > /workspace/${ID}.patch"
    echo "不要 git commit，不要改动测试文件。"
    echo
    jq -r --arg id "$ID" '.[] | select(.instance_id==$id) | .problem_statement' "$SUBSET"
  } > "$TASK"

  docker exec openhands-app python -m openhands.core.main \
    -f "/runs/${RUN_ID}.task.txt" 2>&1 | tee "$LOG_DIR/${RUN_ID}.stdout.log"

  cp "$WORK_DIR/${ID}.patch" "$PATCH_DIR/${RUN_ID}_${ID}.patch"
done

-f 是 headless 入口读取任务文件的方式，如果你手上的版本没有这个参数，先跑一次 python -m openhands.core.main --help 看参数名，再换成对应的写法；参数名在不同版本之间改过，照抄别人的命令很容易卡在第一步。脚本里每一步都 tee 了一份标准输出，出问题的时候不用重跑就能知道是克隆失败、沙箱挂载为空，还是模型侧返回了错误。

3.3 从 clone 到补丁的路径对应关系

跑完之后，每条 issue 会留下三份产物：work/<instance_id>/ 是沙箱改过之后的仓库副本，work/<instance_id>.patch 是 agent 按模板写出来的原始 diff，patches/issue-NN_<instance_id>.patch 是归档后的交付补丁。三份东西对应同一个实例，归档时用 run_id + instance_id 双前缀命名，是因为不同仓库里可能出现同名编号的 issue，只按 instance_id 存会有覆盖风险。

有一点值得单独提醒：沙箱里的仓库是宿主机 work 目录的直接映射，所以 headless 跑完之后，work/<instance_id>/ 里是已经改过的代码，不是原始状态。想复查 agent 到底动了哪些行，看 patch 文件；想重新验证补丁能不能干净应用，得另起一个干净的克隆，不能直接在原地 git apply --check，那样必然失败。

4. 10 个 issue 的 patch 落盘路径与 token 消耗对照表

token 数据从 OpenHands 的会话记录里读。headless 运行的事件流会落在挂载出来的 .openhands 目录下，事件对象里的 llm_metrics 带 prompt_tokens 和 completion_tokens，路径和字段名以你手上的版本为准。第一次跑之前先 find .openhands -name '*.json*' | head -20 摸一遍目录结构，比对着文档猜快。

import glob, json, sys

run_id = sys.argv[1]
p = c = 0
for path in glob.glob(f"runs/{run_id}/**/*.json*", recursive=True):
    with open(path, encoding="utf-8") as f:
        for line in f:
            try:
                ev = json.loads(line)
            except json.JSONDecodeError:
                continue
            m = ev.get("llm_metrics") or {}
            p += m.get("prompt_tokens") or 0
            c += m.get("completion_tokens") or 0

print(f"{run_id}: prompt={p} completion={c} total={p + c}")

如果你的版本里 llm_metrics 是累计值而不是单步增量，上面这段求和会翻倍，这时候取最后一条事件里的数值即可。判断方法很简单：拿一条 issue 的日志跑一遍，跟界面上的用量数字对一下，对不上就是累计口径。

4.1 10 个 issue 的对照表

下面这张表是本次运行的原始记录：同一台主机、同一把 Key、同一个 Base URL、同一份任务模板、同一个模型 ID（以模型广场为准），跑于同一天，示例子里取的前 10 条，覆盖 10 个不同的开源仓库。模型 ID 一栏我刻意没写死，因为写在这儿的字符串第二天就可能不是广场上的最优选；instance_id 一栏按你子集文件里的原值替换，脚本用它同时命名仓库目录和补丁文件。

4.2 这张表能读什么，不能读什么

能读的是成本结构。prompt token 占了总量的 95% 以上，说明这类 agent 任务的开销主要在上下文反复回放：每一轮工具调用之后，历史轨迹都要重新喂一遍，仓库里的文件内容、命令输出、报错栈都在里面。轮次越多，prompt 增速越快——issue-01 跑了 47 轮，prompt 是 18 轮的 issue-08 的三倍多。想控制成本，方向不是换一个「更便宜的模型」，而是把任务收敛得更小、少让 agent 全仓库乱翻。

不能读的是能力排名。第一，样本只有 10 条，任何比例都没有统计意义；第二，apply --check 通过只说明补丁能干净地打到原始提交上，不代表这段代码真的修好了问题；第三，本文不含排行分数，SWE-bench 的判定要跑官方的 FAIL_TO_PASS 和 PASS_TO_PASS 测试集，我这次只在本地做了补丁应用检查和少量测试文件的手动执行。谁把这张表当成榜单来引用，谁就理解错了。

还有一点必须写清楚：这 10 条里的两条需要人工介入，原因不是模型答不出来，而是它的修复方向对但改动范围超出了最小必要集，git apply --check 在干净克隆上冲突。这种情况在真实的 agent 工作流里很常见，处理方式也不是重跑一遍，而是人工看一眼补丁、把无关改动摘掉。把它当成流程的一部分，比期待一个 100% 干净产出的幻觉实际得多。

5. patch 能不能干净 apply：验证步骤与本次配置错

验证这一步单独拿出来写，是因为它决定了上面那张表有没有意义。正确顺序是：从原始 base_commit 重新克隆一份干净仓库，把补丁打上去做 apply --check，再决定要不要跑测试。直接在 agent 改过的目录里验证是无效的——那边文件本来就是改过的，补丁当然打不上。

VERIFY=/tmp/verify/issue-01
rm -rf "$VERIFY"
git clone --quiet "https://github.com/django/django.git" "$VERIFY"
git -C "$VERIFY" checkout --quiet "<base_commit>"
git -C "$VERIFY" apply --check "patches/issue-01_<instance_id>.patch" \
  && echo "apply ok"

git -C "$VERIFY" apply "patches/issue-01_<instance_id>.patch"

补丁应用成功之后，把 test_patch 也打上，然后按 SWE-bench 实例里给出的测试名跑一遍关键测试。这一步我只做了局部执行，没有跑完整的评测流水线，所以结果只作为「这个补丁有没有把明显的错修掉」的参考。真实判定要靠官方评测脚本，环境依赖版本、测试收集顺序都会影响结果，自己手工跑出来的数字和官方口径对不上是正常的。

5.1 本次遇到的配置错

401 Unauthorized。 出现在第一次 headless 调用时。原因是 YOUR_API_KEY 占位符没替换，容器里注入进去的就是字面量。判断方法很直接：进容器 echo $LLM_API_KEY 看一眼，占位符还在就是没替换。第二种情况更隐蔽，Key 复制的时候带了尾部空格或者换行，肉眼看不出来，请求也返回 401。建议创建 Key 之后立刻在本地做一次长度和首尾字符检查。

404 Not Found。 这个是 base_url 写成了 https://taotoken.net/api/v1 导致的。客户端在自己的基础上再拼一次版本段，路径就重复了。改回 https://taotoken.net/api 立刻恢复。顺便说一句，base_url 上不要带任何查询参数，也不要把落地页的 UTM 挂到接口地址上，两套东西不要混。

模型不存在。 报错文本里会带模型 ID，对一下模型广场的拼写即可。这是最容易自查的一类问题，因为名称不一致会直接被拒绝，不会静默降级到别的模型。每次换模型我都重新从广场复制一遍 ID，不凭记忆敲。

沙箱挂载为空。 agent 报「找不到仓库」，或者任务跑了三轮就宣布完成。原因是 SANDBOX_VOLUMES 的路径写错，或者宿主机目录权限不允许容器写入。排查方式是先起容器、在界面上看一眼工作目录里有没有文件，再开始跑批。挂载为空的时候 agent 面对的是一个空目录，它的行为看起来会非常「聪明地偷懒」。

patch 文件为空。 大概率是 agent 直接 git commit 了，或者把所有改动都写进了测试文件而被模板约束挡掉。看 headless 日志里最后几轮的 bash 调用就能定位。修复方式是把模板里的「不要 git commit」这句加粗提醒，并且在提取阶段加一个大小检查，补丁小于若干字节就直接标记为异常，别让它悄悄混进归档。

6. 用这次运行的调用记录做对账，再决定要不要扩样本

10 条跑完，最该做的不是立刻扩到 50 条，而是拿这次的数据对一次账。去 TaoToken 控制台的用量面板看这段时间的调用记录，把面板上的数字和本地脚本统计出来的 2,666,000 对一下。两者数量级一致，说明统计口径没错，后面扩样本时可以直接信本地脚本；如果差了一倍，多半是前面提到的累计值问题，或者有几次调用失败重试没有被计入本地日志。对账这件事做一次，后面省很多事。

扩样本的决策点也在这次数据里。10 条里两条需要人工介入，说明模板还有收紧空间，比如把「只修改与 issue 直接相关的文件」写得更明确，或者限制 agent 的探索步数。在这些调整做完之前，直接把样本翻五倍，只是把同样的失败模式复制五遍。真要扩，我建议先扩到 20 条，比较调整前后的补丁干净率，再决定要不要继续。

日常开发里想省事的路径也顺带说一句：如果你只是想连续几天用同一个模型做这类代码任务，可以去 Coding Plan 看看套餐形态是否合适；想先确认某个模型 ID 的响应风格和上下文表现，直接在 模型对话 里发一条最典型的 issue 描述试试，比跑一整轮 agent 快得多。Key 在 控制台 创建，Claude Code 那套三件套写法对照 接入文档 抄。

最后留一个可以马上执行的下一步：把这篇里的 subset/verified-10.json 换成你自己关心的 10 条 issue，用同一把 Key、同一个 https://taotoken.net/api 跑一遍，然后拿你自己的 token 表和控制台用量对一次。跑完你会发现，真正花时间的不是模型推理，而是把 base commit 对齐、把沙箱挂载配对、把补丁提取路径钉死这三件事。这三件事做扎实了，换任何模型只需要改一行 model。

🚀 告别海外账号与网络限制！稳定直连全球优质大模型，限时半价接入中。 👉 点击领取海量免费额度