1. 先固定 Key 和 Base URL预算公平从供应商可切换开始在 TaoToken 官网https://taotoken.net/?utm_sourcetaotoken_aicg_blog_endutm_contentbudget_fairness_intro拿到 Key 后先把 Base URL 固定成 https://taotoken.net/api再跑 Best-of-N 关闭对照否则你看到的通过率上涨很可能只是 completion_tokens 上涨。这个判断不是凭感觉同一条评测 casen1 和 n8 的 token 账本完全不是一个量级。很多团队把 n8 的 passN 写成“Agent 自进化成功”但把 n 调回 1 后指标打回原形。问题不在模型而在实验没有做预算公平。TaoToken 在本文只做一件事签发 Key、提供可替换的 Base URL。评测脚本、评分器、记忆治理、灰度门控仍然在你本地或 CI 里执行。这个边界很重要——只有供应商可切换、调用账本能对齐才有资格讨论“同预算下是否真的更聪明”。先从官网拿 Keyhttps://taotoken.net/?utm_sourcetaotoken_aicg_blog_endutm_contentbudget_fairness_key。拿到 YOUR_API_KEY 后不要直接开始烧 Best-of-N。先把三个客户端的配置固定下来避免变量污染。Claude Code 的 settings.json 可以这样写{ env: { ANTHROPIC_BASE_URL: https://taotoken.net/api, ANTHROPIC_AUTH_TOKEN: YOUR_API_KEY } }如果 Claude Code 版本使用 ANTHROPIC_API_KEY按 Claude Code 文档替换变量名即可但 Base URL 保持 https://taotoken.net/api。不要把 ANTHROPIC_* 变量塞给 Codex。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 # 按 Codex 文档选择 chat 或 responses本地环境只注入export TAOTOKEN_API_KEYYOUR_API_KEY不要在 Codex 配置里出现 ANTHROPIC_BASE_URL 或 ANTHROPIC_AUTH_TOKEN。两套工具的协议和变量不要混用。如果你用 CC Switch 管理多套供应商维护三件套就够Provider 名称、Base URL、API Key。例如{ provider: TaoToken, baseUrl: https://taotoken.net/api, apiKey: YOUR_API_KEY }CC Switch 切的是 Claude Code 侧配置不要拿它去改 Codex 的 config.toml。配置完成后先跑一条 hello-world再记录 request_tokens、completion_tokens、total_tokens 三个字段。预算公平的第一步不是写评测而是让每次调用都有账本。官网入口在这里https://taotoken.net/?utm_sourcetaotoken_aicg_blog_endutm_contentbudget_fairness_setup。2. Best-of-N 关闭对照判断“进化”不是多花钱预算公平性最容易被忽略的地方是 Best-of-N 会偷偷改变实验预算。你让 Agent 生成 8 个候选再用评分器选最好的那个这个动作本身没有错但它把“单次执行能力”换成了“多次采样 选择能力”。如果新 Skill 只在这种模式下赢关掉 Best-of-N 就输那不是进化是采样预算在替你打工。所以我建议任何一个自进化候选上线前都跑四组对照A 组旧配置n1总预算 B。B 组新配置n1总预算 B。C 组旧配置nN总预算 B。D 组新配置nN总预算 B。重点看三件事第一B 组对比 A 组是否在同预算同 n 下提升第二D 组对比 C 组是否在同预算同 n 下提升第三D 组提升是否显著大于 B 组提升。如果只有 D 组赢说明这个“进化”依赖多路采样。它可能仍有价值但不能被写成“Agent 变聪明了”只能写成“在 N 路采样策略下收益更高”。同预算对照的关键是总 token 对齐。比如总预算 200k tokensn8 时每路最大输出要被限制而不是让每路都按 n1 的 max_tokens 跑。否则 D 组实际预算早就超过 B 组几倍比较没有意义。可以用下面这段脚本在本地跑最小实验Base URL 走 TaoTokenimport os from openai import OpenAI client OpenAI( base_urlhttps://taotoken.net/api, api_keyos.environ[TAOTOKEN_API_KEY], ) def call_case(prompt, model, max_tokens, n1): resp client.chat.completions.create( modelmodel, messages[{role: user, content: prompt}], max_tokensmax_tokens, nn, temperature0.2, ) outputs [c.message.content for c in resp.choices] usage resp.usage return outputs, usage def run_arm(prompt, model, total_budget, n): per_path max(1, total_budget // n) outputs, usage call_case(prompt, model, per_path, nn) return { n: n, outputs: outputs, total_tokens: getattr(usage, total_tokens, None), completion_tokens: getattr(usage, completion_tokens, None), prompt_tokens: getattr(usage, prompt_tokens, None), }脚本只负责调用和记账评分仍然由你的本地评测器完成。把每次运行的n、total_tokens、case_id、passed写进 JSONL后面做统计检验时才有原始账本。真实进化判定至少满足同预算 n1 下通过率提升tokens_per_success 不升高Best-of-N 关闭后提升仍然存在置信区间不跨 0回归集没有变差。只满足“n8 时分数更高”的候选应该进入观察区而不是直接合入 Skill 库。3. 同预算实验配置Token 账本、三分集和判定阈值预算公平不是一句口号它要落到配置文件里。建议把实验配置和评测集分开管理避免同一份 val 集被生成候选的模型看到。train 用于诊断失败模式val 用于筛选候选test 用于最终上线门控。三者互不泄漏。一份可复现的同预算配置可以长这样experiment: budget_fairness_best_of_n provider: base_url: https://taotoken.net/api api_key_env: TAOTOKEN_API_KEY models: candidate: your-candidate-model judge: your-judge-model budget: total_tokens_per_case: 200000 per_case_max_tokens: 4096 best_of_n: [1, 4, 8] datasets: train: eval/train.jsonl val: eval/val.jsonl test: eval/test.jsonl gates: min_same_budget_gain: 0.08 max_token_growth_ratio: 1.15 max_latency_growth_ratio: 1.30 bootstrap_rounds: 2000每次运行都写一条账本记录{ run_id: bf-2026-06-01-001, case_id: date-format-014, arm: candidate_single, n: 1, model: your-candidate-model, base_url: https://taotoken.net/api, prompt_tokens: 812, completion_tokens: 245, total_tokens: 1057, latency_ms: 1830, passed: true, judge_score: 0.86 }最终判定记录不要只写“通过”要写清楚预算条件{ candidate_id: skill-date-parser-v3, baseline_id: skill-date-parser-v2, same_budget: { budget: 200000, baseline_pass: 0.61, candidate_pass: 0.72, delta: 0.11, ci95: [0.04, 0.18], baseline_tokens_per_success: 1120, candidate_tokens_per_success: 980 }, bestofn_off: { n: 1, delta: 0.09 }, bestofn_on: { n: 8, delta: 0.13, total_tokens_ratio: 1.02 }, verdict: real_evolution, reason: 同预算 pass1 提升tokens/success 下降Best-of-N 关闭后仍成立 }反过来如果出现下面这种记录就应该判为“预算泄漏型候选”{ candidate_id: skill-search-v7, same_budget: { n: 1, delta: 0.01, ci95: [-0.03, 0.05], tokens_per_success_growth: 1.42 }, bestofn_on: { n: 8, delta: 0.12, total_tokens_ratio: 5.8 }, verdict: budget_leakage, reason: 仅多路采样时提升单路同预算无显著变化 }这类记录本身也有价值——写入记忆系统时应该标记为反例“该方向依赖多路采样单路预算下无效。” 下次生成修复方案时LLM 看到这条反例就不会继续在同一个方向上浪费迭代。4. 评测归因预算公平视角下定位“烧 Token 假进化”评测信号不可信自进化飞轮就会反转。预算公平是评测信号里最容易被忽略的维度之一。它不只是“花多少钱”的问题而是“提升来自能力还是来自预算”的问题。常见的假进化信号有五类第一长输出骗过评估器。LLM Judge 有时偏好详细答案候选把输出写长后得分升高但同预算下它挤压了其他 case 的可用 token真实成功率并没有提高。要在评测维度里加入简洁性、单位 token 信息量、tokens_per_success。第二passN 冒充 pass1。多路采样后只要有一路对就被记录为成功。这个指标在真实产品里不一定可用——用户不会等你跑 8 次再选最好。必须同时记录 pass1 和 passN并把 Best-of-N 关闭对照作为硬门。第三工具调用冗余。最终答案对了但中间调用了多余接口、重复读取、无效重试。表面看成功实际每次任务的 token 成本涨了几倍。轨迹评测要抓工具调用序列预算账本要抓每次调用的 usage。第四评测集漂移。旧评测集被多轮刷分真实线上分布已经变化。预算公平实验必须配合 val/test 定期更新把线上新失败样本回流进去否则你只是在旧地图上比谁跑得快。第五回归被平均分掩盖。候选在新 case 上提升在旧 case 上退化平均分看似不变。门控里必须有回归集按问题类型分层统计不能只看总分。归因之后按类型处理系统性问题进入 Skill/Prompt 更新偶发个例写入记忆反例能力缺失进入工具补充回归问题立即回滚预算泄漏标记为“仅 Best-of-N 有效”不授予正式 Skill 资格。一条实践经验如果某个候选连续 3 轮在同预算 n1 下没有提升但在 n8 下持续提升先别继续调 Prompt。优先检查是不是采样策略、重试策略或工具调用次数在放大预算。配置层的“进化”解决不了预算层的账本问题。5. 记忆治理只让同预算有效经验晋升为 Skill记忆系统的核心不是存得多而是治理得好。在预算公平视角下一条记忆值不值得晋升要看它在同预算条件下是否可复用。多花钱赢来的经验不能写成通用 Skill否则下次会把“多采样”当成标准动作。建议用三层晋升层级一.learnings/临时记录。任务结束先写一条低门槛允许噪声。层级二候选 Skill。同一模式在多个 case 上复现且通过同预算 n1 对照。层级三正式 Skill。通过 val/test 门控、回归门控、预算门控和人工确认。写入时至少带六个字段来源 run_id、Base URL、模型、预算、n 值、判定结果。例如{ memory_id: mem-date-parser-003, type: skill_candidate, source_run: bf-2026-06-01-001, base_url: https://taotoken.net/api, budget: 200000, n: 1, same_budget_delta: 0.11, bestofn_off_delta: 0.09, tokens_per_success_delta: -0.12, verdict: promote_to_skill, source: val_set_date_parser }反例同样要存而且要存得更醒目{ memory_id: mem-search-017, type: negative_pattern, source_run: bf-2026-05-28-004, pattern: 依赖 Best-of-N 搜索策略提升通过率, same_budget_delta: 0.01, bestofn_ratio: 5.8, verdict: do_not_promote, reason: 单路同预算无效预算敏感 }治理上还要有版本控制、主动遗忘、冲突解决和来源溯源。一条记忆如果和新的同预算实验结果冲突应该降低权重或冻结而不是让 Agent 随机引用。记忆不是日记本它是飞轮的治理账本。6. 落地工程化门控、灰度、回流都以预算公平为硬门从“发现问题”到“安全上线”之间有一段比想象中长的路。预算公平应该贯穿这条链路而不是只在实验阶段做一次。第一层语法和格式检查。Skill 文件、Prompt、配置是否合法。第二层回归检测。原本能做对的 case 是否还能做对。第三层统计显著性。同预算 n1 提升是否超过阈值置信区间是否跨 0。第四层预算门控。tokens_per_success 是否上涨超过阈值p95 延迟是否恶化Best-of-N 使用率是否异常升高。第五层人工确认。语义安全、业务合理、方向对齐。前四层自动过滤掉大部分低质候选人只看通过自动化检查的少量变体。灰度阶段建议 10% 流量跑 7 天监控四个指标同预算通过率、tokens_per_success、p95 延迟、用户负反馈。任何一项 P0 退化就自动回滚。回流机制同样要记录预算维度。灰度期间新出现的失败样本不只要写“什么 case 失败了”还要写“在什么预算和 n 值下失败”。如果某个失败只在 n1 出现、n8 消失它可能不是能力问题而是采样随机性。如果某个失败在 n8 下仍然出现才更值得进入下一轮诊断。版本化一切每次 Skill/Prompt/记忆变更都有版本号、变更日志、来源 run_id、关联评测结果和预算记录。出问题时能定位到哪个版本引入而不是“再改改试试”。修复时尽量用 Diff 模式只改需要改的片段。全文重写容易覆盖无关逻辑也让 review 变得困难。预算公平实验本身也要版本化配置、评测集、评分器、judge 模型、温度参数都要记录否则同预算对照不可复现。7. 人机协作与方向审计别让“越烧越多”被当成越进越强完全放手让 Agent 自己进化可能跑偏事事人工把控又太慢。更现实的做法是分级自主稳定领域高度自主新领域和高风险操作必须有人。有几个节点必须有人规则级记忆写入前、安全边界和权限控制变更前、回归决策、新领域冷启动、预算策略变更。特别是预算策略——把 n 从 1 调到 8、把重试次数从 1 调到 3、把 max_tokens 放大这些动作会直接改变实验公平性不能由 Agent 自己默默决定。方向审计要定期做。每月花半天看几个指标平均输出长度是否持续增长每任务平均 token 是否持续增长Best-of-N 使用率是否在无声上升重试次数是否越来越多同预算 n1 通过率是否真的在提升。如果后一个指标不涨前四个指标一直涨说明系统可能在用预算换分数。这不是进化是成本漂移。评测集里还应该显式加入“意图对齐”维度简洁性、格式规范性、语气合适度、预算友好度。把“我希望它更好”拆成可评测的维度否则评测信号会奖励错误方向。比如你希望回答简洁但 judge 偏好详细多轮之后 Agent 会越来越啰嗦。每一步看起来都在“变好”累积起来却偏离了目标。审核疲劳也要防。如果每天给人工弹 50 个审核请求其中 48 个是低质变体人很快会不看直接通过。应该自动过滤掉语法、回归、统计、预算四层不达标的候选只把“大概率有效、但需要语义判断”的少数候选批量呈现给人。让人做选择题而不是做疲劳填空题。8. 从零到一同预算对照最小闭环清单Phase 1 先跑最小闭环1-2 周。准备 50-100 条评测 case手动跑 A/B/C/D 四组对照记录 token 账本人工判断候选是否同预算有效。这个阶段的目标不是自动化而是验证闭环成立。Phase 2 做半自动化2-4 周。加入 Skill 候选生成、CI 评测门禁、评测集三分法、版本管理、预算门控。目标是在不显著增加 token 成本的前提下自动改进。Phase 3 让飞轮转起来1-2 月。加入灰度发布、回流机制、异步 Dreaming、渐进放权。目标是从“人工推动”变成“系统自转”。Phase 4 探索元进化。让系统自动搜索新方向、优化评测策略、做多 Agent 协同进化。但无论走多远预算公平都是底线同预算 n1 的提升才算真正的能力提升只靠 Best-of-N 烧出来的高分只能当作策略收益不能当作进化证据。现在你可以按下面的路径开始先通过模型对话验证 TaoToken 的调用链路再查看 Coding Plan 选择适合的套餐然后创建 API Key最后按 Claude Code 文档把 Base URL 固定为 https://taotoken.net/api。模型对话https://taotoken.net/models/detail/chat?utm_sourcetaotoken_aicg_blog_endutm_contentbudget_fairness_chatCoding Planhttps://taotoken.net/coding-plan?utm_sourcetaotoken_aicg_blog_endutm_contentbudget_fairness_plan创建 API Keyhttps://taotoken.net/console/api-keys?utm_sourcetaotoken_aicg_blog_endutm_contentbudget_fairness_keysClaude Code 文档https://taotoken.net/doc/ClaudeCodeAnthropic?utm_sourcetaotoken_aicg_blog_endutm_contentbudget_fairness_claudecode拿到 YOUR_API_KEY 后先把 Base URL 写成 https://taotoken.net/api再跑一轮 Best-of-N 关闭对照。把同预算账本、Best-of-N 关闭结果、真实进化判定记录一起留下来——你的 Agent 到底有没有变好账本会给出比报告更诚实的答案。 预算公平性 Best-of-N，TaoToken 只发 Key，同预算对照烧 Token
1. 先固定 Key 和 Base URL预算公平从供应商可切换开始在 TaoToken 官网https://taotoken.net/?utm_sourcetaotoken_aicg_blog_endutm_contentbudget_fairness_intro拿到 Key 后先把 Base URL 固定成 https://taotoken.net/api再跑 Best-of-N 关闭对照否则你看到的通过率上涨很可能只是 completion_tokens 上涨。这个判断不是凭感觉同一条评测 casen1 和 n8 的 token 账本完全不是一个量级。很多团队把 n8 的 passN 写成“Agent 自进化成功”但把 n 调回 1 后指标打回原形。问题不在模型而在实验没有做预算公平。TaoToken 在本文只做一件事签发 Key、提供可替换的 Base URL。评测脚本、评分器、记忆治理、灰度门控仍然在你本地或 CI 里执行。这个边界很重要——只有供应商可切换、调用账本能对齐才有资格讨论“同预算下是否真的更聪明”。先从官网拿 Keyhttps://taotoken.net/?utm_sourcetaotoken_aicg_blog_endutm_contentbudget_fairness_key。拿到 YOUR_API_KEY 后不要直接开始烧 Best-of-N。先把三个客户端的配置固定下来避免变量污染。Claude Code 的 settings.json 可以这样写{ env: { ANTHROPIC_BASE_URL: https://taotoken.net/api, ANTHROPIC_AUTH_TOKEN: YOUR_API_KEY } }如果 Claude Code 版本使用 ANTHROPIC_API_KEY按 Claude Code 文档替换变量名即可但 Base URL 保持 https://taotoken.net/api。不要把 ANTHROPIC_* 变量塞给 Codex。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 # 按 Codex 文档选择 chat 或 responses本地环境只注入export TAOTOKEN_API_KEYYOUR_API_KEY不要在 Codex 配置里出现 ANTHROPIC_BASE_URL 或 ANTHROPIC_AUTH_TOKEN。两套工具的协议和变量不要混用。如果你用 CC Switch 管理多套供应商维护三件套就够Provider 名称、Base URL、API Key。例如{ provider: TaoToken, baseUrl: https://taotoken.net/api, apiKey: YOUR_API_KEY }CC Switch 切的是 Claude Code 侧配置不要拿它去改 Codex 的 config.toml。配置完成后先跑一条 hello-world再记录 request_tokens、completion_tokens、total_tokens 三个字段。预算公平的第一步不是写评测而是让每次调用都有账本。官网入口在这里https://taotoken.net/?utm_sourcetaotoken_aicg_blog_endutm_contentbudget_fairness_setup。2. Best-of-N 关闭对照判断“进化”不是多花钱预算公平性最容易被忽略的地方是 Best-of-N 会偷偷改变实验预算。你让 Agent 生成 8 个候选再用评分器选最好的那个这个动作本身没有错但它把“单次执行能力”换成了“多次采样 选择能力”。如果新 Skill 只在这种模式下赢关掉 Best-of-N 就输那不是进化是采样预算在替你打工。所以我建议任何一个自进化候选上线前都跑四组对照A 组旧配置n1总预算 B。B 组新配置n1总预算 B。C 组旧配置nN总预算 B。D 组新配置nN总预算 B。重点看三件事第一B 组对比 A 组是否在同预算同 n 下提升第二D 组对比 C 组是否在同预算同 n 下提升第三D 组提升是否显著大于 B 组提升。如果只有 D 组赢说明这个“进化”依赖多路采样。它可能仍有价值但不能被写成“Agent 变聪明了”只能写成“在 N 路采样策略下收益更高”。同预算对照的关键是总 token 对齐。比如总预算 200k tokensn8 时每路最大输出要被限制而不是让每路都按 n1 的 max_tokens 跑。否则 D 组实际预算早就超过 B 组几倍比较没有意义。可以用下面这段脚本在本地跑最小实验Base URL 走 TaoTokenimport os from openai import OpenAI client OpenAI( base_urlhttps://taotoken.net/api, api_keyos.environ[TAOTOKEN_API_KEY], ) def call_case(prompt, model, max_tokens, n1): resp client.chat.completions.create( modelmodel, messages[{role: user, content: prompt}], max_tokensmax_tokens, nn, temperature0.2, ) outputs [c.message.content for c in resp.choices] usage resp.usage return outputs, usage def run_arm(prompt, model, total_budget, n): per_path max(1, total_budget // n) outputs, usage call_case(prompt, model, per_path, nn) return { n: n, outputs: outputs, total_tokens: getattr(usage, total_tokens, None), completion_tokens: getattr(usage, completion_tokens, None), prompt_tokens: getattr(usage, prompt_tokens, None), }脚本只负责调用和记账评分仍然由你的本地评测器完成。把每次运行的n、total_tokens、case_id、passed写进 JSONL后面做统计检验时才有原始账本。真实进化判定至少满足同预算 n1 下通过率提升tokens_per_success 不升高Best-of-N 关闭后提升仍然存在置信区间不跨 0回归集没有变差。只满足“n8 时分数更高”的候选应该进入观察区而不是直接合入 Skill 库。3. 同预算实验配置Token 账本、三分集和判定阈值预算公平不是一句口号它要落到配置文件里。建议把实验配置和评测集分开管理避免同一份 val 集被生成候选的模型看到。train 用于诊断失败模式val 用于筛选候选test 用于最终上线门控。三者互不泄漏。一份可复现的同预算配置可以长这样experiment: budget_fairness_best_of_n provider: base_url: https://taotoken.net/api api_key_env: TAOTOKEN_API_KEY models: candidate: your-candidate-model judge: your-judge-model budget: total_tokens_per_case: 200000 per_case_max_tokens: 4096 best_of_n: [1, 4, 8] datasets: train: eval/train.jsonl val: eval/val.jsonl test: eval/test.jsonl gates: min_same_budget_gain: 0.08 max_token_growth_ratio: 1.15 max_latency_growth_ratio: 1.30 bootstrap_rounds: 2000每次运行都写一条账本记录{ run_id: bf-2026-06-01-001, case_id: date-format-014, arm: candidate_single, n: 1, model: your-candidate-model, base_url: https://taotoken.net/api, prompt_tokens: 812, completion_tokens: 245, total_tokens: 1057, latency_ms: 1830, passed: true, judge_score: 0.86 }最终判定记录不要只写“通过”要写清楚预算条件{ candidate_id: skill-date-parser-v3, baseline_id: skill-date-parser-v2, same_budget: { budget: 200000, baseline_pass: 0.61, candidate_pass: 0.72, delta: 0.11, ci95: [0.04, 0.18], baseline_tokens_per_success: 1120, candidate_tokens_per_success: 980 }, bestofn_off: { n: 1, delta: 0.09 }, bestofn_on: { n: 8, delta: 0.13, total_tokens_ratio: 1.02 }, verdict: real_evolution, reason: 同预算 pass1 提升tokens/success 下降Best-of-N 关闭后仍成立 }反过来如果出现下面这种记录就应该判为“预算泄漏型候选”{ candidate_id: skill-search-v7, same_budget: { n: 1, delta: 0.01, ci95: [-0.03, 0.05], tokens_per_success_growth: 1.42 }, bestofn_on: { n: 8, delta: 0.12, total_tokens_ratio: 5.8 }, verdict: budget_leakage, reason: 仅多路采样时提升单路同预算无显著变化 }这类记录本身也有价值——写入记忆系统时应该标记为反例“该方向依赖多路采样单路预算下无效。” 下次生成修复方案时LLM 看到这条反例就不会继续在同一个方向上浪费迭代。4. 评测归因预算公平视角下定位“烧 Token 假进化”评测信号不可信自进化飞轮就会反转。预算公平是评测信号里最容易被忽略的维度之一。它不只是“花多少钱”的问题而是“提升来自能力还是来自预算”的问题。常见的假进化信号有五类第一长输出骗过评估器。LLM Judge 有时偏好详细答案候选把输出写长后得分升高但同预算下它挤压了其他 case 的可用 token真实成功率并没有提高。要在评测维度里加入简洁性、单位 token 信息量、tokens_per_success。第二passN 冒充 pass1。多路采样后只要有一路对就被记录为成功。这个指标在真实产品里不一定可用——用户不会等你跑 8 次再选最好。必须同时记录 pass1 和 passN并把 Best-of-N 关闭对照作为硬门。第三工具调用冗余。最终答案对了但中间调用了多余接口、重复读取、无效重试。表面看成功实际每次任务的 token 成本涨了几倍。轨迹评测要抓工具调用序列预算账本要抓每次调用的 usage。第四评测集漂移。旧评测集被多轮刷分真实线上分布已经变化。预算公平实验必须配合 val/test 定期更新把线上新失败样本回流进去否则你只是在旧地图上比谁跑得快。第五回归被平均分掩盖。候选在新 case 上提升在旧 case 上退化平均分看似不变。门控里必须有回归集按问题类型分层统计不能只看总分。归因之后按类型处理系统性问题进入 Skill/Prompt 更新偶发个例写入记忆反例能力缺失进入工具补充回归问题立即回滚预算泄漏标记为“仅 Best-of-N 有效”不授予正式 Skill 资格。一条实践经验如果某个候选连续 3 轮在同预算 n1 下没有提升但在 n8 下持续提升先别继续调 Prompt。优先检查是不是采样策略、重试策略或工具调用次数在放大预算。配置层的“进化”解决不了预算层的账本问题。5. 记忆治理只让同预算有效经验晋升为 Skill记忆系统的核心不是存得多而是治理得好。在预算公平视角下一条记忆值不值得晋升要看它在同预算条件下是否可复用。多花钱赢来的经验不能写成通用 Skill否则下次会把“多采样”当成标准动作。建议用三层晋升层级一.learnings/临时记录。任务结束先写一条低门槛允许噪声。层级二候选 Skill。同一模式在多个 case 上复现且通过同预算 n1 对照。层级三正式 Skill。通过 val/test 门控、回归门控、预算门控和人工确认。写入时至少带六个字段来源 run_id、Base URL、模型、预算、n 值、判定结果。例如{ memory_id: mem-date-parser-003, type: skill_candidate, source_run: bf-2026-06-01-001, base_url: https://taotoken.net/api, budget: 200000, n: 1, same_budget_delta: 0.11, bestofn_off_delta: 0.09, tokens_per_success_delta: -0.12, verdict: promote_to_skill, source: val_set_date_parser }反例同样要存而且要存得更醒目{ memory_id: mem-search-017, type: negative_pattern, source_run: bf-2026-05-28-004, pattern: 依赖 Best-of-N 搜索策略提升通过率, same_budget_delta: 0.01, bestofn_ratio: 5.8, verdict: do_not_promote, reason: 单路同预算无效预算敏感 }治理上还要有版本控制、主动遗忘、冲突解决和来源溯源。一条记忆如果和新的同预算实验结果冲突应该降低权重或冻结而不是让 Agent 随机引用。记忆不是日记本它是飞轮的治理账本。6. 落地工程化门控、灰度、回流都以预算公平为硬门从“发现问题”到“安全上线”之间有一段比想象中长的路。预算公平应该贯穿这条链路而不是只在实验阶段做一次。第一层语法和格式检查。Skill 文件、Prompt、配置是否合法。第二层回归检测。原本能做对的 case 是否还能做对。第三层统计显著性。同预算 n1 提升是否超过阈值置信区间是否跨 0。第四层预算门控。tokens_per_success 是否上涨超过阈值p95 延迟是否恶化Best-of-N 使用率是否异常升高。第五层人工确认。语义安全、业务合理、方向对齐。前四层自动过滤掉大部分低质候选人只看通过自动化检查的少量变体。灰度阶段建议 10% 流量跑 7 天监控四个指标同预算通过率、tokens_per_success、p95 延迟、用户负反馈。任何一项 P0 退化就自动回滚。回流机制同样要记录预算维度。灰度期间新出现的失败样本不只要写“什么 case 失败了”还要写“在什么预算和 n 值下失败”。如果某个失败只在 n1 出现、n8 消失它可能不是能力问题而是采样随机性。如果某个失败在 n8 下仍然出现才更值得进入下一轮诊断。版本化一切每次 Skill/Prompt/记忆变更都有版本号、变更日志、来源 run_id、关联评测结果和预算记录。出问题时能定位到哪个版本引入而不是“再改改试试”。修复时尽量用 Diff 模式只改需要改的片段。全文重写容易覆盖无关逻辑也让 review 变得困难。预算公平实验本身也要版本化配置、评测集、评分器、judge 模型、温度参数都要记录否则同预算对照不可复现。7. 人机协作与方向审计别让“越烧越多”被当成越进越强完全放手让 Agent 自己进化可能跑偏事事人工把控又太慢。更现实的做法是分级自主稳定领域高度自主新领域和高风险操作必须有人。有几个节点必须有人规则级记忆写入前、安全边界和权限控制变更前、回归决策、新领域冷启动、预算策略变更。特别是预算策略——把 n 从 1 调到 8、把重试次数从 1 调到 3、把 max_tokens 放大这些动作会直接改变实验公平性不能由 Agent 自己默默决定。方向审计要定期做。每月花半天看几个指标平均输出长度是否持续增长每任务平均 token 是否持续增长Best-of-N 使用率是否在无声上升重试次数是否越来越多同预算 n1 通过率是否真的在提升。如果后一个指标不涨前四个指标一直涨说明系统可能在用预算换分数。这不是进化是成本漂移。评测集里还应该显式加入“意图对齐”维度简洁性、格式规范性、语气合适度、预算友好度。把“我希望它更好”拆成可评测的维度否则评测信号会奖励错误方向。比如你希望回答简洁但 judge 偏好详细多轮之后 Agent 会越来越啰嗦。每一步看起来都在“变好”累积起来却偏离了目标。审核疲劳也要防。如果每天给人工弹 50 个审核请求其中 48 个是低质变体人很快会不看直接通过。应该自动过滤掉语法、回归、统计、预算四层不达标的候选只把“大概率有效、但需要语义判断”的少数候选批量呈现给人。让人做选择题而不是做疲劳填空题。8. 从零到一同预算对照最小闭环清单Phase 1 先跑最小闭环1-2 周。准备 50-100 条评测 case手动跑 A/B/C/D 四组对照记录 token 账本人工判断候选是否同预算有效。这个阶段的目标不是自动化而是验证闭环成立。Phase 2 做半自动化2-4 周。加入 Skill 候选生成、CI 评测门禁、评测集三分法、版本管理、预算门控。目标是在不显著增加 token 成本的前提下自动改进。Phase 3 让飞轮转起来1-2 月。加入灰度发布、回流机制、异步 Dreaming、渐进放权。目标是从“人工推动”变成“系统自转”。Phase 4 探索元进化。让系统自动搜索新方向、优化评测策略、做多 Agent 协同进化。但无论走多远预算公平都是底线同预算 n1 的提升才算真正的能力提升只靠 Best-of-N 烧出来的高分只能当作策略收益不能当作进化证据。现在你可以按下面的路径开始先通过模型对话验证 TaoToken 的调用链路再查看 Coding Plan 选择适合的套餐然后创建 API Key最后按 Claude Code 文档把 Base URL 固定为 https://taotoken.net/api。模型对话https://taotoken.net/models/detail/chat?utm_sourcetaotoken_aicg_blog_endutm_contentbudget_fairness_chatCoding Planhttps://taotoken.net/coding-plan?utm_sourcetaotoken_aicg_blog_endutm_contentbudget_fairness_plan创建 API Keyhttps://taotoken.net/console/api-keys?utm_sourcetaotoken_aicg_blog_endutm_contentbudget_fairness_keysClaude Code 文档https://taotoken.net/doc/ClaudeCodeAnthropic?utm_sourcetaotoken_aicg_blog_endutm_contentbudget_fairness_claudecode拿到 YOUR_API_KEY 后先把 Base URL 写成 https://taotoken.net/api再跑一轮 Best-of-N 关闭对照。把同预算账本、Best-of-N 关闭结果、真实进化判定记录一起留下来——你的 Agent 到底有没有变好账本会给出比报告更诚实的答案。