1. 从 Self-Refine 的 A/B 实验开始TaoToken 只提供 Key如果你在 Claude Code 里把同一个任务跑两遍一遍开 Self-Refine一遍关掉却忘了ANTHROPIC_BASE_URL和 Codex 的config.toml指向了不同供应商实验结论会被配置污染。先把供应商收敛到 TaoToken打开 https://taotoken.net/?utm_sourcetaotoken_aicg_blog_endutm_contentself_refine_intro 获取 KeyBase URL 填https://taotoken.net/api。本文只做一件事用可复现的对照实验验证 Skill 在 Self-Refine 之外到底有没有增量价值。注意TaoToken 在这个实验里的角色很窄它只提供 Key、Base URL 和模型调用入口。它不替你设计 Skill也不替你判断“有 Skill 一定更好”。真正要验证的是同一个任务、同一批 case、同一套评估脚本只有“是否加载 Skill”这个变量不同时Self-Refine 的最终通过率、轮数、Token 消耗和轨迹合规率会怎样变化。这和“Agent 自进化飞轮”里最容易混淆的概念直接相关。Self-Refine 属于 Artifacts 层让模型在单次任务里多改几版输出输出可能更好但任务结束就归零。Skill 属于 Harness 层把经验写成文件、持久化、跨会话加载下一次任务直接受益。Model 层微调权重当然更根本但成本高、周期长不适合大多数团队做第一轮验证。所以这篇文章不会把 Self-Refine 吹成自进化。它只是一个对照实验里的“基线增强器”。真正要回答的是无 Skill 时Self-Refine 能把哪些 case 从错改到对有 Skill 时同一批 case 是否更快、更稳、更合规难度梯度拉高后Skill 的增量价值是否反而更明显如果结果对了Agent 真的使用 Skill 了吗还是只是碰巧答对在相同 Token 预算下这个提升还成立吗实验开始前先记住一个工程原则配置必须可复制变量必须可隔离。下面从 Claude Code、Codex、CC Switch 三件套开始把接入层固定住。2. 实验设计把 Self-Refine 当基线把 Skill 当处理变量2.1 三组对照而不是两组很多团队只跑“有 Skill / 无 Skill”两组但这样会把 Self-Refine 的收益和 Skill 的收益混在一起。更清晰的做法是三组组别Self-RefineSkill目的A 组裸模型关无看模型本来就会不会B 组Self-Refine 基线开无看多轮自改能带来多少提升C 组Skill Self-Refine开有看持久化经验是否带来额外增量最关键的是 C 组相对 B 组。如果 C 组相比 B 组没有显著提升那 Skill 可能只是占了上下文窗口并没有产生实际贡献。如果 C 组相比 A 组提升很大但相比 B 组提升很小说明收益主要来自 Self-Refine而不是 Skill。2.2 难度梯度 case 怎么设如果 case 全是简单题模型裸跑也能对对照实验看不出差异。必须设计难度梯度。建议至少四档L1单步事实类。例如“把 2026/06/18 转成 ISO 日期”。L2多步规则类。例如“从日志里提取时间、状态码、请求 ID再按错误类型聚合”。L3跨工具链路类。例如“先查 API A 拿分页数据再去重再按字段生成摘要”。L4长尾陷阱类。例如“接口在空数组时返回{}而不是[]要求 Agent 识别并回退”。每档至少 5 条总共 20 条起步。case 要带标准答案或可自动校验的规则。开放型任务可以加 LLM Judge但必须配人工抽检和元评测集。2.3 指标不要只看最终正确率Self-Refine 很容易制造一种假象最终答案对了但过程很脏。所以建议记录六类指标首轮通过率第一版输出是否直接可用。最终通过率Self-Refine 结束后是否通过。Refine 轮数平均改了几轮。Token 消耗总输入 输出 Token。轨迹命中率运行轨迹里是否出现 Skill 定义的关键步骤。路径合规率结果对了之外是否走了规定校验步骤。其中轨迹命中率和路径合规率是 Skill 增量价值验证的关键。因为一个 Skill 可能“存在但没被使用”。Agent 靠自身能力答对Skill 只是躺在上下文里这种 Skill 不值得沉淀。2.4 评估器必须和生成器分离用同一个模型实例评价自己的输出容易出现自洽偏差。实验里至少做到生成模型和评估模型分离评估温度设为 0评估输出使用 JSON Schema 约束正确性、格式、效率、路径合规分开评每轮保留原始输入、输出、轨迹、评分。否则 C 组比 B 组高 5 分你都不知道是 Skill 有效还是评估器偏好长答案。3. Claude Code 配置settings.json 接入 TaoToken Base URL先把 Claude Code 的配置固定下来。进入 https://taotoken.net/?utm_sourcetaotoken_aicg_blog_endutm_contentself_refine_claude_setup 获取 Key然后编辑~/.claude/settings.json。{ env: { ANTHROPIC_BASE_URL: https://taotoken.net/api, ANTHROPIC_AUTH_TOKEN: YOUR_API_KEY, ANTHROPIC_MODEL: claude-sonnet-4-5 } }说明几点ANTHROPIC_BASE_URL只填https://taotoken.net/api不要带 UTM 参数。UTM 是官网页面用的不是 API Base URL 的一部分。ANTHROPIC_AUTH_TOKEN用你在 TaoToken 控制台创建的 Key 替换YOUR_API_KEY。ANTHROPIC_MODEL按你账号下可用的模型 ID 填。不同时间模型列表可能变化以控制台为准。不要把 Codex 的TAOTOKEN_API_KEY写进 Claude Code 的ANTHROPIC_AUTH_TOKEN也不要反过来。两套配置可以共用同一个 Key但变量名不要混。配置完成后在你本地终端启动 Claude Code发一个最小任务claude然后在会话里输入请只回答TaoToken Base URL 是什么如果返回正常说明 Claude Code 的接入层已通。如果报 401先检查 Key 是否替换如果报 404检查 Base URL 是否误填了页面地址如果模型不存在回到控制台确认模型 ID。这一步看似简单但对照实验里最常见的污染源就是配置。A 组用了一套供应商B 组切到另一套C 组又换了模型最后把结果差异归因给 Skill完全站不住脚。4. Codex 配置config.toml 单独走 OpenAI 兼容不要混 ANTHROPIC_*Codex 的配置和 Claude Code 不是同一套变量。Claude Code 用ANTHROPIC_*Codex 用config.toml和它自己的环境变量。不要把ANTHROPIC_BASE_URL或ANTHROPIC_AUTH_TOKEN写进 Codex 配置里否则会出现“配置看起来有但请求没走对”的问题。在 TaoToken 控制台创建 Key 后编辑~/.codex/config.tomlmodel gpt-5-codex model_provider taotoken [model_providers.taotoken] name TaoToken base_url https://taotoken.net/api env_key TAOTOKEN_API_KEY wire_api chat然后在本地终端设置环境变量export TAOTOKEN_API_KEYYOUR_API_KEY如果你希望持久化可以放到 shell 配置里或者交给 CC Switch 管理。注意base_url同样只写https://taotoken.net/api不要加 UTM。env_key指向TAOTOKEN_API_KEY不要写ANTHROPIC_AUTH_TOKEN。wire_api按 Codex 版本和模型兼容性选择。如果遇到流式异常优先检查这里是否与模型侧要求一致。Codex 的模型名和 Claude Code 的模型名不是一套命名。不要拿 Claude 模型名填 Codex也不要拿 Codex 模型名填 Claude Code。配置完后本地运行codex输入一个最小问题返回当前配置使用的 provider 名称。如果请求能正常返回说明 Codex 侧接入完成。接下来才进入 CC Switch 三件套把两套配置和 Key 管理起来。5. CC Switch 三件套多供应商切换不丢实验变量做对照实验时最怕的不是模型不聪明而是你切来切去切乱了。建议把三样东西固定在一个目录下~/.cc-switch/ ├── claude.settings.json ├── codex.config.toml └── taotoken.env其中taotoken.env只存 Keyexport TAOTOKEN_API_KEYYOUR_API_KEY export ANTHROPIC_AUTH_TOKENYOUR_API_KEY注意虽然这里两个变量都指向同一个 Key但它们在注入时分别服务于不同工具。Claude Code 读ANTHROPIC_AUTH_TOKENCodex 读TAOTOKEN_API_KEY。不要因为 Key 相同就混用变量名。切换脚本可以这样写全部在你本地执行#!/usr/bin/env bash set -euo pipefail PROFILE_DIR$HOME/.cc-switch cp $PROFILE_DIR/claude.settings.json $HOME/.claude/settings.json mkdir -p $HOME/.codex cp $PROFILE_DIR/codex.config.toml $HOME/.codex/config.toml set -a source $PROFILE_DIR/taotoken.env set a echo TaoToken profile applied.这个脚本做三件事切换 Claude Code 配置、切换 Codex 配置、加载 Key。它不碰你的业务数据库也不执行任何线上命令。实验用的 SQL、日志查询、API 调用都应在你本地或隔离测试环境中由你手动执行。如果你要对比不同供应商建议把每个供应商都做成一组三件套而不是在一个配置文件里反复改。因为实验记录里必须写清楚A 组用的哪个 Base URL、哪个 Key、哪个模型。配置可追溯结论才可复现。6. 跑对照实验难度梯度 case、Skill 示例与评分卡6.1 Skill 示例日期格式归一化不要写空泛的 Skill。Skill 要短、可执行、带反例。例如# skills/date-normalize.md 触发条件 用户要求转换日期格式或输入中出现多种日期写法。 步骤 1. 先识别源格式YYYY/MM/DD、MM-DD-YYYY、YYYYMMDD、自然语言日期。 2. 选择对应解析分支不要用字符串截断。 3. 统一输出 ISO 8601YYYY-MM-DD。 4. 输出前做一次格式校验正则匹配 ^\d{4}-\d{2}-\d{2}$。 反例 - 不要把 2026/06/18 直接截成 2026-06-18。 - 不要把 06/18/2026 当成 2026 年 6 月 18 日以外的解释。这个 Skill 很小但它包含触发条件、步骤、校验和反例。对照实验里C 组会加载它B 组不加载。6.2 轨迹评测确认 Skill 真被用了最终答案对不代表 Skill 被使用。需要在运行轨迹里检查关键步骤。例如required_steps [ identify_source_format, convert_with_mapping, validate_output ] def trace_hit_rate(trace, required_steps): hits 0 for step in required_steps: if any(step in event.get(name, ) for event in trace): hits 1 return hits / len(required_steps)如果 C 组最终正确率高于 B 组但轨迹命中率很低说明提升可能不是 Skill 带来的。如果轨迹命中了但路径合规率低说明 Agent 绕过了关键校验只是这次碰巧对了。下一次遇到脏数据就可能翻车。6.3 评分卡示例一轮本地复现可以记录成这样。下面是示例值不是行业结论你需要用自己的 case 重跑难度A 组首轮通过B 组 Self-Refine 最终通过C 组 Skill Self-Refine 最终通过C 相对 B 增量C 组轨迹命中率L18/109/109/10040%L25/107/109/10280%L32/105/108/10385%L41/103/107/10490%这个表最重要的信息不是具体数字而是趋势L1 太简单Skill 增量接近 0L2 到 L4 难度上来后Skill 的增量开始出现而且轨迹命中率同步上升。这说明 Skill 不是在所有场景都有用它主要解决“模型本来会一点但容易漏步骤”的中高难度任务。6.4 预算公平性检查还要看 Token。不要让 C 组靠 3 倍预算换 10% 提升。记录每组平均 Tokensummary { A: {pass_rate: 0.40, avg_tokens: 1200}, B: {pass_rate: 0.60, avg_tokens: 2100}, C: {pass_rate: 0.82, avg_tokens: 1800}, }如果 C 组通过率更高、Token 反而更低说明 Skill 降低了试错轮数这是高质量增量。如果 C 组通过率只高一点但 Token 暴涨那它可能只是多花钱买分。对照实验必须在预算接近的条件下对比否则很容易自欺欺人。7. 增量价值结论Skill 的收益出现在难度拐点之后把上面的实验收束一下可以得到四条可复现结论。第一Self-Refine 有用但它属于 Artifacts 层。它能让本次输出变好但任务结束后不改变 Agent 的长期行为。今天让模型多改三版解决日期格式明天遇到同类问题它还会从零开始。第二Skill 的价值不在“让模型第一次就全对”而在“减少重复试错”。在 L2 到 L4 难度上C 组通常表现出更少的 Refine 轮数、更高的轨迹命中率和更低的重复错误率。原因不是 Skill 比模型聪明而是 Skill 把“先识别格式、再转换、再校验”这类步骤从隐性经验变成了显式流程。第三简单任务测不出 Skill。如果 case 太简单无 Skill 也能过有 Skill 也只是增加上下文负担。所以对照实验必须带难度梯度。L1 没差异不代表 Skill 没用L2 到 L4 出现差异才说明增量价值需要难度拐点才能显现。第四最终答案正确率不是唯一证据。必须同时看轨迹和路径。一个 Skill 如果只是让最终答案看起来对了但 Agent 跳过了关键校验那它不是有效经验而是埋雷。下一次数据格式一变它就可能输出高置信的错误结果。一句话总结Self-Refine 是草稿迭代Skill 是经验持久化。对照实验的任务就是把“草稿带来的提升”和“经验带来的增量”拆开。8. 把对照实验接回自进化飞轮评测→记忆→落地→控制做完这组 A/B/C 实验你会发现它正好对应 Agent 自进化飞轮的四个齿。Self-Refine 只是第一层真正让 Agent 变好的是后面的信号、积累、落地和控制。8.1 评测是信号源不是周报数字在这个实验里评测不只是最后打个分。它承担三件事方向指引L2 到 L4 的失败模式告诉你 Skill 该写什么。质量门控C 组是否真的比 B 组好决定 Skill 是否值得保留。经验筛选哪些 case 的成功可以沉淀为 Skill哪些只是偶发。如果评测信号失真比如 LLM Judge 偏好长答案Agent 会学到“答案越长越好”而不是“任务越做越对”。所以评测器必须和生成器分离评估温度设为 0分维度独立评估并且定期用人工抽检校准。8.2 记忆是治理不是向量库实验产出的成功 case、失败 case、轨迹命中记录不能全塞进一个向量库。那会变成噪声池。正确做法是策展式写入只有明确成功的 case 才作为正例候选。失败 case 标记为反例写清楚“为什么此路不通”。规则级经验必须人工确认不能自动写入全局记忆。每条记忆带来源、版本、有效期和关联评测结果。否则一条错误经验被写入后会沿着后续几百次任务扩散。记忆系统首先要治理其次才是存储。8.3 落地是 Agent CI/CD不是一键全自动从“发现 Skill 有效”到“Skill 真正上线”中间还有很长的工程链路诊断归因是模型不会还是步骤缺失还是工具参数错了生成候选只生成 Diff不要全文重写 Skill。独立评测每个候选在隔离环境跑同一批 case。安全门控语法、回归、统计显著性、Playbook 一致性逐层过滤。人工确认安全边界、权限、拒答逻辑不能自动改。灰度发布小流量观察出 P0 退化自动回滚。监控回流灰度期新失败样本进入下一轮评测种子。经验沉淀有效方向写进 Playbook下一轮不重复踩坑。这里面最容易被忽视的是版本化。Skill、Prompt、记忆每次更新都要有版本号、变更日志、来源标记和关联评测结果。否则线上出问题只能“再改改试试”那是盲人摸象。8.4 控制是人机协作不是审核疲劳完全放手让 Agent 自己改自己风险很高。完全人工逐条审批又会把人累垮。更好的方式是分级自主稳定场景可以自动化程度高一些。新场景和高风险操作必须有人把关。规则级记忆写入前、安全边界调整、回归决策、冷启动种子、最终 Skill 确认这五个节点不能交给 Agent。如果每天弹 50 个审核请求其中 48 个是低质变体人三天后就会不看直接通过。这比没有审核更危险。解法是自动门控先过滤 95% 低质候选再批量异步审核并且让审核制度根据历史表现动态升降级。9. 常见报错与排查Base URL、Key、模型名、wire_api做对照实验时配置错误会伪装成“Skill 无效”。下面这些本地排查步骤可以省很多时间。9.1 Claude Code 报 401检查~/.claude/settings.json{ env: { ANTHROPIC_BASE_URL: https://taotoken.net/api, ANTHROPIC_AUTH_TOKEN: YOUR_API_KEY } }常见原因YOUR_API_KEY没替换Key 被引号或空格污染复制了 Codex 的TAOTOKEN_API_KEY但没对应到ANTHROPIC_AUTH_TOKEN环境变量覆盖了 settings.json 里的值。9.2 Codex 报 provider 不存在检查~/.codex/config.tomlmodel_provider taotoken [model_providers.taotoken] name TaoToken base_url https://taotoken.net/api env_key TAOTOKEN_API_KEY wire_api chat常见原因model_provider和[model_providers.xxx]名字不一致env_key写了ANTHROPIC_AUTH_TOKENBase URL 误填了官网页面地址本地没有export TAOTOKEN_API_KEY。9.3 请求 404 或模型不存在先确认 Base URL 是https://taotoken.net/api不是https://taotoken.net/也不是带utm_source的页面地址。UTM 只用于官网访问统计不用于 API。再确认模型 ID。Claude Code 和 Codex 的模型命名不同不要跨工具复制。控制台里可用模型为准。9.4 流式输出中断Codex 侧优先检查wire_api是否与当前版本兼容。Claude Code 侧则检查是否是模型名或网络层问题。不要用“切到另一个供应商”来掩盖配置问题因为那会直接破坏对照实验的变量隔离。9.5 CC Switch 切换后没生效检查三个文件是否真的复制到位ls -l ~/.claude/settings.json ls -l ~/.codex/config.toml env | grep -E TAOTOKEN_API_KEY|ANTHROPIC_AUTH_TOKEN如果文件正确但环境变量没加载重启终端或重新执行切换脚本。不要在跑 A 组时用 B 组的环境变量。10. 文末 CTA把对照实验跑起来再决定 Skill 要不要留如果你还没开始最省时间的顺序是这样先用模型对话验证任务本身能不能被模型理解https://taotoken.net/models/detail/chat?utm_sourcetaotoken_aicg_blog_endutm_contentself_refine_chat如果你要连续跑多组对照实验看 Coding Plan 是否更适合https://taotoken.net/coding-plan?utm_sourcetaotoken_aicg_blog_endutm_contentself_refine_coding_plan到控制台创建实验专用 Key不要和线上业务 Key 混用https://taotoken.net/console/api-keys?utm_sourcetaotoken_aicg_blog_endutm_contentself_refine_api_keys按 Claude Code 文档把settings.json配好Base URL 填https://taotoken.net/apihttps://taotoken.net/doc/ClaudeCodeAnthropic?utm_sourcetaotoken_aicg_blog_endutm_contentself_refine_claude_code_doc回到官网入口按同一套 Key 管理方式启动你的实验https://taotoken.net/?utm_sourcetaotoken_aicg_blog_endutm_contentself_refine_final_cta最后再强调一次实验原则TaoToken 只提供 Key、Base URL 和模型调用入口。Skill 有没有增量价值必须由你用有 Skill 与无 Skill 两组结果、难度梯度 case、轨迹命中率和预算公平性共同证明。Self-Refine 能让本次输出变好只有经过对照实验验证的 Skill才值得进入记忆系统、落地流水线和下一轮自进化飞轮。