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 优化本质是请求策略变更应和普通服务发布一样保留回滚路径。八、总结Token 治理的起点是可观测而不是删词。先建立任务级成本基线再逐层引入工具筛选、历史摘要和缓存并用固定样本验证质量变化。对任何会改变业务状态的工具成本优化都不能绕过权限校验、确认流程和审计记录。参考资料OpenAIPrompt cachingOWASPLLM 应用 Top 10
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 优化本质是请求策略变更应和普通服务发布一样保留回滚路径。八、总结Token 治理的起点是可观测而不是删词。先建立任务级成本基线再逐层引入工具筛选、历史摘要和缓存并用固定样本验证质量变化。对任何会改变业务状态的工具成本优化都不能绕过权限校验、确认流程和审计记录。参考资料OpenAIPrompt cachingOWASPLLM 应用 Top 10
