SWE-agent 实战：TaoToken 跑通 SWE-bench Verified 的 5 个实例

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

1. 用 SWE-agent 跑 SWE-bench Verified 子集：任务说明

SWE-agent 是一个能在终端里自动阅读代码、定位 bug、生成 patch 的 agent 框架，SWE-bench Verified 则常被用来检验它生成的 patch 是否真的能通过测试。这次我用 TaoToken 在官网 https://taotoken.net/?utm_source=taotoken_aicg_blog_end 创建 Key 后，把 SWE-agent 的模型配置指向 https://taotoken.net/api，跑通了 SWE-bench Verified 里的 5 个实例。下面记录的是同一套默认提示模板下的逐实例结果，以及我复现时用到的完整配置。

SWE-bench Verified 是 OpenAI 在原始 SWE-bench 基础上人工复核过的 500 个 GitHub issue，每个实例都对应一个真实仓库、一段 issue 描述以及一组可自动执行的测试用例。完整跑一遍这 500 个实例需要几十个小时的 GPU 推理和大量 Docker 构建时间，而且很多实例的依赖环境老旧，构建失败率很高。我不追求全量复现，只从数据集中挑出 5 个分布在不同仓库的实例，目的是观察同一个模型在同一个默认提示模板下，究竟能稳定地产出几个正确 patch。这里说的 pass@1 严格定义为：agent 只生成一次 patch，随后立刻在目标仓库的干净环境里跑官方测试，测试通过记 pass，否则记 fail。这个定义和公开榜单上的 pass@1 在抽样规模和运行配置上都不一样，所以我下面的结果只代表一次本机运行，不用于任何模型排名讨论。

选择 5 个实例还有一个实际原因：agent 类任务非常耗时，每个实例从读取 issue 到最终生成 patch，通常要走十几轮甚至几十轮 tool call。如果选 10 个以上，调试配置和排查环境问题的时间会成倍增加。5 个实例既有纯 bug 修复，也有需要调整测试预期的任务，能够暴露模型在“定位问题-修改代码-运行测试”这条链路上的典型弱点。在开始跑之前，我把 SWE-agent 的温度参数固定为 0，top_p 固定为 1，关闭了采样随机性，这样同一个实例重复跑的差异主要来自环境构建和工具调用的顺序波动，而不是模型解码的随机性。虽然温度 0 并不能保证完全确定性，但至少排除了解码采样这个最大的不确定因素。提示模板则保持 SWE-agent 自带默认，不做任何删改，这样整份记录可以被人直接用相同设置复核。

2. 把 TaoToken 接进 SWE-agent：环境变量与配置文件

TaoToken 在 SWE-agent 这个项目里只扮演 API 供应商的角色，它不参与 agent 的决策，也不修改工具逻辑。我需要做的只是让 SWE-agent 在调用模型时，把请求发到 https://taotoken.net/api，并携带有效的 API Key。整个链路是：SWE-agent 内部使用 LiteLLM 统一管理不同模型后端的请求，LiteLLM 读取 OpenAI 兼容环境变量后，将 chat completion 请求发送到我指定的地址。因此，配置的重点就是三个变量：API 地址、API Key、模型 ID。模型 ID 以 TaoToken 模型广场展示为准，不要在命令行里凭记忆输入一个具体的模型名，因为广场内容会更新，写死某个模型名反而误导后来的读者。

2.1 创建 Key 和控制台入口

打开 TaoToken，注册后进入控制台，创建一个 API Key。创建好的 Key 形如 YOUR_API_KEY，这个字符串在后续所有配置里都是同一个。控制台里同时能看到模型广场，广场上每个模型 ID 的唯一标识就是你在配置里真正要用的 YOUR_MODEL_ID。我强烈建议你在运行时把模型 ID 从页面上直接复制，而不是手动输入。我见过很多次因为 - 和 _ 混淆导致模型名无法识别的情况，从页面复制可以避免这类低级错误。创建 Key 之后，控制台还会显示用量统计接口，这个在后面核对 Token 消耗时非常有用。

注意，TaoToken 的 API 基础地址是 https://taotoken.net/api，末尾没有 /v1。这一点和许多 OpenAI 兼容服务不同。我用过的其他服务商通常要求把 /v1 拼在 base URL 后面，但 TaoToken 的网关设计把 /api 作为根路径，实际请求会拼成 https://taotoken.net/api/chat/completions。如果画蛇添足地加上 /v1，返回的会是 404。我在第 4 节会专门讲这个坑的排障过程。控制台的用量记录页面能够按时间列出每次请求的输入 token、输出 token 和模型 ID，这对我后续做成本对账非常有帮助。

