强化学习 / OPD】OpenClaw-RL 源码阅读笔记 --- (7)--- Policy Serving 配置落地：TaoToken 统一 Key 接入 settings.json 骨架

1. 从源码到落地Policy Serving 为什么需要一个统一 Key如果你正在读 OpenClaw-RL 的源码大概率已经翻到OpenClawAPIServer这一层了。它对外是 FastAPI 代理对内把请求转发给 SGLang 推理引擎同时还要拦截 response、抽 logprobs、触发 PRM 评分、构造训练 Sample。源码里这条链路是清晰的但真正把训练跑起来之后很多人会卡在另一个问题上Policy Serving 这一层要调模型服务Key 和 API 通道到底怎么配才稳。强化学习训练和普通推理不一样。普通推理调一次模型就结束了而 OpenClaw-RL 的 rollout 是持续性的用户请求进来要转发、PRM 要评分、OPD 模式下 teacher forward 也要走模型服务。这些调用如果各自散落在环境变量、脚本参数、硬编码里改一次配置要翻五六个文件训练中断一次排查半天。所以把 Policy Serving 的模型接入收敛成一份统一的settings.json用同一个 Key 走同一个 API 通道是工程落地里很实际的一步。这篇是源码阅读笔记的第 7 篇聚焦 Policy Serving 配置落地。我会给出settings.json里 TaoToken 统一 Key 和 API 通道的可复制骨架然后走一遍 Policy Serving 请求的验证动作最后把常见的报错排查路径列清楚。目标很直接把源码里看懂的那层代理逻辑变成你本地能复现的服务接入配置。适合已经能跑通 OpenClaw-RL 训练、现在需要稳定调用模型服务的开发者。2. TaoToken 前置统一 Key 与 API 通道准备在写settings.json之前先把 TaoToken 这边的接入信息准备好。TaoToken 提供的是统一的模型 API 通道你拿到一个 Key 之后对话、编码、Agent 类请求都可以走同一个入口不用为每个模型单独维护一套鉴权。对 Policy Serving 这种要同时处理转发、评分、teacher forward 的场景来说统一通道能省掉很多配置分叉。第一步是拿 Key。打开官网 https://taotoken.net/?utm_sourcetaotoken_aicg_blog_endutm_mediumcsdnutm_campaignrewriteutm_content 进控制台创建 API Key。创建的时候建议按用途命名比如openclaw-policy-serving这样后面在训练日志里看到调用来源能对上。Key 只在创建时完整显示一次复制后先存到安全的地方。第二步是确认 API 基地址。TaoToken 的 API 入口是 https://taotoken.net/api 注意这个地址不带 UTM 参数配置里填的就是它。Policy Serving 里所有对模型服务的调用base_url 都指向这里具体路径由 SDK 或 httpx 拼接。第三步是确认你要调的模型名。OpenClaw-RL 源码里 RL server 默认SERVED_MODEL_NAMEqwen3-8bOPD server 默认qwen3-4b实际部署可以用环境变量覆盖。你在 TaoToken 这边要选对应的模型标识填进配置两边名字要对得上否则转发过去会报模型不存在。这里有个容易忽略的点Policy Serving 不只是转发用户请求它还要调 PRM 评分、OPD 模式下还要算 teacher logprobs。这些内部调用如果也走同一个 Key 和通道配置就只需要维护一份。所以settings.json的设计思路是把 Key、base_url、超时、并发这些公共项抽出来各个调用点引用同一份而不是每个模块各写一套。注意Key 不要写进会提交到 git 的文件里。settings.json建议放本地配置目录或者用环境变量注入后再读取源码仓库里只保留一份settings.example.json做模板。3. 可复制配置settings.json 骨架下面这份骨架是按 Policy Serving 的实际调用需求组织的。它把 TaoToken 的统一 Key 和 API 通道放在provider段Policy Serving 自己的转发、评分、teacher 调用分别引用这份公共配置。你可以直接复制把api_key换成自己的模型名按实际部署调整。{ provider: { name: taotoken, base_url: https://taotoken.net/api, api_key: sk-你的TaoTokenKey, timeout_seconds: 120, max_retries: 2, default_headers: { Content-Type: application/json } }, policy_serving: { listen_host: 0.0.0.0, listen_port: 30000, sglang_chat_url: http://127.0.0.1:30001/v1/chat/completions, served_model_name: qwen3-8b, submission_enabled: true, session_timeout_seconds: 600, max_concurrent_requests: 16, stream: true }, reward_judging: { enabled: true, provider_ref: provider, model: qwen3-8b, prm_endpoint: http://127.0.0.1:30002/generate, score_timeout_seconds: 60 }, opd: { enabled: false, provider_ref: provider, teacher_model: qwen3-4b, topk: 20, hint_judge_enabled: true }, logging: { level: INFO, log_request_body: false, log_response_logprobs: true } }几个字段说明一下。provider.base_url固定指向 TaoToken 的 API 入口api_key是统一 Key。policy_serving.sglang_chat_url是源码里forward_to_sglang()实际转发到的地址也就是 SGLang 推理引擎那一层它和 TaoToken 的通道是两回事前者是内部推理服务后者是模型 API 通道。reward_judging和opd段里的provider_ref都指向provider这样评分和 teacher forward 复用同一份 Key 和 base_url不用重复填。submission_enabled对应源码里的submission_enabled.is_set()控制 503 暂停开关。训练阶段切换时你可以通过改这个字段来暂停样本提交而不用重启整个服务。max_concurrent_requests对应源码里的 semaphore 并发控制Policy Serving 要同时服务真实用户、PRM 评分和 teacher forward并发给太小会拖慢 rollout给太大又可能压垮推理引擎16 是个可以起步的值按你的 GPU 情况调。opd.enabled默认 false因为 Binary RL 模式不需要 teacher。如果你跑的是openclaw-opd或openclaw-combine把它改成 trueteacher_model填对应模型。topk对应源码里_compute_teacher_topk_logprobs()的 top-k 计算20 是常见起点。配置读取这块建议在启动脚本里做一次校验Key 是否为空、base_url 是否可达、模型名是否在允许列表里。校验不过就直接退出别让服务带着错配置起来否则请求进来才报错排查成本高很多。4. 验证请求一次 Policy Serving 调用走通配置写完先别急着接训练。单独发一次请求确认 Policy Serving 这层能正常转发、能拿到 response、logprobs 能抽出来。这一步走通了再挂训练流程。先起服务。假设你的启动脚本读settings.json启动后监听 30000 端口。用 curl 发一个最小请求curl -X POST http://127.0.0.1:30000/v1/chat/completions \ -H Content-Type: application/json \ -H X-Session-Id: test-session-001 \ -d { model: qwen3-8b, messages: [ {role: user, content: 用一句话说明什么是策略服务} ], stream: false, logprobs: true, top_logprobs: 5 }这里X-Session-Id对应源码里的 session 管理Policy Serving 靠它区分不同会话做数据缓冲和状态刷新。logprobs和top_logprobs打开是因为源码里_extract_logprobs_from_chat_response()要从 response 里抽这些值关掉的话训练样本构造会缺数据。预期返回是一个标准的 chat completion 结构choices[0].message.content有回复内容choices[0].logprobs里有 token 级别的对数概率。如果返回里 logprobs 是空的先检查请求体里logprobs有没有传 true再检查 SGLang 那边启动参数有没有开 logprobs 支持。再验证一下 TaoToken 通道本身通不通。绕过 Policy Serving直接打一次 TaoToken 的 APIcurl -X POST https://taotoken.net/api/v1/chat/completions \ -H Authorization: Bearer sk-你的TaoTokenKey \ -H Content-Type: application/json \ -d { model: qwen3-8b, messages: [{role: user, content: ping}], max_tokens: 16 }这个请求返回正常说明 Key 和通道没问题。如果这个通了但 Policy Serving 转发失败问题就在本地服务配置或 SGLang 那一层不在 TaoToken 通道。这样分层验证能快速定位问题在哪一段。两步都通之后再看服务日志。正常的话日志里应该能看到请求进入、转发到 SGLang、response 返回、logprobs 抽取、样本缓冲这几步。如果submission_enabled是 true还会看到样本提交到 output_queue 的记录。这些日志对应源码里的调用链对着看能确认每一环都走到了。5. 常见报错排查路径Policy Serving 这层的报错大多集中在几个地方。下面按现象列排查路径。401 或鉴权失败。先确认settings.json里api_key填的是完整 Key没有多余空格或换行。再确认请求头里Authorization: Bearer格式正确。如果 Policy Serving 转发时没带上鉴权头检查转发逻辑有没有把 provider 段的 headers 透传过去。TaoToken 通道的鉴权失败直接打一次第 4 节的直连请求就能确认 Key 本身有没有问题。模型不存在或 model not found。这是模型名对不上。源码里 RL server 默认qwen3-8bOPD server 默认qwen3-4b你settings.json里served_model_name和teacher_model要跟实际部署一致。如果部署时用环境变量覆盖了SERVED_MODEL_NAME配置里也要同步改。两边名字差一个字符都会报这个错。连接超时或 connection refused。先看sglang_chat_url指向的地址和端口对不对。源码里这个地址是 Slime 自动分配后传给 API Server 的你手动配的时候要确认 SGLang 或 SlimeRouter 真的在监听那个端口。用curl直接打sglang_chat_url看通不通。如果 SGLang 没起来Policy Serving 转发必然失败。TaoToken 通道的超时检查timeout_seconds是不是太小长回复场景 120 秒起步比较稳。logprobs 为空导致样本构造失败。这个前面提过请求体里logprobs要开SGLang 启动参数也要支持。另外检查_extract_logprobs_from_chat_response()对应的解析逻辑确认 response 结构和解析代码匹配。如果 SGLang 版本升级改了返回结构解析可能拿不到值。503 服务暂停。这是submission_enabled被置为 false 了。源码里这个开关控制样本提交训练阶段切换时会用到。检查配置里这个字段或者看有没有代码在运行时改了它。如果是训练流程主动暂停等它恢复就行如果是误配改回 true 重启服务。并发打满导致请求排队。max_concurrent_requests给太小真实用户请求、PRM 评分、teacher forward 抢信号量就会排队。看日志里有没有等待信号量的记录适当调大这个值。但别一次调太大先小步加观察 GPU 利用率和延迟。session 超时导致数据丢失。session_timeout_seconds控制会话超时超时后_buffer_record()里的 pending records 可能被清理。如果发现训练样本比预期少检查这个值是不是太短长对话场景要适当放宽。排查的时候有个通用思路先分层再定位。TaoToken 通道、Policy Serving 本地服务、SGLang 推理引擎这三层用直连请求分别验证哪层不通就查哪层。别一上来就翻源码先把网络和配置层面的问题排掉剩下的再对着源码调用链看。6. 把配置沉淀下来让 Policy Serving 稳定跑源码读到第 7 篇Policy Serving 这层的逻辑应该比较清楚了它是代理、是数据采集点、是训练管道的入口但它本身不做推理。真正做推理的是 SGLang真正提供模型 API 通道的是 TaoToken 这类统一入口。把这两者分清楚配置就不会乱。settings.json这份骨架的价值在于收敛。Key 只有一份base_url 只有一份超时和并发只有一份各个调用点引用同一份配置。训练跑起来之后你要调并发、调超时、切 OPD 模式改的都是同一份文件不用满仓库找散落的参数。这对长期跑训练的场景很重要配置漂移是很多诡异问题的根源。如果你还在 Binary RL 阶段opd.enabled保持 false先把转发和 PRM 评分这条链路跑稳。等要上 OPD 或 combine 模式再把 teacher 相关配置打开用第 4 节的验证方法单独测一次 teacher forward。一步一步来比一次性全开好排查。Key 管理和通道配置这块控制台里可以创建多个 Key 按用途区分接入文档里有各语言 SDK 的调用示例。如果你后面要长期跑编码类或 Agent 类任务Coding Plan 那条线也可以了解一下和 Policy Serving 的模型调用是互补的。配置落地这件事做完一次后面就是复用和微调把时间留给训练本身。