在 Stellar Colosseum 的模型配置里只改 model、没改 base_url章节级子问题一并行就会打到默认通道日志里出现 401/404 或 usage 为空。先把模型通道换成 TaoToken到 https://taotoken.net/?utm_sourcetaotoken_aicg_blog_endutm_contentstellar-colosseum-intro 获取 Key再把 Base URL 写为 https://taotoken.net/api。Google Research 最近发布的 Stellar Colosseum 把长程数学与理论计算机科学研究拆成多智能体协作流程先试探证明策略过门槛后按章节拆子问题并行生成候选再做定向证伪与批评合并。这个流程在单轮对话里看不出问题一旦进入并行候选阶段Token 消耗会被上下文复制、多轮批评和合并长上下文迅速放大。本文不讨论新闻本身而是给出一套可跟做的接入与排查路径在 Stellar Colosseum 的模型配置中替换 API Key/Base URL跑一个章节级子问题对照官方通道与 TaoToken 通道的候选生成轮次和 Token 统计确认哪个阶段在多智能体并行时消耗最大。1. Stellar Colosseum 的章节级子问题先把 TaoToken Key 和 Base URL 接进去Stellar Colosseum 是面向长程数学和理论计算机科学的模型无关多智能体框架。它的运行不是一次性问答而是先让多个策略探索器试探证明路线当路线达到就绪门槛后把整条证明拆成章节级子问题每个子问题再并行生成多个候选方案随后交给批评者做定向证伪最后把存活方案合并。这个设计对研究任务很合理但对模型调用通道很敏感每一层并行都会产生新的请求而每个请求都可能携带较长的上下文。如果模型配置没有正确指向 TaoToken或者 Key 没有替换成 YOUR_API_KEY 的实际值最先暴露的往往不是证明失败而是请求被拒、模型找不到或 usage 字段缺失。因此第一步不是调 prompt而是确认模型调用通道。在 Stellar Colosseum 里模型无关通常意味着它会通过适配层读取 OpenAI 兼容接口或 Anthropic 接口。不同适配层的环境变量名不同但核心只有三项Base URL、API Key、模型名。Base URL 要写成 TaoToken 给出的工具配置地址https://taotoken.net/api注意这个地址不要加 UTM 参数UTM 只用于官网入口统计。API Key 从 TaoToken 控制台创建替换代码或配置文件里的 YOUR_API_KEY。模型名则按你在 TaoToken 控制台或模型对话页面实际可用的名称填写。不要凭记忆写一个不存在的模型名否则会得到 model not found 一类的错误。最小验证动作不是直接跑完整证明而是选一个章节级子问题让它只触发候选生成与一次批评。观察日志里是否出现正常的 usage 统计。如果 usage 为空说明客户端没有解析返回体或者请求没有真正走到 TaoToken 通道。此时先检查 base_url 是否被项目里另一个配置文件覆盖再检查环境变量是否在启动进程之前导出。很多并行框架会为每个子智能体创建独立进程或线程父进程的环境变量不一定自动传递最好在配置层显式写入。官网入口在这里https://taotoken.net/?utm_sourcetaotoken_aicg_blog_endutm_contentstellar-colosseum-key 。进入控制台后创建 Key再回到 Stellar Colosseum 的模型配置中替换。不要跳过这一步直接跑并行任务因为并行候选一旦开始错误请求会成倍出现排查成本更高。2. 用 TaoToken Key 跑通章节级子问题最小配置与验证路径先准备一个可回滚的配置目录。复制 Stellar Colosseum 原有的模型配置保存为 config.taotoken.json 或环境变量文件。然后按下面顺序操作。第一步获取 TaoToken Key。入口是 https://taotoken.net/?utm_sourcetaotoken_aicg_blog_endutm_contentstellar-colosseum-config 。创建后立即复制Key 通常只显示一次。第二步设置通用环境变量。如果你的 Stellar Colosseum 适配层读取 OpenAI 兼容变量可以这样写export TAOTOKEN_API_KEYYOUR_API_KEY export OPENAI_BASE_URLhttps://taotoken.net/api export OPENAI_API_KEY$TAOTOKEN_API_KEY如果适配层读取 Anthropic 变量则这样写export ANTHROPIC_BASE_URLhttps://taotoken.net/api export ANTHROPIC_API_KEYYOUR_API_KEY不要把 Anthropic 变量套到 Codex 上Codex 的配置方式不同后面会单独说明。第三步在 Stellar Colosseum 的模型配置里指定 provider。不同版本的字段名可能不同但语义相同provider 名称、base_url、api_key、model。你可以用下面这个通用 JSON 片段作为对照字段名请按项目实际适配层映射{ model_provider: { name: taotoken, base_url: https://taotoken.net/api, api_key: YOUR_API_KEY, api_key_env: TAOTOKEN_API_KEY }, agents: { strategy_explorer: { model: claude-sonnet-4-20250514, max_parallel: 2 }, candidate_generator: { model: claude-sonnet-4-20250514, max_parallel: 4 }, critic: { model: claude-sonnet-4-20250514, max_parallel: 4 }, merger: { model: claude-sonnet-4-20250514, max_parallel: 1 } } }第四步只跑一个章节级子问题。把并行数临时调低比如 strategy_explorer 设为 1candidate_generator 设为 2critic 设为 1merger 设为 1。这样能先确认通路再逐步放大并行度。运行后在日志里找 usage 字段确认 input_tokens 和 output_tokens 有值。第五步记录基准。把这次运行的候选生成轮次、批评轮次、合并轮次、每轮 Token 统计保存成 JSONL。后面与官方通道对照时必须保证模型、温度、max_tokens、子问题文本、并行数完全一致否则比较没有意义。3. Claude Code settings.json 接入 TaoToken多智能体并行证明时 Token 统计口径Claude Code 的配置走 settings.json 和 ANTHROPIC_* 环境变量。你可以在用户级 ~/.claude/settings.json 或项目级 .claude/settings.json 中写入{ env: { ANTHROPIC_BASE_URL: https://taotoken.net/api, ANTHROPIC_API_KEY: YOUR_API_KEY, ANTHROPIC_MODEL: claude-sonnet-4-20250514 } }保存后重启 Claude Code或者重新加载配置。验证方式是先发一个单轮问题看是否返回正常。再发一个需要长上下文的任务观察是否出现 401 或 404。如果 401检查 YOUR_API_KEY 是否已经替换如果 404检查 Base URL 是否误写成 https://taotoken.net/api/v1 或 https://taotoken.net/。工具配置地址以 https://taotoken.net/api 为准。对于 Stellar Colosseum如果某个 agent 要通过 Claude Code 通道调用模型需要让该 agent 的适配层读取 ANTHROPIC_* 变量。建议把策略探索器和批评者放在同一个 provider 上把候选生成器放在另一个 provider 上方便对比不同阶段的 Token 消耗。但不要在 Codex 配置里写 ANTHROPIC_API_KEY这会导致变量不生效。Claude Code 文档入口https://taotoken.net/doc/ClaudeCodeAnthropic?utm_sourcetaotoken_aicg_blog_endutm_contentstellar-colosseum-claudecode 。遇到配置项不确定时先看文档再改 settings.json。Token 统计方面Claude Code 本身可能不直接展示每个子智能体的用量因此需要在 Stellar Colosseum 的模型适配层加日志。每次请求记录 stage、agent、round、input_tokens、output_tokens。这样后面才能定位是策略探索、候选生成、定向证伪还是批评合并消耗最大。4. Codex config.toml 接入 TaoToken不要混用 ANTHROPIC_* 变量Codex 使用 config.toml不使用 Claude Code 的 ANTHROPIC_* 变量。一个可参考的配置如下model o4-mini model_provider taotoken preferred_auth_method apikey [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注意 env_key 写的是 TAOTOKEN_API_KEY不是 ANTHROPIC_API_KEY也不是 OPENAI_API_KEY。Codex 启动后会读取这个变量再按 model_provider 找到 base_url。如果遇到 404先确认 base_url 没有多余路径如果遇到 model not found确认 model 名称在 TaoToken 侧可用。获取 Key 的入口https://taotoken.net/?utm_sourcetaotoken_aicg_blog_endutm_contentstellar-colosseum-codex 。在 Stellar Colosseum 中如果候选生成器使用 Codex 通道可以把该 agent 的模型设为 o4-mini并让它走 config.toml 里的 taotoken provider。但不要让 Codex agent 读取 ANTHROPIC_*否则会出现配置冲突。建议在框架里为不同 agent 显式指定 provider 名称而不是依赖全局环境变量。这样多智能体并行时每个 agent 的调用通道清晰Token 统计也能按 provider 分开。5. CC Switch 三件套在 Claude Code 与 Codex 之间切 TaoToken 通道如果你用 CC Switch 管理多个编码工具可以把 TaoToken 配成一个独立 profile。所谓三件套就是供应商、Base URL、API Key 三项。不同版本的字段名可能不一样但语义固定。可以参考下面这个结构{ provider: taotoken, baseUrl: https://taotoken.net/api, apiKey: YOUR_API_KEY }如果 CC Switch 需要同时维护 Claude Code 和 Codex建议拆成两个 profile。Claude Code profile 的模型填 claude-sonnet-4-20250514环境变量走 ANTHROPIC_*Codex profile 的模型填 o4-mini配置走 config.toml 和 TAOTOKEN_API_KEY。切换 profile 后重启终端或重新加载配置确保旧环境变量不会残留。常见问题是切换后仍然命中旧通道。排查时先看当前终端里的环境变量再看工具自己的配置文件。Claude Code 看 settings.jsonCodex 看 config.tomlCC Switch 看当前激活的 profile。三处只要有一处写错多智能体并行时就会有一部分 agent 走错通道Token 统计也会混在一起。建议在日志里记录实际请求的 base_url 和 provider 名称哪怕只记录 host 部分也能快速判断请求去了哪里。6. 多智能体并行候选的 Token 放大点策略探索、候选生成、证伪、合并逐段拆Stellar Colosseum 的 Token 消耗不是均匀分布的。要从并行候选角度排查最好把流程拆成五个阶段分别统计。第一阶段是策略探索。多个策略探索器并行试探不同证明路线每个探索器可能进行多轮对话。假设有 S 个策略、每策略 R 轮那么请求数约为 S×R。这个阶段单轮上下文可能不长但轮次多而且每个策略都要携带任务背景。如果背景材料很长S 份背景会被重复发送。第二阶段是就绪门槛。框架会判断当前路线是否达到进入下一阶段的标准。这个判断可能由模型投票、评分或批评完成也可能触发重试。很多人忽略门槛本身的调用量实际上它会在策略探索和章节拆分之间产生额外请求。如果门槛判断要求多个判定者并行Token 消耗会再乘一个系数。第三阶段是章节级子问题拆分。证明路线被拆成多个章节后每个章节作为独立子问题运行。独立上下文的好处是并行度高坏处是系统提示、研究背景、符号表、已知引理会被复制到每个子问题。如果拆出 N 个章节系统提示就被发送 N 次。这个阶段的 Token 放大来自上下文复制而不是单次请求变长。第四阶段是并行候选生成。每个章节级子问题生成 K 个候选方案每个候选可能还要多轮修正。请求数约为 N×K×R。这是最容易失控的阶段。候选生成器通常需要读取章节上下文、前序证明片段、可用引理和约束条件。如果每个候选都完整携带这些内容输入 Token 会随候选数线性增长。更麻烦的是候选之间往往不能共享 KV 缓存因为它们是独立请求。第五阶段是定向证伪与批评合并。每个候选会被多个批评者检查批评者要读取候选全文再输出反驳、漏洞或改进建议。请求数约为 N×K×MM 是批评者数量。批评阶段虽然输出可能不长但输入包含候选全文所以 input_tokens 很高。最后的合并器要读取存活候选和批评意见输入 Token 接近上游多个结果之和。如果上下文窗口接近上限还要分段摘要摘要本身又会产生额外调用。把五个阶段加起来Token 消耗不是简单相加而是逐层放大。排查时不要只看总 Token而要看每个阶段的 calls、input、output 和平均每轮 Token。通常候选生成和批评合并是最大的两个消耗点。策略探索可能轮次多但单次上下文短合并阶段调用次数少但单次输入极长。只有分阶段统计才能确认在你的具体子问题上哪个阶段最贵。7. 章节级子问题对照实验官方通道 vs TaoToken 通道的统计脚本要验证 TaoToken Key 是否撑得住 Token 消耗可以做一次对照实验。实验目标不是比较模型能力而是比较同一章节级子问题在两个通道下的候选生成轮次和 Token 统计。步骤如下。第一步固定实验条件。选一个中等长度的章节级子问题固定模型名称、温度、max_tokens、并行数、候选数、批评者数量。官方通道和 TaoToken 通道使用同一份输入。第二步在 Stellar Colosseum 的模型适配层加日志。每次模型调用结束后追加一行 JSONL至少包含 stage、agent、round、input_tokens、output_tokens。stage 取值可以是 strategy、gate、split、candidate、critic、merge。agent 记录具体智能体编号。round 记录该智能体的对话轮次。日志示例{stage:strategy,agent:explorer-1,input_tokens:1200,output_tokens:300,round:1} {stage:candidate,agent:generator-3,input_tokens:4500,output_tokens:900,round:2} {stage:critic,agent:critic-2,input_tokens:5200,output_tokens:400,round:1} {stage:merge,agent:merger,input_tokens:18000,output_tokens:1500,round:1}第三步分别运行官方通道和 TaoToken 通道得到 usage_official.jsonl 和 usage_taotoken.jsonl。第四步用下面的 Python 脚本汇总import json from collections import defaultdict def summarize(path): stats defaultdict(lambda: {calls: 0, input: 0, output: 0}) with open(path, r, encodingutf-8) as f: for line in f: line line.strip() if not line: continue rec json.loads(line) stage rec.get(stage, unknown) stats[stage][calls] 1 stats[stage][input] int(rec.get(input_tokens, 0)) stats[stage][output] int(rec.get(output_tokens, 0)) return stats for name, path in [ (官方通道, usage_official.jsonl), (TaoToken, usage_taotoken.jsonl), ]: print(f {name} ) for stage, v in summarize(path).items(): total v[input] v[output] print( f{stage}: calls{v[calls]}, finput{v[input]}, output{v[output]}, total{total} )第五步比较结果。重点看三个指标候选生成阶段的 calls 是否随并行数增加而增加批评阶段的 input 是否接近候选全文长度乘以批评者数量合并阶段的 input 是否接近所有候选和批评的总和。如果 TaoToken 通道的统计与官方通道趋势一致说明接入正确。如果 TaoToken 通道出现大量 429说明并行数超过了当前 Key 的并发限制需要降低 max_parallel 或调整运行节奏。第六步做优化对照。把候选数从 K 降到 K/2或者把批评者从 M 降到 1再跑一次。观察总 Token 下降最多的阶段。通常降低候选数会显著减少候选生成和批评阶段的 input而限制合并器读取的候选数量会显著减少合并阶段 input。把这些优化写回 Stellar Colosseum 的配置再跑完整章节。8. 常见报错与配置检查清单401、404、429、usage 为空多智能体并行时错误会被并发放大。下面这些检查项建议按顺序过一遍。401 UnauthorizedKey 没替换或者环境变量名不对。Claude Code 检查 ANTHROPIC_API_KEYCodex 检查 TAOTOKEN_API_KEY通用适配层检查实际读取的变量名。确认 YOUR_API_KEY 已经换成真实 Key。404 Not FoundBase URL 写错。工具配置地址是 https://taotoken.net/api。不要写成官网首页也不要随意追加 /v1。如果客户端要求完整路径先按客户端文档确认不要靠猜。model not found模型名在 TaoToken 侧不可用。到模型对话页面确认可用模型再写回配置。不要同时混用 Anthropic 模型名和 OpenAI 模型名到同一个 provider。429 Too Many Requests并行候选数过高。降低 candidate_generator 和 critic 的 max_parallel或者增加重试间隔。多智能体框架默认并发可能很高第一次接入时建议从 1 到 2 开始。usage 为空客户端没有解析 usage 字段或者请求被中间层截断。先在适配层记录请求前后的 Token 计数再到 TaoToken 控制台看用量。如果控制台有量而日志没有说明解析逻辑需要补。上下文超限合并阶段读取了太多候选全文。限制合并器输入的候选数量先让批评者输出摘要再让合并器读取摘要而非全文。流式响应中断长证明任务需要更长超时。检查框架的 timeout 和重试配置避免并行请求互相拖垮。配置不生效Claude Code 看 settings.jsonCodex 看 config.tomlCC Switch 看当前激活 profile。切换后重启终端避免旧环境变量残留。9. 把 TaoToken 接入 Stellar Colosseum 的最短路径如果你已经确认 Stellar Colosseum 的章节级子问题需要多智能体并行建议按最短路径接入 TaoToken先到模型对话页面确认可用模型https://taotoken.net/models/detail/chat?utm_sourcetaotoken_aicg_blog_endutm_contentstellar-colosseum-chat查看 Coding Plan 是否匹配你的并行规模https://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 文档配置 settings.jsonhttps://taotoken.net/doc/ClaudeCodeAnthropic?utm_sourcetaotoken_aicg_blog_endutm_contentstellar-colosseum-claudecode接入后不要立刻把并行数拉满。先用一个章节级子问题跑通记录候选生成轮次和 Token 统计再逐步增加候选数、批评者数量和章节数。每次调整都保留一份 usage JSONL对比哪个阶段的 input_tokens 增长最快。Stellar Colosseum 的多智能体并行证明很有价值但它的 Token 消耗来自上下文复制和多轮批评而不是单次回答变长。把 TaoToken Key、Base URL、模型名配置正确再用分阶段统计定位最大消耗点才能让长程数学研究任务跑得更稳。