多智能体协作系统成本优化：Token管控、模型调度与预算熔断实战

提到多智能体协作系统，很多开发者第一反应是“效果真香”，第二反应往往是“账单真贵”。Agent 经济学这个说法，研究的就是在多智能体协作系统里，如何用工程手段把 token 消耗、模型调用成本、计算资源这些开销压到合理区间，同时不牺牲任务质量。这个问题不是有钱就能解决的，因为很多成本浪费来自系统设计层面——角色定义得太宽、上下文传递太全、模型选得太高，每一项都在悄悄掏空预算。

这篇文章适合已经在用或者打算用多智能体架构做项目的开发者、算法工程师和技术负责人。我会把成本结构拆开讲清楚，给出可落地的优化策略，包括角色裁剪、上下文瘦身、模型分级调度、预算熔断等内容，最后附上一个完整的成本优化复盘和监控方案。没有高深理论，全是能直接拿去用的经验。

1. 先算账：多智能体协作系统的成本从哪里来

1.1 Token 维度下的三笔开销

优化成本的第一步是知道钱花在哪了。多智能体系统的运行成本，归根结底由三部分组成：输入 token、输出 token 和调用次数。这三者不是独立存在的，它们互相影响，而且在实际项目里往往呈现出“滚雪球”效应。

第一笔开销是输入 token。输入 token 包含系统提示词、任务描述、历史上下文、前序 Agent 的输出结果。在多智能体系统里，最典型的问题是一个 Agent 的输出会变成下一个 Agent 的输入，如果全量传递，上下文会像滚雪球一样越滚越大。我见过很多项目，5 个 Agent 串行跑完一个任务，最后一个 Agent 的输入里塞了前面所有 Agent 的完整输出，光是 prompt 就有几万字。

第二笔开销是输出 token。输出 token 包括各 Agent 生成的内容、思考过程、中间结果。很多场景下，Agent 生成的中间产物过长，不是因为任务需要，而是因为系统提示词没有约束输出格式。比如让 Agent 输出一份解析报告，它可能给出一大段完整推理，而实际上只需要结论和关键参数。

第三笔开销是调用次数。每个 Agent 每轮交互都是一次 API 调用，调用次数越多，总成本越高。多智能体系统里经常出现无意义的来回通信，比如 A Agent 问 B Agent 一个问题，B 回答之后 A 又追问细节，这种对话式协作如果没有终止条件，成本会呈线性甚至指数增长。

这三笔开销之间的关系可以用一个生活类比来理解：多智能体系统就像一个项目组，每个 Agent 是组员。组员之间频繁开会（调用次数），每次开会都要发完整的项目文档（输入 token），每个人发言都要长篇大论（输出 token）。如果项目管理者不限制会议次数、发言时长和文档篇幅，人力成本就完全失控。多智能体的 token 消耗也是一样的逻辑。

1.2 不同协作模式的成本差异

多智能体的协作模式直接决定成本水平。串行模式下，每个 Agent 按顺序处理任务，前一个的输出是后一个的输入。这种模式逻辑清晰，但上下文累积严重，成本随链路长度近似线性增长。并行模式下，多个 Agent 同时处理互不依赖的子任务，耗时缩短但 token 总量不变，只影响时间维度。混合模式则是在同一个工作流中既存在并行又有串行，成本模式最复杂，也最需要精细设计。

用一个实际项目数据来感受一下差异。某模拟任务从需求分析到生成最终方案，经过 5 个 Agent 串行处理：规划 Agent、检索 Agent、写作 Agent、审校 Agent、修订 Agent。假设每个环节的输入输出如下：

这里的数字是简化估算，真实场景可能更高。但已经可以看出问题：检索 Agent 输出的 8,000 token 完整传给了写作 Agent，写作 Agent 的 4,000 token 初稿又完整传给了审校 Agent。累计输入 token 达到 50,500，累计输出 token 21,000，单次任务总消耗约 71,500 token。

同样是这个任务，如果改成混合模式：规划与检索合并成一个“侦察 Agent”，只输出 2,000 token 的精炼简报；写作 Agent 只消费简报而不是完整检索结果；审校 Agent 只对差异部分做检查，而不是重读全文；修订 Agent 按差异指令直接修改。总输入降到 15,800，输出降到 11,300，合计约 27,100 token。降幅接近 62%。

