1. 为什么长程证明的章节拆分阶段最容易卡在模型接入在给 Stellar Colosseum 的章节拆分 Agent 设置模型 Key 时我把 Key 的来源统一换成了 TaoToken官网入口https://taotoken.net/?utm_sourcetaotoken_aicg_blog_endutm_contentstellar_colosseum_open并把 Base URL 写成 https://taotoken.net/api。这样做的直接原因是长程证明一旦进入章节拆分阶段模型调用不再是一次问答而是“章节拆分 Agent 产出子问题、并行子问题 Agent 批量生成候选、证伪与批评 Agent 再合并”的链式流程如果每个 Agent 各自指向不同 endpoint401、404、429 和超时会混在一起日志很难定位。Google Research 近期公开的 Stellar Colosseum面向长程数学与理论计算机科学研究特点是与具体模型解耦通过多智能体协作推进证明。它的运行方式可以粗略理解为几个阶段先探索多种证明策略达到某个就绪门槛后把整体路线切成章节级子问题再让多个子问题 Agent 并行生成候选方案最后通过定向证伪和批评合并收敛。对工程侧来说真正吃 Token、也最容易出接入问题的恰好是章节拆分 Agent 和并行子问题 Agent前者上下文长、调用次数不一定多但每次都需要稳定返回结构化结果后者并发高、单次输出可能不长但一旦限流或超时整个章节推进就会断掉。很多人在本地跑 Stellar Colosseum 时第一反应是给每个 Agent 配一个独立的模型供应商。结果常见现象是章节拆分 Agent 能跑但并行子问题 Agent 开始批量调用后出现401 invalid api key、404 not found、429 rate limit或者某些请求长时间挂起。排查时又因为 Key、Base URL、模型名、并发参数散落在多个配置文件里很难判断到底是框架问题、网络问题还是供应商兼容问题。更稳的做法是先统一模型入口所有 Agent 通过同一个 OpenAI 兼容 Base URL 调用模型Key 从 TaoToken 控制台创建再在 Stellar Colosseum 的适配层里按 Agent 角色分模型、分并发、分重试策略。这一步并不改变 Stellar Colosseum 的多智能体逻辑只是把“模型从哪来”这件事收口。收口之后章节拆分模板、跑通日志和 Token 统计才有可比性。下面按章节拆分视角把接入、模板、日志、统计和常见排障串起来。2. Stellar Colosseum 章节拆分流程与 Token 消耗地图Stellar Colosseum 的长程证明不是一次性生成完整证明而是把研究任务拆成可并行、可证伪、可合并的单元。章节拆分阶段位于“策略探索”和“并行候选生成”之间它负责把已经通过就绪门槛的证明路线转成一组章节级子问题。这个阶段的质量直接决定后面并行子问题 Agent 的效率拆得太粗子问题仍然很长模型容易在中途丢失目标拆得太细Agent 数量膨胀Token 消耗和调度复杂度都会上升。从接入角度看可以把流程拆成下面几层阶段主要 Agent调用特征Token 消耗特征接入关注点策略探索strategy_agent少量长上下文调用输入长、输出中等模型长上下文能力、稳定性就绪门槛readiness_gate判定型调用输入中等、输出短返回结构固定、低温度章节拆分chapter_split_agent单次或少量调用输入很长、输出结构化 JSON必须稳定返回可解析 JSON并行子问题subproblem_agent高并发批量调用输入中等、输出中等限流、重试、超时、并发控制定向证伪falsifier_agent中等并发输入中等、输出短判断准确性、低温度批评合并merger_agent少量长上下文调用输入长、输出中等长上下文、冲突合并其中章节拆分 Agent 的 Token 消耗主体是“长输入 结构化输出”。它通常要读取多份策略探索结果、就绪门槛判定理由、已有引理和约束条件然后输出章节列表。并行子问题 Agent 的 Token 消耗主体是“调用次数 × 单次输入输出”。如果拆出 8 个章节每个章节再生成 3 个候选就是 24 次子问题调用如果还有证伪和重试调用量会继续上升。因此接入层必须能承受并发而不是只保证单次请求成功。一个容易被忽略的点是章节拆分 Agent 和并行子问题 Agent 对模型的需求并不完全相同。章节拆分 Agent 更需要长上下文和结构化输出稳定性并行子问题 Agent 更看重吞吐、单次成本、限流恢复能力。通过 TaoToken 统一 Base URL 后可以在配置层为不同 Agent 指定不同模型名而不必改 Stellar Colosseum 的主体代码。这样既能保留多智能体框架的模型无关特性也能让 Token 统计按 Agent 角色归因。如果你还没有创建 Key可以直接从 TaoToken 官网进入控制台https://taotoken.net/?utm_sourcetaotoken_aicg_blog_endutm_contentstellar_colosseum_key。创建后把 Key 放进环境变量不要在代码里硬编码也不要把 Key 写进会提交到 Git 的配置文件。3. 在 TaoToken 获取 Key 并设置 Base URLStellar Colosseum 是模型无关框架实际接入方式取决于你使用的适配器。如果它通过 OpenAI SDK、OpenAI 兼容接口或 LiteLLM 调用模型那么最关键的两个配置就是 API Key 和 Base URL。Key 从 TaoToken 控制台创建Base URL 固定为https://taotoken.net/api注意Base URL 在工具配置中不需要加 UTM 参数。UTM 只用于官网入口和文档链接的归因。最简单的环境变量配置如下export OPENAI_API_KEYYOUR_API_KEY export OPENAI_BASE_URLhttps://taotoken.net/api如果你的 Stellar Colosseum 适配器读取的是自定义变量名也可以写成export TAOTOKEN_API_KEYYOUR_API_KEY export TAOTOKEN_BASE_URLhttps://taotoken.net/api然后在适配器初始化时把它映射到 OpenAI 兼容客户端。例如用 Python 写一个最小验证脚本先确认 Key 和 Base URL 能通再启动多智能体流程import os from openai import OpenAI client OpenAI( api_keyos.environ[OPENAI_API_KEY], base_urlos.environ.get(OPENAI_BASE_URL, https://taotoken.net/api), ) resp client.chat.completions.create( modelgpt-4.1-mini, # 按你控制台可用的模型名替换 messages[ {role: system, content: 你是一个连通性测试助手。}, {role: user, content: 只回复 OK。}, ], temperature0, ) print(resp.choices[0].message.content)如果使用 curl可以先检查模型列表或最小对话请求curl -s https://taotoken.net/api/v1/models \ -H Authorization: Bearer $OPENAI_API_KEY | headcurl -s https://taotoken.net/api/v1/chat/completions \ -H Authorization: Bearer $OPENAI_API_KEY \ -H Content-Type: application/json \ -d { model: gpt-4.1-mini, messages: [{role: user, content: 只回复 OK}], temperature: 0 }这里要特别注意路径拼接。不同 SDK 对 Base URL 的处理方式不同有的会在 Base URL 后自动追加/v1有的要求你手动写全/v1。Stellar Colosseum 的适配器如果基于 OpenAI SDK通常把 Base URL 设为https://taotoken.net/api即可由 SDK 追加/v1。如果你在日志里看到404先检查请求 URL 是否变成了/api/v1/v1/...或/api/chat/completions这类错误拼接而不是先怀疑模型名。Key 创建和管理入口在 TaoToken 控制台可以从官网进入https://taotoken.net/?utm_sourcetaotoken_aicg_blog_endutm_contentstellar_colosseum_console。建议为 Stellar Colosseum 单独建一个 Key名称里带stellar-colosseum方便按项目统计和轮换。多人协作时不要把同一个 Key 分发到多个本地环境否则一旦某个并行子问题 Agent 触发限流你无法判断是哪个环境造成的。4. 章节拆分模板把证明路线切成可并行子问题章节拆分 Agent 的输出必须是结构化的否则并行子问题 Agent 无法稳定消费。下面给一个可复现的章节拆分模板你可以直接放进 Stellar Colosseum 的章节拆分提示词或适配层中。模板的目标不是替框架做研究判断而是把“已通过就绪门槛的策略”转成章节列表并给每个章节补充候选生成提示和证伪提示。你是 Stellar Colosseum 的章节拆分 Agent。 输入 1. 已通过就绪门槛的证明策略摘要 2. 当前已知引理、定义、约束 3. 不允许使用的假设或尚未证明的结论 4. 目标定理的最终形式。 任务 把证明路线拆成章节级子问题。每个章节必须满足 - 有明确目标不是一个泛泛的方向 - 能独立交给一个子问题 Agent 生成候选 - 有可验证的接受条件 - 有依赖章节时依赖关系必须显式列出 - 对高风险章节附带定向证伪提示。 输出必须是 JSON不要输出 Markdown不要输出解释性前后缀。对应的 JSON 结构可以设计为{ strategy_id: strategy-001, readiness_gate: { passed: true, score: 0.82, reasons: [ 主路线与备用路线已区分, 关键引理依赖已列出, 未证明假设已标记 ] }, chapters: [ { chapter_id: C1, title: 建立基本定义与等价转化, goal: 把目标定理转化为后续章节可使用的等价形式。, depends_on: [], acceptance: [ 等价转化步骤逐步可查, 每个新定义都有明确来源, 没有引入未证明假设 ], candidate_prompt: 请给出该等价转化的完整推导并标记每一步使用的定义或引理。, falsify_prompt: 请尝试找出该等价转化中隐藏的方向性错误或边界条件遗漏。 }, { chapter_id: C2, title: 证明核心引理 A, goal: 证明后续主证明依赖的核心引理 A。, depends_on: [C1], acceptance: [ 引理陈述与依赖条件一致, 证明中每一步可追溯到已有结论, 极端情况已单独讨论 ], candidate_prompt: 基于 C1 的等价形式给出核心引理 A 的候选证明。, falsify_prompt: 检查核心引理 A 是否在边界条件下失效并给出反例或修补条件。 } ] }这个模板的关键点有三个。第一readiness_gate要保留因为它解释了为什么现在可以拆分后续如果合并阶段发现路线有误可以回溯到就绪门槛判定。第二depends_on必须显式否则并行子问题 Agent 可能在没有前置结论时提前生成候选造成无效 Token 消耗。第三falsify_prompt要跟着章节走定向证伪才有目标而不是泛泛地让模型“检查错误”。在 Stellar Colosseum 中章节拆分 Agent 的输出可以直接作为并行子问题 Agent 的调度输入。一个简单的调度伪代码如下import asyncio from collections import defaultdict async def run_subproblem_agent(chapter, sem): async with sem: # 这里调用你的模型客户端Base URL 来自 https://taotoken.net/api return await call_model( promptchapter[candidate_prompt], metadata{chapter_id: chapter[chapter_id], agent: subproblem} ) async def run_parallel_chapters(chapters, concurrency4): sem asyncio.Semaphore(concurrency) tasks [run_subproblem_agent(ch, sem) for ch in chapters] results await asyncio.gather(*tasks, return_exceptionsTrue) grouped defaultdict(list) for ch, result in zip(chapters, results): grouped[ch[chapter_id]].append(result) return grouped并发数不要一上来就开满。建议先从 2 到 4 并发开始观察日志中的 429 和超时比例再逐步增加。章节拆分 Agent 本身通常不需要高并发但并行子问题 Agent 是 Token 消耗主体必须做并发控制、超时控制和失败重试。5. 跑通日志从 401 到章节拆分成功下面是一条本地跑通日志的示例重点展示章节拆分阶段如何确认 Base URL、Key、章节数量和并行子问题启动情况。实际日志字段会因你的 Stellar Colosseum 版本和适配器不同而变化但排查顺序可以复用。[10:12:03] bootstrap: load env OPENAI_BASE_URLhttps://taotoken.net/api [10:12:03] bootstrap: api_keyYOUR_API_KEY lengthok prefixsk-*** [10:12:03] adapter: provideropenai-compatible streamfalse timeout120s [10:12:04] strategy_agent: start strategy_count3 [10:12:07] strategy_agent: done viable_strategies2 [10:12:08] readiness_gate: evaluating strategy-001 [10:12:09] readiness_gate: passedtrue score0.82 [10:12:09] chapter_split_agent: start strategy_idstrategy-001 [10:12:11] chapter_split_agent: raw_output_chars4820 [10:12:11] chapter_split_agent: json_parseok chapters8 [10:12:11] subproblem_agent: spawn8 concurrency4 [10:12:13] subproblem_agent: chapterC1 statusrunning [10:12:13] subproblem_agent: chapterC2 statusrunning [10:12:13] subproblem_agent: chapterC3 statusrunning [10:12:13] subproblem_agent: chapterC4 statusrunning [10:12:16] subproblem_agent: chapterC1 statusdone tokensprompt6120 completion1180 [10:12:17] subproblem_agent: chapterC2 statusdone tokensprompt5840 completion1320 [10:12:19] subproblem_agent: chapterC3 statusdone tokensprompt6310 completion990 [10:12:20] subproblem_agent: chapterC4 statusdone tokensprompt5980 completion1450 [10:12:22] subproblem_agent: batch1 done4 failed0 [10:12:22] subproblem_agent: spawn_batch2 chaptersC5,C6,C7,C8 [10:12:29] subproblem_agent: batch2 done4 failed0 [10:12:30] falsifier_agent: start candidates8 [10:12:34] falsifier_agent: rejected1 repaired1 [10:12:36] merger_agent: start chapters8 rejected1 [10:12:39] merger_agent: merged7 confidencemedium [10:12:39] token_summary: chapter_splitprompt12800 completion2600 [10:12:39] token_summary: subproblem_totalprompt48200 completion9800 [10:12:39] run: statusfinished这条日志里chapter_split_agent成功解析出 8 个章节随后并行子问题 Agent 分两批执行每批 4 个并发。真正需要盯住的指标是json_parse是否 ok、spawn数量是否等于章节数、failed是否为 0、rejected是否被后续修复、token_summary是否按 Agent 分类。常见错误与修复方式如下现象可能原因修复401 invalid api keyKey 未设置、拼写错误、未带 Bearer重新从控制台创建 Key确认请求头为Authorization: Bearer YOUR_API_KEY404 not foundBase URL 路径重复或缺少/v1Stellar Colosseum 适配器统一用https://taotoken.net/api不要手写重复/v1429 rate limit并行子问题 Agent 并发过高降低concurrency增加退避重试按章节分批timeout章节拆分输入过长或模型响应慢拆分输入增加超时或给章节拆分 Agent 换长上下文模型json parse error章节拆分 Agent 输出带解释文字在提示词中强制 JSON加入解析失败重试和截断修复model not found模型名与 TaoToken 控制台不一致在控制台确认可用模型名再更新配置建议把每次运行的失败类型计入日志而不是只看最终成功或失败。因为章节拆分阶段的错误会放大到并行子问题阶段一个章节 JSON 字段缺失可能导致多个子问题 Agent 重复生成一个依赖关系错误可能导致后续合并阶段出现矛盾。6. Token 统计与成本观察谁在消耗章节拆分预算可复现产出里最重要的一项就是 Token 统计。没有统计你无法判断章节拆分 Agent 和并行子问题 Agent 谁在消耗预算也无法决定哪些 Agent 该用更强模型、哪些该用更便宜的模型。下面给出一条本地样例的统计口径不代表所有证明规模只说明统计维度。统计项章节拆分 Agent并行子问题 Agent定向证伪 Agent批评合并 Agent调用次数1881输入 Token 示例12800482001860015200输出 Token 示例2600980042003100主要成本来源长上下文 JSON 结构并发调用次数候选逐个检查长上下文合并优化方向精简输入、固定 schema限流、缓存、批处理只对高风险章节执行合并前去重从这张表可以看出章节拆分 Agent 单次调用输入很长但调用次数少并行子问题 Agent 单次输入不一定最大但调用次数多是整体 Token 消耗的主要放大项。实际优化时可以这样分配模型章节拆分 Agent使用长上下文能力更稳的模型温度调低强制 JSON。并行子问题 Agent使用吞吐更好、成本更低的模型控制并发设置最大输出长度。定向证伪 Agent只对高风险章节或候选开启不必每个候选都全量证伪。批评合并 Agent使用长上下文模型但输入前先去重避免重复章节和重复候选挤占上下文。可以用下面的 Python 片段在每次调用后记录 Tokenimport json import time from pathlib import Path LOG_PATH Path(stellar_colosseum_token_log.jsonl) def log_usage(agent, chapter_id, response): usage getattr(response, usage, None) record { ts: time.time(), agent: agent, chapter_id: chapter_id, prompt_tokens: getattr(usage, prompt_tokens, None) if usage else None, completion_tokens: getattr(usage, completion_tokens, None) if usage else None, total_tokens: getattr(usage, total_tokens, None) if usage else None, } with LOG_PATH.open(a, encodingutf-8) as f: f.write(json.dumps(record, ensure_asciiFalse) \n)统计后按agent聚合就能得到类似下面的汇总import json from collections import defaultdict from pathlib import Path summary defaultdict(lambda: {calls: 0, prompt: 0, completion: 0}) for line in Path(stellar_colosseum_token_log.jsonl).read_text(encodingutf-8).splitlines(): item json.loads(line) agent item[agent] summary[agent][calls] 1 summary[agent][prompt] item.get(prompt_tokens) or 0 summary[agent][completion] item.get(completion_tokens) or 0 for agent, row in summary.items(): print(agent, row)如果发现并行子问题 Agent 的calls远高于章节数通常是因为重试或失败重放。此时不要只看总 Token还要看failed和retry字段。很多“Token 消耗异常”并不是模型单价问题而是章节拆分输出不稳定导致重复调用。7. Claude Code、Codex 与 CC Switch 接入 TaoToken 的配置差异虽然 Stellar Colosseum 的模型调用通常走 OpenAI 兼容接口但本地开发时经常还会同时使用 Claude Code、Codex 或 CC Switch 做辅助。它们的配置方式不同不能把ANTHROPIC_*套到 Codex也不能把 Codex 的config.toml直接当成 Claude Code 的settings.json。下面按工具分别给出可复制配置Base URL 统一为https://taotoken.net/apiKey 统一用YOUR_API_KEY。Claude Codesettings.json 与 ANTHROPIC_*Claude Code 使用ANTHROPIC_*系列环境变量。可以在项目或用户的settings.json中配置{ env: { ANTHROPIC_BASE_URL: https://taotoken.net/api, ANTHROPIC_AUTH_TOKEN: YOUR_API_KEY, ANTHROPIC_MODEL: claude-sonnet-4-5 } }如果你在 shell 里临时测试也可以直接导出export ANTHROPIC_BASE_URLhttps://taotoken.net/api export ANTHROPIC_AUTH_TOKENYOUR_API_KEY export ANTHROPIC_MODELclaude-sonnet-4-5注意这里使用的是ANTHROPIC_AUTH_TOKEN不是OPENAI_API_KEY。Claude Code 的模型名也要按 TaoToken 控制台实际可用的名称填写。Codexconfig.toml 与独立 providerCodex 使用config.toml不要混用 Claude Code 的ANTHROPIC_*。一个常见配置如下model 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然后在环境变量中设置 Keyexport TAOTOKEN_API_KEYYOUR_API_KEY如果你的 Codex 版本字段名不同以本地版本为准但核心不变base_url指向https://taotoken.net/apienv_key指向你实际导出的 Key 变量不要写ANTHROPIC_AUTH_TOKEN。CC Switch三件套配置CC Switch 这类切换工具通常只需要三件套Provider 名称、Base URL、API Key。可以按下面填写配置项值Provider NameTaoTokenBase URLhttps://taotoken.net/apiAPI KeyYOUR_API_KEY备注Stellar Colosseum 共用同一入口按 Agent 分模型这样切换时不需要改 Stellar Colosseum 的主体代码只需要确认当前激活的 Provider 是 TaoToken且 Base URL 没有被写成带 UTM 的官网地址。UTM 链接只用于访问官网和文档不用于 API 调用。如果你需要重新创建 Key可以从官网进入控制台https://taotoken.net/?utm_sourcetaotoken_aicg_blog_endutm_contentstellar_colosseum_ccswitch。8. 把章节拆分跑通后下一步做什么当 Stellar Colosseum 的章节拆分 Agent 能稳定输出 JSON并行子问题 Agent 能按章节调度并且 Token 统计能按 Agent 归因接入层就算跑通了。接下来可以继续做三件事第一把章节拆分模板版本化。每次调整提示词或 JSON schema都记录版本号并在跑通日志里带上。这样当合并阶段出现矛盾时可以回溯是章节拆分变化导致的还是子问题生成变化导致的。第二给并行子问题 Agent 加缓存和去重。相同章节、相同候选提示词、相同模型参数如果短时间内重复调用可以直接复用结果。长程证明研究中很多子问题会反复出现缓存能显著减少无效 Token。第三按 Agent 角色分配模型。章节拆分 Agent 用长上下文和结构化输出更稳的模型并行子问题 Agent 用吞吐和成本更优的模型证伪 Agent 只在高风险章节开启。TaoToken 提供统一 Base URL 和 Key 管理方便你在同一入口下做这些切换。如果你要直接复现本文流程建议按下面路径操作先打开模型对话确认模型可用https://taotoken.net/models/detail/chat?utm_sourcetaotoken_aicg_blog_endutm_contentstellar_colosseum_chat如果需要长期跑 Stellar Colosseum 和本地 Coding 工具查看 Coding Planhttps://taotoken.net/coding-plan?utm_sourcetaotoken_aicg_blog_endutm_contentstellar_colosseum_plan创建或管理 API Keyhttps://taotoken.net/console/api-keys?utm_sourcetaotoken_aicg_blog_endutm_contentstellar_colosseum_keys如果同时使用 Claude Code参考 Claude Code 文档https://taotoken.net/doc/ClaudeCodeAnthropic?utm_sourcetaotoken_aicg_blog_endutm_contentstellar_colosseum_claudecode最后再提醒一次配置要点Stellar Colosseum 的模型调用 Base URL 用https://taotoken.net/apiKey 用YOUR_API_KEY章节拆分 Agent 和并行子问题 Agent 分别统计 Token遇到 401、404、429 时先查 Key、路径拼接和并发数。把这些基础项固定下来长程证明的章节拆分阶段才能从“偶尔跑通”变成“可复现、可统计、可优化”的工程流程。
45：长程证明章节拆分，Stellar Colosseum 连 TaoToken 后跑通
1. 为什么长程证明的章节拆分阶段最容易卡在模型接入在给 Stellar Colosseum 的章节拆分 Agent 设置模型 Key 时我把 Key 的来源统一换成了 TaoToken官网入口https://taotoken.net/?utm_sourcetaotoken_aicg_blog_endutm_contentstellar_colosseum_open并把 Base URL 写成 https://taotoken.net/api。这样做的直接原因是长程证明一旦进入章节拆分阶段模型调用不再是一次问答而是“章节拆分 Agent 产出子问题、并行子问题 Agent 批量生成候选、证伪与批评 Agent 再合并”的链式流程如果每个 Agent 各自指向不同 endpoint401、404、429 和超时会混在一起日志很难定位。Google Research 近期公开的 Stellar Colosseum面向长程数学与理论计算机科学研究特点是与具体模型解耦通过多智能体协作推进证明。它的运行方式可以粗略理解为几个阶段先探索多种证明策略达到某个就绪门槛后把整体路线切成章节级子问题再让多个子问题 Agent 并行生成候选方案最后通过定向证伪和批评合并收敛。对工程侧来说真正吃 Token、也最容易出接入问题的恰好是章节拆分 Agent 和并行子问题 Agent前者上下文长、调用次数不一定多但每次都需要稳定返回结构化结果后者并发高、单次输出可能不长但一旦限流或超时整个章节推进就会断掉。很多人在本地跑 Stellar Colosseum 时第一反应是给每个 Agent 配一个独立的模型供应商。结果常见现象是章节拆分 Agent 能跑但并行子问题 Agent 开始批量调用后出现401 invalid api key、404 not found、429 rate limit或者某些请求长时间挂起。排查时又因为 Key、Base URL、模型名、并发参数散落在多个配置文件里很难判断到底是框架问题、网络问题还是供应商兼容问题。更稳的做法是先统一模型入口所有 Agent 通过同一个 OpenAI 兼容 Base URL 调用模型Key 从 TaoToken 控制台创建再在 Stellar Colosseum 的适配层里按 Agent 角色分模型、分并发、分重试策略。这一步并不改变 Stellar Colosseum 的多智能体逻辑只是把“模型从哪来”这件事收口。收口之后章节拆分模板、跑通日志和 Token 统计才有可比性。下面按章节拆分视角把接入、模板、日志、统计和常见排障串起来。2. Stellar Colosseum 章节拆分流程与 Token 消耗地图Stellar Colosseum 的长程证明不是一次性生成完整证明而是把研究任务拆成可并行、可证伪、可合并的单元。章节拆分阶段位于“策略探索”和“并行候选生成”之间它负责把已经通过就绪门槛的证明路线转成一组章节级子问题。这个阶段的质量直接决定后面并行子问题 Agent 的效率拆得太粗子问题仍然很长模型容易在中途丢失目标拆得太细Agent 数量膨胀Token 消耗和调度复杂度都会上升。从接入角度看可以把流程拆成下面几层阶段主要 Agent调用特征Token 消耗特征接入关注点策略探索strategy_agent少量长上下文调用输入长、输出中等模型长上下文能力、稳定性就绪门槛readiness_gate判定型调用输入中等、输出短返回结构固定、低温度章节拆分chapter_split_agent单次或少量调用输入很长、输出结构化 JSON必须稳定返回可解析 JSON并行子问题subproblem_agent高并发批量调用输入中等、输出中等限流、重试、超时、并发控制定向证伪falsifier_agent中等并发输入中等、输出短判断准确性、低温度批评合并merger_agent少量长上下文调用输入长、输出中等长上下文、冲突合并其中章节拆分 Agent 的 Token 消耗主体是“长输入 结构化输出”。它通常要读取多份策略探索结果、就绪门槛判定理由、已有引理和约束条件然后输出章节列表。并行子问题 Agent 的 Token 消耗主体是“调用次数 × 单次输入输出”。如果拆出 8 个章节每个章节再生成 3 个候选就是 24 次子问题调用如果还有证伪和重试调用量会继续上升。因此接入层必须能承受并发而不是只保证单次请求成功。一个容易被忽略的点是章节拆分 Agent 和并行子问题 Agent 对模型的需求并不完全相同。章节拆分 Agent 更需要长上下文和结构化输出稳定性并行子问题 Agent 更看重吞吐、单次成本、限流恢复能力。通过 TaoToken 统一 Base URL 后可以在配置层为不同 Agent 指定不同模型名而不必改 Stellar Colosseum 的主体代码。这样既能保留多智能体框架的模型无关特性也能让 Token 统计按 Agent 角色归因。如果你还没有创建 Key可以直接从 TaoToken 官网进入控制台https://taotoken.net/?utm_sourcetaotoken_aicg_blog_endutm_contentstellar_colosseum_key。创建后把 Key 放进环境变量不要在代码里硬编码也不要把 Key 写进会提交到 Git 的配置文件。3. 在 TaoToken 获取 Key 并设置 Base URLStellar Colosseum 是模型无关框架实际接入方式取决于你使用的适配器。如果它通过 OpenAI SDK、OpenAI 兼容接口或 LiteLLM 调用模型那么最关键的两个配置就是 API Key 和 Base URL。Key 从 TaoToken 控制台创建Base URL 固定为https://taotoken.net/api注意Base URL 在工具配置中不需要加 UTM 参数。UTM 只用于官网入口和文档链接的归因。最简单的环境变量配置如下export OPENAI_API_KEYYOUR_API_KEY export OPENAI_BASE_URLhttps://taotoken.net/api如果你的 Stellar Colosseum 适配器读取的是自定义变量名也可以写成export TAOTOKEN_API_KEYYOUR_API_KEY export TAOTOKEN_BASE_URLhttps://taotoken.net/api然后在适配器初始化时把它映射到 OpenAI 兼容客户端。例如用 Python 写一个最小验证脚本先确认 Key 和 Base URL 能通再启动多智能体流程import os from openai import OpenAI client OpenAI( api_keyos.environ[OPENAI_API_KEY], base_urlos.environ.get(OPENAI_BASE_URL, https://taotoken.net/api), ) resp client.chat.completions.create( modelgpt-4.1-mini, # 按你控制台可用的模型名替换 messages[ {role: system, content: 你是一个连通性测试助手。}, {role: user, content: 只回复 OK。}, ], temperature0, ) print(resp.choices[0].message.content)如果使用 curl可以先检查模型列表或最小对话请求curl -s https://taotoken.net/api/v1/models \ -H Authorization: Bearer $OPENAI_API_KEY | headcurl -s https://taotoken.net/api/v1/chat/completions \ -H Authorization: Bearer $OPENAI_API_KEY \ -H Content-Type: application/json \ -d { model: gpt-4.1-mini, messages: [{role: user, content: 只回复 OK}], temperature: 0 }这里要特别注意路径拼接。不同 SDK 对 Base URL 的处理方式不同有的会在 Base URL 后自动追加/v1有的要求你手动写全/v1。Stellar Colosseum 的适配器如果基于 OpenAI SDK通常把 Base URL 设为https://taotoken.net/api即可由 SDK 追加/v1。如果你在日志里看到404先检查请求 URL 是否变成了/api/v1/v1/...或/api/chat/completions这类错误拼接而不是先怀疑模型名。Key 创建和管理入口在 TaoToken 控制台可以从官网进入https://taotoken.net/?utm_sourcetaotoken_aicg_blog_endutm_contentstellar_colosseum_console。建议为 Stellar Colosseum 单独建一个 Key名称里带stellar-colosseum方便按项目统计和轮换。多人协作时不要把同一个 Key 分发到多个本地环境否则一旦某个并行子问题 Agent 触发限流你无法判断是哪个环境造成的。4. 章节拆分模板把证明路线切成可并行子问题章节拆分 Agent 的输出必须是结构化的否则并行子问题 Agent 无法稳定消费。下面给一个可复现的章节拆分模板你可以直接放进 Stellar Colosseum 的章节拆分提示词或适配层中。模板的目标不是替框架做研究判断而是把“已通过就绪门槛的策略”转成章节列表并给每个章节补充候选生成提示和证伪提示。你是 Stellar Colosseum 的章节拆分 Agent。 输入 1. 已通过就绪门槛的证明策略摘要 2. 当前已知引理、定义、约束 3. 不允许使用的假设或尚未证明的结论 4. 目标定理的最终形式。 任务 把证明路线拆成章节级子问题。每个章节必须满足 - 有明确目标不是一个泛泛的方向 - 能独立交给一个子问题 Agent 生成候选 - 有可验证的接受条件 - 有依赖章节时依赖关系必须显式列出 - 对高风险章节附带定向证伪提示。 输出必须是 JSON不要输出 Markdown不要输出解释性前后缀。对应的 JSON 结构可以设计为{ strategy_id: strategy-001, readiness_gate: { passed: true, score: 0.82, reasons: [ 主路线与备用路线已区分, 关键引理依赖已列出, 未证明假设已标记 ] }, chapters: [ { chapter_id: C1, title: 建立基本定义与等价转化, goal: 把目标定理转化为后续章节可使用的等价形式。, depends_on: [], acceptance: [ 等价转化步骤逐步可查, 每个新定义都有明确来源, 没有引入未证明假设 ], candidate_prompt: 请给出该等价转化的完整推导并标记每一步使用的定义或引理。, falsify_prompt: 请尝试找出该等价转化中隐藏的方向性错误或边界条件遗漏。 }, { chapter_id: C2, title: 证明核心引理 A, goal: 证明后续主证明依赖的核心引理 A。, depends_on: [C1], acceptance: [ 引理陈述与依赖条件一致, 证明中每一步可追溯到已有结论, 极端情况已单独讨论 ], candidate_prompt: 基于 C1 的等价形式给出核心引理 A 的候选证明。, falsify_prompt: 检查核心引理 A 是否在边界条件下失效并给出反例或修补条件。 } ] }这个模板的关键点有三个。第一readiness_gate要保留因为它解释了为什么现在可以拆分后续如果合并阶段发现路线有误可以回溯到就绪门槛判定。第二depends_on必须显式否则并行子问题 Agent 可能在没有前置结论时提前生成候选造成无效 Token 消耗。第三falsify_prompt要跟着章节走定向证伪才有目标而不是泛泛地让模型“检查错误”。在 Stellar Colosseum 中章节拆分 Agent 的输出可以直接作为并行子问题 Agent 的调度输入。一个简单的调度伪代码如下import asyncio from collections import defaultdict async def run_subproblem_agent(chapter, sem): async with sem: # 这里调用你的模型客户端Base URL 来自 https://taotoken.net/api return await call_model( promptchapter[candidate_prompt], metadata{chapter_id: chapter[chapter_id], agent: subproblem} ) async def run_parallel_chapters(chapters, concurrency4): sem asyncio.Semaphore(concurrency) tasks [run_subproblem_agent(ch, sem) for ch in chapters] results await asyncio.gather(*tasks, return_exceptionsTrue) grouped defaultdict(list) for ch, result in zip(chapters, results): grouped[ch[chapter_id]].append(result) return grouped并发数不要一上来就开满。建议先从 2 到 4 并发开始观察日志中的 429 和超时比例再逐步增加。章节拆分 Agent 本身通常不需要高并发但并行子问题 Agent 是 Token 消耗主体必须做并发控制、超时控制和失败重试。5. 跑通日志从 401 到章节拆分成功下面是一条本地跑通日志的示例重点展示章节拆分阶段如何确认 Base URL、Key、章节数量和并行子问题启动情况。实际日志字段会因你的 Stellar Colosseum 版本和适配器不同而变化但排查顺序可以复用。[10:12:03] bootstrap: load env OPENAI_BASE_URLhttps://taotoken.net/api [10:12:03] bootstrap: api_keyYOUR_API_KEY lengthok prefixsk-*** [10:12:03] adapter: provideropenai-compatible streamfalse timeout120s [10:12:04] strategy_agent: start strategy_count3 [10:12:07] strategy_agent: done viable_strategies2 [10:12:08] readiness_gate: evaluating strategy-001 [10:12:09] readiness_gate: passedtrue score0.82 [10:12:09] chapter_split_agent: start strategy_idstrategy-001 [10:12:11] chapter_split_agent: raw_output_chars4820 [10:12:11] chapter_split_agent: json_parseok chapters8 [10:12:11] subproblem_agent: spawn8 concurrency4 [10:12:13] subproblem_agent: chapterC1 statusrunning [10:12:13] subproblem_agent: chapterC2 statusrunning [10:12:13] subproblem_agent: chapterC3 statusrunning [10:12:13] subproblem_agent: chapterC4 statusrunning [10:12:16] subproblem_agent: chapterC1 statusdone tokensprompt6120 completion1180 [10:12:17] subproblem_agent: chapterC2 statusdone tokensprompt5840 completion1320 [10:12:19] subproblem_agent: chapterC3 statusdone tokensprompt6310 completion990 [10:12:20] subproblem_agent: chapterC4 statusdone tokensprompt5980 completion1450 [10:12:22] subproblem_agent: batch1 done4 failed0 [10:12:22] subproblem_agent: spawn_batch2 chaptersC5,C6,C7,C8 [10:12:29] subproblem_agent: batch2 done4 failed0 [10:12:30] falsifier_agent: start candidates8 [10:12:34] falsifier_agent: rejected1 repaired1 [10:12:36] merger_agent: start chapters8 rejected1 [10:12:39] merger_agent: merged7 confidencemedium [10:12:39] token_summary: chapter_splitprompt12800 completion2600 [10:12:39] token_summary: subproblem_totalprompt48200 completion9800 [10:12:39] run: statusfinished这条日志里chapter_split_agent成功解析出 8 个章节随后并行子问题 Agent 分两批执行每批 4 个并发。真正需要盯住的指标是json_parse是否 ok、spawn数量是否等于章节数、failed是否为 0、rejected是否被后续修复、token_summary是否按 Agent 分类。常见错误与修复方式如下现象可能原因修复401 invalid api keyKey 未设置、拼写错误、未带 Bearer重新从控制台创建 Key确认请求头为Authorization: Bearer YOUR_API_KEY404 not foundBase URL 路径重复或缺少/v1Stellar Colosseum 适配器统一用https://taotoken.net/api不要手写重复/v1429 rate limit并行子问题 Agent 并发过高降低concurrency增加退避重试按章节分批timeout章节拆分输入过长或模型响应慢拆分输入增加超时或给章节拆分 Agent 换长上下文模型json parse error章节拆分 Agent 输出带解释文字在提示词中强制 JSON加入解析失败重试和截断修复model not found模型名与 TaoToken 控制台不一致在控制台确认可用模型名再更新配置建议把每次运行的失败类型计入日志而不是只看最终成功或失败。因为章节拆分阶段的错误会放大到并行子问题阶段一个章节 JSON 字段缺失可能导致多个子问题 Agent 重复生成一个依赖关系错误可能导致后续合并阶段出现矛盾。6. Token 统计与成本观察谁在消耗章节拆分预算可复现产出里最重要的一项就是 Token 统计。没有统计你无法判断章节拆分 Agent 和并行子问题 Agent 谁在消耗预算也无法决定哪些 Agent 该用更强模型、哪些该用更便宜的模型。下面给出一条本地样例的统计口径不代表所有证明规模只说明统计维度。统计项章节拆分 Agent并行子问题 Agent定向证伪 Agent批评合并 Agent调用次数1881输入 Token 示例12800482001860015200输出 Token 示例2600980042003100主要成本来源长上下文 JSON 结构并发调用次数候选逐个检查长上下文合并优化方向精简输入、固定 schema限流、缓存、批处理只对高风险章节执行合并前去重从这张表可以看出章节拆分 Agent 单次调用输入很长但调用次数少并行子问题 Agent 单次输入不一定最大但调用次数多是整体 Token 消耗的主要放大项。实际优化时可以这样分配模型章节拆分 Agent使用长上下文能力更稳的模型温度调低强制 JSON。并行子问题 Agent使用吞吐更好、成本更低的模型控制并发设置最大输出长度。定向证伪 Agent只对高风险章节或候选开启不必每个候选都全量证伪。批评合并 Agent使用长上下文模型但输入前先去重避免重复章节和重复候选挤占上下文。可以用下面的 Python 片段在每次调用后记录 Tokenimport json import time from pathlib import Path LOG_PATH Path(stellar_colosseum_token_log.jsonl) def log_usage(agent, chapter_id, response): usage getattr(response, usage, None) record { ts: time.time(), agent: agent, chapter_id: chapter_id, prompt_tokens: getattr(usage, prompt_tokens, None) if usage else None, completion_tokens: getattr(usage, completion_tokens, None) if usage else None, total_tokens: getattr(usage, total_tokens, None) if usage else None, } with LOG_PATH.open(a, encodingutf-8) as f: f.write(json.dumps(record, ensure_asciiFalse) \n)统计后按agent聚合就能得到类似下面的汇总import json from collections import defaultdict from pathlib import Path summary defaultdict(lambda: {calls: 0, prompt: 0, completion: 0}) for line in Path(stellar_colosseum_token_log.jsonl).read_text(encodingutf-8).splitlines(): item json.loads(line) agent item[agent] summary[agent][calls] 1 summary[agent][prompt] item.get(prompt_tokens) or 0 summary[agent][completion] item.get(completion_tokens) or 0 for agent, row in summary.items(): print(agent, row)如果发现并行子问题 Agent 的calls远高于章节数通常是因为重试或失败重放。此时不要只看总 Token还要看failed和retry字段。很多“Token 消耗异常”并不是模型单价问题而是章节拆分输出不稳定导致重复调用。7. Claude Code、Codex 与 CC Switch 接入 TaoToken 的配置差异虽然 Stellar Colosseum 的模型调用通常走 OpenAI 兼容接口但本地开发时经常还会同时使用 Claude Code、Codex 或 CC Switch 做辅助。它们的配置方式不同不能把ANTHROPIC_*套到 Codex也不能把 Codex 的config.toml直接当成 Claude Code 的settings.json。下面按工具分别给出可复制配置Base URL 统一为https://taotoken.net/apiKey 统一用YOUR_API_KEY。Claude Codesettings.json 与 ANTHROPIC_*Claude Code 使用ANTHROPIC_*系列环境变量。可以在项目或用户的settings.json中配置{ env: { ANTHROPIC_BASE_URL: https://taotoken.net/api, ANTHROPIC_AUTH_TOKEN: YOUR_API_KEY, ANTHROPIC_MODEL: claude-sonnet-4-5 } }如果你在 shell 里临时测试也可以直接导出export ANTHROPIC_BASE_URLhttps://taotoken.net/api export ANTHROPIC_AUTH_TOKENYOUR_API_KEY export ANTHROPIC_MODELclaude-sonnet-4-5注意这里使用的是ANTHROPIC_AUTH_TOKEN不是OPENAI_API_KEY。Claude Code 的模型名也要按 TaoToken 控制台实际可用的名称填写。Codexconfig.toml 与独立 providerCodex 使用config.toml不要混用 Claude Code 的ANTHROPIC_*。一个常见配置如下model 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然后在环境变量中设置 Keyexport TAOTOKEN_API_KEYYOUR_API_KEY如果你的 Codex 版本字段名不同以本地版本为准但核心不变base_url指向https://taotoken.net/apienv_key指向你实际导出的 Key 变量不要写ANTHROPIC_AUTH_TOKEN。CC Switch三件套配置CC Switch 这类切换工具通常只需要三件套Provider 名称、Base URL、API Key。可以按下面填写配置项值Provider NameTaoTokenBase URLhttps://taotoken.net/apiAPI KeyYOUR_API_KEY备注Stellar Colosseum 共用同一入口按 Agent 分模型这样切换时不需要改 Stellar Colosseum 的主体代码只需要确认当前激活的 Provider 是 TaoToken且 Base URL 没有被写成带 UTM 的官网地址。UTM 链接只用于访问官网和文档不用于 API 调用。如果你需要重新创建 Key可以从官网进入控制台https://taotoken.net/?utm_sourcetaotoken_aicg_blog_endutm_contentstellar_colosseum_ccswitch。8. 把章节拆分跑通后下一步做什么当 Stellar Colosseum 的章节拆分 Agent 能稳定输出 JSON并行子问题 Agent 能按章节调度并且 Token 统计能按 Agent 归因接入层就算跑通了。接下来可以继续做三件事第一把章节拆分模板版本化。每次调整提示词或 JSON schema都记录版本号并在跑通日志里带上。这样当合并阶段出现矛盾时可以回溯是章节拆分变化导致的还是子问题生成变化导致的。第二给并行子问题 Agent 加缓存和去重。相同章节、相同候选提示词、相同模型参数如果短时间内重复调用可以直接复用结果。长程证明研究中很多子问题会反复出现缓存能显著减少无效 Token。第三按 Agent 角色分配模型。章节拆分 Agent 用长上下文和结构化输出更稳的模型并行子问题 Agent 用吞吐和成本更优的模型证伪 Agent 只在高风险章节开启。TaoToken 提供统一 Base URL 和 Key 管理方便你在同一入口下做这些切换。如果你要直接复现本文流程建议按下面路径操作先打开模型对话确认模型可用https://taotoken.net/models/detail/chat?utm_sourcetaotoken_aicg_blog_endutm_contentstellar_colosseum_chat如果需要长期跑 Stellar Colosseum 和本地 Coding 工具查看 Coding Planhttps://taotoken.net/coding-plan?utm_sourcetaotoken_aicg_blog_endutm_contentstellar_colosseum_plan创建或管理 API Keyhttps://taotoken.net/console/api-keys?utm_sourcetaotoken_aicg_blog_endutm_contentstellar_colosseum_keys如果同时使用 Claude Code参考 Claude Code 文档https://taotoken.net/doc/ClaudeCodeAnthropic?utm_sourcetaotoken_aicg_blog_endutm_contentstellar_colosseum_claudecode最后再提醒一次配置要点Stellar Colosseum 的模型调用 Base URL 用https://taotoken.net/apiKey 用YOUR_API_KEY章节拆分 Agent 和并行子问题 Agent 分别统计 Token遇到 401、404、429 时先查 Key、路径拼接和并发数。把这些基础项固定下来长程证明的章节拆分阶段才能从“偶尔跑通”变成“可复现、可统计、可优化”的工程流程。
