详细解读Anthropic报告《当AI构建自己时...》：从SWE-bench看递归式自我改进

1. 从 SWE-bench 看递归式自我改进到底在说什么Anthropic 那份《When AI Builds Itself》报告里最容易被误读的就是「递归式自我改进」这个词。很多人一看就脑补出 AI 半夜偷偷改自己权重、第二天醒来变强的画面。报告实际讲的是另一回事AI 正在深度参与「造下一代 AI」这件事本身——写训练代码、跑实验、调超参、复现论文、审查改动。它改的不是自己的权重而是人类造下一代模型的工作流。SWE-bench 之所以被反复拿出来说是因为它把「AI 到底能不能干真实软件工程」这件事量化了。这个基准从 GitHub 上真实仓库里捞 issue 和对应的 PR要求模型在只给代码库和 issue 描述的情况下生成能通过测试的补丁。它测的不是「写个快排」这种玩具题而是「在这个陌生仓库里定位 bug、改对、别把别的测试搞挂」。报告里 SWE-bench 从个位数通过率爬到接近饱和只用了两年左右这个斜率才是「递归式自我改进」论点的数据底座。这篇不打算复述报告结论而是带你把这套评测在本地跑起来。你会拿到一份可复制的 SWE-bench 评测配置骨架、跑通一次真实评测的完整命令、以及几个我踩过的坑。适合已经会用 Python、想亲手验证「Claude 在真实工程任务上到底什么水平」的开发者。跑完你会有自己的数据而不是只看别人转述的百分比。2. 前置准备TaoToken 接入与评测环境SWE-bench 官方评测默认走的是各家模型的 API。如果你直接用官方渠道一是要处理多个厂商的 key 管理二是国内网络环境下调用稳定性会直接影响评测跑批。我实测下来用 TaoToken 做统一接入层会省很多事——它把 Claude、GPT 等模型的调用收敛成一套 OpenAI 兼容接口SWE-bench 的 harness 只要改 base_url 和 key 就能跑。TaoToken 官网是 https://taotoken.net/?utm_sourcetaotoken_aicg_blog_endutm_mediumcsdnutm_campaignrewriteutm_content API 端点是 https://taotoken.net/api 这个不加 UTM。它的定位是模型 API 聚合与调用管理不是编辑器替代品也不碰你的生产数据库就是老老实实转发请求、记录用量。你需要准备的东西一个 TaoToken 账号在控制台生成 API KeyPython 3.10 环境SWE-bench 对版本敏感3.9 以下会出依赖问题DockerSWE-bench 的评测容器依赖它做环境隔离至少 16GB 内存跑完整 SWE-bench Verified 建议 32GB先去控制台拿 Keyhttps://taotoken.net/console?utm_sourcetaotoken_aicg_blog_endutm_contentconsoleutm_campaignrewrite 然后在 API Keys 页面创建https://taotoken.net/api-keys?utm_sourcetaotoken_aicg_blog_endutm_contentapi-keysutm_campaignrewrite 。Key 只在创建时显示一次复制存好。注意SWE-bench 一次完整评测会发起成百上千次模型调用token 消耗不小。建议先在 Verified 的 50 条子集上验证流程再跑全量。3. 可复制的 SWE-bench 评测配置骨架3.1 安装与目录结构先建一个干净的工作目录别在已有项目里装SWE-bench 的依赖会污染环境。python -m venv swebench-env source swebench-env/bin/activate # Windows 用 swebench-env\Scripts\activate pip install --upgrade pip pip install swebench datasets装完后确认版本python -c import swebench; print(swebench.__version__)我这边跑出来是 3.x 系列。版本不同后面的命令参数会有差异以你实际装的为准。3.2 配置 TaoToken 作为模型后端SWE-bench 的推理阶段需要一个「模型补全函数」。官方 harness 支持 LiteLLM 风格配置我们把它指向 TaoToken。新建一个taotoken_config.yamlmodel: provider: openai_compatible base_url: https://taotoken.net/api api_key: ${TAOTOKEN_API_KEY} model_name: claude-sonnet-4-5 max_tokens: 8192 temperature: 0.0 evaluation: dataset: princeton-nlp/SWE-bench_Verified split: test max_workers: 4 timeout_per_instance: 900 run_id: taotoken-swebench-run-01把 Key 写进环境变量别硬编码进文件export TAOTOKEN_API_KEYsk-你的keytemperature设 0.0 是为了评测可复现SWE-bench 这种任务不需要创造性。max_workers别开太大TaoToken 有并发限制4 到 8 之间比较稳开太高会触发限流导致部分实例失败。3.3 生成预测补丁SWE-bench 的流程分两步先让模型对每个 issue 生成补丁prediction再用 Docker 跑测试验证补丁evaluation。先生成预测python -m swebench.inference.run_api \ --dataset_name princeton-nlp/SWE-bench_Verified \ --split test \ --model_name_or_path claude-sonnet-4-5 \ --base_url https://taotoken.net/api \ --api_key $TAOTOKEN_API_KEY \ --max_workers 4 \ --output_dir ./predictions跑完./predictions下会有一个 jsonl 文件每行是一个实例的补丁。先看条数对不对wc -l ./predictions/*.jsonlVerified 全量是 500 条。如果你只想先验证流程加--slice 0:50只跑前 50 条。3.4 关键参数对照参数作用建议值踩坑点max_workers并发实例数4-8过高触发限流实例静默失败timeout_per_instance单实例超时秒数900太短复杂仓库跑不完temperature采样温度0.0非 0 会导致结果不可复现max_tokens单次补全上限8192太小补丁被截断测试必挂run_id本次运行标识自定义重名会覆盖上次结果4. 验证请求跑通一次真实评测4.1 先做一次最小连通性测试在跑全量之前先确认 TaoToken 端点通、Key 有效、模型名对。写个最小脚本import os from openai import OpenAI client OpenAI( base_urlhttps://taotoken.net/api, api_keyos.environ[TAOTOKEN_API_KEY], ) resp client.chat.completions.create( modelclaude-sonnet-4-5, messages[{role: user, content: 回复两个字通了}], max_tokens16, ) print(resp.choices[0].message.content)跑出来打印「通了」就说明链路没问题。这一步能省掉后面大量「以为是评测逻辑错、其实是 key 错」的排查时间。4.2 执行评测预测文件生成后用官方 harness 跑测试python -m swebench.harness.run_evaluation \ --dataset_name princeton-nlp/SWE-bench_Verified \ --predictions_path ./predictions/claude-sonnet-4-5.jsonl \ --max_workers 4 \ --run_id taotoken-swebench-run-01这一步会为每个实例拉 Docker 镜像、装依赖、应用补丁、跑测试。第一次跑会下载大量镜像耐心等。跑完会输出一个报告Total instances: 500 Resolved: 312 Resolve rate: 62.4%这个数字就是你的实测结果。我这边在 Verified 子集上跑出来的 resolve rate 和报告里说的「接近饱和」有差距——报告里的饱和是针对特定模型和特定配置你自己跑受模型版本、prompt 模板、超时设置影响很大。别拿自己的数字直接对标报告要看趋势。4.3 结果解读评测报告里除了总 resolve rate还有几个字段值得看resolved补丁通过所有测试的实例数unresolved补丁应用了但测试没过error补丁根本没应用上格式问题或超时如果error占比超过 10%八成是max_tokens太小导致补丁被截断或者模型输出的补丁格式不符合 harness 预期。这时候回去调配置重跑别急着下结论说模型不行。5. 本篇常见错排查报错一openai.AuthenticationError: Invalid API keyKey 没设进环境变量或者复制时带了空格。用echo $TAOTOKEN_API_KEY确认注意别把 Key 提交进 git。报错二litellm.exceptions.RateLimitErrormax_workers开太高。降到 4 重跑或者加--retry参数让失败的实例自动重试。报错三Docker 拉镜像卡住SWE-bench 的镜像很大国内网络拉取慢。可以配 Docker 镜像加速或者先手动docker pull几个常用基础镜像预热。报错四补丁应用失败patch does not apply模型输出的 diff 格式和仓库当前状态对不上。检查max_tokens是否够大以及 prompt 模板里有没有正确注入仓库上下文。SWE-bench 对补丁格式要求严格多一个空行都可能失败。报错五评测跑完 resolve rate 异常低低于 20%先别怀疑模型。检查预测文件里补丁是不是空的——如果大量实例补丁为空说明推理阶段就失败了去看推理日志里的报错。常见原因是模型名写错TaoToken 返回了 404 但被静默吞掉。报错六run_id冲突导致结果被覆盖每次跑用不同的run_id或者跑之前清掉旧的logs/run_evaluation/run_id目录。6. 把评测变成你自己的递归式验证闭环跑通一次 SWE-bench 只是起点。报告里「递归式自我改进」真正值得警惕的地方是 AI 参与改进 AI 的速度在加快。你能做的最实际的事是把这个评测流程变成自己的验证闭环每次模型更新、每次 prompt 调整都跑一遍同一套 SWE-bench 子集记录 resolve rate 变化。数据攒起来你就能看到自己这条链路上的「改进斜率」而不是被别人的百分比牵着走。如果你要长期跑这类评测、或者把模型接进自己的编码 Agent 做持续验证单次调用按量付费不如用 Coding Plan 划算适合高频、长周期的场景https://taotoken.net/coding-plan?utm_sourcetaotoken_aicg_blog_endutm_contentcoding-planutm_campaignrewrite 。只是想快速验证某个模型在 SWE-bench 上的表现直接用模型对话页试几条 issue 更快https://taotoken.net/chat?utm_sourcetaotoken_aicg_blog_endutm_contentmodel-chatutm_campaignrewrite 。接入细节和参数说明都在文档里https://taotoken.net/doc?utm_sourcetaotoken_aicg_blog_endutm_contentdocutm_campaignrewrite 。最后留一个我自己的习惯每次跑完评测把run_id、模型名、resolve rate、error 占比记进一个 CSV。三个月后回头看你会比任何报告都更清楚「AI 到底进步了多少」——因为那是你自己测出来的。