华为云Flexus+DeepSeek征文｜Dify 多 Agent 成本治理实战：当 Agent 越来越多，怎么让每一分 token 花得明白

picture_share

261人浏览 · 2026-08-14 07:00:26

picture_share · 2026-08-14 07:00:26 发布

一、引言：Agent 没崩，账单先崩了

上一期我们把插件做成了"可控可信"的受管资产，团队可以放心地多开发插件、多接工具了。但新问题随之而来：Agent 越来越多，调用越来越频繁，月底打开账单的那一刻，心凉了半截。

真实场景是这样的：你搭了一个多 Agent 客服系统——意图识别 Agent 先分流，订单查询 Agent 查数据，售后 Agent 处理退款，质检 Agent 复盘对话；后台还有一批异步 Agent 在跑日报生成、数据归档。每个 Agent 单独看都不贵，一次调用几厘钱，但乘上"每天几千次调用 × 每个请求带着几万 token 上下文 × 工具来回好几趟"，账单就失控了。更隐蔽的是：多 Agent 场景下，同一份上下文会被复制很多份。编排者把完整对话塞给子 Agent，子 Agent 又把它塞给自己的工具，一层层叠加上去，token 消耗是指数级的，而不是线性的。

"省 token"听起来像抠门，但在生产环境里，成本治理的本质是容量规划：如果每个任务平均烧 2 万 token，你算得清一天 10 万次任务要烧多少、要备多少预算、峰值会不会打爆账户余额吗？算不清，就不敢上量；不敢上量，业务价值就出不来。所以这一期我们聊多 Agent 场景下的成本治理：先算明白账，再找出四个烧钱的放大器，最后给出从"看得见"到"省得下"的完整打法。本文基于华为云 Flexus 云服务器 + Dify + DeepSeek 系列实战环境，是《华为云Flexus+DeepSeek征文》系列的第十八篇。

二、成本从哪来：多 Agent 烧钱的四个放大器

在动手优化之前，先把钱的去向搞清楚。单 Agent 的成本公式很简单：

单次请求成本 = 输入 token 数 × 输入单价 + 输出 token 数 × 输出单价

多 Agent 场景之所以贵，是因为存在四个"放大器"，把公式里的 token 数成倍放大：

2.1 放大器一：上下文膨胀

每个 Agent 的每次调用都要带上它的完整对话历史。对话越长，每次调用的输入 token 越多，而且是平方级增长——第 100 轮对话时，每轮都要把前 99 轮重发一遍。一个 20 轮的客服对话，光历史消息就可能攒到 3-4 万 token。

2.2 放大器二：工具调用往返

Agent 每调一次工具，工具结果要回灌进上下文，然后 Agent 才能决定下一步。一个任务走"查订单→查物流→查售后政策→生成回复"四步，每步都带着前面全部上下文跑一遍。工具结果越大（比如拉了一张 200 行的订单表），回灌越狠。

2.3 放大器三：多 Agent 消息复制

这是多 Agent 特有的坑。编排者收到用户消息后，把完整对话传给子 Agent；子 Agent 完成后再把自己的完整输出回传给编排者；编排者可能还要把结果再传给另一个子 Agent。同一段内容在系统里被复制了 3-4 份，每一份都按输入 token 计费。实测中，多 Agent 协作的任务，上下文重复率常常超过 60%。

2.4 放大器四：重试与并发

失败重试是最贵的隐形消耗——一次超时重试，等于把前面所有 token 再烧一遍；并发峰值时多个 Agent 同时跑长任务，单分钟 token 消耗可以飙到平时的 10 倍。如果不设上限，一个突发的异常循环（比如 Agent 反复调用同一个失败的工具）就能把预算烧穿。

先记住一个结论：多 Agent 优化的 80% 收益，来自砍掉"重复"和"冗余"——重复的上下文、冗余的工具结果、多余的模型档位。 后面所有手段都是围绕这一点展开的。

三、先算明白账：建立成本可见性

优化要有依据，依据来自数据。第一步不是省，而是让每一分 token 都看得见。

3.1 单请求成本公式与定价模型

以 DeepSeek 系模型为例，计费按输入/输出分别计价，输入通常远便宜于输出（输出 token 单价是输入的数倍）。这意味着：

少输出比少输入更省钱——让模型"想清楚再简短说"，收益立竿见影；
压缩输入同样重要——上下文每砍 1 万 token，成本按输入单价线性下降。

把公式落到工程上，一个任务的总成本是：

任务成本 = Σ(每次调用的输入×输入单价 + 输出×输出单价) + Σ(工具执行开销)

