Token Counting

多智能体工作流的 Token 预算规划

2026年7月23日TokenTest Team
English中文

单次 LLM 调用很容易做预算。多智能体工作流则不然。

规划器会撰写简报。检索器会分散展开。工作器会消耗检索到的上下文。审核器会阅读它们的输出。一次失败的工具调用会触发重试。等到最终答案出现时，同一条信息可能已经跨过多个模型边界——而每个边界都可能产生新的输入和输出用量。

这就是为什么多智能体工作流的 token 预算规划必须在工作流层面进行，而不仅仅是在每个提示词中进行。

本指南将提供一个实用的分配公式、一个规划器–检索器–工作器–审核器的完整示例，以及一个可直接粘贴运行的测试，你可以通过 TokenTest 来验证实时用量行为。

简短答案

先设定一个硬性的工作流上限，然后将其分配到各个智能体调用、工具负载、重试和共享预留中：

workflow_hard_cap
= sum(expected_calls × per_call_token_cap)
+ tool_result_allowance
+ retry_reserve
+ shared_emergency_reserve

对于每一次模型调用，定义：

per_call_token_cap
= maximum_input_tokens
+ maximum_output_tokens

当提供方报告了缓存输入和推理 token 时，请分别跟踪它们，但不要假装它们从工作流中消失了。缓存输入仍然属于输入用量，而推理 token 即使最终答案中不可见，也会消耗输出额度。

为什么仅靠单个智能体的限制还不够

假设每个智能体的输出上限看起来都很合理。工作流仍然可能超出预算，因为存在四个放大因素。

1. 扇出会放大调用次数

一次规划器调用可能会启动两个检索器和三个工作器。若某个工作器的预算是 2,000 token，那么当有三个工作器运行时，这并不等于 2,000 个工作流 token——它最多会达到 6,000。

2. 交接内容会被再次计数

规划器的输出是规划器调用中的输出用量。当该计划被插入到工作器提示词中时，它就变成了工作器调用中的输入用量。在每个模型边界上汇总用量并不是重复计算；这反映了多步推理在实际中的消耗和报告方式。

3. 工具结果会扩展下游提示词

搜索片段、数据库行、代码输出和文件摘录可能比请求它们的智能体指令更大。如果工具负载没有大小限制，下游输入就可能主导整个运行。

4. 重试隐藏在编排逻辑中

超时、无效的 JSON 响应、失败的工具调用或审核器拒绝，都可能让一个昂贵步骤重复执行。生产环境的预算需要在重试发生前就预留重试额度。

一个能在生产环境中站得住脚的工作流 token 预算公式

用相同的结构为每个角色做预算：

role_budget
= maximum_call_count
× (maximum_input_tokens + maximum_output_tokens)

然后计算工作流上限：

workflow_hard_cap
= planner_budget
+ retriever_budget
+ worker_budget
+ reviewer_budget
+ tool_result_allowance
+ retry_reserve
+ shared_emergency_reserve

这是一种刻意保守的做法。它是硬上限模型，而不是预测模型。对于日常规划，请保留另一个基于实际观测到的中位数用量的数值。硬上限用于保护系统；观测预算则帮助你优化它。

示例：一个 16,636-token 的研究工作流

想象一个工作流：先研究一个问题，再起草答案，最后在交付前进行检查。

角色或预留 最大调用次数 每次输入上限 每次输出上限 分配的 token
Planner 1 900 220 1,120
Retrievers 2 650 80 1,460
Workers 3 1,800 450 6,750
Reviewer 1 2,400 300 2,700
Tool-result allowance — — — 1,200
Retry reserve — — — 2,406
Shared emergency reserve — — — 1,000
Workflow hard cap 16,636

模型调用小计为 12,030 个 token。重试预留为该小计的 20%，即 2,406 个 token。工具结果和应急预留则单独添加。

这张表为编排器可强制执行的决策提供了依据：

按角色分配，而不是按相同比例分配

平均切分看起来很简单，但智能体角色承担的工作并不相同。

Planner：输出少，杠杆高

