1. 为什么要在 SWE-Bench 上跑 Codex AgentGPT-5.5 发布之后编程类 Agent 的评测热度又被拉高了一截。Terminal-Bench 2.0 拿到 82.7%、Expert-SWE 拿到 73.1%这些数字背后其实指向同一件事模型不再只是补全一段函数而是能自己规划路径、调工具、跑测试、看报错、再迭代。SWE-Bench 系列正好是检验这种「端到端修真实仓库 issue」能力的老牌场地所以很多团队在 GPT-5.5 上线后第一反应就是——把 Codex Agent 接到 SWE-Bench 上跑一轮看看自己关心的那类仓库问题到底能修掉多少。但真动手就会发现卡住你的往往不是模型本身而是三件琐事一是 Codex Agent 的配置文件骨架怎么搭二是模型通道怎么统一管理三是 SWE-Bench 的验证动作怎么设计才能看出「是真修好了还是碰巧过了测试」。这篇就按这三件事往下走给你一份可以直接复制的配置骨架再配上统一的 Key/API 通道接入步骤最后给出验证请求和预期结果。适合想快速跑通评测、又不想在环境上耗一整天的开发者。我试过把同一批 issue 分别走直连和统一通道配置层面的差异其实很小真正省时间的是 Key 不用来回换、日志能集中看。下面从通道准备开始。2. TaoToken 前置统一 Key 与 API 通道准备Codex Agent 在评测里会频繁发起请求一个 SWE-Bench 实例可能触发几十次工具调用和补丁生成。如果每个模型、每个环境都单独配一套 Key管理成本会迅速失控。TaoToken 在这里的角色就是一个统一的模型接入层你拿到一个 Key就能通过同一套 API 通道访问不同模型评测脚本里只维护一个 base_url 和一个 api_key。先访问官网了解整体能力https://taotoken.net/?utm_sourcetaotoken_aicg_blog_endutm_mediumcsdnutm_campaignrewriteutm_content然后进控制台创建 Keyhttps://taotoken.net/console?utm_sourcetaotoken_aicg_blog_endutm_mediumcsdnutm_campaignrewriteutm_contentKey 管理页在这里可以随时新建、吊销、查看用量https://taotoken.net/api-keys?utm_sourcetaotoken_aicg_blog_endutm_mediumcsdnutm_campaignrewriteutm_contentAPI 通道地址固定为 https://taotoken.net/api 注意这个地址不带任何查询参数配置时直接填即可。如果你用的是兼容 OpenAI 协议的客户端或 SDK把 base_url 指向它、把 Key 填进去就能跑。注意Key 只放在环境变量或本地密钥文件里不要写进会提交到 Git 的配置文件。评测仓库经常要 push 结果硬编码 Key 是最常见的翻车点。对于长期跑评测、需要反复调用 Codex Agent 的场景可以顺带看一下 Coding Plan它更适合高频、长周期的编码任务https://taotoken.net/coding-plan?utm_sourcetaotoken_aicg_blog_endutm_mediumcsdnutm_campaignrewriteutm_content通道准备好之后先别急着上 SWE-Bench用一次最小请求确认链路是通的。3. 可复制的 Codex Agent 配置骨架这一节给的是配置文件骨架不是某个特定版本的完整仓库。你可以把它当成模板按自己的目录结构改路径。核心思路是把「模型通道」「Agent 行为」「SWE-Bench 运行参数」三层分开这样换模型或换评测集时只动一层。先建目录mkdir -p codex-swebench/{config,agent,scripts,logs} cd codex-swebench环境变量文件.env只放通道信息# .env TAOTOKEN_API_KEYsk-你的Key TAOTOKEN_BASE_URLhttps://taotoken.net/api CODEX_MODELgpt-5.5 SWEBENCH_DATASETprinceton-nlp/SWE-bench_Lite SWEBENCH_SPLITtest MAX_WORKERS4Agent 主配置config/agent.yaml这是骨架里最关键的一份# config/agent.yaml agent: name: codex-swebench-agent model: ${CODEX_MODEL} provider: base_url: ${TAOTOKEN_BASE_URL} api_key_env: TAOTOKEN_API_KEY protocol: openai-compatible max_turns: 40 max_tokens_per_turn: 8192 temperature: 0.2 tools: - name: shell enabled: true timeout_sec: 120 - name: file_edit enabled: true backup: true - name: test_runner enabled: true command: pytest -q - name: git_diff enabled: true workspace: root: ./workspace reset_before_each_instance: true keep_patch: true patch_dir: ./logs/patches loop: plan_then_act: true reflect_on_failure: true max_retry_per_instance: 2 stop_on_test_pass: true几个参数值得单独说。max_turns控制单个实例最多交互多少轮SWE-Bench 的 issue 复杂度差异很大设太小会在长任务上提前放弃设太大又容易在死循环里烧 token40 是一个比较稳的起点。temperature压到 0.2 是为了让补丁更稳定评测场景不需要发散。stop_on_test_pass打开后一旦目标测试通过就停止避免 Agent 继续「优化」把已经对的补丁改坏。SWE-Bench 运行配置config/swebench.yamldataset: name: ${SWEBENCH_DATASET} split: ${SWEBENCH_SPLIT} instance_ids: [] # 留空表示跑全量调试时填具体 id run: max_workers: ${MAX_WORKERS} timeout_per_instance_sec: 900 retry_failed: 1 evaluation: apply_patch: true run_tests: true report_dir: ./logs/reports metrics: - resolved_rate - patch_apply_rate - avg_turns - avg_tokens启动脚本scripts/run_eval.sh#!/usr/bin/env bash set -euo pipefail export $(grep -v ^# .env | xargs) python -m agent.run \ --agent-config config/agent.yaml \ --bench-config config/swebench.yaml \ --output-dir ./logs \ --log-level INFO这份骨架的好处是每一层都能单独替换。想换模型只改.env里的CODEX_MODEL想换评测集只改SWEBENCH_DATASET想调 Agent 行为只动agent.yaml。评测脚本本身不用改。4. 验证请求与成功结果配置搭好之后先做一次链路验证再跑单实例最后才跑批量。这个顺序能帮你把「通道问题」和「Agent 问题」分开定位。第一步验证通道。用 curl 发一个最小请求curl -s https://taotoken.net/api/v1/chat/completions \ -H Authorization: Bearer $TAOTOKEN_API_KEY \ -H Content-Type: application/json \ -d { model: gpt-5.5, messages: [{role: user, content: reply with ok}], max_tokens: 16 }预期结果是返回一个标准 JSONchoices[0].message.content里有内容HTTP 状态码 200。如果这里就报 401说明 Key 或环境变量没生效报 404检查 base_url 是不是多写了路径。第二步跑单个 SWE-Bench 实例。先在swebench.yaml的instance_ids里填一个你熟悉的仓库 issue比如某个小项目的 bug 修复dataset: name: princeton-nlp/SWE-bench_Lite split: test instance_ids: - django__django-11099然后执行bash scripts/run_eval.sh跑完后看logs/reports/下的报告。一个成功的单实例结果应该包含这几项patch_apply_rate: 1.0表示补丁能干净地打到仓库上resolved_rate: 1.0表示目标测试通过avg_turns在 10 到 25 之间比较正常avg_tokens能反映这次修复的成本。第三步跑批量。把instance_ids清空max_workers设成 4重新执行。批量跑的时候重点看两个指标resolved_rate的整体水平以及patch_apply_rate和resolved_rate之间的差距。如果补丁能打上但测试不过说明 Agent 理解了问题但改错了地方如果补丁都打不上多半是文件定位或 diff 格式的问题。提示批量跑之前先把logs/patches清空否则新旧补丁混在一起排查时会很痛苦。想直接对比不同模型在同一批 issue 上的表现可以在模型对话里手动试几个 prompt感受一下差异https://taotoken.net/chat?utm_sourcetaotoken_aicg_blog_endutm_mediumcsdnutm_campaignrewriteutm_content5. 本篇常见错排查评测跑不起来八成是下面这几类问题。按出现频率排一下。Key 读取失败。表现是启动就报 401 或api_key not found。先确认.env里的变量名和agent.yaml里api_key_env写的一致再确认run_eval.sh里的export真的把变量导进去了。用echo $TAOTOKEN_API_KEY检查一下如果为空就是加载顺序的问题。base_url 写错。常见的是把https://taotoken.net/api写成带/v1或带查询参数的地址。通道地址就是https://taotoken.net/apiSDK 内部会自己拼路径。多写一段就会 404。补丁打不上。看patch_apply_rate如果明显低于resolved_rate说明 Agent 生成的 diff 格式有问题或者它改的文件路径和仓库实际结构对不上。检查agent.yaml里file_edit.backup是否打开备份能帮你还原被改乱的工作区。测试一直不通过但 Agent 不停止。这是max_turns设太大加上reflect_on_failure反复重试导致的。把max_retry_per_instance降到 1同时确认stop_on_test_pass是 true。SWE-Bench 的测试命令要和仓库实际用的框架一致pytest -q不是万能的有些仓库用tox或自定义脚本需要在test_runner.command里改。并发跑崩。max_workers设太高会导致工作区互相污染尤其是多个实例共用同一个workspace.root的时候。要么给每个 worker 分配独立子目录要么把并发降到 2 到 4。日志里如果出现文件被同时改写基本就是这个原因。token 消耗异常。单个实例avg_tokens远超预期通常是 Agent 在某个报错上循环。打开reflect_on_failure的同时限制重试次数并在日志里搜retry看它卡在哪一步。接入相关的细节如果对不上可以对照接入文档再核一遍参数https://taotoken.net/doc?utm_sourcetaotoken_aicg_blog_endutm_mediumcsdnutm_campaignrewriteutm_content6. 把评测跑成可复用的流程跑通一次 SWE-Bench 不难难的是让它变成一个能反复用、结果能对比的流程。几个实际经验把每次运行的配置快照存进logs/包括.env的脱敏版本和两份 yaml这样两周后回头看结果时知道当时用的什么参数补丁目录按时间戳分文件夹别覆盖报告里除了resolved_rate把avg_turns和avg_tokens一起记下来这两个数能告诉你「修好了」和「修得划算」之间的差别。如果你打算长期跑 Codex Agent 做编码类任务Coding Plan 那条通道更适合高频调用配置方式和单次请求一致只是额度模型不同https://taotoken.net/coding-plan?utm_sourcetaotoken_aicg_blog_endutm_mediumcsdnutm_campaignrewriteutm_content最后一步把批量跑的结果和单实例结果对一下。如果单实例全过、批量掉一半问题几乎一定在并发隔离或超时设置上而不是模型能力。先修流程再谈模型。
