LangGraph Supervisor Token消耗等于8个Agent总和？优化方案解析

LangGraph Supervisor 的 Token 消耗困境

一位 Reddit 用户提出的问题引发了不少多智能体系统开发者的共鸣：在 LangGraph 中构建了一个 Supervisor 协调 8 个 Agent 的架构后，发现 Supervisor 自身的 Token 消耗竟然与 8 个 Agent 加起来一样多。这正常吗？

从架构角度看，Supervisor 模式的核心是"中心化调度"——Supervisor 负责接收用户请求、判断应该调用哪个 Agent、传递上下文、汇总结果。这意味着 Supervisor 需要在每一轮交互中承载完整的对话历史和所有 Agent 的返回信息。

当 Agent 数量达到 8 个时，Supervisor 的上下文窗口会迅速膨胀。如果每个 Agent 的输出都包含详细的分析、代码或数据，Supervisor 不得不在每次路由决策时重新处理这些累积的历史信息。这不是 Bug，而是 Supervisor 架构的固有特征。

为什么 Supervisor 会成为 Token 黑洞

Supervisor 消耗大量 Token 的根本原因在于它的工作方式与传统 Agent 有本质不同。

重复的上下文加载。 每次 Supervisor 做路由决策时，它需要看到完整的对话状态——包括用户原始输入、之前所有 Agent 的回复、以及自己的历史决策。在 8 个 Agent 的场景下，如果每个 Agent 平均产生 500 Token 输出，到第 8 个 Agent 被调用时，Supervisor 的输入已经累积了约 4000 Token 的历史。而每次路由都是一次完整的 LLM 调用。

路由决策本身的开销。 Supervisor 的 System Prompt 通常比单个 Agent 更长，因为需要描述所有 Agent 的能力边界、调用条件和输出格式。8 个 Agent 的职责说明就可能占据 1000-2000 Token。

串行调用的放大效应。 在多数 LangGraph 实现中，Supervisor 按顺序调用 Agent。A 调用后，Supervisor 要处理 A 的结果并决定下一步；B 调用后，又要重复这个过程。每次循环都加重了 Token 负担。

关于 Token 与上下文窗口。 大语言模型处理文本的基本单位是 Token，一个英文单词大约对应 1-2 个 Token，一个中文字符通常也接近 1 个 Token。模型的「上下文窗口」指的是单次调用中能够处理的 Token 上限，包括输入和输出。Supervisor 每次做路由决策都是一次独立的 LLM 调用，需要把历史消息重新作为输入喂给模型，因此同一段历史会被反复计费。这也解释了为什么上下文越长，单次调用成本越高——成本大致随上下文长度线性增长，而调用次数又随 Agent 数量增加，两者相乘便产生了「非线性」的膨胀感。了解 Token 与上下文窗口的关系，是理解后文各类优化手段（摘要压缩、并行调用、分级路由）为何有效的关键。

优化策略：从架构层面降低消耗

精简 Supervisor 的 System Prompt

大多数 Supervisor 的提示词存在大量冗余。将每个 Agent 的完整描述压缩为不超过 50 字的能力摘要，只保留"什么情况下调用谁"的核心信息。路由决策不需要知道 Agent 的全部细节，只需要知道它的能力边界。

引入摘要机制压缩历史

在 Supervisor 的状态中维护一个滚动摘要，而非保留所有 Agent 的完整输出。每次 Agent 返回后，用轻量级模型（如 Haiku 或 GPT-4o-mini）生成 100 字以内的结果摘要，Supervisor 后续决策只读取摘要而非原文。这在 8 个 Agent 的场景下可能减少 60%-80% 的上下文 Token。

