如何优化 Agent token 成本?

考查重点:调用归因与单位任务成本。按任务统计调用和token,固定计算用代码、重复结果缓存、按需上下文与小模型路由,质量门槛下比较总费用

本题目录

参考答案

核心回答

我会先按一次完整任务统计模型调用与费用,再从减少无效调用、缩小必要上下文、合理选择模型和复用结果四个方向优化。

例如,固定计算交给代码,重复检索复用仍有效的结果;只给当前步骤需要的历史、工具说明和证据,长工具结果先筛选再送入模型;简单且可验证的子任务尝试小模型,失败再升级;稳定的提示词前缀利用供应商缓存。同时限制无进展循环、重复重试和不必要的输出。

判断是否优化成功,要同时看任务质量、耗时与每个成功任务的总成本。压缩、路由和子 Agent 自身也会调用模型,不能只统计最终回答那一次,更不能以 Token 降了就认定业务成本一定下降。

展开说明

1. 先定位钱花在哪一步

给一次任务下的规划、工具选择、子 Agent、总结和重试分别记录调用,保存实际模型、输入与输出用量、缓存读写、结束原因和费用来源。把失败尝试也放回所属任务,才能发现是历史反复发送、工具返回太长,还是错误重试消耗最多。

计量时先统一字段含义。供应商原始响应和追踪平台对 input_tokens 的定义可能不同:有的只表示未缓存输入,有的表示全部输入,缓存量只是其中的明细。应先拆成互不重叠的计费类别,再按相应单价相加;不能把总输入和缓存子项重复计费,也不能把父任务已汇总的费用再加一次子调用。

缺少 usage 的调用应标为未知或估算,不能直接当成零。在线追踪用于定位,最终还要与供应商账单口径核对;模型别名、缓存写入和特殊计费项目都可能影响估算。

2. 减少没有增加任务进展的调用

能稳定用规则、数据库查询或程序计算完成的环节,不必再让模型推理一遍。已取得且仍有效的证据可以复用,避免每轮重新搜索同一内容。并行子 Agent 适合独立任务,但重复的系统提示、材料和交接也会产生费用;并行降低耗时,不代表自动减少 Token。

循环需要有任务级调用、Token 或费用预算,并识别重复工具参数、相同错误和无新增证据。达到边界时返回已完成部分或请求补充信息,不应继续机械重试。重试是否安全还取决于工具:对于可能已经产生外部写入的超时,先确认结果,再决定是否重做。

3. 控制上下文和输出,但保留完成任务所需的信息

历史可以保留近期交互,再把较早过程整理为目标、约束、已确认事实、证据位置和待办。工具返回先筛选相关字段或片段,完整内容保留可读取的位置;工具目录、Skill 先提供必要描述,选中后再加载详细内容。不能为了变短删掉否定条件、单位、版本或关键错误信息。

输出按使用场景设合理长度,例如分类只需结构化结果,用户解释才需要展开。上限太小导致截断、解析失败和重试,也可能更贵。压缩本身若调用模型,同样要计算它的费用和后续节省。

模型路由则优先选择边界清楚、结果可校验的步骤。小模型失败后升级大模型时,要把两次成本相加,评估端到端质量;不能只看“小模型承担了多少请求”,也不宜只依赖模型自报置信度。

4. 分清提示词缓存与业务结果缓存

提示词缓存通常复用已处理的相同前缀。系统规则、工具说明和稳定资料尽量保持内容及顺序稳定,把变化频繁的任务数据放在后面;实际命中仍受供应商、模型、有效期和缓存条件影响。缓存读写可能分别计费,命中也不意味着这些内容不占上下文窗口。

业务结果缓存复用的是查询或计算结果,需要按参数、身份与权限、数据版本和时效区分。相同问题在不同用户下可能没有相同可用结果;资料更新后,旧结果也可能失效。两种缓存解决的问题不同,不能混成“开了缓存就不用再检索或鉴权”。

5. 用同一任务集做对照

固定任务、数据、工具条件和质量标准,比较优化前后的成功率、完整任务费用以及平均和 P95 耗时。单位成功成本的分子包含这批任务的失败与重试费用,分母是成功完成的任务数;这样能暴露“单次调用便宜,但失败更多”的方案。

对于缓存,还应区分冷启动与已有缓存的情况,并观察真实的缓存写入、读取和未缓存用量。一次短任务的收益不能直接推到长会话,最终选择满足质量与时延要求的方案。

常见追问

Skill 执行完移除正文,会不会破坏 KV Cache?

