1. 从 Meta SSR 说起：Self-play RL 在 Coding 场景到底在练什么
Self-play RL 放到 Coding 场景里，本质是让同一个模型分饰两角：一个负责往能跑通的代码里“埋雷”，另一个只拿着被弱化过的测试补丁去“排雷”。Meta FAIR 与 TBD Lab 那篇 SSR（Self-play SWE-RL）最抓人的点，是它把“人类写 Issue、人类写测试”这条数据供应链彻底绕开了——只给一个打好依赖的 Docker 镜像，剩下的测试发现、解析、运行命令全由 Injection Agent 现场探索。这件事对做 AI 应用开发的我们意味着什么？意味着你不需要先攒几千条带标注的修复数据，也能在本地搭一个“模型自己出题、自己解题、自己记错题本”的最小闭环。
我先把 SSR 的核心循环拆成能落地的三件事。第一件是 Bug 制品（Artifact），它不是一个模糊的“请修 bug”提示，而是一组文件：bug_inject.diff在业务代码里植入缺陷，test_weaken.diff把会暴露缺陷的断言删掉或弱化，test_script.sh负责跑测试并输出文本日志，test_parser.py把日志转成{test_id: pass/fail}的 JSON 供奖励计算，test_files.txt记录哪些测试文件参与验证，防止 Solver 靠改测试作弊。第二件是双角色奖励：Injection 端拿到的奖励是分段的，一致性失败给 -1.0，Bug 不可解（solve-rate s=0）或太简单（s=1）给 -α，只有理想难度 0<s<1 才给 1-(1+α)s，目标是把 solve-rate 拉到约 0.2；Solver 端则是二进制的，全部测试通过 +1，否则 -1。第三件是参数共享加同时 RL 更新，两个角色的梯度一起回传，让模型同时学会“造难”和“解难”。
为什么这套东西值得你在本地复现？因为它的工程门槛比想象中低。旧范式依赖 GitHub Issue/PR、人类写的自然语言描述和测试用例，数据标着天花板；SSR 只需要一份能跑起来的镜像，数据随训练无限增殖。你要做的不是复刻 Meta 的完整训练集群，而是用统一 Key 把多模型对战、奖励回传、失败重试这条链路先跑通。下面我会用 TaoToken 作为统一 API 通道，给出可复制的环境变量、Base URL 配置、双角色对战脚本，以及验证请求和常见报错排查。适合谁：想跑通多模型自博弈闭环的开发者、做 Coding Agent 评测的同学、以及想理解 Self-play RL 奖励设计但不想从零搭训练框架的人。
2. TaoToken 前置：统一 Key 与 Base URL 怎么配才不踩坑
在动手写对战脚本之前，先把通道打通。TaoToken 在这里扮演的角色是统一 Key 和统一 Base URL 的入口，让你用同一套凭证去调用不同模型，省掉为每个模型单独维护 endpoint 和鉴权的麻烦。官网入口是 https://taotoken.net/?utm_source=taotoken_aicg_blog_end&utm_medium=csdn&utm_campaign=rewrite&utm_content= ，API 地址是 https://taotoken.net/api ，注意 API 地址后面不加 UTM 参数，配置时直接写这个根路径即可。
你需要准备的东西只有三样：一个可用的 API Key、一个模型 ID、以及正确的 Base URL。模型 ID 的选取建议遵循“双角色可同源也可异源”的原则——SSR 论文里两个角色共享同一套权重，但你本地复现时完全可以先用两个不同模型跑通链路，再换成同模型自博弈。比如 Injection 端用擅长代码生成的模型，Solver 端用擅长长上下文推理的模型，等奖励回传稳定后再统一。
环境变量建议这样组织，避免把 Key 硬编码进脚本：
export TAOTOKEN_API_KEY="sk-你的实际Key" export TAOTOKEN_BASE_URL="https://taotoken.net/api" export INJECT_MODEL="你的注入角色模型ID" export SOLVE_MODEL="你的求解角色模型ID"如果你用的是 OpenAI 兼容的 SDK，Base URL 直接填https://taotoken.net/api，SDK 会自动拼接/v1/chat/completions这类路径。这里有个容易踩的坑：有人把 Base URL 写成https://taotoken.net/api/v1，结果请求变成/api/v1/v1/chat/completions直接 404。正确做法是只写到/api，让 SDK 自己补版本段。
关于 Key 的获取和模型列表，你可以走 API Keys 页面和接入文档，这两个入口在 CTA 部分我会给出带归因参数的链接。这里先强调配置纪律：Key 只放环境变量，脚本里用os.environ读取；Base URL 统一常量；模型 ID 单独抽成变量，方便你后面做 A/B 对战。如果你打算长期跑训练闭环，建议直接上 Coding Plan，因为自博弈会产生大量高频请求，按量计费在调试阶段容易失控，而套餐制更适合这种“跑一晚上看曲线”的场景。
配置完成后先别急着写对战逻辑，用一条最小请求验证通道是否通。下面这段 Python 代码可以直接复制，作用是发一条最简单的对话请求，确认 Key、Base URL、模型 ID 三者都对：
import os from openai import OpenAI client = OpenAI( api_key=os.environ["TAOTOKEN_API_KEY"], base_url=os.environ["TAOTOKEN_BASE_URL"], ) resp = client.chat.completions.create( model=os.environ["INJECT_MODEL"], messages=[{"role": "user", "content": "回复两个字：通了"}], ) print(resp.choices[0].message.content)如果这行打印出“通了”，说明通道没问题，可以进入下一步。如果报 401，检查 Key 是否有多余空格；如果报连接错误，检查 Base URL 是否写成了带/v1的版本。这一步看起来简单，但后面所有对战脚本都依赖它，先把地基打牢。
3. 可复制配置：双角色对战脚本与奖励回传骨架
现在进入核心部分。我要给你的不是论文的完整复现，而是一个能在本地跑起来的最小闭环骨架：Injection 角色生成 Bug 制品，Solver 角色尝试修复，奖励函数根据测试结果回传，失败尝试进入错题本喂给下一轮。为了让配置可复制，我先给出一个 JSON 形式的角色配置，你可以直接存成ssr_config.json：
{ "base_url": "https://taotoken.net/api", "roles": { "injector": { "model": "你的注入角色模型ID", "system_prompt": "你是一个 Bug 注入器。给定一段可运行代码和测试，生成 bug_inject.diff 与 test_weaken.diff，并输出 test_script.sh 与 test_parser.py。", "temperature": 0.7 }, "solver": { "model": "你的求解角色模型ID", "system_prompt": "你是一个 Bug 修复器。你只能看到被弱化后的测试补丁的逆，以及报错仓库。请输出修复补丁。", "temperature": 0.2 } }, "reward": { "inject_consistency_fail": -1.0, "inject_too_easy": -0.3, "inject_ideal": 1.0, "solve_pass": 1.0, "solve_fail": -1.0, "target_solve_rate": 0.2 } }这个 JSON 里的target_solve_rate对应论文里 challenger 的最优解 p*≈0.2，意思是让 Injection 端把难度控制在 Solver 大约两成能解出来的水平，太简单或太难都会掉奖励。inject_too_easy我用了 -0.3 作为 α 的占位，你可以根据实际训练曲线调整。
接下来是对战脚本骨架。它的流程是：读配置、初始化两个 client、循环若干轮、每轮先让 injector 产出制品、再让 solver 尝试修复、根据测试结果算奖励、把失败样本写入错题本。为了让你能直接跑，我用伪代码加真实 API 调用的混合写法，测试执行部分用subprocess调test_script.sh：
import os, json, subprocess from openai import OpenAI cfg = json.load(open("ssr_config.json")) client = OpenAI(api_key=os.environ["TAOTOKEN_API_KEY"], base_url=cfg["base_url"]) def call_role(role, user_content): r = cfg["roles"][role] resp = client.chat.completions.create( model=r["model"], temperature=r["temperature"], messages=[ {"role": "system", "content": r["system_prompt"]}, {"role": "user", "content": user_content}, ], ) return resp.choices[0].message.content def run_tests(script_path): result = subprocess.run(["bash", script_path], capture_output=True, text=True) return result.stdout def parse_reward(log_text, parser_path): out = subprocess.run(["python", parser_path], input=log_text, capture_output=True, text=True) return json.loads(out.stdout) wrong_book = [] for step in range(150): artifact = call_role("injector", "基于当前仓库生成 Bug 制品") # 这里应把 artifact 落盘为 diff 并应用，省略文件写入细节 log = run_tests("test_script.sh") result = parse_reward(log, "test_parser.py") solve_rate = sum(result.values()) / max(len(result), 1) if solve_rate == 0 or solve_rate == 1: inject_reward = cfg["reward"]["inject_too_easy"] else: inject_reward = cfg["reward"]["inject_ideal"] fix_patch = call_role("solver", "根据逆测试补丁修复仓库") # 应用 fix_patch 后重跑测试 final_log = run_tests("test_script.sh") final_result = parse_reward(final_log, "test_parser.py") solve_reward = cfg["reward"]["solve_pass"] if all(final_result.values()) else cfg["reward"]["solve_fail"] if solve_reward < 0: wrong_book.append({"step": step, "artifact": artifact, "patch": fix_patch}) print(f"step={step} inject_r={inject_reward} solve_r={solve_reward} s={solve_rate:.2f}")这段脚本的关键设计点有三个。第一，奖励回传不是简单看“修没修好”，而是先算 solve_rate 再决定 Injection 端奖励，这样能防止注入器摆烂或出太简单的题。第二，失败尝试直接进wrong_book，下一轮可以把它作为高阶 Bug 喂回去，对应论文里“错题本”的机制。第三，test_parser.py的输出必须是{test_id: pass/fail}的 JSON，这是奖励计算的契约，格式错了整个闭环就断了。
如果你用的是 Cline MCP 或 Claude Code 这类工具来驱动，配置三件套要写全：Base URL 填https://taotoken.net/api，Key 填你的实际 Key，Model ID 填配置里的模型 ID。缺任何一个都会在调用时报鉴权或模型不存在。Codex 的auth.json同理，把这三项对应字段填对即可。CC Switch 场景下切换配置时，注意 Base URL 不要带尾斜杠，否则部分客户端会拼出双斜杠路径。
4. 验证请求与成功结果：怎么确认闭环真的在转
脚本写完不等于闭环跑通。你需要一组验证动作，确认“注入—求解—奖励—重试”这条链路每一环都有真实输出。我建议按下面四步走，每步都有可观察的成功标志。
第一步，验证 Injection 端能产出完整制品。单独调一次 injector，把返回内容打印出来，检查是否包含bug_inject.diff、test_weaken.diff、test_script.sh、test_parser.py、test_files.txt这五类文件。如果模型只返回了一段自然语言描述而没有 diff，说明 system prompt 需要加强结构化约束，比如明确要求“只输出 JSON，字段为文件名到内容的映射”。
第二步，验证测试脚本能跑并产出可解析日志。手动执行bash test_script.sh，看它是否输出文本日志；再执行python test_parser.py，看是否输出合法 JSON。这一步的成功标志是你能看到类似{"test_add": false, "test_sub": true}的结构。如果 parser 报 JSON 解析错误，多半是日志里混入了非测试输出，需要在脚本里加过滤。
第三步，验证奖励回传数值符合预期。跑 5 到 10 轮，观察打印出的inject_r和solve_r。正常情况下你会看到 solve_rate 在 0 到 1 之间波动，inject_r 在理想区间给正奖励，solve_r 偶尔给 +1 偶尔给 -1。如果 solve_rate 长期是 0 或 1，说明难度控制失效，需要调target_solve_rate或检查注入策略是否退化成“一行改值”这种 trivial 修改。
第四步，验证错题本真的被复用。在脚本里加一行日志，打印len(wrong_book)，跑 20 轮后这个数应该大于 0。然后手动取一条错题，把它作为下一轮 injector 的输入上下文，看 solver 是否仍然失败——如果仍然失败，说明这条错题确实是高阶 Bug，闭环在自我升级；如果一喂就过，说明错题难度不够，需要提高注入策略的多样性。
成功结果的形态是什么样的？参考论文 Figure 8 的曲线，你应该看到 solve_rate 稳定在 0.2 附近小幅震荡，而不是一路飙到 1 或跌到 0。同时wrong_book持续增长但增速放缓，说明模型在学会解决越来越难的题。如果你跑的是双模型对战，还可以对比两个模型互换角色后的曲线，观察哪个模型更适合当注入器、哪个更适合当求解器。
这里有个实测经验：奖励函数里的 α 不要设太大，否则注入器会倾向于出“不可解”的题来骗 -α 以外的惩罚规避，反而学不到东西。我试过把 α 从 0.3 调到 0.1，solve_rate 的震荡幅度明显收窄，曲线更接近论文里的稳定自我提升形态。
5. 本篇常见错排查：401、local proxy failed、reading choices、OAuth
跑闭环的过程中，报错基本集中在通道层和解析层。我把最常见的四类列出来，对照真实报错给排查路径。
第一类，401 Unauthorized。报错原文通常是Error code: 401 - {'error': {'message': 'Invalid API key'}}。原因有三个：Key 复制时带了换行或空格、Key 已失效、或者你把 Base URL 写成了别的域名导致鉴权头没发到正确服务。排查动作：先用echo $TAOTOKEN_API_KEY | wc -c看长度是否异常，再确认 Base URL 是https://taotoken.net/api。如果都没问题，去 API Keys 页面重新生成一个 Key 替换。
第二类，local proxy failed。这个报错一般出现在客户端配置了本地代理但代理没启动时，原文类似local proxy failed: connection refused。注意这里说的是本地网络配置问题，不是让你去搞什么网络工具。排查动作：检查你的 HTTP_PROXY/HTTPS_PROXY 环境变量是否指向了一个没在跑的本地端口，如果是就 unset 掉；检查客户端设置里是否开了“使用系统代理”但系统代理本身不可用。把代理配置清干净，直连https://taotoken.net/api通常就恢复了。
第三类，reading choices 相关报错。典型原文是KeyError: 'choices'或TypeError: 'NoneType' object is not subscriptable，发生在resp.choices[0]这一行。原因通常是请求返回了错误结构而不是正常 completion，比如模型 ID 写错时返回的是 error 对象。排查动作：在取 choices 之前先打印完整resp，看它到底是 completion 还是 error。如果是 error，检查模型 ID 是否在可用列表里；如果是空 choices，检查 messages 是否为空或格式不对。
第四类，OAuth 相关报错。如果你用 Claude Code 或类似工具接入，可能会遇到OAuth token expired或invalid_grant。这类报错说明你走的是 OAuth 鉴权路径而不是 API Key 路径。排查动作：确认你在工具里选的是 API Key 模式，Base URL 填https://taotoken.net/api，Key 填 API Key 而不是 OAuth token。如果你确实需要 OAuth 流程，去接入文档看对应工具的配置说明，不要混用两种鉴权方式。
除了这四类，还有一个隐蔽的坑：test_parser.py输出的 JSON 里 test_id 重复，导致sum(result.values())算出的 solve_rate 失真。排查动作是在 parser 里加一行去重断言，确保每个 test_id 只出现一次。这个坑不报错，但会让你的奖励曲线看起来很奇怪，早发现早省事。
6. 把闭环跑长：从最小复现到可持续的自我升级
最小闭环跑通之后，你大概率会想把它跑得更久、更稳。这里给几个不涉及训练框架改造的实用调整方向。
第一，把单轮对战改成批量对战。一次让 injector 生成 4 到 8 个 Bug 制品，solver 并行尝试修复，奖励取平均后再回传。这样做的好处是降低单次请求波动对奖励信号的干扰，曲线更平滑。批量大小受限于你的并发额度，如果用的是 Coding Plan，可以适当开大。
第二，给错题本加优先级。不是所有失败样本都值得回喂，优先选那些 solver 连续两轮都失败的题，这类题的信息量最大。你可以在wrong_book里给每条记录加一个fail_count字段，回喂时按 fail_count 降序取前 N 条。
第三，定期做角色互换。跑 50 轮后把 injector 和 solver 的模型 ID 对调，观察曲线是否还能维持。如果能，说明两个模型都具备双向能力；如果不能，说明其中一个模型在某个方向上偏弱，这本身就是有价值的评测信号。
第四，把奖励日志落盘成 CSV，字段包括 step、inject_r、solve_r、solve_rate、wrong_book_size。跑一晚上后直接用 pandas 画曲线，比在终端看打印直观得多。这一步不需要额外依赖，Python 标准库的 csv 模块就够。
如果你想把这条链路接到更完整的 Agent 工作流里，比如让模型自己决定什么时候注入、什么时候求解、什么时候请求人工介入，那就需要更细的奖励设计和状态管理。这部分可以先从模型对话里试提示词，确认角色行为符合预期后再固化进脚本。长期跑编码类自博弈任务的话，Coding Plan 在请求配额和稳定性上会比按量调用更省心，尤其是你需要连续跑几百轮的时候。
最后留一个我踩过的坑：不要在脚本里用time.sleep硬等测试执行，测试脚本本身可能卡住。给subprocess.run加timeout=60，超时就当失败处理并记录，否则整个闭环会挂在一个死循环的测试上。这个改动很小，但能让你第二天早上看到的是完整曲线而不是卡死的进程。