这个案例说明一个核心观点：多智能体协作系统的最大成本杠杆，不在模型单价，而在系统设计。同样的任务，设计得好和设计得差，成本可以相差数倍。

2. 角色设计与调度逻辑中的“省钱心法”

2.1 Agent 不是越多越好，角色裁剪是第一步

很多人在设计多智能体系统时会陷入一个误区：角色越细分越好。规划 Agent、检索 Agent、写作 Agent、审校 Agent、润色 Agent、格式 Agent……听着分工明确，实际上大部分角色都在做重复劳动，每次角色之间的交接都是一次完整的上下文传递和一次新的 API 调用。

以我维护的一个某跨平台系统为例，早期版本定义了 7 个 Agent，后来精简到 3 个，任务质量没有下降，成本却下降了 45%。核心变化就是做减法：把“规划”和“检索”合并成“侦察 Agent”，把“写作”和“润色”合并成“产出 Agent”，保留独立的“审校 Agent”负责质量把关。

角色裁剪的核心原则是“每个 Agent 必须有不可被其他 Agent 替代的职责”。如果两个 Agent 的工作内容有 60% 以上重叠，就应该合并。判断方法是把每个 Agent 的职责描述列出来，做一次职责矩阵分析，看到重叠项就标红，然后一个个剪掉。

角色数量与成本的关系不是线性而是指数的。增加一个 Agent 意味着多一次交接，每一次交接都意味着要传递一整套上下文。三个 Agent 之间有两组交接，五个 Agent 之间就有四组交接，每个交接点都是上下文膨胀和 token 消耗的放大器。

建议每个新 Agent 在加入系统前回答四个问题：这个角色的输入输出是什么？如果没有它，现有 Agent 能否完成这部分工作？它消耗的 token 占总预算的比例预计是多少？它能带来多少可量化的质量提升？答不上来就不加。

2.2 任务分解的粒度控制与成本之间的关系

任务分解粒度，指系统把一个大任务拆成多少个子任务、每个子任务的最小单位是什么。粒度太粗，任务模糊，Agent 处理效果差；粒度太细，Agent 数量多，上下文传递层数深，成本暴涨。最优的粒度是“刚好够用的一层或两层分解”。

举个例子，同样是“生成一份市场分析报告”，粗糙的做法是扔给一个 Agent 让它“写出来”；细致的做法是拆成 20 个子任务，从行业背景、竞品分析、用户画像、价格策略、渠道建议到排版格式，每个子任务都由独立 Agent 处理。前者的优点是省 token，缺点是质量不稳定；后者的优点是看起来专业，缺点是上下文传递链太长，token 消耗呈指数增长。

我常用的方案是两层分解：第一层按任务类型拆分，比如“调研”和“撰写”；第二层按结构拆分，比如“调研部分先收集信息再提炼要点”。超出两层就属于过度设计。在两层级联中，信息可以用压缩后的摘要传递，而不是全量的原始输出。

粒度控制还涉及另一个决策：子任务是串行还是并行。互不依赖的子任务应该并行执行，这样可以缩短耗时，但 token 总量并不会减少。串行子任务之间则要严格控制上下文传递，坚决避免“全量传递 + 无限累加”的模式。并行和串行的选择本质上是时间预算和 token 预算之间的权衡，不同项目有不同偏好，没有绝对标准，但通用原则是：能并行就并行，不能并行就压缩传递。

2.3 设计一个“省钱调度流”的实操示例

以常见的“智能客服工单处理”场景为例，演示如何设计低成本的调度流。早期版本是：工单进入后先由意图识别 Agent 判断类别，再交给知识库检索 Agent 查资料，然后由回答生成 Agent 组织回复，最后让质检 Agent 检查答案。

优化后的调度流变成了两段式：

先由“路由器 Agent”做一次轻量级判断，成本极低但决定后续路径。如果工单是简单问题，例如退货流程、账户信息查询，直接使用预置模板回答，根本不需要进入多 Agent 流程。如果工单是中等难度问题，例如产品故障排查，则走单 Agent + 知识库工具的单轮问答。只有复杂工单，例如涉及多个系统交叉、需要综合判断的异常。才进入完整的多 Agent 协作流程。

这里我省去了流程图的表述，可以直接用伪代码说明调度逻辑：