关于滚动摘要与轻量级模型。 「滚动摘要」指的是一种增量式的上下文管理方式：随着对话或 Agent 调用不断推进，用一个额外的、较小的模型把较旧的历史信息不断压缩成简短的要点，只保留最近的原始内容，从而让上下文长度保持在一个相对稳定的区间，而不是无限增长。之所以选用 Haiku、GPT-4o-mini 这类轻量级模型，是因为摘要任务对推理深度要求不高，但对成本和延迟敏感——用大模型做摘要反而会引入新的开销。需要注意的是，摘要会带来信息损失，因此要设计好「摘要保留什么」的规则，例如保留关键数据、结论和待办项，丢弃冗长的推理过程。在 8 个 Agent 的场景下，这一机制通常可把上下文从数千 Token 压到千级以内。

改用并行调用与状态压缩

如果 8 个 Agent 之间的任务相互独立，考虑让它们并行执行，Supervisor 只在最后汇总一次。LangGraph 支持通过 Send API 实现 Map-Reduce 模式，避免每个 Agent 都触发一轮 Supervisor 路由。

关于 Map-Reduce 与 Send API。 Map-Reduce 是一种经典的并行计算范式：Map 阶段把一个大任务拆成若干可独立处理的子任务并行执行，Reduce 阶段再把各子结果合并成最终输出。在多智能体系统中，它对应「同时派出多个 Agent 处理各自的子问题，最后由一个汇总节点归并结果」。LangGraph 通过 Send API 支持这种模式——它允许一个节点根据条件动态地把状态分发给多个下游节点，这些节点并行运行，其结果汇聚到同一个状态对象中。相比 Supervisor 逐个路由的方式，Map-Reduce 把 N 轮串行调用压缩成一轮并行加一次汇总，大幅减少了 Supervisor 参与决策的次数，因而显著降低 Token 消耗与整体延迟，但前提是各 Agent 的任务确实相互独立、没有依赖顺序。

分级路由替代统一路由

把 8 个 Agent 分成 2-3 个组，每组设一个子 Supervisor。顶层 Supervisor 只负责选择组，子 Supervisor 处理组内路由。这样每次路由决策的上下文只包含当前组的信息，而不是全部 8 个 Agent 的状态。

架构选择的权衡

你可能没注意到，Supervisor 集中式架构虽然 Token 开销大，但它带来了可观测性和控制力的优势。所有决策经过中心节点，便于调试、日志记录和错误追踪。对于调试阶段或 Agent 数量较少（3 个以内）的场景，这种开销通常是可接受的。

但当 Agent 扩展到 8 个以上时，Token 成本会非线性增长。开发者需要在"中心化控制"和"分布式自主"之间做出权衡。另一种思路是采用 Handoff 模式——Agent 之间直接传递控制权，而非每次都经过 Supervisor 中转。

LangGraph 官方文档也承认 Supervisor 模式在大规模 Agent 场景下的扩展性问题，并建议结合具体业务需求选择架构。如果你的场景中 Agent 之间存在明确的流程关系，用 StateGraph 定义固定流程可能比动态路由更高效。

关于 Handoff 模式与 StateGraph。 Handoff（交接）是一种去中心化的多智能体协作方式：Agent 之间直接把控制权和上下文传递给彼此，而不是每次都回到 Supervisor 中转。它通常配合「工具调用」实现——某个 Agent 通过调用一个「转交给另一个 Agent」的工具来移交控制权。其优势是路径更短、Token 更省，代价是全局状态分散、可观测性下降，调试时更难追踪完整链路。StateGraph 则是 LangGraph 的核心抽象，用节点和边显式地定义一条固定或带条件分支的执行流程，适合任务步骤明确、依赖关系稳定的场景。相比之下，Supervisor 属于动态路由：下一步走哪条边由模型在运行时决定。因此选择 Handoff 或 StateGraph，本质上是在「灵活性」与「可预测的成本和控制力」之间做取舍。

总结

Supervisor 消耗与所有 Agent 总和相当的 Token，在 8 个 Agent 的规模下并非异常，而是中心化调度架构的固有成本。核心原因在于每次路由决策都需要加载完整上下文，以及 System Prompt 中 Agent 描述本身的开销。优化方向包括：精简提示词、引入摘要压缩、并行调用、分级路由，以及在合适场景下放弃 Supervisor 模式改用 Handoff 或固定流程。