2.2 环境变量方式（最通用）

SWE-agent 依赖 LiteLLM 与模型交互，所以环境变量可以直接复用 LiteLLM 的规范。打开终端，依次设置三条环境变量：

export OPENAI_API_BASE=https://taotoken.net/api
export OPENAI_API_KEY=YOUR_API_KEY
export OPENAI_MODEL=YOUR_MODEL_ID

然后运行 SWE-agent run 命令：

swe-agent run --model openai/$OPENAI_MODEL \
  --dataset princeton-nlp/SWE-bench_Verified \
  --split test \
  --instance-id <具体实例ID> \
  --log_dir ./logs/swe-agent-run

这里的 openai/ 前缀是给 LiteLLM 识别协议用的。TaoToken 的接口兼容 OpenAI 格式，所以这个前缀必须带上。如果你的模型 ID 里已经包含了类似的 provider 前缀，那么你需要把 --model 后面的整体写为 openai/模型ID，也就是在原有模型 ID 前再加一个 openai/。我在第一次运行时直接把模型 ID 填成了 YOUR_MODEL_ID，没有加前缀，结果 LiteLLM 报错说模型名无法解析。加上 openai/ 后立刻正常。如果你使用的是 SWE-agent 的旧版本，可能还需要设置 --agent.model.name 之类的参数，但环境变量方式在 0.9 以上版本都通用，具体版本以你自己安装的为准。

环境变量方式的好处是排障简单：如果某个变量写错了，直接 unset 掉重新 export 即可，不需要编辑 YAML 文件。缺点是每次新开终端都要重新设置。如果你希望配置长期保留，可以写进 shell profile，或者用 SWE-agent 的模型配置文件。

2.3 模型配置文件方式与连通性自检

SWE-agent 也支持把模型信息写进 YAML 配置文件，常见位置是 ~/.swe-agent/model_config.yaml。内容大致如下：

model: "openai/YOUR_MODEL_ID"
api_base: "https://taotoken.net/api"
api_key: "YOUR_API_KEY"

这个配置文件的键名在不同 SWE-agent 版本里略有差异。比如有的版本用 api_base，有的版本用 base_url。如果你从源码安装，可以直接在 sweagent/config/model_config.yaml 里修改。我第一次尝试配置文件时，把 api_base 写成了 api_base_url，结果 SWE-agent 忽略了这个字段，仍然走了默认的 OpenAI 地址，导致请求发到了 api.openai.com。这种错误最隐蔽，因为日志里显示的模型名和 Key 都没问题，只有请求地址不对。后来我仔细看了源码里的配置类定义，才发现多了一个 _url 后缀。所以如果你用了配置文件方式，务必以你本机安装的源码中字段名为准。

在跑 SWE-agent 之前，我建议先用 TaoToken CLI 做一次连通性自检。TaoToken 提供了一个命令行工具，安装和调用方式如下：

npm install -g @taotoken/taotoken
taotoken cc -k YOUR_API_KEY -u https://taotoken.net/api -m YOUR_MODEL_ID

如果 CLI 能正常返回模型响应，就说明你的 Key、Base URL、模型 ID 三个信息都能对得上，此时再去跑 SWE-agent 可以避开大量环境变量写错的迷惑。这个 CLI 本身不会介入 SWE-agent 的运行，它只是在我怀疑 API 配置有问题时，用来快速区分是 SWE-agent 配置问题还是 TaoToken 凭证问题。实际跑 5 个实例时，我并没有在 SWE-agent 的作业里调用这个 CLI，完全是通过刚才的 OPENAI_API_BASE 环境变量在传输。

3. 同一提示模板下的 5 个实例：pass@1 结果与原始日志

3.1 实例选择与运行方式

我首先从 Hugging Face 上的 princeton-nlp/SWE-bench_Verified 数据集拉取了实例索引，然后根据仓库名称排序，按顺序从不同仓库抽取了 5 个实例。为了避免无意中挑选到最简单的样本，我没有看每个实例的具体 issue 内容，只根据仓库名和编号做了均匀抽样。这样选出的实例分布在 Django、SymPy、scikit-learn、astropy 和 matplotlib 这几个仓库中，既有经典 web 框架，也有科学计算库，还有可视化库，任务类型不会过度集中。5 个实例的完整 instance_id 我建议你自己从数据集里拉取，因为盲贴一串 ID 并不有助于理解问题，而且这里我也没有获得授权去公开完整数据集内容。