python复制async def dispatch_ticket(ticket_content):
    intent = await call_light_model(
        "判断工单类别，返回 simple / medium / complex",
        ticket_content
    )
    if intent == "simple":
        return await get_template_answer(ticket_content)
    elif intent == "medium":
        return await call_standard_model_with_tool(ticket_content)
    else:
        return await run_agent_workflow(ticket_content)

这个路由策略在真实运营数据里表现很好：大约 60% 的工单走了模板路径，25% 走了单 Agent 路径，只有 15% 走了完整多 Agent 流程。总成本相比“所有工单都进多 Agent 流程”的方案下降了 70% 以上。

这就是调度层面的省钱心法：不是所有任务都值得动用多智能体，入口分流是第一道成本闸门。

3. 上下文管理：多智能体系统的“油耗大户”

3.1 上下文为什么越滚越大，token 消耗跟着涨

上下文管理是多智能体成本优化中最容易被忽视、也是见效最快的环节。原因在于：绝大部分多智能体系统的 token 消耗不是花在“生成内容”上，而是花在“传递和接收历史信息”上。你每把一个前序 Agent 的完整输出塞给下一个 Agent，都是在为历史内容付费。

上下文膨胀有几个典型推手。第一是“全量传递”习惯，很多开发者在实现时直接把 A 的输出作为 B 的输入，完全不考虑 B 到底需要哪些信息。第二是长对话累积，Agent 在与外部工具或其他 Agent 交互时会产生大量过程记录，这些记录没有清理机制。第三是系统提示词里塞了过多静态内容，每次调用都要重复付费。

更麻烦的是，上下文膨胀不仅增加成本，还会降低模型输出的质量。上下文过长时，模型容易忽略早期信息，产生所谓的“Lost in the Middle”现象。也就是说，你花了一大笔 token 传了一大堆资料，最终模型根本没看进去多少。这样钱花了，效果还更差，属于双重损失。

解决上下文膨胀，首选方式是设计“信息摘要层”，用一个专门的摘要 Agent 对长上下文做压缩。压缩策略分两种：一种是全局摘要，每隔固定轮次把之前的对话压缩成几百字的要点；另一种是局部剪枝，删除已经用完的、不再影响后续决策的信息。实际项目里我两者都会用，全局摘要负责维护主线，局部剪枝负责清理噪音。

3.2 上下文瘦身的三个实用策略

第一个策略是“事实清单替换原文”。让 Agent 在执行任务时，把关键信息整理成结构化的事实清单，如下所示，而不是保留原始对话内容。

json复制{
  "user_requirement": "需要一份支持多平台的登录方案",
  "acceptance_criteria": ["支持手机号", "支持第三方授权", "响应时间小于2秒"],
  "existing_systems": ["用户中心", "SSO服务"]
}

第二个策略是“滚动窗口摘要”。在长流程任务中，每个 Agent 结束工作后，除了输出最终结果，还要更新一份“任务记忆卡”。记忆卡里只有三部分内容：已完成事项、当前状态、下一步计划。下一个 Agent 不读原始输出，只读记忆卡。这个做法能把单个 Agent 的输入上下文减少 50% 到 70%。

第三个策略是“按需检索替代全量传递”。不是把整个知识库或前序 Agent 的输出全部丢给当前 Agent，而是给它一个检索工具，让它自己查询需要的片段。检索是定向的，传递是全量的，两者成本差异非常大。

3.3 缓存、复用与批量处理策略

多智能体系统里很多计算是重复的。同一个问题可能被不同用户、不同任务反复查询。如果每次都调用模型重新生成答案，成本就会无限膨胀。引入缓存机制是成本优化的关键手段。

常用方案有两种：一种是精确缓存，对于完全相同的输入直接返回历史结果，适用于规则明确、答案稳定的场景。另一种是语义缓存，先对输入做嵌入向量化处理，再在缓存中找相似内容，相似度超过阈值就直接复用历史结果。语义缓存的优点是可以命中“问法不同但意思相近”的请求，覆盖更广。

另一个容易被忽略的成本点是批量处理。如果系统是异步架构，可以把多个独立的小任务合并成一个批次喂给模型。批次处理在 token 消耗上不一定更省，但能减少固定开销，比如请求头、系统提示词只需加载一次，整体吞吐能力和利用率会更高。

缓存和批量处理做得好，可以在不改变任何模型和角色的情况下直接降低 20% 到 30% 的调用成本。我见过有项目把所有知识库查询结果都做了语义缓存，上线一周后总 token 消耗立刻下降了四分之一。