Planner 通常应该产出一个紧凑的任务图，而不是长篇论文。为它提供足够的输入，以理解约束，并提供足够的输出，以定义任务、依赖关系和验收标准。如果计划过于冗长，下游每个智能体都要为这份冗长再次付费。

Retriever：严格的输出结构

Retrievers 往往只需要很少的生成式输出。它们的预算风险主要在于返回的证据。限制结果数量、摘录长度和工具有效载荷总量。在可能的情况下，请求标识符和简短片段，而不是完整文档。

Worker：最大的有效分配

Workers 通常需要最大的角色预算，因为它们要结合指令、证据和中间状态。应根据任务难度来分配。如果只有一个分支承担困难的综合工作，就不要让每个并行 worker 都拥有相同的最大额度。

Reviewer：受保护，而非可有可无

在 workers 开始之前，先预留 reviewer 的预算。否则，早期智能体可能会耗尽整个工作流上限，导致没有空间来验证答案。Reviewer 应检查任务完成情况、矛盾之处、引用覆盖率和格式，而不是默认重写整段回复。

同时使用软限制和硬上限

硬上限回答的是：“这个运行何时必须停止？”软限制回答的是：“编排器何时应改变行为？”

两者都要设置。

护栏 示例行为
已消耗 50% 正常继续
已消耗 70% 停止启动可选分支
已消耗 85% 总结状态并直接路由到审查
达到审查者预留额度 阻止新的 worker 调用
达到硬上限 以预算耗尽状态停止工作流

软限制使工作流能够优雅降级。如果没有软限制，只有硬上限，往往会在已经付出昂贵代价后突然失败。

跟踪解释超支的 token 字段

至少为每次模型调用记录以下字段：

{
  "workflow_id": "research-042",
  "agent_role": "worker",
  "attempt": 1,
  "requested_model": "your-model-alias",
  "returned_model": "reported-model-version",
  "input_tokens": 0,
  "cached_input_tokens": null,
  "output_tokens": 0,
  "reasoning_tokens": null,
  "total_tokens": 0,
  "tool_result_tokens": 0,
  "remaining_workflow_budget": 0,
  "finish_reason": "stop",
  "task_valid": true
}

对“未报告”的情况使用 null。不要把缺失的 cached-token 或 reasoning-token 字段变成 0。0 表示提供方明确报告没有；null 表示你没有证据。

OpenAI 的 Agents SDK 文档展示了请求、输入 tokens、输出 tokens 和总 tokens 的运行级用量聚合，并在可用时提供缓存输入和推理输出的详细字段。其 tracing 文档还描述了跨 agent 运行、模型生成、函数调用、handoff 和 guardrails 的 traces 与 spans。这个组合才是正确的心智模型：先跟踪工作流结构，再把用量附加到每个可计费的模型边界上。

先计数，后验证

使用三层方法，而不是只相信一个数字。

  1. 本地估算：在编辑提示词时很有用，但前提是分词器和请求模板与目标模型足够接近。
  2. 提供方原生预检：在可用时使用提供方的计数端点。OpenAI 文档说明了 POST /v1/responses/input_tokens；Anthropic 文档说明了 POST /v1/messages/count_tokens；Google 为 Gemini 模型文档说明了 countTokens。
  3. 实时用量验证：运行真实端点并检查返回的用量、停止行为、缓存证据和 reasoning-token 证据。

预检计数估算的是请求。实时用量揭示的是完整的工作流行为，包括生成的输出和重试。

多语言工作流需要单独的预算

不要把英语 token 比率应用到每一种语言上。

分词结果会因分词器、模型、标点、脚本、代码混用和聊天模板而变化。在多语言请求中，工具 schema 和重复的英文字段名也会改变比率。

对于每种生产语言：

  1. 保持任务含义和输出 schema 等价。
  2. 统计完整请求，而不只是翻译后的用户句子。
  3. 运行相同的工作流形态和调用限制。
  4. 比较中位数输入、输出、重试率和任务有效性。
  5. 根据更高的观察到的百分位数加上余量来设定生产上限。

如果某种语言持续消耗更多输入，请针对该语言调整检索规模或提示结构，而不要默默降低输出质量。

