Agent Token 成本治理：预算收紧时的估算与优化路径-开发者社区

Agent Token 成本治理：预算收紧时的估算与优化路径

Agent 的成本失控通常不是模型突然变贵，而是请求边界没有收住：每轮都附带完整历史、全部工具 Schema 和无关检索片段。调用次数上来后，单次多出的几百个 Token 会被放大成持续支出。

这篇文章讨论一个可操作的目标：先找到 Token 花在什么地方，再用不伤害任务质量的方式缩短上下文。不要先设“降低多少”的目标。没有固定任务集、模型版本和输入分布，百分比没有比较价值。

一、先把账单拆到一次调用

成本核算至少要记录四类输入：system prompt、对话历史、工具定义和检索上下文；输出则单独记录完成文本与工具参数。日志还应包含模型名、请求路由、缓存命中、任务类型和失败原因。这样才能区分“工具太多”与“历史太长”，也能发现重试造成的重复消耗。

先为三到五个高频任务准备固定样本。每次改动只替换一个变量，例如把工具从全量注入改为按意图筛选。比较总 Token、任务成功率、人工兜底率和首字延迟，而不是只看成本。若成功率下降，需要检查被裁掉的工具或事实是否正好是任务依赖。

二、上下文压缩应放在调用前

工具路由、历史摘要和语义缓存都应是显式步骤。路由器负责挑选候选工具；摘要器只压缩已结束的对话段；缓存只复用可以接受近似结果的查询。把三件事混在一个 Prompt 里，出了问题很难判断是哪一层造成偏差。

工具筛选尤其要保守。对写操作、付费操作和跨系统操作，宁可少量候选后再走一次澄清，也不要让模型在大量相似工具中猜参数。工具描述的版本号与权限范围应随请求一起记录，便于回放。

三、Go 服务端的预算闸门

下面的代码只负责预算校验。它不替代模型 SDK，也不决定工具是否安全；调用前仍要完成鉴权和参数校验。

type Budget struct { MaxInputTokens int MaxToolCount int } func CheckRequest(b Budget, history []Message, tools []Tool) error { if len(tools) > b.MaxToolCount { return fmt.Errorf("tool count %d exceeds limit %d", len(tools), b.MaxToolCount) } inputTokens, err := EstimateTokens(history, tools) if err != nil { return fmt.Errorf("estimate request tokens: %w", err) } if inputTokens > b.MaxInputTokens { return fmt.Errorf("input budget exceeded: %d > %d", inputTokens, b.MaxInputTokens) } return nil }

EstimateTokens应使用实际模型的 tokenizer，而不是按字符数猜测。超预算时不要静默截断：返回可识别的错误码，由上层选择缩短历史、减少检索片段、改用低成本模型，或要求用户收窄问题。每个分支都要写入同一个 trace，才能复盘策略是否有效。

四、工具筛选不要只靠关键词

最简单的做法是从用户问题里匹配工具名或描述，再取前几个工具。这适合作为第一层召回，但不能直接决定最终注入的工具集。名称相近的“查询订单”和“修改订单”很容易被一起召回；如果两个工具都开放给模型，模型会在参数不完整时选择副作用更大的那一个。

一个更稳妥的流程是三段式：先按租户、角色和业务场景过滤无权限工具；再用关键词或向量检索召回候选；最后由服务端规则排除写操作、金额操作和不可逆操作。模型只在剩余候选中选择。需要写入时，让它先生成结构化的执行计划，展示给调用方或人工审批，再由后端执行。

工具 Schema 也要控制体积。公共字段如request_id、tenant_id不应在每个工具中重复解释；很长的枚举值可以由服务端查询补全。压缩 Schema 前，要保留参数类型、必填字段和业务约束。否则省下的输入 Token 会以参数校验失败和重试的形式回到账单里。

五、摘要不是删除，而是可回查的压缩

对话摘要应当区分“已确认事实”“待确认假设”和“已执行动作”。例如，用户已确认的地域、权限和交付格式可以写进摘要；模型猜测的根因不能直接固化为事实。每条摘要记录都应保存来源消息 ID 和生成时的提示词版本。出现争议时，系统应能回到原对话，而不是让新的模型继续在错误摘要上推理。

摘要触发条件也不宜只看轮次。更可靠的条件是输入 Token 接近预算阈值，或任务进入新的阶段。前者避免模型上下文被截断，后者避免把“需求澄清”和“执行结果”混进同一段摘要。对于需要逐字保留的合同、代码、命令和配置，不要摘要；可以先提取索引，再按需取回原文片段。

六、缓存命中后仍要验证业务语义

语义缓存会把相似问题归到同一答案，适合知识问答，不适合价格、库存、权限等实时数据。摘要可以减少历史长度，却可能丢掉约束条件；摘要后的事实最好带来源消息 ID，并在关键决策前回查原文。

另一个常见误区是把工具 JSON 一律放进缓存。工具契约变化后，旧缓存会让模型看到过期参数。工具定义、模型配置和提示词版本至少应组成缓存键的一部分。缓存失效时应回落到完整但受预算限制的调用路径。

缓存命中不能直接跳过权限判断和数据新鲜度判断。可以把缓存答案分成两类：纯文本解释允许按相似度复用；涉及用户数据的答案必须再次验证租户、资源 ID 和更新时间。命中记录应写入命中阈值、候选 key、答案版本和实际节省的输入/输出 Token，避免团队只看到“命中率”而不知道命中了什么。

七、用回归集判断优化是否值得上线

准备一组覆盖常见路径和失败路径的任务：单工具查询、多工具依赖、长对话续问、无权限请求、工具超时和检索为空。每个样本定义可检查的完成条件，例如是否选择了正确工具、是否拒绝了越权操作、答案是否引用了正确数据。优化前后在同一模型、同一参数和同一并发设置下运行，记录输入 Token、输出 Token、成功率、P95 延迟和人工介入次数。

发布时建议先把新策略放在少量可回滚流量上。监控不只看平均成本，还要看预算拒绝率、缓存误命中、工具参数校验失败和降级比例。任一指标异常时，关闭摘要或缓存开关，恢复到上一个策略版本。Token 优化本质是请求策略变更，应和普通服务发布一样保留回滚路径。