4. 分级调度与模型路由：让每个 Agent 用对档位的模型

4.1 不同任务的复杂度对应不同档位的模型

多智能体系统里最常见的资源浪费，是让最强的模型处理最简单的任务。旗舰级大模型的 API 单价通常是轻量模型的数倍到数十倍，如果规划、检索、写作、审校全用同一个旗舰模型，成本会直线上升。

合理的做法是分级调度。给不同 Agent 配置不同档位的模型，把“重型推理”留给最关键、最复杂的环节，把“机械执行”交给轻量模型。

以“内容生成”类多 Agent 系统为例，我的典型配置是：

这个配置的核心思路是把顶级模型用在“把关”环节，而不是“生产”环节。大多数内容质量问题发生在审校阶段，所以审校 Agent 值得用旗舰模型。生产环节只要遵循明确的格式和语气要求，标准模型足以胜任。

4.2 路由 Agent 的搭建要点与成本收益测算

路由 Agent 是分级调度的大脑，它的作用是在任务入口判断任务复杂度和类型，然后分发到对应档位的处理流程。路由本身也是一次模型调用，所以这个 Agent 必须足够轻、足够快，否则会形成新的成本负担。

我常用一个极简的动态路由方案：先让路由 Agent 输出一个 JSON 结构，包括 mode 字段和 reason 字段。mode 决定走流程，reason 是简短判断依据。这个流程对应的伪代码如下：

python复制def route(task):
    response = call_light_model(
        system = "你是任务路由器，只需输出JSON，包含mode和reason两个字段",
        user = task
    )
    decision = json.loads(response)
    if decision["mode"] == "simple":
        return simple_handler(task)
    elif decision["mode"] == "complex":
        return complex_workflow(task)
    else:
        return standard_handler(task)

路由 Agent 的单次成本很小，一般只占总预算的 1% 到 2%，但它带来的分流效益非常大。之前提到的工单场景里，60% 的简单工单不再进入多智能体流程，直接省掉了大头成本。

成本收益可以这样粗略测算：假设系统一天处理 10,000 个任务，每个任务的 token 消耗大约为：复杂任务 20,000，普通任务 8,000，简单任务 2,000。如果全部走标准多 Agent 流程，按平均 8,000 token 计算，一天的消耗是 8,000 万 token。加上路由分流后，假设 60% 走模板（500 token），25% 走单 Agent（2,000 token），15% 走完整流程（20,000 token），总消耗是 3,000 万 token 加 500 万加 3,000 万，合计 6,500 万 token。这只是一个非常粗略的估算，好让各位有一个体感。真实场景里，如果简单任务能够真正替换为模板和轻量模型，节省的比例会更可观。

4.3 模型选择中的隐藏成本与配置经验

模型选择不只是看单次调用的 API 价格，还要看几个隐藏因素。第一个是输出长度限制，有些模型默认生成的回答特别长，即使任务只需要一个简短结论，它还是会输出一大段解释，这时就需要在系统提示词里设置输出上限。第二个是失败重试率，某些模型在某些任务上容易出现格式错误或超时，导致系统自动重试，一次重试的成本可能是正常调用的两倍甚至三倍。第三个是上下文窗口大小，窗口越大，你就越容易掉进“把所有内容都塞进去”的陷阱，实际开销因此成倍增加。

规避这些隐藏成本的建议如下：每个 Agent 的提示词里都写明输出格式和最大长度，比如在系统提示词中直接写明“用不超过 200 字回答”，避免模型自由发挥；为每个 Agent 设置独立的重试次数上限，例如最多重试两次，防止异常状态下的无限重试；在选型时优先比较“完成同一任务的实际花费”，而不是单纯看模型的 token 单价。

还有一条配置经验是：把输出长文的任务和输出短结果的任务拆开，分别使用不同档位的模型。比如写作 Agent 生成长文可以用标准模型，审校 Agent 只需要输出“问题清单”这种短结构，也可以用标准模型。真正需要旗舰模型的是那些需要深度推理、逻辑归因的环节，比如判断答案是否安全、是否合规、是否逻辑自洽。

5. 成本监控与预算熔断机制：防止账单失控的最后防线

5.1 为每个 Agent 建立成本日志与监控指标

优化做完了，还需要一套监控体系来保证成本不会反弹。多智能体系统的成本监控不能只看“总共花了多少钱”，要能追溯到每个 Agent、每个任务、每个环节。