3.2 Dify 里怎么拿数据

Dify 自带应用运营看板，能看到每个应用的调用次数、token 消耗趋势，但粒度到不了"单个任务烧了多少"。要拿到细粒度数据，三条路：

日志留痕：Dify 的日志系统记录每次对话的模型调用明细（含 token 数），把日志接出来按任务 ID 聚合，就能算出单任务成本；
自定义埋点：在 Agent 的工作流里加一个"成本统计"节点，把累计输入/输出 token 写入消息元数据或外部存储；
网关/代理层：如果走了统一 LLM 网关，网关本身就带 token 计量，按应用维度切分即可。

3.3 三个必须盯的核心指标

指标	含义	健康线参考
单任务成本	每完成一个业务任务的 token 费用	有明确预算，超预算告警
token/成功任务	单位产出消耗，衡量效率	持续下降或稳定
工具往返成本占比	工具调用回灌的 token 占总消耗比例	目标 < 30%

这三个指标建立起来之后，优化就不是"感觉省了"，而是"数字降了"。后面每一招优化，都能用这三个指标验证效果。

四、上下文瘦身：砍掉最大的浪费

上下文是最大的烧钱项，也是最容易砍的。按"先砍重复、再砍冗余、最后压缩"的顺序来。

4.1 历史消息裁剪

对话历史不是越多越好。长对话里，90% 的早期消息对当前决策没有贡献。常用策略：

滑动窗口：只保留最近 N 轮（比如 10 轮），更早的压缩成一句摘要；
相关性过滤：按关键词/意图判断哪些历史消息与当前问题相关，只保留相关部分；
时间衰减：超过 X 小时的历史消息不进上下文，只进记忆库。

4.2 摘要代替全文

对必须保留但不需要细节的历史，用"滚动摘要"：每 N 轮把前面内容总结成一段摘要，后续请求只带摘要 + 最近几轮原文。示例（Dify 工作流中的摘要节点）：

输入：全部历史消息（20 轮，约 3 万 token）
输出：摘要（200 token）
策略：保留最近 5 轮原文 + 之前内容的滚动摘要
效果：单次调用输入从 3 万 token 降到 6000 左右，降幅 80%

4.3 工具结果截断

工具返回大结果时，别全量回灌。三个手段：

字段裁剪：查询只取需要的列（SELECT 订单号, 状态, 金额 而不是 SELECT *）；
行数限制：工具接口默认 limit=20，需要更多再分页取；
结果摘要：让工具返回"统计信息 + 前几条明细"，而不是全量数据。比如查 200 行订单，改成返回"共 200 条，总金额 5.2 万，前 10 条明细"，token 从 3000 降到 400。

4.4 公共上下文外置

系统提示、知识库内容、业务规则这些"每个请求都要带"的公共上下文，能外置就外置：

知识库走 RAG：需要时检索，而不是把整份知识文档塞进 system prompt；
规则走工具：业务规则封装成查询工具，Agent 需要时再取；
提示词瘦身：system prompt 每砍 1000 token，乘上每天调用量，就是真金白银。

五、多 Agent 通信优化：别复制对话，传递结论

多 Agent 场景最特殊的成本问题，是消息复制。优化原则一句话：子 Agent 之间传递结论，不传递对话。

5.1 传递摘要而非全量

编排者把任务交给子 Agent 时，只传"任务描述 + 必要上下文"（比如订单号、用户 ID），不传完整对话历史；子 Agent 返回时，只回传"结论 + 关键数据"，不回传自己的思考过程。实测效果：

优化前：编排者把 3 万 token 的完整对话传给子 Agent
优化后：只传 500 token 的任务卡片（订单号+诉求+必要背景）
节省：子 Agent 侧输入 token 减少 98%

5.2 编排者不重复搬运

编排者的职责是"分发和汇总"，不是"复读机"。子 Agent 的输出不要原样塞回主对话，而是提取关键字段（结构化输出）后，把字段写进汇总结果。比如订单 Agent 返回 JSON：

{
  "order_id": "SO20260812001",
  "status": "shipped",
  "amount": 1299.00,
  "eta": "2026-08-14"
}

编排者只把 status 和 eta 拼进给用户的回复，而不是把整段 JSON 原文回显。

5.3 共享上下文放外部

多个 Agent 都需要的数据（用户画像、订单总览、政策文档），不要每个 Agent 都从对话里取，而是放到共享的知识库/数据库，各 Agent 按需检索。公共数据只存一份，谁用谁查，token 只烧一次。

六、缓存：让重复的 token 只付一次

