1. RRSI 论文到底在解决什么：智能体 Harness 递归自我改进的过拟合陷阱
如果你正在做多智能体平台，大概率已经踩过这个坑：让一个 LLM 自动改 prompt、改控制流、改工具描述，改完在测试集上分数涨了，换一批任务立刻打回原形。谷歌这篇 RRSI 论文（Regularized Recursive Self-Improvement of Agent Harnesses）把这件事讲透了——harness 进化本质上是在一个有限的 evolve 集上反复做经验优化，这个动作本身就会过拟合。
先解释几个词。Harness 指的是包裹在冻结骨干模型外面的那一层：系统提示词、控制流、工具接口、记忆文件、上下文管理策略。同一个模型，harness 写得好不好，直接决定它能不能读对文件、能不能从失败命令里恢复、能不能把发现写进交付物。RRSI 要做的就是让 harness 自动进化，但加了一层正则化约束，防止进化出来的东西只是对某个 benchmark 的拟合。
论文最核心的观察是：evolve 集被跨轮次反复复用。第 t 轮提出的候选，依赖第 t-1 轮在同一批任务上测到的结果。这就是经典的 adaptive data analysis 问题——每多看一眼有限数据，有效样本量就被消耗一次。后果很直接：evolve 集分数虚高，但分布外（OOD）不涨甚至低于初始 harness。
论文给了一组很硬的数字。在 agentic workspace 任务上，未进化的基座 harness H0 的 OOD 均值是 39.7。此前最强的 Meta-Harness 在 evolve 集上考到 93.0，OOD 只涨了 0.9 到 40.6。TTHE 更惨，OOD 反而跌了 1.7 到 37.9，比不进化还差。RRSI 故意把 evolve 分压到 90.5（所有被进化 harness 里涨得最少的），OOD 却拉到 43.6，是唯一显著超过 H0 一分以上的方法。
这个交换关系是全文的题眼：evolve 分和泛化在这里是对立指标。你越想在那个被打分的 split 上考高分，就越容易把 benchmark 特有的模式编码进 harness，换一批任务就露馅。
论文还做了消融实验来证明正则化确实在起作用。去掉接受端正则，evolve 分从 90.5 升到 91.5，OOD 从 43.6 跌到 41.0，token 成本涨了一半。去掉提出端正则，evolve 只损失 0.2 分，OOD 却损失 1.7 分。两端都去掉，evolve 冲到全场最高的 92.8，OOD 停在 40.3，几乎回到原点，每次试验耗 380 万 token。完整 RRSI 只用 242 万 token，OOD 最高。
还有一个特别值得注意的结论：harness 是程序，不是权重。用 Gemini 3.5 Flash 进化出的 harness，原封不动拿到从未参与搜索的 Gemini 3.1 Flash Lite 上，Terminal-Bench 准确率从 11.2 升到 14.6，相对提升 30.4%。这说明学到的是可复用机制，不是对某个模型的拟合。对做 Agent 平台的人来说，这意味着 harness 进化能力应该沉淀为独立于具体模型版本的一层资产。
论文的边界也很清楚。它只覆盖冻结骨干下的 harness 级 RSI，不涉及进化中更新模型权重。全程无置信区间，主实验单一策略族（Claude Opus 4.8），超参对 domain 很敏感——β1 在三个 domain 取 44.5 / 35.4 / 24.4，δ 取 0.017 / 0.004 / 0.020，换 domain 必须重新校准。critic 只能拦显式泄漏，提示词里藏进 benchmark 风格线索这类隐式过拟合很难识别。复现门槛是算力：每个候选要在 evolve 集上跑多次真实 agent rollout。
对你做多智能体开发的迁移价值在于：选择端四道闸（泄漏筛查、噪声底线、成本-增益权衡、结构化剪枝）本质上是一套 agent 自改进的控制面/变更治理层，可审计、非补偿准入、可回滚。你可以直接抄的 pattern 包括余弦退火编辑预算、给每个 diff 结构化记账、窗口化无贡献组件剪枝、成本-增益线性闸门。
2. TaoToken 统一 Key 通道：多模型 Harness 进化的前置准备
RRSI 这类 harness 进化实验有个很现实的工程问题：proposer、analyst、critic、以及被进化的 agent 本身，往往需要调用不同厂商、不同规格的模型。Claude Opus 4.8 做 proposer，Gemini 3.5 Flash 做裁判，可能还要一个小模型做泄漏筛查。如果每个模型都单独申请 key、单独配 base URL、单独处理计费和限流，光是环境变量就能把你搞疯。
TaoToken 在这里的角色是统一 Key/API 通道。你只需要一个 API Key，就能在多个模型之间切换，base URL 统一指向https://taotoken.net/api。对 harness 进化这种需要频繁切换模型做对照实验的场景，这个统一层能省掉大量配置工作。
先说你需要的三件套：Base URL、API Key、Model ID。Base URL 固定是https://taotoken.net/api，API Key 在控制台创建，Model ID 按你要调用的模型填。这三样东西在后面的配置文件里会反复出现。
创建 Key 的入口在控制台的 API Keys 页面。登录后新建一个 Key，复制出来保存好——它只会完整显示一次。如果你要做多模型对照实验，建议按用途建多个 Key，比如一个给 proposer 用，一个给 critic 用，方便在账单里区分成本。
模型对话页面可以用来快速验证某个模型是否可用。在正式跑 harness 进化之前，先用对话页面发一条测试消息，确认 Key 和模型 ID 都对。这一步能帮你排除掉大部分配置问题。
如果你打算长期跑编码类 agent 和 harness 进化实验，Coding Plan 值得看一下。它针对高频编码调用做了额度优化，比按量计费更适合持续性的 agent rollout。RRSI 的复现成本主要就在 rollout 上——每个候选要在 evolve 集上跑多次真实 agent 执行，token 消耗量很大。
接入文档里有各语言 SDK 的配置示例。Python 用 openai 库的话，只需要改 base_url 和 api_key 两个参数。Node.js 类似。如果你用的是 Claude Code 这类工具，配置方式略有不同，需要设置 ANTHROPIC_BASE_URL 和 ANTHROPIC_AUTH_TOKEN。
这里要强调一点：TaoToken 是统一 API 通道，不是让你绕过什么。它的价值在于把多模型调用的配置复杂度收敛到一个 Key 上，让你能把精力放在 harness 逻辑本身，而不是环境变量管理。
对 RRSI 复现来说，统一通道还有个隐性好处：成本可观测。论文里反复强调 token 成本是选择端的重要约束（ΔC ≤ β0 + β1·ΔS），你需要能准确追踪每个候选、每个模型的 token 消耗。统一通道让所有调用走同一个计费口径，做成本-增益分析时不用在多个账单之间对账。
配置完成后，建议先跑一个最小验证：用同一个 Key 分别调用两个不同模型，确认都能正常返回。这一步过了，再进入 harness 配置环节。
3. 可复制的 Harness 配置片段：正则化递归自我改进的工程落地
这一节给你可以直接抄的配置。RRSI 的核心是把正则化拆到进化循环的两端：提出端控预算，选择端控准入。下面用 JSON 和 TOML 两种格式给出配置片段，你可以按自己的技术栈选。
先看 harness 进化的主配置。这个 JSON 对应论文里的超参表，我按 agentic workspace 的设置填了值：
{ "rrsi": { "evolution": { "T": 20, "k": 2, "delta": 0.004, "b_min": 1, "b_max": 4, "w": 3, "m_draft": 1, "n_prune": 4 }, "cost_gate": { "beta_0": 0.10, "beta_1": 35.4 }, "in_band_rule": { "w_s": 0.0, "w_c": 1.0, "w_n": 0.5 }, "domain_guard": { "enabled": false } } }解释几个关键参数。T 是进化轮次，agentic workspace 用 20 轮。k 是每个任务跑几次试验，取 2。delta 是经验噪声容忍度，0.004 对应约 14100 条标准判定中的 60 条。b_min 和 b_max 控制单轮能捆绑多少独立编辑，从 4 退火到 1。w 是停滞检测窗口，连续 3 轮进展落在噪声带内就触发结构化探索。n_prune 是剪枝窗口，4 轮内无正贡献的组件标记为删除目标。
cost_gate 里的 beta_0 和 beta_1 是成本-增益线性闸门：ΔC ≤ β0 + β1·ΔS。beta_0 设 0.10 表示可忽略的分数提升容忍 10% 成本增加，beta_1 设 35.4 表示每多一分改进允许追加 35.4% 成本。这个值对 domain 很敏感，换任务类型必须重新校准。
in_band_rule 处理增益未超过噪声容忍度的情况。w_s 设 0 表示分数提升本身不能让候选变得可接受，必须从更低成本（w_c）或结构新颖度（w_n）获得信用。
如果你用 TOML，等价配置如下：
[rrsi.evolution] T = 20 k = 2 delta = 0.004 b_min = 1 b_max = 4 w = 3 m_draft = 1 n_prune = 4 [rrsi.cost_gate] beta_0 = 0.10 beta_1 = 35.4 [rrsi.in_band_rule] w_s = 0.0 w_c = 1.0 w_n = 0.5 [rrsi.domain_guard] enabled = false接下来是模型调用的配置。这里用 TaoToken 统一通道，三件套齐全：
{ "llm_provider": { "base_url": "https://taotoken.net/api", "api_key": "sk-your-taotoken-key", "models": { "proposer": "claude-opus-4-8", "analyst": "claude-opus-4-8", "critic": "claude-opus-4-8", "judge": "gemini-3-5-flash" } } }proposer 负责生成候选 harness，analyst 写跨轮失败反馈，critic 做泄漏筛查，judge 在需要 LLM 裁判的环境里打分。你可以按预算把不同角色分到不同模型上。
如果你用 Claude Code 做 harness 编辑，settings 配置需要这样写：
{ "env": { "ANTHROPIC_BASE_URL": "https://taotoken.net/api", "ANTHROPIC_AUTH_TOKEN": "sk-your-taotoken-key", "ANTHROPIC_MODEL": "claude-opus-4-8" } }这个配置放在 Claude Code 的 settings.json 里。ANTHROPIC_BASE_URL 指向 TaoToken 的 API 地址，ANTHROPIC_AUTH_TOKEN 填你的 Key，ANTHROPIC_MODEL 指定模型 ID。三件套缺一不可。
如果你用 Cline 或类似的 VS Code 插件，MCP 配置里同样需要这三样。Base URL 填https://taotoken.net/api，API Key 填你的 Key，Model ID 按插件要求填。
Codex 的 auth.json 配置格式不同，但核心三件套一样：
{ "api_base": "https://taotoken.net/api", "api_key": "sk-your-taotoken-key", "model": "claude-opus-4-8" }配置写完后，先别急着跑完整进化。用一个小 evolve 集（比如 5 个任务）跑 2 轮，确认整个循环能走通。这一步能帮你发现配置错误，避免在完整实验跑到一半时才发现问题。
4. 验证请求与成功结果：跑通一轮自我改进闭环
配置就绪后，下一步是验证请求能正常发出、结果能正确解析。我按 RRSI 的进化循环拆成几个可独立验证的步骤。
第一步，验证模型调用。用 curl 发一个最小请求：
curl https://taotoken.net/api/v1/chat/completions \ -H "Content-Type: application/json" \ -H "Authorization: Bearer sk-your-taotoken-key" \ -d '{ "model": "claude-opus-4-8", "messages": [{"role": "user", "content": "Reply with OK only."}], "max_tokens": 10 }'预期返回里 choices[0].message.content 应该是 "OK"。如果返回 401，说明 Key 有问题；如果返回 model not found，说明 Model ID 写错了。这一步过了，说明统一通道配置正确。
第二步，验证 harness 评估。写一个最小评估脚本，用当前 harness 在 evolve 集上跑一次，记录分数和 token 成本：
import json from openai import OpenAI client = OpenAI( base_url="https://taotoken.net/api", api_key="sk-your-taotoken-key" ) def evaluate_harness(harness, tasks, k=2): scores = [] costs = [] for task in tasks: for _ in range(k): resp = client.chat.completions.create( model="claude-opus-4-8", messages=[ {"role": "system", "content": harness["system_prompt"]}, {"role": "user", "content": task["input"]} ] ) scores.append(score_task(resp, task)) costs.append(resp.usage.total_tokens) return sum(scores)/len(scores), sum(costs)/len(costs)score_task 是你自己的打分函数，编码任务可以用单元测试通过率，agentic workspace 可以用 rubric 判定。跑完后你会得到两个数：平均分 S 和平均 token 成本 C。
第三步，验证噪声带估计。在进化开始前，反复评估未改动的基座 harness，估计 delta：
baseline_scores = [] for _ in range(5): s, _ = evaluate_harness(base_harness, evolve_tasks) baseline_scores.append(s) delta = max(baseline_scores) - min(baseline_scores) print(f"noise band delta = {delta:.4f}")这个 delta 就是你的经验噪声容忍度。论文里 agentic workspace 取 0.004，但你的环境和任务集不同，必须自己校准。
第四步，跑一轮完整进化。用配置里的参数，从 H0 出发，跑 T 轮：
H = base_harness S_star = evaluate_harness(H, evolve_tasks)[0] for t in range(T): b_t = round(b_min + (b_max - b_min) * 0.5 * (1 + math.cos(math.pi * t / T))) feedback = analyze(H, evolve_tasks) candidates = propose(H, feedback, budget=b_t, n=m_draft) accepted = [] for H_prime in candidates: if not leakage_screen(H_prime): continue S_prime, C_prime = evaluate_harness(H_prime, evolve_tasks) delta_S = S_prime - S_star delta_C = (C_prime - C_current) / C_current if S_prime < S_star - delta: continue if delta_S > delta: if delta_C > beta_0 + beta_1 * delta_S: continue else: if w_s * delta_S - w_c * delta_C + w_n * novelty(H_prime) <= 0: continue accepted.append((H_prime, S_prime)) if accepted: H, S_star = max(accepted, key=lambda x: x[1]) print(f"round {t}: S_star={S_star:.4f}, budget={b_t}")跑完后你会看到 S_star 的变化曲线。关键观察点：evolve 分涨了多少，OOD 分涨了多少。如果 evolve 涨很多但 OOD 不涨，说明正则化没起作用，需要调 delta 或 beta 参数。
成功的结果应该长这样：evolve 分小幅上涨（比如 +1 到 +2 分），OOD 分同步上涨（+3 到 +4 分），token 成本没有大幅膨胀。如果 evolve 分暴涨而 OOD 不动，那就是过拟合了。
第五步，记录指标变化。每个候选的 diff、假设、ΔS、ΔC、是否被接受，都要结构化记账：
record = { "round": t, "component": "control_flow", "hypothesis": "add pre-completion verification audit", "diff": diff_text, "delta_S": delta_S, "delta_C": delta_C, "accepted": accepted_flag }这份记录是后续做信用分配和剪枝的依据。论文里强调，被拒绝的机制仍是负面证据，成功的机制保留明确信用。
跑通这一轮闭环后，你就有了一个可复现的 RRSI 基线。接下来可以做的实验：换不同骨干模型验证迁移性，去掉某一端正则看消融效果，或者调整 beta_1 看成本-增益权衡的敏感度。
5. 本篇常见错排查：401、local proxy failed、reading choices、OAuth
配置和运行过程中最容易撞上的几类报错，我按实际遇到的频率排一下。
401 Unauthorized。这个最常见，原因通常是 Key 没填对、Key 过期、或者 Authorization header 格式错了。检查三件事：Key 是否完整复制（没有多余空格），header 是否是Bearer sk-xxx格式，base URL 是否指向https://taotoken.net/api。如果你用的是 Claude Code，检查 ANTHROPIC_AUTH_TOKEN 而不是 ANTHROPIC_API_KEY，这两个变量名不一样。
local proxy failed / connection refused。这个报错通常出现在你本地配了代理但代理没启动，或者 base URL 写成了 localhost。检查你的环境变量里有没有 HTTP_PROXY / HTTPS_PROXY 指向一个不存在的本地端口。另外确认 base URL 没有误写成http://localhost:xxxx。统一通道的地址是https://taotoken.net/api，不需要本地代理。
reading choices 相关报错。这个通常出现在解析响应时。如果你用 OpenAI SDK，响应结构是resp.choices[0].message.content。如果报 KeyError 或 IndexError，可能是模型返回了空 choices，或者你用的 SDK 版本和 API 响应格式不匹配。先打印完整响应看看结构：
resp = client.chat.completions.create(...) print(resp.model_dump_json(indent=2))确认 choices 数组非空、message.content 存在。如果模型返回的是 tool_calls 而不是 content，需要按 tool_calls 结构解析。
OAuth 相关报错。如果你用 Claude Code 或类似工具，可能会遇到 OAuth token 过期或刷新失败。这类工具通常支持 API Key 和 OAuth 两种认证方式。用统一通道时，应该走 API Key 模式，在 settings 里配 ANTHROPIC_AUTH_TOKEN。如果工具强制走 OAuth，检查是否有配置项可以切换到 API Key 模式。
model not found。Model ID 写错了。不同厂商的模型 ID 格式不同，Claude 系列通常是claude-opus-4-8这种格式，Gemini 系列是gemini-3-5-flash。去模型对话页面确认可用的 Model ID 列表，别自己猜。
rate limit exceeded。并发太高或额度用完。RRSI 的 rollout 阶段会并发调用多个模型，容易触发限流。加一个重试逻辑：
import time from openai import RateLimitError def call_with_retry(client, **kwargs): for attempt in range(5): try: return client.chat.completions.create(**kwargs) except RateLimitError: time.sleep(2 ** attempt) raise RuntimeError("max retries exceeded")token 成本异常高。检查你的 harness 是不是在上下文管理上出了问题。RRSI 论文里特别强调，未正则化的进化会导致 token 占用无约束膨胀。如果你发现某个候选的 ΔC 远超 beta_0 + beta_1 * ΔS，说明成本闸门没生效，检查配置里的 beta 参数是否被正确加载。
evolve 分涨但 OOD 不涨。这是最需要警惕的。说明你的正则化没起作用，harness 在过拟合 evolve 集。排查方向：delta 是否设得太小（噪声被当成信号），critic 是否漏掉了显式泄漏，b_max 是否太大（单轮捆绑太多编辑导致无法归因）。按论文的消融结果，去掉任一端正则都会出现这个症状。
剪枝没生效，harness 越来越臃肿。检查 n_prune 窗口和 g_t(ℓ) 的计算。一个组件如果在 n_prune 轮内没有产生严格为正的增益，应该被标记为删除目标。如果你的实现里 g_t(ℓ) 用了累计增益而不是窗口内增益，剪枝就不会触发。
跨模型迁移失败。如果你用模型 A 进化的 harness 拿到模型 B 上效果不好，先确认 harness 里没有硬编码模型特定的行为。论文里跨骨干迁移成功的前提是 harness 学到的是可复用机制，而不是对某个模型输出风格的拟合。检查你的 harness 里有没有类似 "if model == 'xxx'" 的分支。
6. 从 RRSI 到你的 Agent 平台：统一 Key 通道下的持续进化
把 RRSI 的思路落到你自己的多智能体平台上，最直接的可迁移 pattern 是选择端四道闸。这四道闸本质上是 agent 自改进的控制面：critic 做泄漏审查，noise floor 保证稳定性，cost-gate 控制性价比，domain guard 守领域红线。任何对生产 harness 的改动都要过这四道闸，留痕、可审计、可回滚。
具体到工程实现，你可以先抄这几个 pattern。余弦退火编辑预算：b_t = b_min + (b_max - b_min) * 0.5 * (1 + cos(pi * t / T))，早期允许捆绑多改动探索新机制，后期强制稀疏可归因。结构化记账：每个 diff 记录 (组件, 假设, ΔS, ΔC, 是否采纳)，作为 proposer 的条件上下文。窗口化剪枝：固定 n_prune 轮内无正贡献的组件标记为删除目标。成本-增益线性闸门：ΔC <= beta_0 + beta_1 * ΔS，防止 token 占用无约束膨胀。
这些 pattern 和你现有的 agent loop 怎么结合？如果你已经在用反馈自动改 prompt 或工具描述，那你已经在做 RSI 了。缺的往往不是更强的 proposer，而是一个抗过拟合的选择端治理层。把四道闸加到你现有的选择逻辑里，就能显著降低过拟合风险。
TaoToken 统一 Key 通道在这个架构里的位置是基础设施层。它让你能用同一个 Key 调用 proposer、critic、judge 等不同角色的模型，成本统一口径，配置收敛到一个 base URL。对需要频繁做模型对照实验的 harness 进化场景，这个统一层能省掉大量环境管理开销。
如果你要复现论文的实验，建议按这个顺序：先跑通 coding 单域（Terminal-Bench + SWE-bench OOD），复现表 2 消融确认"去正则→evolve 涨 / OOD 跌 / token 涨"的方向，然后给关键 OOD 数字补多次重复估计置信区间。复现的主要门槛是算力——每个候选要在 evolve 集上跑多次真实 agent rollout，20 到 40 轮乘以多候选，token 消耗量不小。用 Coding Plan 做长期编码类实验会比按量计费更可控。
最后说一个论文里容易被忽略但很重要的点：harness 是程序资产，可以跨模型沉淀。表 4 给了实验支撑——用 Gemini 3.5 Flash 进化的 harness 拿到 Gemini 3.1 Flash Lite 上仍然有效。这意味着你做 Agent 平台时，harness 进化与治理应该作为独立于具体模型版本的一层，而不是每次发新模型就重写一遍。这一层的价值会随着你积累的 harness 资产增多而增长。
接入文档里有完整的 API 配置示例，模型对话页面可以快速验证模型可用性，API Keys 页面管理你的统一 Key。先把最小闭环跑通，再逐步加正则化约束，比一上来就配全套参数更容易定位问题。
