1. 从章节级证明子问题到 Key 发放先把调度面拆清楚如果你正在复现 Stellar Colosseum 那类“先探索证明策略、过就绪门槛、再拆章节级子问题”的多智能体流程第一件容易踩坑的事不是提示词而是并行子问题 Agent 和候选生成器如何拿到可控的模型调用凭据。TaoToken 的接入入口是 https://taotoken.net/?utm_sourcetaotoken_aicg_blog_endutm_contentstellar_subproblem_intro Base URL 统一设为 https://taotoken.net/api。下面按“子问题调度”的视角把 Key 发放、Claude Code/Codex 配置、CC Switch 三件套、调度表和调用日志串成一条可复现路线。这类框架通常不是让一个模型从头到尾硬解长程数学问题而是先把证明路线当作可搜索对象策略探索 Agent 提出多种可能路径系统检查是否达到可推进条件也就是底稿里说的就绪门槛通过之后把整条路线按章节、引理、构造步骤切成更小的子问题。此时真正消耗 Token 的主体会从“一个总控模型”变成“并行子问题 Agent”和“候选生成器”每个子问题可能要求多个候选证明每个候选还要被定向证伪、批评、合并。如果没有调度表和 Key 发放记录你很快会分不清哪次调用属于哪条路线、哪个子问题、哪个候选。TaoToken 在这个流程里承担的是模型调用入口角色。你需要去 https://taotoken.net/?utm_sourcetaotoken_aicg_blog_endutm_contentstellar_subproblem_key 获取 Key然后把所有 Claude Code、Codex 或自建调度器里的 Base URL 指向 https://taotoken.net/api。注意Base URL 本身不带 UTMUTM 只用于官网和 deep link 归因。Key 占位符统一写成 YOUR_API_KEY不要提交到仓库。本节点的目标不是写一篇 Stellar Colosseum 新闻评论而是给出一套能跟做的接入与排障方法。你需要产出三样东西子问题调度表、Key 发放记录、调用日志。调度表决定谁在什么条件下调用模型Key 发放记录决定凭据如何归属调用日志决定如何回看失败、重试、证伪和合并。只要这三样齐了长程证明路线拆分就不会变成一堆不可追踪的并发请求。2. 子问题调度表把长程证明路线拆成可追踪的 API 任务子问题调度表是整个多智能体流程的骨架。它不需要一开始就很复杂但必须能回答四个问题这个子问题属于哪条证明路线、依赖谁、由哪类 Agent 执行、调用失败后如何重试。对于 Stellar Colosseum 这类“章节级子问题”场景建议最小字段包括subproblem_id,parent_route,chapter,goal,deps,ready_gate,agent_role,model_alias,max_tokens,temperature,candidate_count,key_alias,log_path,status,falsification_owner,merge_order SP-001,R1,Chapter-1,证明引理A,R0,gate-passed,subproblem_solver,reasoning-model,8000,0.3,3,tt-stellar-r1-sp001-solver,logs/sp-001.jsonl,pending,FD-001,10 SP-002,R1,Chapter-1,构造辅助对象,R0,gate-passed,candidate_generator,reasoning-model,6000,0.7,5,tt-stellar-r1-sp002-gen,logs/sp-002.jsonl,pending,FD-002,20 SP-003,R1,Chapter-2,合并候选并消除冲突,SP-001;SP-002,wait-deps,critic_merger,reasoning-model,10000,0.2,1,tt-stellar-r1-sp003-merge,logs/sp-003.jsonl,blocked,FD-003,30这张表的关键不是字段名多漂亮而是每个并行子问题都能映射到一条调用日志。parent_route表示它属于哪条策略路线ready_gate表示是否已经通过就绪门槛agent_role区分subproblem_solver、candidate_generator、falsifier、critic_mergercandidate_count决定候选生成器要发几次请求key_alias是 Key 发放记录里的别名不是完整 Keyfalsification_owner指定谁负责定向证伪merge_order决定批评合并的顺序。你可以用一份 YAML 作为输入在本地生成调度表。下面示例只生成 CSV不直接调用远程模型适合在本地或 CI 沙箱执行import csv import yaml from pathlib import Path config yaml.safe_load(Path(stellar_schedule.yml).read_text(encodingutf-8)) rows [] for route in config[routes]: for sp in route[subproblems]: rows.append({ subproblem_id: sp[id], parent_route: route[id], chapter: sp[chapter], goal: sp[goal], deps: ;.join(sp.get(deps, [])), ready_gate: sp.get(ready_gate, pending), agent_role: sp[role], model_alias: sp.get(model_alias, reasoning-model), max_tokens: sp.get(max_tokens, 8000), temperature: sp.get(temperature, 0.3), candidate_count: sp.get(candidate_count, 1), key_alias: sp[key_alias], log_path: flogs/{sp[id].lower()}.jsonl, status: sp.get(status, pending), falsification_owner: sp.get(falsification_owner, ), merge_order: sp.get(merge_order, 0), }) with open(subproblem_schedule.csv, w, newline, encodingutf-8) as f: writer csv.DictWriter(f, fieldnamesrows[0].keys()) writer.writeheader() writer.writerows(rows)对应的stellar_schedule.yml可以这样写routes: - id: R1 strategy: direct-construction subproblems: - id: SP-001 chapter: Chapter-1 goal: 证明引理A role: subproblem_solver deps: [] ready_gate: gate-passed key_alias: tt-stellar-r1-sp001-solver candidate_count: 3 - id: SP-002 chapter: Chapter-1 goal: 构造辅助对象 role: candidate_generator deps: [] ready_gate: gate-passed key_alias: tt-stellar-r1-sp002-gen candidate_count: 5 - id: SP-003 chapter: Chapter-2 goal: 合并候选并消除冲突 role: critic_merger deps: [SP-001, SP-002] ready_gate: wait-deps key_alias: tt-stellar-r1-sp003-merge candidate_count: 1 merge_order: 30实际跑并行子问题时不要让所有子问题同时无限并发。建议按parent_route和ready_gate做两级队列同一路线内先跑无依赖的subproblem_solver和candidate_generator等候选返回后再跑falsifier最后按merge_order进入critic_merger。这样 Token 消耗主体清晰候选生成器负责发散子问题 Agent 负责收敛批评合并只处理已经通过证伪的候选。3. TaoToken Key 发放记录为并行子问题 Agent 建立可审计凭据当你准备给 Stellar Colosseum 模型调用发 Key 时建议先去 https://taotoken.net/?utm_sourcetaotoken_aicg_blog_endutm_contentstellar_subproblem_console 创建或管理 Key。不要把同一个 Key 直接写进每个子问题 Agent 的 prompt也不要在日志里打印完整 Key。正确做法是给每个子问题或每类角色分配一个key_alias真实 Key 只放在环境变量或密钥管理系统中。Key 发放记录可以先用 CSV 维护key_alias,subproblem_id,agent_role,owner,created_at,rotate_after,status,env_name tt-stellar-r1-sp001-solver,SP-001,subproblem_solver,proof-team,2025-06-01,30d,active,TAOTOKEN_KEY_SP001 tt-stellar-r1-sp002-gen,SP-002,candidate_generator,proof-team,2025-06-01,30d,active,TAOTOKEN_KEY_SP002 tt-stellar-r1-sp003-merge,SP-003,critic_merger,proof-team,2025-06-01,30d,active,TAOTOKEN_KEY_SP003本地运行时用环境变量注入export TAOTOKEN_BASE_URLhttps://taotoken.net/api export TAOTOKEN_KEY_SP001YOUR_API_KEY export TAOTOKEN_KEY_SP002YOUR_API_KEY export TAOTOKEN_KEY_SP003YOUR_API_KEY如果你的调度器用 Python可以按key_alias取对应环境变量而不是把 Key 硬编码import os def resolve_key(key_alias: str) - str: env_name { tt-stellar-r1-sp001-solver: TAOTOKEN_KEY_SP001, tt-stellar-r1-sp002-gen: TAOTOKEN_KEY_SP002, tt-stellar-r1-sp003-merge: TAOTOKEN_KEY_SP003, }[key_alias] value os.environ.get(env_name) if not value: raise RuntimeError(fmissing env: {env_name}) return value这里要强调三点。第一Base URL 是 https://taotoken.net/api不要写成官网页面地址也不要给 Base URL 加 UTM。第二Key 别名进入调度表真实 Key 只进入环境变量或密钥管理。第三Key 发放记录要能回答“哪个子问题用了哪个 Key、什么时候轮换、谁负责”。这样即使某个候选生成器出现大量失败你也可以先按key_alias聚合日志再判断是 Key 权限、模型路由、提示词还是子问题本身的问题。对于长程证明任务建议按路线或章节做粗粒度隔离。比如R1路线下所有子问题共享一组 Key 别名R2路线使用另一组。这样当某条策略路线被证伪后你可以停止对应 Key 的调度保留日志用于批评合并。不要等到最后才发现某条失败路线消耗了大量候选生成调用却无法归因到具体子问题。4. Claude Code 配置settings.json 与 ANTHROPIC_* 的并行子问题写法Claude Code 适合作为本地子问题 Agent 的执行入口尤其是你需要让模型在项目目录里读取证明草稿、生成候选、写调度记录时。配置时使用settings.json和ANTHROPIC_*环境变量。下面示例把 Base URL 指向 TaoToken{ env: { ANTHROPIC_BASE_URL: https://taotoken.net/api, ANTHROPIC_API_KEY: YOUR_API_KEY, ANTHROPIC_MODEL: your-claude-model-id } }如果使用项目级配置可以放在项目的.claude/settings.json或.claude/settings.local.json。团队共享的配置放settings.json个人本地 Key 放settings.local.json并加入.gitignore。不要在settings.json里写真实 Key。Claude Code 运行时你也可以用 shell 环境变量覆盖export ANTHROPIC_BASE_URLhttps://taotoken.net/api export ANTHROPIC_API_KEYYOUR_API_KEY export ANTHROPIC_MODELyour-claude-model-id在 Stellar Colosseum 的调度里Claude Code 通常承担subproblem_solver或critic_merger。你可以给每个子问题单独开一个工作目录例如mkdir -p work/SP-001 work/SP-002 work/SP-003 cd work/SP-001然后在对应目录放置该子问题的上下文、候选文件和日志路径。注意Claude Code 的ANTHROPIC_*只用于 Claude Code 自身不要把它复制到 Codex 的config.toml里。Codex 使用自己的配置体系下一节单独写。为了和调度表对齐可以约定每个子问题目录下必须有work/SP-001/ prompt.md candidates/ schedule_row.json logs/calls.jsonl result.mdschedule_row.json是从subproblem_schedule.csv抽取的单行记录方便子问题 Agent 读取自己的goal、deps、candidate_count和key_alias。调用日志写入logs/calls.jsonl而不是只留在终端输出里。这样你最终合并时批评合并 Agent 可以按subproblem_id读取候选和证伪结果。5. Codex 配置config.toml 中切换 TaoToken不混用 ANTHROPIC_*Codex 使用config.toml不要在里面写ANTHROPIC_*。如果你的流程里 Codex 用于辅助生成验证脚本、整理候选证明或检查章节级依赖可以这样配置模型提供方model your-codex-model-id model_provider taotoken [model_providers.taotoken] name TaoToken base_url https://taotoken.net/api env_key TAOTOKEN_API_KEY wire_api responses然后在本地设置export TAOTOKEN_API_KEYYOUR_API_KEY如果你的 Codex 版本要求wire_api为其他值以本地实际报错为准。关键是两点base_url指向 https://taotoken.net/apienv_key指向你本地的环境变量名而不是直接把 Key 写入config.toml。在子问题调度里Codex 更适合做“候选生成器的后处理”或“验证脚本生成”不要把长程数学证明的全部希望压在一个编码模型上。你可以让 Codex 读取candidates/下的候选证明生成检查脚本、反例搜索脚本或合并 diff然后把结果写回result.md。调度表里可以增加一列tool_runtime区分claude-code、codex或python-schedulersubproblem_id,agent_role,tool_runtime,key_alias,status SP-001,subproblem_solver,claude-code,tt-stellar-r1-sp001-solver,pending SP-002,candidate_generator,codex,tt-stellar-r1-sp002-gen,pending SP-003,critic_merger,python-scheduler,tt-stellar-r1-sp003-merge,pending这样你不会把 Claude Code 的ANTHROPIC_*误配到 Codex也不会把 Codex 的TAOTOKEN_API_KEY误配到 Claude Code。两者共用的是 TaoToken 的 Base URL 和 Key 管理策略不是同一套环境变量名。6. CC Switch 三件套供应商档案、激活快照、项目覆盖如果你的团队使用 CC Switch 管理 Claude Code 供应商建议把它的“三件套”纳入子问题调度流程。不同版本的路径和字段可能不同下面以本地配置为例核心思想是把供应商档案、当前激活项、项目级覆盖分开。第一件供应商档案用来保存 TaoToken 入口{ providers: [ { name: taotoken, baseUrl: https://taotoken.net/api, apiKeyEnv: ANTHROPIC_API_KEY, model: your-claude-model-id } ] }第二件激活快照用来表示当前调度批次使用哪个供应商{ activeProvider: taotoken, batchId: stellar-r1-20250601, notes: R1 route subproblem scheduling }第三件项目覆盖放在具体子问题工作目录或项目级.claude/settings.local.json中{ env: { ANTHROPIC_BASE_URL: https://taotoken.net/api, ANTHROPIC_API_KEY: YOUR_API_KEY, ANTHROPIC_MODEL: your-claude-model-id } }三件套的职责要分清供应商档案描述“可以连哪里”激活快照描述“当前批次用哪里”项目覆盖描述“这个子问题目录用什么模型和 Key”。当某个子问题需要切模型时只改项目覆盖不要改全局供应商档案。当整条路线切换供应商时改激活快照并在 Key 发放记录里新增一条变更记录。这样并行子问题 Agent 的调用日志才能和配置变更对齐。如果你不用 CC Switch也可以用同样的三件套思想一个供应商清单、一个批次激活文件、一个项目级覆盖文件。重点不是工具名而是避免所有子问题共用一个不可追踪的全局配置。7. 调用日志与失败重试把证伪和批评合并接回调度表调用日志是长程证明路线拆分的黑匣子。每个子问题 Agent、候选生成器、证伪器和批评合并器都应该写 JSONL而不是只打印到控制台。推荐字段{ts:2025-06-01T10:00:01Z,subproblem_id:SP-001,agent_role:subproblem_solver,key_alias:tt-stellar-r1-sp001-solver,model:your-model-id,base_url:https://taotoken.net/api,prompt_hash:a1b2c3,candidate_id:cand-001,status:ok,latency_ms:8421,input_tokens:1200,output_tokens:900,retry_count:0} {ts:2025-06-01T10:00:12Z,subproblem_id:SP-002,agent_role:candidate_generator,key_alias:tt-stellar-r1-sp002-gen,model:your-model-id,base_url:https://taotoken.net/api,prompt_hash:d4e5f6,candidate_id:cand-004,status:error,error_type:timeout,retry_count:1}日志里不要写完整 Key只写key_alias。base_url固定写https://taotoken.net/api方便排查是否有人误配到其他地址。prompt_hash用于对比同一子问题不同候选是否用了相同输入。candidate_id用于后续证伪和合并。retry_count用于判断某个子问题是否长期不稳定。按子问题聚合时可以用本地 Python 做最简分析import json from collections import defaultdict stats defaultdict(lambda: {ok: 0, error: 0, tokens: 0}) with open(logs/all_calls.jsonl, encodingutf-8) as f: for line in f: row json.loads(line) key row[subproblem_id] if row[status] ok: stats[key][ok] 1 else: stats[key][error] 1 stats[key][tokens] row.get(input_tokens, 0) row.get(output_tokens, 0) for sp, s in stats.items(): print(sp, s)拿到统计后回到subproblem_schedule.csv更新status。如果SP-002的候选生成器大面积超时先检查 Key 别名、并发数和max_tokens如果SP-003的批评合并失败检查依赖是否齐全、候选是否都通过了证伪。不要把失败重试直接交给另一个 Agent 无限循环应该由调度器根据retry_count和max_retries控制。证伪结果也要写回调度表。例如FD-002对SP-002的 5 个候选给出 2 个反例、3 个可合并那么critic_merger只处理这 3 个。批评合并按merge_order排序确保先处理章节内依赖再处理跨章节依赖。最终result.md和calls.jsonl一起归档形成可复现产出。8. 文末 CTA从模型对话到 Coding Plan 的接入路径如果你已经准备好把 Stellar Colosseum 式的子问题调度接到 TaoToken建议按下面路径操作先体验模型对话确认你的证明子问题提示词和模型路由是否匹配https://taotoken.net/models/detail/chat?utm_sourcetaotoken_aicg_blog_endutm_contentstellar_subproblem_cta如果涉及 Claude Code、Codex 或批量 Coding Agent查看 Coding Planhttps://taotoken.net/coding-plan?utm_sourcetaotoken_aicg_blog_endutm_contentstellar_subproblem_cta为并行子问题 Agent 和候选生成器创建 Key并登记到 Key 发放记录https://taotoken.net/console/api-keys?utm_sourcetaotoken_aicg_blog_endutm_contentstellar_subproblem_ctaClaude Code 用户继续参考接入文档把ANTHROPIC_BASE_URL设为 https://taotoken.net/apihttps://taotoken.net/doc/ClaudeCodeAnthropic?utm_sourcetaotoken_aicg_blog_endutm_contentstellar_subproblem_cta最后再强调一次所有 Base URL 统一使用 https://taotoken.net/apiKey 使用 YOUR_API_KEY 占位官网入口使用 https://taotoken.net/?utm_sourcetaotoken_aicg_blog_endutm_contentstellar_subproblem_final 获取最新控制台路径。把子问题调度表、Key 发放记录、调用日志三样东西落到本地文件后你的长程证明路线拆分就不再是一次性实验而是可以回放、审计、重试和继续合并的工程流程。