运行期间，我保持 SWE-agent 的默认提示模板完全不变。SWE-agent 默认会为模型提供一套工具集，包括文件查看、搜索、编辑、执行命令等。每次运行前都会在一个全新的 Docker 容器里 checkout 对应的仓库和 issue 基线，然后让 agent 自由决定要调用哪些工具。我关闭了模型侧的采样随机性，但 Docker 构建和网络请求仍然会引入一些时间上的不确定因素，所以同一实例多次运行的结果不会完全一致。这也是为什么我在表格下方特别强调：一次运行得到的 pass@1 不能代表模型的真实水平。

3.2 本地复现结果表

下表是我在某天下午连续跑完 5 个实例后整理的结果。运行环境是 Ubuntu 22.04，Python 3.11，SWE-agent 从 GitHub 源码安装，Docker 版本为 24.0，模型温度设置为 0。Token 消耗数据来自 TaoToken 控制台用量记录，而不是 SWE-agent 自己的统计。

5 个实例中，agent 生成了 4 个 patch，其中 3 个通过了测试，所以本地单次 pass@1 为 60%。这个数字没有任何横向对比意义，因为只测了 5 个实例，而且一次运行可能受环境网络影响。比如 astropy 那个实例，第一次构建镜像时因为 apt-get 超时失败，SWE-agent 自动重试了一次才成功。如果重试也失败，结果估计就是 fail。因此我强烈反对把这张表里的百分比拿去和任何公开榜单比较，它只说明 TaoToken 的 API 通道在这次运行里没有出现请求中断、超时或乱码，模型本身的能力没有因为通道问题被削减。

3.3 失败案例与 Token 对账

最有价值的失败案例是 matplotlib 那个实例。agent 在读取 issue 后，连续多次执行 git diff 和 git status，似乎一直在检查当前仓库状态，但始终没有进入文件编辑器去修改代码。我翻了运行日志，发现它的上下文已经消耗到接近窗口上限，最后一步生成的是 git diff 的重复输出，没有再继续执行修改动作。这看起来像是模型在长上下文中丢失了“下一步该做什么”的意图，而不是 API 配置错误。如果遇到这种问题，通常的处理方法是给 agent 的自带提示模板里加一个“先定位，再修改，最后验证”的显式步骤，但这会改变提示模板，影响与基准的一致性，所以我这次没有调整，直接记录了 fail。

scikit-learn 那个实例生成了 patch，但测试没过。日志显示 agent 定位到了一个相关函数，并且修改了它的返回逻辑，可测试里另外还有一个边界条件需要处理。模型生成的 patch 没有覆盖到那个边界条件，所以测试失败。这种情况下 patch 生成得很快，但正确性不足。对比 Django 和 SymPy 两个通过实例，它们的共同点是 issue 描述里直接给出了失败函数名，模型可以精准定位；而 scikit-learn 的 issue 描述更偏向讨论某个行为，没有给出具体函数名，模型就把修改落在了错误位置。这些都是 agent 评测里常见的失败模式，和 API 通道的稳定性没有关系。

Token 对账方面，我在每次运行结束后去 TaoToken 控制台查看该 Key 的用量明细，发现记录里的输入 token 和输出 token 与 SWE-agent 日志中显示的 total_tokens 基本一致。这样我就确认，所有请求确实都走到了 https://taotoken.net/api，没有中途被路由到其他服务。如果你复现后发现控制台用量为 0，那一定是环境变量没有生效，SWE-agent 还在请求 OpenAI 官方地址。

4. 复现中踩过的三个配置/环境坑

4.1 Base URL 加 /v1 导致 404

这个坑我踩过。第一次配置时，我习惯性地把 Base URL 写成 https://taotoken.net/api/v1，结果 SWE-agent 日志里出现了 404 Not Found。原因是 TaoToken 的网关把 /api 作为根路径，请求会拼成 https://taotoken.net/api/v1/chat/completions，但正确的路径是 https://taotoken.net/api/chat/completions。把环境变量改回 https://taotoken.net/api 后，同样的 Key 和模型 ID 就不再报错。这个坑在使用多个 OpenAI 兼容服务时特别容易犯，因为有些服务商确实要求 /v1。TaoToken 的文档里直接给了 https://taotoken.net/api，所以我建议你严格按照文档来，不要对标其他服务商的做法。如果你已经加上了 /v1，并且不想改环境变量，倒是可以在 YAML 配置文件里把 api_base 写成带 /v1 的地址试试，但那样做的请求路径就不对了，至少我测试的版本会 404。

4.2 模型 ID 前缀缺失导致模型名无法解析

