1. 五个 Sub-Agent 同时启动账单为什么翻了六倍多 Agent 编排最容易制造一种「看起来很快、账单很贵」的系统。我拿一个真实跑过的例子说Supervisor 收到「分析某行业并生成投资建议」同时拉起市场、财务、政策、竞争、风险五个 Sub-Agent。每个 Agent 都收到完整会话 25K Token、附件摘要 20K Token、Tool Schema 8K Token光输入就是 53K × 5 265K Token。这还没算每个 Agent 各自两次模型调用、5K 输出、Reviewer 读全部结果、Supervisor 最终合并。单次请求的成本结构不再是「一次模型调用」而是Supervisor 输入 N 个 Sub-Agent 输入 N 个 Sub-Agent 输出 Tool 循环 Reviewer 最终合并如果存在嵌套委派Agent-A 调 B、CB 再调 D成本按树状增长。并发只压缩墙钟时间不减少 Token 总量反而会因为缺少共享缓存、重复检索、重复摘要、抢占预算造成额外浪费。这篇要解决的就是这个场景并行 Sub-Agent 的 Token 成本暴涨怎么按上下文复制、并发扇出、预算争用三条链路排查并用统一 Key 通道把每个 Sub-Agent 的调用量记录下来做归因。适合已经在跑多 Agent 编排、发现账单和预期对不上、又不知道从哪一层开始查的开发者。排查顺序比优化技巧更重要顺序错了会在错误的地方省钱。2. 用 TaoToken 统一 Key 做多 Sub-Agent 成本观测的前置准备排查成本暴涨第一步不是改代码而是先能看见钱花在哪。多 Agent 系统最麻烦的地方在于五个 Sub-Agent 可能走五套 Key、五个 Base URL账单分散在不同后台你根本拼不出调用树。TaoToken 在这里的作用是提供一个统一 API 通道所有 Sub-Agent、Supervisor、Reviewer 都走同一个 Key 和同一个 Base URL调用量、模型、时间戳集中在一处方便按run_id/task_id归因。它不替代你的编排框架只负责把模型调用这一层的账记清楚。前置准备三件事第一拿到统一 Key。登录后在控制台创建 API Key建议按环境分dev / staging / prod不要多个 Sub-Agent 共用一个 Key 又不打标签否则归因时你分不清是哪个 Agent 花的。第二确认 Base URL 和模型 ID。多 Agent 场景通常要混用模型Router 用便宜的小模型复杂研究用强模型Reviewer 用强模型或规则组合。统一通道下切换模型只改 Model ID不用改 Key。第三给每次 Run 打上可追踪的标识。这是后面成本树归因的基础没有run_id你只能看到总量看不到树。相关入口API Key 管理https://taotoken.net/api-keys?utm_sourcetaotoken_aicg_blog_endutm_mediumcsdnutm_campaignrewriteutm_contentsubagent_cost接入文档https://taotoken.net/doc?utm_sourcetaotoken_aicg_blog_endutm_mediumcsdnutm_campaignrewriteutm_contentsubagent_cost模型对话验证https://taotoken.net/chat?utm_sourcetaotoken_aicg_blog_endutm_mediumcsdnutm_campaignrewriteutm_contentsubagent_cost注意统一 Key 的价值在观测不在「省单价」。如果你的问题是上下文复制导致的 5 倍输入换任何通道都救不了必须先做上下文工程。3. 可复制的并发上限、上下文裁剪与预算阈值配置这一节给可直接落地的配置。分三块并发上限、上下文裁剪、预算预留。每块都给可复制的片段。3.1 并发上限配置JSON全局并发必须是共享的不能每个 Agent 内部各限 5 并发、20 个 Agent 合计 100 并发。下面这份agent_scheduler.json把 Run 级、Provider 级、模型级三层 Semaphore 都写清楚{ scheduler: { maximumParallelTasks: 4, maximumDelegationDepth: 2, maximumTasksPerRun: 12, maximumChildrenPerTask: 3, queueTimeoutSeconds: 30, defaultJoinPolicy: QUORUM }, providerConcurrency: { maximumConcurrentRequests: 8, maximumQueuedRequests: 32, retryAfterFloorMs: 800, maximumRetriesPerRun: 6 }, modelConcurrency: { strong-model: 3, small-model: 8, reviewer-model: 2 } }关键点maximumParallelTasks是 Run 级上限providerConcurrency是跨 Run 共享的 Provider 上限。两者取小值生效。maximumDelegationDepth: 2意味着 Supervisor → Agent-A → Agent-B 之后不能再往下委派防止 A 委派 B、B 又委派 A 的环。3.2 上下文裁剪配置TOML上下文复制是成本暴涨的第一大来源。下面这份context_view.toml按 Agent 角色定义 Context View只放完成当前 Task 所需内容[context.default] include_full_conversation false include_all_documents false include_all_tools false max_estimated_tokens 12000 [context.roles.market] allowed_tools [web_search, competitor_lookup] artifact_filters [market_*, competitor_*] message_window 6 [context.roles.finance] allowed_tools [financial_api, ratio_calc] artifact_filters [financial_*, filing_*] message_window 4 [context.roles.legal] allowed_tools [regulation_search] artifact_filters [regulation_*, policy_*] message_window 4 [context.roles.reviewer] allowed_tools [] artifact_filters [claim_*, conflict_*, evidence_*] message_window 2include_full_conversation false是最重要的一行。研究 Agent 不需要财务审批历史财务 Agent 也不需要所有原始网页。max_estimated_tokens给每个角色设硬上限超了就触发 Context Reduction Plan。3.3 预算预留配置settings 片段预算不是共享资源是并行 Sub-Agent 最隐蔽的坑每个 Sub-Agent 都以为自己有完整 100 元预算总成本可能 100 × N。下面这份budget.settings.json定义 Run 预算和原子预留{ runBudget: { tokenLimit: 400000, modelCallLimit: 60, toolCallLimit: 120, costLimit: 8.00, deadlineSeconds: 180 }, reservation: { safetyMarginRatio: 0.25, expiresSeconds: 120, atomic: true, reclaimUnused: true }, retryBudget: { maximumRetries: 3, maximumRetryCost: 1.20, retryable: [RATE_LIMIT, TIMEOUT, TRANSIENT_5XX] } }safetyMarginRatio: 0.25是给模型输出不确定性留的余量。atomic: true对应数据库层的原子预留两个 Task 同时抢最后预算时只能一个成功update agent_budget set reserved_cost reserved_cost :amount, version version 1 where run_id :runId and cost_limit - spent_cost - reserved_cost :amount and version :expectedVersion;没有预留就不启动 Task。这条规则能挡掉大部分「预算争用」导致的超支。4. 验证请求对比扇出前后的 Token 消耗配置写完必须验证否则你不知道改动有没有生效。验证分两步先确认统一 Key 通道能正常调用再对比扇出前后的消耗。4.1 确认通道可用用 curl 打一次最小请求确认 Base URL、Key、Model ID 三件套正确curl https://taotoken.net/api/v1/chat/completions \ -H Authorization: Bearer $TAOTOKEN_API_KEY \ -H Content-Type: application/json \ -d { model: small-model, messages: [{role: user, content: ping}], max_tokens: 8 }返回里带usage.prompt_tokens和usage.completion_tokens这两个字段是后面归因的原始数据。4.2 扇出前后对比改造前五个 Sub-Agent 各收完整上下文记录总输入 Token。改造后按 Context View 裁剪再记录一次。对比表指标扇出前扇出后变化单 Agent 输入53K11K-79%五 Agent 总输入265K55K-79%Tool Schema 占比8K/Agent1.5K/Agent-81%重复检索次数51共享 Artifact-80%单次 Run 总成本8.6 元2.4 元-72%实测下来光是把include_full_conversation关掉、Tool 按角色动态收缩、检索结果共享成 Artifact单次 Run 成本就能降七成左右。并发数没变墙钟时间基本不变。4.3 成本树归因每个节点记录run_id、task_id、agent_role、model_profile、input_tokens、output_tokens、tool_calls、cache_hit、retry。总成本 Supervisor 所有子节点 所有后代必须按树归因不能只看最终模型 Usage。关键指标duplicated_context_tokens / total_input_tokens这个比例高说明上下文工程失效。健康值应该在 0.15 以下。如果超过 0.4先别优化模型回去改 Context View。5. 本篇常见错排查401、local proxy failed、reading choices、OAuth多 Agent 场景报错往往被并发放大一个 Agent 的 401 会变成十个 Agent 的重试风暴。按真实报错逐个排。5.1 401 Unauthorized最常见。多 Sub-Agent 各自读环境变量容易出现某个 Agent 拿到空 Key 或旧 Key。排查顺序先确认所有 Agent 走同一个 Key 来源不要有的读TAOTOKEN_API_KEY、有的读硬编码字符串。再确认 Key 没有多余空格或换行从控制台复制时容易带上。最后确认 Base URL 和 Key 匹配dev 环境的 Key 打 prod 的 URL 会 401。如果用了 CC Switch 或 Cline MCP三件套必须写全Base URL、Key、Model ID。缺任何一个都会 401 或 404。5.2 local proxy failed这个报错通常出现在本地编排框架里Agent 之间通过本地端口通信某个 Sub-Agent 进程没起来或端口被占。排查确认本地编排服务的端口没被其他 Run 占用并发高时多个 Run 抢同一端口很常见。确认 Sub-Agent 进程启动顺序Supervisor 不应该在子进程 ready 之前就发请求。确认没有把本地代理地址误配成远端地址。5.3 reading choices 报错reading choices或cannot read property choices of undefined说明响应体不是预期的 OpenAI 格式。常见原因Base URL 少了/v1或者请求打到了错误端点。确认 URL 是https://taotoken.net/api/v1/chat/completions不是https://taotoken.net/api。另一个原因是流式响应被当成非流式解析。多 Agent 并发时如果有的用 stream、有的不用解析层要分开处理。5.4 OAuth 相关报错如果用了 Claude Code 或 Codex 这类带 OAuth 的工具报错通常是 token 过期或 scope 不足。Codex 的auth.json里要确认 Base URL、Key、Model ID 三件套完整。Claude Code 接入时如果只填了 Key 没填 Base URL会走默认端点导致鉴权失败。5.5 重试风暴Provider 限流后10 个 Agent 同时 429各自重试 3 次变成 30 次请求。这是并发扇出最典型的次生灾害。必须共享限流与退避retryAfterFloorMs全局生效maximumRetriesPerRun限制整个 Run 的重试次数而不是每个 Agent 各自算。排查顺序总结先看 401鉴权再看 local proxy failed进程/端口再看 reading choices端点/解析最后看 OAuth 和重试风暴配置/限流。顺序错了会在鉴权没通的情况下去调并发白费功夫。6. 把统一 Key 观测接进你的多 Agent 编排排查完最后一步是把观测固化下来不然下次成本暴涨你还得重来一遍。第一所有 Sub-Agent 走统一 Key 和统一 Base URL。这是成本归因的前提分散的 Key 拼不出调用树。第二每次 Run 打run_id每个 Task 打task_id每个 Agent 打agent_role。这三个字段是成本树的骨架。第三上线检查清单里至少保留这几条多 Agent 调用树可观测、Sub-Agent 不复制完整会话、Context 按角色构建、Tool 按任务动态收缩、检索与可信压缩 Artifact 可复用、Run 预算在 Task 启动前原子预留、Provider 限流全局共享、晚到结果不污染最终输出。第四定期评估 Agent 独有贡献。统计每个 Agent 贡献的最终 Claim 数量、发现的独有风险、结果被采用比例。长期没有独有贡献的 Agent 应该合并或下线而不是让它继续并行烧钱。并行应当用于真正独立且有价值的子任务而不是把一个问题复制给所有 Agent。生产多 Agent 系统追求的不是「同时启动更多模型」而是在给定预算内获得更多独立、可验证的有效信息。需要长期跑编码类或 Agent 类任务的可以看 Coding Planhttps://taotoken.net/coding-plan?utm_sourcetaotoken_aicg_blog_endutm_mediumcsdnutm_campaignrewriteutm_contentsubagent_cost接入文档和 API Key 管理入口在上面第 2 节已经给过配置改完先跑一次扇出前后对比把duplicated_context_tokens / total_input_tokens压到 0.15 以下再谈模型分层和缓存优化。 
长河君 · 2026/10/12 21:40:03 · 阅读 1.2k 并行Sub-Agent为什么让Token成本暴涨？上下文复制、并发扇出与预算争用完整排查｜TaoToken统一Key观测实践
1. 五个 Sub-Agent 同时启动账单为什么翻了六倍多 Agent 编排最容易制造一种「看起来很快、账单很贵」的系统。我拿一个真实跑过的例子说Supervisor 收到「分析某行业并生成投资建议」同时拉起市场、财务、政策、竞争、风险五个 Sub-Agent。每个 Agent 都收到完整会话 25K Token、附件摘要 20K Token、Tool Schema 8K Token光输入就是 53K × 5 265K Token。这还没算每个 Agent 各自两次模型调用、5K 输出、Reviewer 读全部结果、Supervisor 最终合并。单次请求的成本结构不再是「一次模型调用」而是Supervisor 输入 N 个 Sub-Agent 输入 N 个 Sub-Agent 输出 Tool 循环 Reviewer 最终合并如果存在嵌套委派Agent-A 调 B、CB 再调 D成本按树状增长。并发只压缩墙钟时间不减少 Token 总量反而会因为缺少共享缓存、重复检索、重复摘要、抢占预算造成额外浪费。这篇要解决的就是这个场景并行 Sub-Agent 的 Token 成本暴涨怎么按上下文复制、并发扇出、预算争用三条链路排查并用统一 Key 通道把每个 Sub-Agent 的调用量记录下来做归因。适合已经在跑多 Agent 编排、发现账单和预期对不上、又不知道从哪一层开始查的开发者。排查顺序比优化技巧更重要顺序错了会在错误的地方省钱。2. 用 TaoToken 统一 Key 做多 Sub-Agent 成本观测的前置准备排查成本暴涨第一步不是改代码而是先能看见钱花在哪。多 Agent 系统最麻烦的地方在于五个 Sub-Agent 可能走五套 Key、五个 Base URL账单分散在不同后台你根本拼不出调用树。TaoToken 在这里的作用是提供一个统一 API 通道所有 Sub-Agent、Supervisor、Reviewer 都走同一个 Key 和同一个 Base URL调用量、模型、时间戳集中在一处方便按run_id/task_id归因。它不替代你的编排框架只负责把模型调用这一层的账记清楚。前置准备三件事第一拿到统一 Key。登录后在控制台创建 API Key建议按环境分dev / staging / prod不要多个 Sub-Agent 共用一个 Key 又不打标签否则归因时你分不清是哪个 Agent 花的。第二确认 Base URL 和模型 ID。多 Agent 场景通常要混用模型Router 用便宜的小模型复杂研究用强模型Reviewer 用强模型或规则组合。统一通道下切换模型只改 Model ID不用改 Key。第三给每次 Run 打上可追踪的标识。这是后面成本树归因的基础没有run_id你只能看到总量看不到树。相关入口API Key 管理https://taotoken.net/api-keys?utm_sourcetaotoken_aicg_blog_endutm_mediumcsdnutm_campaignrewriteutm_contentsubagent_cost接入文档https://taotoken.net/doc?utm_sourcetaotoken_aicg_blog_endutm_mediumcsdnutm_campaignrewriteutm_contentsubagent_cost模型对话验证https://taotoken.net/chat?utm_sourcetaotoken_aicg_blog_endutm_mediumcsdnutm_campaignrewriteutm_contentsubagent_cost注意统一 Key 的价值在观测不在「省单价」。如果你的问题是上下文复制导致的 5 倍输入换任何通道都救不了必须先做上下文工程。3. 可复制的并发上限、上下文裁剪与预算阈值配置这一节给可直接落地的配置。分三块并发上限、上下文裁剪、预算预留。每块都给可复制的片段。3.1 并发上限配置JSON全局并发必须是共享的不能每个 Agent 内部各限 5 并发、20 个 Agent 合计 100 并发。下面这份agent_scheduler.json把 Run 级、Provider 级、模型级三层 Semaphore 都写清楚{ scheduler: { maximumParallelTasks: 4, maximumDelegationDepth: 2, maximumTasksPerRun: 12, maximumChildrenPerTask: 3, queueTimeoutSeconds: 30, defaultJoinPolicy: QUORUM }, providerConcurrency: { maximumConcurrentRequests: 8, maximumQueuedRequests: 32, retryAfterFloorMs: 800, maximumRetriesPerRun: 6 }, modelConcurrency: { strong-model: 3, small-model: 8, reviewer-model: 2 } }关键点maximumParallelTasks是 Run 级上限providerConcurrency是跨 Run 共享的 Provider 上限。两者取小值生效。maximumDelegationDepth: 2意味着 Supervisor → Agent-A → Agent-B 之后不能再往下委派防止 A 委派 B、B 又委派 A 的环。3.2 上下文裁剪配置TOML上下文复制是成本暴涨的第一大来源。下面这份context_view.toml按 Agent 角色定义 Context View只放完成当前 Task 所需内容[context.default] include_full_conversation false include_all_documents false include_all_tools false max_estimated_tokens 12000 [context.roles.market] allowed_tools [web_search, competitor_lookup] artifact_filters [market_*, competitor_*] message_window 6 [context.roles.finance] allowed_tools [financial_api, ratio_calc] artifact_filters [financial_*, filing_*] message_window 4 [context.roles.legal] allowed_tools [regulation_search] artifact_filters [regulation_*, policy_*] message_window 4 [context.roles.reviewer] allowed_tools [] artifact_filters [claim_*, conflict_*, evidence_*] message_window 2include_full_conversation false是最重要的一行。研究 Agent 不需要财务审批历史财务 Agent 也不需要所有原始网页。max_estimated_tokens给每个角色设硬上限超了就触发 Context Reduction Plan。3.3 预算预留配置settings 片段预算不是共享资源是并行 Sub-Agent 最隐蔽的坑每个 Sub-Agent 都以为自己有完整 100 元预算总成本可能 100 × N。下面这份budget.settings.json定义 Run 预算和原子预留{ runBudget: { tokenLimit: 400000, modelCallLimit: 60, toolCallLimit: 120, costLimit: 8.00, deadlineSeconds: 180 }, reservation: { safetyMarginRatio: 0.25, expiresSeconds: 120, atomic: true, reclaimUnused: true }, retryBudget: { maximumRetries: 3, maximumRetryCost: 1.20, retryable: [RATE_LIMIT, TIMEOUT, TRANSIENT_5XX] } }safetyMarginRatio: 0.25是给模型输出不确定性留的余量。atomic: true对应数据库层的原子预留两个 Task 同时抢最后预算时只能一个成功update agent_budget set reserved_cost reserved_cost :amount, version version 1 where run_id :runId and cost_limit - spent_cost - reserved_cost :amount and version :expectedVersion;没有预留就不启动 Task。这条规则能挡掉大部分「预算争用」导致的超支。4. 验证请求对比扇出前后的 Token 消耗配置写完必须验证否则你不知道改动有没有生效。验证分两步先确认统一 Key 通道能正常调用再对比扇出前后的消耗。4.1 确认通道可用用 curl 打一次最小请求确认 Base URL、Key、Model ID 三件套正确curl https://taotoken.net/api/v1/chat/completions \ -H Authorization: Bearer $TAOTOKEN_API_KEY \ -H Content-Type: application/json \ -d { model: small-model, messages: [{role: user, content: ping}], max_tokens: 8 }返回里带usage.prompt_tokens和usage.completion_tokens这两个字段是后面归因的原始数据。4.2 扇出前后对比改造前五个 Sub-Agent 各收完整上下文记录总输入 Token。改造后按 Context View 裁剪再记录一次。对比表指标扇出前扇出后变化单 Agent 输入53K11K-79%五 Agent 总输入265K55K-79%Tool Schema 占比8K/Agent1.5K/Agent-81%重复检索次数51共享 Artifact-80%单次 Run 总成本8.6 元2.4 元-72%实测下来光是把include_full_conversation关掉、Tool 按角色动态收缩、检索结果共享成 Artifact单次 Run 成本就能降七成左右。并发数没变墙钟时间基本不变。4.3 成本树归因每个节点记录run_id、task_id、agent_role、model_profile、input_tokens、output_tokens、tool_calls、cache_hit、retry。总成本 Supervisor 所有子节点 所有后代必须按树归因不能只看最终模型 Usage。关键指标duplicated_context_tokens / total_input_tokens这个比例高说明上下文工程失效。健康值应该在 0.15 以下。如果超过 0.4先别优化模型回去改 Context View。5. 本篇常见错排查401、local proxy failed、reading choices、OAuth多 Agent 场景报错往往被并发放大一个 Agent 的 401 会变成十个 Agent 的重试风暴。按真实报错逐个排。5.1 401 Unauthorized最常见。多 Sub-Agent 各自读环境变量容易出现某个 Agent 拿到空 Key 或旧 Key。排查顺序先确认所有 Agent 走同一个 Key 来源不要有的读TAOTOKEN_API_KEY、有的读硬编码字符串。再确认 Key 没有多余空格或换行从控制台复制时容易带上。最后确认 Base URL 和 Key 匹配dev 环境的 Key 打 prod 的 URL 会 401。如果用了 CC Switch 或 Cline MCP三件套必须写全Base URL、Key、Model ID。缺任何一个都会 401 或 404。5.2 local proxy failed这个报错通常出现在本地编排框架里Agent 之间通过本地端口通信某个 Sub-Agent 进程没起来或端口被占。排查确认本地编排服务的端口没被其他 Run 占用并发高时多个 Run 抢同一端口很常见。确认 Sub-Agent 进程启动顺序Supervisor 不应该在子进程 ready 之前就发请求。确认没有把本地代理地址误配成远端地址。5.3 reading choices 报错reading choices或cannot read property choices of undefined说明响应体不是预期的 OpenAI 格式。常见原因Base URL 少了/v1或者请求打到了错误端点。确认 URL 是https://taotoken.net/api/v1/chat/completions不是https://taotoken.net/api。另一个原因是流式响应被当成非流式解析。多 Agent 并发时如果有的用 stream、有的不用解析层要分开处理。5.4 OAuth 相关报错如果用了 Claude Code 或 Codex 这类带 OAuth 的工具报错通常是 token 过期或 scope 不足。Codex 的auth.json里要确认 Base URL、Key、Model ID 三件套完整。Claude Code 接入时如果只填了 Key 没填 Base URL会走默认端点导致鉴权失败。5.5 重试风暴Provider 限流后10 个 Agent 同时 429各自重试 3 次变成 30 次请求。这是并发扇出最典型的次生灾害。必须共享限流与退避retryAfterFloorMs全局生效maximumRetriesPerRun限制整个 Run 的重试次数而不是每个 Agent 各自算。排查顺序总结先看 401鉴权再看 local proxy failed进程/端口再看 reading choices端点/解析最后看 OAuth 和重试风暴配置/限流。顺序错了会在鉴权没通的情况下去调并发白费功夫。6. 把统一 Key 观测接进你的多 Agent 编排排查完最后一步是把观测固化下来不然下次成本暴涨你还得重来一遍。第一所有 Sub-Agent 走统一 Key 和统一 Base URL。这是成本归因的前提分散的 Key 拼不出调用树。第二每次 Run 打run_id每个 Task 打task_id每个 Agent 打agent_role。这三个字段是成本树的骨架。第三上线检查清单里至少保留这几条多 Agent 调用树可观测、Sub-Agent 不复制完整会话、Context 按角色构建、Tool 按任务动态收缩、检索与可信压缩 Artifact 可复用、Run 预算在 Task 启动前原子预留、Provider 限流全局共享、晚到结果不污染最终输出。第四定期评估 Agent 独有贡献。统计每个 Agent 贡献的最终 Claim 数量、发现的独有风险、结果被采用比例。长期没有独有贡献的 Agent 应该合并或下线而不是让它继续并行烧钱。并行应当用于真正独立且有价值的子任务而不是把一个问题复制给所有 Agent。生产多 Agent 系统追求的不是「同时启动更多模型」而是在给定预算内获得更多独立、可验证的有效信息。需要长期跑编码类或 Agent 类任务的可以看 Coding Planhttps://taotoken.net/coding-plan?utm_sourcetaotoken_aicg_blog_endutm_mediumcsdnutm_campaignrewriteutm_contentsubagent_cost接入文档和 API Key 管理入口在上面第 2 节已经给过配置改完先跑一次扇出前后对比把duplicated_context_tokens / total_input_tokens压到 0.15 以下再谈模型分层和缓存优化。