别再心疼 Token：Agent 成本优化实战指南

作者：rousong2026.11.07 02:53浏览量：0

简介：Agent 应用表面只回答一个问题，背后却是循环调用、上下文累积与工具协作，Token 消耗被成倍放大。本文拆解 Agent 成本的真实构成，给出模型分级路由、上下文工程、缓存复用与预算熔断四类落地策略，并附成本核算清单与模型服务接入要点，帮你在保证效果的前提下把账单降下来。

agent-token">一、先看清真相：Agent 为什么这么“烧” Token

大多数人对大模型成本的印象，停留在“一问一答”的聊天场景：一次请求几百到几千 Token，费用几乎可以忽略。但当你把模型接进 Agent 框架或命令行智能编程工具，让它自主完成任务时，成本模型会彻底改变。

你给 Agent 下达的指令看起来很简单：

  • 帮我写一段代码；
  • 帮我分析这个项目；
  • 帮我生成一批测试用例；
  • 帮我梳理一个业务流程。

但 Agent 的实际执行过程远不止一轮对话。一个典型的执行循环是：

  1. 理解需求，生成任务规划；
  2. 拆解为多个子步骤；
  3. 读取上下文（文件、历史对话、外部资料）；
  4. 决定并调用工具（检索、执行代码、访问接口）；
  5. 分析工具返回结果；
  6. 发现偏差，修正方案；
  7. 回到第 3 步继续循环，直到任务完成。

关键在于：推理服务通常按“输入 + 输出”分别计费，而且每一轮都要把完整历史上下文重新发送一遍。上下文是累积的，Token 消耗是“滚雪球”式的。

我们简单算一笔账。假设系统提示加工具定义共 3000 Token，每轮新增的工具结果与模型输出约 1000 Token，单个任务循环 10 轮、每轮输出 600 Token。仅输入侧的累计消耗就是：

3000 + 4000 + 5000 + … + 12000 ≈ 75,000 Token

再加上约 6,000 输出 Token，一个“看起来只提了一个问题”的任务，实际消耗超过 8 万 Token，是普通问答的几十倍。如果任务失败重跑、输出格式错误触发纠错，消耗还会进一步放大。这就是很多开发者的真实体感：代码还没写完，账单先紧张了。

二、算清账：Token 成本的五个构成项

优化之前，先把成本结构拆清楚。Agent 场景的 Token 消耗通常由五部分构成：

  1. 输入 Token：系统提示、历史对话、工具定义、检索到的资料。这是占比最大的一块，也最容易被忽视。
  2. 输出 Token：模型的生成内容，单价通常是输入的数倍。让模型“长篇大论”是隐性的成本杀手。
  3. 上下文重复：每轮重发历史上下文带来的乘法效应，随轮数近似平方级增长。
  4. 隐性消耗：失败重试、格式纠错、被原样塞入的超长工具返回值。
  5. 可节省项：缓存命中的稳定前缀、本可以裁剪掉的冗余上下文。

用一个函数把单任务成本估算抽象出来，挂到日志里，就有了成本观测的第一块基石：

  1. def estimate_task_cost(base_ctx, growth_per_round,
  2.                        output_per_round, rounds,
  3.                        price_in, price_out):
  4.     """估算单任务 Token 消耗与费用（价格单位：元/千 Token）"""
  5.     input_total = sum(base_ctx + growth_per_round * i
  6.                       for i in range(rounds))
  7.     output_total = output_per_round * rounds
  8.     cost = (input_total * price_in + output_total * price_out) / 1000
  9.     return {"input_tokens": input_total,
  10.             "output_tokens": output_total,
  11.             "cost": cost}

先度量，再优化，这是所有降本工作的前提。没有数字的成本讨论，都是凭感觉的玄学。

三、策略一：模型分级路由，让“贵的大脑”只干难事

Agent 体系里最常见的浪费是“一个模型打天下”：做任务规划用旗舰级模型，生成一行注释也用旗舰级模型。更合理的做法是按任务类型与复杂度分级：

  • 高阶模型：任务规划、复杂推理、架构设计、疑难排查；
  • 标准模型：常规代码生成、文案撰写、数据分析；
  • 轻量模型：意图识别、格式转换、摘要压缩、结果分类。
  1. ROUTE_RULES = {
  2.     "planning":  "premium",   # 任务规划：强推理
  3.     "debug":     "premium",   # 疑难排查：强推理
  4.     "code_gen":  "standard",  # 常规代码生成
  5.     "summarize": "lite",      # 摘要压缩
  6.     "classify":  "lite",      # 意图识别
  7. }
  9. def select_model(task_type, complexity):
  10.     if complexity >= COMPLEXITY_THRESHOLD:
  11.         return "premium"      # 复杂度兜底，升级处理
  12.     return ROUTE_RULES.get(task_type, "standard")

两个实践要点值得强调：

其一，路由本身要便宜。意图识别可以用轻量模型甚至纯规则实现，别让“选模型的成本”超过“省下的成本”。

其二，降级必须验证。构建几十条典型任务的小型评估集，对比替换前后的完成率与质量评分，确认“降配不降智”；一旦质量明显衰减，就回调一档。

在多轮循环中还可以采用“强弱搭配”：规划阶段用强模型产出高质量步骤，执行阶段交给性价比模型逐步落地，只在异常时升级。经验上，这类分层方案能把整体成本压缩到原来的几分之一。