我一开始从模型广场复制 ID 时，只复制了后半段，漏掉了前面的 provider 前缀。比如广场上显示的是 openai/某模型，我只复制了 某模型，填进环境变量。SWE-agent 启动后日志报错：“Model not found” 或 “The model 某模型 does not exist”。这个报错很误导人，会让人以为是 Key 没有权限。实际上原因是 LiteLLM 在解析模型名时，需要从名字前缀判断走哪一家 API 协议。如果你给了一个没有前缀的名字，LiteLLM 会默认尝试去 OpenAI 官方找这个模型，自然找不到。解决办法就是让 OPENAI_MODEL 持有完整的模型 ID，并且在 --model 参数前加上 openai/。如果你的模型 ID 已经包含了 openai/，那么 --model openai/openai/某模型 这种嵌套前缀也是错的，需要去掉一层。总之，模型 ID 的准确形式完全以模型广场展示的字符串为准，不要自己拼接任何前缀或后缀。

4.3 Docker 构建环境超时不是 API 的问题

5 个实例里，astropy 的第一次运行卡在了 Docker 镜像构建阶段，日志里连续出现 apt-get update 超时。这时候 SWE-agent 还没有开始调用任何模型，所以不应该怀疑是 TaoToken 的问题。我检查了当时的 Docker 镜像拉取速度，发现基本镜像 python:3.11 从 Docker Hub 拉取时网络特别慢。换用国内的镜像加速器后，重新构建才成功。如果你复现时在日志里看到类似 Error response from daemon: Get https://registry-1.docker.io/v2/ 之类的错误，直接去调整 Docker 的镜像源，不要动 TaoToken 相关的配置。另外，有些实例的依赖安装脚本还会从 GitHub 或 PyPI 拉包，这些环节也可能超时。我这次只改动了 Docker 镜像加速，没有修改 SWE-agent 的任何超时参数，astropy 实例就恢复了正常。这个坑提醒我们，agent 类评测的结果受基础设施稳定性影响很大，一次失败不一定代表模型能力差。

5. 从这张表到你的复现：步骤与 CTA

5.1 复现步骤

如果你想得到一张和上面类似的结果表，并不需要跑完整个 SWE-bench 500 个实例。你可以只做四件事：第一，安装 SWE-agent，推荐从源码安装以便调试版本差异；第二，在 TaoToken 创建 API Key；第三，按第 2.2 节的方式设置三个环境变量；第四，从 SWE-bench Verified 数据集中任选 5 个实例，每个实例用独立的 --instance-id 参数运行。运行命令时一定记得指定 --log_dir，否则日志默认存在临时目录里，过几天就被系统清理掉了。我选择把日志放在项目下的 logs/ 目录，每个实例结束后重命名子目录，对应到实例编号，方便之后查询。

复现时不要只记录 pass/fail，建议同时记录每次运行的总耗时和 Token 消耗。耗时可以看 SWE-agent 终端输出的结束时间，或者用 time 命令包一层。Token 消耗去 TaoToken 控制台查看，按时间筛选到那一段窗口，把所有请求的 token 相加。如果你发现控制台里的记录和 SWE-agent 日志里的 token 数对不上，可以先检查是不是有重试请求，比如网络抖动导致 SWE-agent 自动重试了同一个请求，控制台里会有两条记录，而日志里只显示最后一条。我在 astropy 重试构建时没有增加模型请求，所以没有出现这种情况，但如果你的网络环境不稳定，就有可能出现。

5.2 对照你的结果

跑完后，把你的结果表和我这张放在一起看。重点不是对比谁高谁低，而是看看在相同提示模板、相同 Key、相同 Base URL 的情况下，pass@1 的差异有多大。如果你选的是完全相同的 5 个实例，可能也会得到不同的结果，因为 SWE-agent 的默认提示模板里包含了一定的随机工具调用顺序。我的建议是，如果你需要更稳定的评估，就选 10 个以上实例，每个实例跑 3 次，取多数票作为最终判定。那样得到的 pass@1 才有一点参考意义。只跑 5 实例一次，结果只适合做管道连通性验证。验证完管道之后，你真正要评估的是某个模型在 SWE-bench 上的表现，而不是 TaoToken 在 SWE-bench 上的表现。因为 SWE-bench 公榜上登记的是模型，不是 API 供应商。

最后，回到 TaoToken 控制台，翻一遍这次 5 个实例产生的用量记录，看看每一笔请求是否都如实在账单上体现。我这次复现时发现，TaoToken 控制台里的用量统计不仅包括输入和输出 token，还可以按模型 ID 筛选，这对做成本审计很有帮助。如果你打算长期跑 agent 任务，建议你在同一把 Key 下单独创建一个“复现专用”的 Key，这样控制台里的用量记录就能和这次评测日志严格对应，不会被其他无关请求污染。创建新 Key 时的入口，就在这次创建 API Key 的同一个控制台页面。

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