很多请求之间高度相似——同一批用户问同一类问题，同一个 Agent 反复查同一份数据。缓存能把这些"重复的 token"直接归零。

6.1 前缀缓存（Prefix Caching）

DeepSeek 等模型服务支持前缀缓存：请求的公共前缀（system prompt + 固定上下文）如果与缓存中的前缀一致，输入 token 按缓存命中价计费（通常远低于全价）。要吃到这个红利：

system prompt 保持稳定：不要每次都动态拼一段随机前缀（比如把时间戳、随机变量放最前面）；
固定结构放前面：system prompt、工具定义、固定规则放最前，动态内容放最后；
命中率监控：网关/服务商控制台看前缀命中率，目标 > 70%。

6.2 语义缓存

对"问题相似、答案可复用"的场景（FAQ、政策查询、常见报表），加一层语义缓存：新请求先做向量检索，与历史问题相似度超过阈值（如 0.92）直接命中缓存答案，不再调模型。适合：

客服高频问题（"怎么退货""运费谁出"）；
固定格式的报表生成（"昨天订单量""本周退款率"）；
多 Agent 中重复出现的子任务（多个用户问同一个订单的物流状态）。

注意：语义缓存只适用于确定性回答，涉及个性化、实时数据、多轮上下文的任务不能缓存，否则会答错。

七、模型分级路由：贵模型干难活，便宜模型干杂活

多 Agent 场景天然适合"按任务难度分档"：不是所有任务都值得用最强模型。分级路由是成本治理里收益最大、见效最快的一招。

7.1 分级思路

任务类型	建议模型	理由
意图识别、实体抽取、简单问答	轻量快速模型	任务简单，贵模型浪费
多步推理、代码生成、复杂决策	DeepSeek-R1 等强推理模型	需要深度思考，贵得值
总结、改写、格式转换	中等模型	输出质量要求中等

7.2 Dify 里的落地方式

Dify 支持在应用/工作流里配置不同模型节点，实现方式有两种：

工作流分支路由：意图识别节点用轻量模型，识别结果走不同分支，复杂分支才调用 R1；
Agent 策略内路由：在自定义 Agent Strategy 插件里做模型选择逻辑——先低成本试探，难度高再升级。

7.3 动态降级

分级之外再加一层"动态降级"：当某类任务连续失败或超预算时，自动切到低一档模型。比如 R1 推理超时两次，降级到中等模型直接给答案。降级不是牺牲质量，而是给系统留一条低成本逃生通道，防止高成本路径在峰值时拖垮预算。

八、预算与限流：给成本装上护栏

前面是"省"，这一节是"防"——防止任何单点把预算打穿。

8.1 任务级预算

每个任务设 token 预算上限（比如单任务 ≤ 3 万 token 或 ≤ 0.5 元），达到上限强制终止或降级。落地方式：

Dify 工作流里加"预算检查"节点，累计 token 超阈值就跳转结束分支；
代码里在每次模型调用后累加 token，超过阈值抛出"预算超限"异常，走兜底逻辑。

8.2 并发限流与熔断

限流：控制同时进行的模型调用数（Dify 可配置并发），防止峰值打爆账户；
熔断：当模型服务返回错误率超过阈值（如 5%），熔断器打开，后续请求直接走降级路径，不再调用模型；
退避重试：失败重试带指数退避（1s→2s→4s），且设置最大重试次数（2 次），避免"无限重试烧 token"。

8.3 超预算告警

把"单任务成本""每日总成本"接到告警：日成本超过预算的 80% 预警，超过 100% 触发限流。宁可业务慢一点，也不能月底看到超额账单。

九、实战案例：多 Agent 客服系统的成本优化

把前面的招数串起来，看一个完整案例。

9.1 场景与基线

某电商多 Agent 客服系统：意图识别 Agent + 订单 Agent + 售后 Agent + 质检 Agent，日均 5000 个任务。优化前基线：

单任务平均消耗：约 2.4 万 token（其中上下文复制占 55%，工具回灌占 25%）；
单任务成本：约 0.18 元（R1 处理所有任务）；
日成本：约 900 元。

9.2 优化动作与效果

优化项	动作	单任务效果
上下文瘦身	滑动窗口 10 轮 + 滚动摘要	输入 token 降 62%
工具结果截断	字段裁剪 + limit=20 + 统计摘要	回灌 token 降 75%
消息传递优化	子 Agent 传结论不传对话	复制 token 降 90%
模型分级	意图/简单问答走轻量模型，复杂推理走 R1	R1 调用占比从 100% 降到 35%
语义缓存	高频 FAQ 缓存命中率 45%	缓存命中任务零模型消耗