我的做法是让系统的每次 Agent 调用都输出一条结构化日志，字段包括任务 ID、Agent 角色、模型档位、输入 token 数、输出 token 数、调用耗时、估算成本。把这个日志汇总到分析端，按任务维度和管理维度分别做聚合。

日常关注三个核心指标：单任务平均成本、单任务最高成本和每日总成本。单任务平均成本反映整体效率，单任务最高成本用来发现异常链路。如果某条链路的成本突然上涨，多半是上下文膨胀或某个 Agent 陷入重复调用。

为了及时发现异常，可以设定阈值告警：任务成本超过该类型任务平均成本的三倍，触发警告；超过五倍，触发冻结。这个机制能防止单个故障任务耗尽当月预算。

5.2 预算熔断与人工兜底设计

预算熔断机制的意义，不是省小钱，而是防止大规模故障。多智能体系统出现无限循环调用的时候，token 消耗是按秒计算的，如果没有熔断，半小时就能让月底账单变成一个天文数字。

我用过的熔断规则有三种。第一是单任务熔断，任务累计成本达到预算上限的 150% 时强制终止，并返回失败提示。第二是单 Agent 熔断，某个 Agent 的调用次数超过预设上限时禁止继续调用，需要人工介入调整。第三是全局熔断，当日总成本达到预算的 80% 时只允许处理优先级最高的任务，达到 100% 时全部停止，等待审批。

熔断机制落地时要注意“人工兜底”的设计：熔断不是让用户无响应，而是降级到人工流程或最终回复预置提示。比如客服工单系统在触发熔断后，工单自动转给人工客服处理，同时把已生成的中间结果附上，方便人工了解前因后果。

从实战经验看，预算熔断是“体系稳定运行的保险丝”，一定要上线。没有熔断的系统就像一个不设上限的信用卡副卡，日常监控再勤快也挡不住单点风险的爆发。

5.3 优化效果复盘模板与定期审计流程

最后是复盘。成本优化不是一次性的工作，因为任务类型会变化，模型价格会调整，Agent 行为也会因为模型迭代而改变。建议每两周做一次成本复盘，按以下模板整理数据：

审计流程分成三步：先看各 Agent 的 token 消耗占比，找到头部消耗点；再核对每个消耗点对应的任务，判断是否存在过度设计或上下文膨胀；最后对比优化前后同类型任务的成本，确认优化效果是否持续。

如果在审计中发现一个问题，比如某个 Agent 的输入 token 特别高但输出很短，大概率是上下文里塞了无用的历史记录。常见的做法就是检查这个 Agent 的输入组成，做出相应调整。

6. 常见问题速查与三条最值得记住的避坑经验

6.1 常见问题与排查建议速查表

在优化多智能体系统成本的过程中，我总结了一些典型的坑，整理成表格方便快速定位：

6.2 三条最值得记住的避坑经验

第一个经验：不要轻易让 Agent 之间“自由对话”。多智能体系统最自然的写法是让两个 Agent 你来我往地讨论，但这种模式在文本大模型架构下既昂贵又不可控。更省钱的做法是把“对话”重构为“顺序提交”：A Agent 输出意见，B Agent 一次性汇总和处理，不再进行多轮往返。两者在效果上可能相差不大，但成本可以差出数倍。

第二个经验：全量传递永远是最贵的方案。任何形式的完整历史传递，哪怕是短期内看着省事，长期来看都是成本失控的温床。我在设计系统时会反复检查每个 Agent 收到的最小必要输入，尽量以摘要、事实清单、定向检索结果代替原始对话记录。

第三个经验：成本优化要考虑模型价差。很多项目追逐“更大的模型、更强的推理”，而实际上大多数任务根本用不上。审校和质量控制环节上旗舰模型，生产与执行环节上标准模型，路由与分发环节用轻量模型，这套组合策略远比全部用旗舰模型更可持续。它是一种长线工程，而不是简单的一次性调价。

我个人在实际操作中的体会是：多智能体系统的成本优化没有一劳永逸的做法，它是一个需要反复迭代的过程。每次模型版本更新、任务需求变化或者 Agent 行为漂移，都会打破原本的平衡，需要重新审视角色分工、上下文传递和模型配置。配置一个得力的路由 Agent，把每一分 token 花在真正必要的位置。同时记得保留一个“预算熔断开关”，它必然会在一些意想不到的时刻帮你守住底线。