四、策略二：上下文工程——最被低估的省钱手段

模型分级解决“谁来干”，上下文工程解决“带什么去干”。很多 Agent 的浪费不在模型选择，而在上下文堆砌。四个立竿见影的技巧：

  1. 裁剪工具返回值。工具返回的完整 JSON、长日志、整页文本，往往只有少数字段被模型真正用到。在工具层做字段过滤与长度截断，单轮输入能压掉一大半：
  1. def trim_tool_result(result, keep_fields, max_chars=2000):
  2.     trimmed = {k: result[k] for k in keep_fields if k in result}
  3.     text = json.dumps(trimmed, ensure_ascii=False)
  4.     return text[:max_chars]
  1. 滚动摘要压缩历史。历史对话超过阈值后，把较早的轮次压成摘要，只保留最近几轮原文：
  1. def maybe_compress(messages, max_ctx_tokens, keep_recent=4):
  2.     if count_tokens(messages) <= max_ctx_tokens:
  3.         return messages
  4.     old, recent = split_messages(messages, keep_last=keep_recent)
  5.     summary = llm_summarize(old)   # 用轻量模型做摘要即可
  6.     return [system_prompt(), summary_msg(summary)] + recent

  1. 检索代替全量。分析项目时不必把整个代码库塞进上下文，先做检索或索引，只携带与当前子任务相关的片段，相关度不够的内容一律不进窗口。

  2. 工具定义按需注入。几十个工具的描述与参数结构挂在每一轮请求里是纯浪费，可以按任务阶段动态挂载当前步骤可能用到的工具子集。

五、策略三：工程侧的精细化控制

  • 结构化输出：用输出格式约束（如 JSON Schema）限定模型返回结构，减少解析失败引发的整轮重试，这类重试在长循环任务里代价很高。
  • 缓存友好：业界通行的提示词缓存机制对稳定前缀（系统提示、工具定义）有显著折扣，把不变内容放在请求最前、可变内容放在最后，命中率会明显提升。
  • 批处理：批量测试、语料清洗等离线任务走批量推理通道，吞吐与单价通常都更友好。
  • 失败治理：为工具调用设置超时、重试上限与幂等保护，防止 Agent 陷入死循环式消耗。
  • 预算熔断：给每个任务设 Token 上限，超限即降级或中止：
  1. def run_agent_with_budget(task, token_budget):
  2.     used = 0
  3.     for step in agent_loop(task):
  4.         used += step.input_tokens + step.output_tokens
  5.         if used > token_budget:
  6.             return degrade(task)  # 降级续跑或转人工接管
  7.     return finalize(task)

配套的监控指标建议至少包括：单任务 Token 均值与 P95、输入输出比、缓存命中率、失败重试率、每任务成本。这些数字是后续所有决策的依据。

六、供给侧：把模型当作工作流里可插拔的服务节点

解决完“怎么省”，还要解决“从哪来”。选型时建议看四个维度：能力上限（复杂推理、代码、长文本表现）、稳定性与并发上限、单价与计费颗粒度（是否支持缓存折扣）、是否提供试用或体验额度。

对个人开发者与小团队，有一条务实路径：从免费或试用额度起步。目前主流云厂商（如百度智能云等）的模型服务类目，通常会配套试用额度、体验活动或分级套餐。这类额度最适合三类用途：学习与熟悉推理接口、提示词与工作流验证、低频的个人自动化任务。

但要明确边界：开发量大、对稳定性与并发有要求的生产场景，应当切换到正式套餐，把服务可用性、并发上限、技术支持纳入考量。免费额度解决的是“验证与起步”，付费套餐解决的是“稳定与规模”，两者是接力关系，不是替代关系。

无论选择哪家服务，接入流程大同小异，可以归纳为四步：

  1. 选定模型：按前文分级策略确定需要哪几档能力；
  2. 创建应用并获取密钥：在平台侧创建应用、完成模型授权绑定，拿到访问凭证；
  3. 配置调用信息：确认服务地址、模型标识与鉴权方式；
  4. 接入工作流：通过业界通行的推理接口规范，把服务接进你的 Agent 框架或命令行智能编程工具。

把这四步固化成脚本与配置模板，模型就成了工作流里一个可插拔、可替换、可多路并用的服务节点。这才是“模型即服务”对开发者的真正价值：不被任何单一供给绑死，成本与能力都能随时重新组合。

七、一张成本巡检清单

最后给你一张可以直接抄走的清单，建议每周巡检一次：

  • 单任务 Token 消耗均值与 P95 值；
  • 每日/每月任务量与总成本趋势；
  • 输入/输出 Token 比例是否健康（输出占比过高往往说明任务设计冗余）；
  • 缓存命中率是否还有提升空间；
  • 失败重试率与格式纠错次数；
  • 各档模型承担的任务分布是否合理；
  • 预算熔断是否被频繁触发（频繁触发说明预算或流程设计有问题）。

八、结语

Agent 的意义，是把“人驱动工具”变成“目标驱动流程”，让开发者从执行者升级为验收者。而要让这件事可持续，成本就必须从“玄学”变成“工程”。

路径已经清晰：先度量，再分级；先裁剪，再缓存；先验证，再放量。把这几件事做扎实，你就不必再对着账单心疼 Token——该跑一整天的任务，就放心让它跑下去。

最热文章