可直接粘贴的 TokenTest 测试

将此提示用作受控的 worker 任务。跨运行保持模型、temperature、输出上限和端点不变。

You are the worker agent in a multi-agent research workflow.

Budget constraints:
- Return valid JSON only.
- Use no more than 180 visible words.
- Include exactly three evidence items.
- If evidence is insufficient, set "status" to "needs_more_evidence" instead of guessing.

Task:
Explain why workflow-level token budgets must include fan-out, retries, tool results, and downstream handoffs.

Output schema:
{
  "status": "complete | needs_more_evidence",
  "summary": "string",
  "evidence": [
    {"factor": "string", "budget_effect": "string"}
  ],
  "next_action": "string"
}

在 TokenTest 中运行它，然后检查端点是否报告了合理的输入、输出和总用量；输出是否在配置的限制附近停止；以及当路由声称支持时，缓存或推理细节是否出现。至少重复测试三次，然后再将中位数作为规划输入。

TokenTest 目前的评估控制台旨在针对 token 用量、能力、路由协议、安全边界和通道可靠性进行实时端点检查。其用量完整性检查包括用量是否存在、总量一致性、输入单调性、输出合理性、停止限制关联、流式用量、缓存证据以及思考或推理证据。TokenTest 声明不会存储 API 密钥，但你仍应遵循组织的凭据和数据处理政策。

实用的编排策略

以下策略可作为起点：

before launching a call:
  projected = current_usage + call_input_cap + call_output_cap

  if projected > workflow_hard_cap:
    stop with budget_exhausted

  if remaining_budget <= reviewer_reserve + emergency_reserve:
    block new optional workers
    route current evidence to reviewer

after every call:
  record reported usage
  update remaining budget
  validate the output
  release unused reserved output only if no retry is pending

关键细节在于，编排器必须在每次调用之前检查预算，而不仅仅是在提供方返回用量之后。

常见的 token 预算错误

只为最终答案做预算

用户可能只看到 300 个 token，而工作流在规划、检索、起草和审查中消耗了数千个。

在上下文规划中减去缓存 token

缓存可能会改变计费或延迟行为，这取决于提供商，但缓存的 tokens 仍然是输入序列的一部分。应将它们单独跟踪；不要把它们当作免费的上下文。

默认允许审阅者重写

完整重写会生成另一段大规模输出。更好的做法是使用返回通过/失败决策和受限补丁列表的审阅者。只有当答案未通过定义好的门槛时才重写。

将最大上下文窗口作为运行预算

模型的上下文窗口是技术上限，不是安全的工作流目标。你的运行预算还需要为输出留出空间、为重试留出空间、考虑工具调用波动，以及下游审阅容量。

在验证任务之前比较效率

较短的无效答案并不更高效。请记录 task_valid，并且只在满足任务的输出之间比较 token 效率。

最终清单

在部署多智能体工作流之前，请确认你已经具备：

然后在 TokenTest 中使用真实路由运行工作流，保存原始用量证据，并用观测到的中位数和高百分位限制来替换规划假设。

常见问题

多智能体工作流应该保留多少重试储备？

先从按步骤观察到的重试率出发。在还没有生产数据之前，对于最容易失败的关键步骤，保留一个有上限的重试额度（例如一次重试）比无限重试更合理。本文中的 20% 储备只是示例，不是通用规则。

每个智能体都应该获得相同的 token 预算吗？

不应该。应按角色、调用次数、任务复杂度和下游复用情况分配。规划器和检索器通常需要简洁输出；综合生成组件通常需要更多；审阅者则需要受保护的储备。

推理 tokens 算入输出限制吗？

对于 OpenAI 推理模型，官方文档说明推理 tokens 属于输出 token 用量，并受 max_output_tokens 控制。其他提供商可能以不同方式报告或限制它们，因此请验证你实际使用的路由。

一个 token 计数器能估算工作流中的每个模型吗？

不能可靠地做到。不同的模型家族和服务栈可能使用不同的分词器、聊天模板、特殊 tokens 和工具编码。更推荐使用模型原生计数和实时用量证据。

来源