对典型的前缀缓存,修改已加载正文会改变该位置之后的前缀匹配,较早未变化的前缀仍可能命中;具体表现还取决于后端实现。移除内容可能减少后续输入,也可能损失部分缓存收益,所以不能直接说“全部缓存失效”或“一定更省”。

可以对同一组任务比较保留与折叠方案,统计真实缓存读写、未缓存输入、总费用和回答质量。折叠后仍需保留执行结论、关键约束及重新读取入口,不能指望模型继续访问已经移出上下文的正文。

为什么不能只统计最终回答的 Token?

因为规划、路由、摘要、工具选择、子 Agent 和失败重试都可能付费。最终答案很短,也可能经过大量中间调用。应沿任务追踪完整调用树,并避免聚合层级重复计算。

给调用设置最大 Token 数就够了吗?

不够。单次输出上限只能约束一部分用量,还需控制总轮数、上下文增长和任务级预算,并在质量要求下判断是否值得继续。达到上限后的截断与重试也应纳入成本。

对应教程

  • 研搜项目:中间件机制与 Skills 配置:调用次数限制的示例说明如何给 Agent 循环设置边界,并区分单次运行与会话累计限制;Token 计量、计费核对和缓存效果仍需结合实际模型后端设计。

参考资料

  • 国内:JavaGuide:AI 可观测性:借鉴逐调用的模型、用量、缓存、重试与费用记录,说明正文中怎样沿完整任务定位成本来源。
  • 国内:zero2Agent:工程落地与成本:参考循环预算、上下文、模型分工与单位成功成本,说明正文中单次调用更便宜仍可能增加完整任务费用的原因。
  • 国内:WeThinkIn:企业级 Agent 平台:借鉴规则化步骤、小模型路由与失败升级,解释正文中按可验证性分配模型并合计升级成本的策略。
  • 国外:Anthropic:Prompt caching:依据前缀匹配与缓存读写用量,解释正文中稳定提示词和 Skill 折叠对缓存命中及计费的影响。
  • 国外:LangSmith:Cost tracking:依据调用树聚合与 Token 分类口径,解释正文中总输入、缓存子项和父子调用费用不能重复相加的原因。

相关面经

11 篇

字节跳动

AI 全栈实习生
实习一面
查看原面经 →
Agent 任务轮次多、Token 消耗大,面对几百上千用户时如何降低成本?

公司未注明

Agent 开发实习生
实习
查看原面经 →
是否考虑过大模型 Token 缓存命中率? 如何降低多轮对话的 Token 成本?

字节跳动

前端开发
秋招二面
查看原面经 →
自研 Agent 如何做评测、可观测性、控制 token 成本。

公司未注明

后端开发工程师
查看原面经 →
在智能客服场景中,如何解决大模型产生的幻觉问题?另外,在调用大模型时,有哪些降低 Token 消耗、控制调用成本的方法?

水滴

AI 全栈工程师
校招秋招一面
查看原面经 →
降低token成本的方式都有哪些?大模型的 kv cache 机制讲一下?
展开剩余 6 篇面经

作业帮

AI 应用开发实习生
实习一面、二面
查看原面经 →
你在实践过程中有没有什么关于agent的token节约设计呢?

腾讯

Agent 开发工程师
社招一面
查看原面经 →
介绍一下token消耗优化的一些手段

去哪儿

前端开发工程师
一面
查看原面经 →
Agent项目Token成本从哪些维度做优化?

影石创新

AI Agent
实习一面
查看原面经 →
如果 Token 消耗突然增加,你会如何定位原因并进行优化?

阿里巴巴

大模型算法工程师
一面
查看原面经 →
搭建Agent系统时,在不降低任务效果的前提下,如何减少整体token开销?

蚂蚁国际

AI 应用 / Agent 开发
暑期实习一面
查看原面经 →
开发中token很昂贵,节省token有哪些方式?

收录题集

7 个来源,共11 份题集

Agent 与自主系统

AMIT SHEKHAR · ai-engineering-interview-questions · 2 条原题

查看题集 →

影石创新高频面试题

Rocky Ding · AIGC-Interview-Book · 1 条原题

查看题集 →

Harness 与 Skills

沉默王二 · 王二讲 Agent · 1 条原题

查看题集 →

Agent开发面试题

摸鱼酱mio · 个人整理 · 1 条原题

查看题集 →

工程化踩坑:死循环、状态丢失与成本控制

Onefly · zero2Agent · 1 条原题

查看题集 →
展开剩余 6 份题集

相关题目

4 题