5分钟烧掉1000块！Agent token成本如何治理

关注腾讯云开发者，一手技术干货提前解锁👇

01

故事还是事故：不到 5 分钟，1000块没了？

我们产品同学在体验 DeepSeek Harness 时，让 Agent 帮忙分析如何做一个 DSH 插件，输入只有几十个 token，使用的是 GPT-5.6 Sol。

但恐怖的是，不到 5 分钟，1000 块没了。

展开内部执行链路后发现，Agent 背景执行图是：

其中输入约 1964 万，输出约 13 万；更值得注意的是，用量记录里的 cacheReadTokens 每次都为 0 ——缓存完全没有生效，但他完全没感知。

我们查了很多技术问题：为什么启动了 12 个 subagent、为什么重复检索、为什么上下文被反复携带、为什么缓存失效。但在这里，我们并不想讨论这 1000 块钱具体是怎么烧掉的，而是想讨论它暴露出的一个 Agent 产品事实，也是一个被大家忽略的问题：

用户只提出了一次需求，Agent 却在后台自主完成了数百次付费决策。用户既看不见这些决策，也没有机会在成本迅速扩大时再次确认。

真正“恐怖”的，是 Agent 的自主规划、调用工具和创建 subagent——这是一个黑匣子，带来不可预期的成本扩张。于是，这个故事从一次成本事故，变成了一个更值得思考的产品命题：

当 Agent 获得自主执行能力时，它也同时获得了消费用户预算的能力。一个 Agent 产品，应该如何管理好这种能力？

因为我们自己也在做 Agent 产品，所以试着把这次事件带来的思考整理出来。它不是一套被验证为最优的标准答案，而是一次产品层面的启示。

02

由此得到的启示：同执行权限一样，消费权限也应该成为 Agent 产品的一等公民

在传统聊天产品里，一次输入对应一次响应，用户对“一问一答”的成本规模大致有直觉。

但 Agent 不一样。

用户发出的仍然只是一条消息，系统背后却可能经历任务规划、文件读取、代码检索、工具调用、失败重试、结果验证，以及多层 subagent 并行执行。用户看到的是一个任务，系统运行的却是一张动态生成的执行图——这张图有多深、分出多少支路、每一步用什么模型、携带多少上下文，都不由用户直接决定，却共同决定了最终账单。

所以，Agent 的自主性其实包含两层授权：

• 执行授权： 允许它读文件、调工具、改代码、拆任务
• 消费授权： 允许它调用多少次模型、启动多少代理、运行多久、花多少钱

有去调研过，市面上很多产品已经认真设计了执行授权，却还没有把消费授权当作一等公民。

但用户同意 Agent“完成这个任务”，并不等于给了系统一张没有上限的空白支票。想想，如果一个用户第一次使用你的 Agent 产品，5 分钟就花了 1000 块，他还会再用吗？大概率不会了。

由此触发，我们盘点了一个 Agent 任务始末，一个完整的 Agent 成本闭环至少应该围绕六个环节展开：

1. 事前控制： 用户先决定最多愿意付出多少
2. 提前感知： 系统提前告诉用户大概会付出多少
3. 过程可见： 运行过程中，用户知道钱正在花到哪里
4. 主动告警： 系统判断当前消耗是否仍然合理
5. 随时可控： 用户可以暂停、停止或调整执行策略
6. 账单可解释： 任务结束后，能说清楚钱为什么这样花

当然，这也不是固定的，而且我们也没有真正地去实操过，一切都是基于我们盘点后的一个思考。

2.1 事前控制：先让用户决定上限

这一点一直都没有思考清楚哈，因为在花多少这件事情，其实是需要用户对 Agent 对模型都有一定概念的。同时，每次如果都让用户去配的话，也是一件很麻烦的事情，所以这件事情可能需要去做 A/B test 吧。

事前控制解决的不是“这次任务大概多少钱”，而是一个更基础的问题：无论任务后来变得多复杂，用户最多允许系统花多少？

这是用户给 Agent 划定的消费边界。模型只决定单次调用的价格，并不决定最终会调用多少次。 同一个模型，调用 3 次和调用 265 次完全不是一个成本量级；一个 Agent 自己完成任务，和递归启动 12 个 subagent，也不是一回事。因此在“使用什么模型”之外，产品还应该允许用户设置：

• 单次任务最高金额
• 最长运行时间，最大轮数
• 最多使用多少个 subagent
• 是否允许自动切换到更贵的模型
• 到达阈值后是提醒、暂停还是直接停止

但如前面所说，其实就需要用户对Agent对模型有一定的认知才可以。所以成本控制不该增加用户的认知负担。我们既希望用户能控制成本，又不能把 token、轮数、并发数、subagent 深度这些工程参数直接扔给用户。也许对普通用户，更自然的方式是提供几种预设：

但我估计这也不是银弹，期待后续有更好的方案吧。

2.2 提前感知：任务开始前，尽可能告诉用户“可能会花多少”

事前控制回答的是“最多允许花多少”，提前感知回答的是另一个问题：

按照系统目前的判断，这个任务大概会花多少？

虽然可能不会很准，但 有总比没有好，迟到总比不到好。而且慢慢的会越来越准确的。

Agent 的执行路径会动态变化，很难在任务开始前给出精确到小数点后的报价，但“不可能精确预测”和“什么都不告诉用户”之间，我还是更期望有一个简单的预测的，哪怕这个预测可能不是那么准，我心里面可能有一丝丝的底，而且随着样本的变多，我相信这里会越来越准确的。

系统可以先做一次低成本的任务分类（简单问答 / 只读调研 / 方案设计 / 代码修改 / 新功能开发 / 全仓重构），再结合历史任务的 P50、P90 消耗、当前模型价格、仓库规模和预计执行策略，给出一个费用区间。

看过现在很多的产品，是有把消耗的token展示出来的，但我们觉得，展示 token 不如直接展示 金额、时间和风险，因为token本身不是钱呐，感知不是那么强烈的。

当然除了费用区间之外，还可以展示主要成本因素——模型价格较高、上下文规模较大、预计多轮工具调用、任务可能被拆分为多个子任务。只有说清楚“为什么可能贵”，用户才能决定是继续、换模型，还是缩小范围。

对于新任务类型或冷启动阶段，产品不应该装作自己算得很准，可以直接告诉用户“这是低置信度估算，如果明显偏离会主动告警并暂停询问”。运行后的重新估算可以改变“预计最终费用”，但不能自动改变用户已经设置的最高预算。

2.3 过程可见：不应该只看到一个旋转的“正在思考”

Agent 开始运行后，用户最常看到的是“正在思考”“正在搜索”“正在执行”。但对一个可能持续做出付费决策的系统来说，这些状态远远不够。过程可见至少应该回答四个问题：

1. 已经花了多少
2. 距离上限还有多少
3. Agent 当前在做什么
4. 按照当前速度，最终可能花多少

例如：

已使用：¥4.20 / 上限 ¥10 当前阶段：检索代码结构 运行中 Agent：主 Agent 1 个，subagent 2 个 当前预估总费用：约 ¥6～¥8 费用高于同类任务中位数，主要因为检索结果较大

用户不需要看到每一次 API 调用，但应该看得见成本趋势和执行规模；如果用户能够看得到整个的趋势，那么他也可以及时地去做一些纠偏和处理。

但可见，不等于把调试面板全部暴露出来。普通用户关心金额、时间、阶段和风险；专业用户需要时再展开查看：每个 Agent 的消耗、当前模型和调用次数、输入/输出/推理 token、缓存读取与写入、工具返回体积、重试和重复探索情况。过程展示应该采用渐进式披露：默认展示用户能理解的成本状态，需要时再展开技术细节。

如果费用曲线突然变陡，界面不能只是把 ¥2 更新成 ¥8，而应该尝试说明原因：新启动了 subagent、检索范围从单个目录扩大到整个仓库、工具返回体积超预期、上下文增长过快、出现多次失败重试、系统切换到了更贵的模型。

只有把执行变化和费用变化联系起来，过程可见才不是一个被动计数器，而是一种真正的用户知情机制。

2.4 主动告警：Agent 既然知道过程，就应该有基本的判断消耗是否合理

这可能是这次事件带给我们最重要的一层思考。

传统费用告警通常很简单：消费超过一个固定金额，就发出通知。但 Agent 系统其实知道大量过程信息——它知道和上一轮相比哪些内容没有变化、当前调用了什么模型和价格、已经创建了多少个 subagent、工具返回了多少内容、是否在不断重试、每一步是否获得了新的信息。

换句话说，Agent 不只能知道“已经花了多少钱”，还应该能够大致判断：

这笔钱花得是否符合当前任务的正常执行过程？

1. 信号一：预估消耗与实际消耗是否明显偏离 系统可以根据同类任务的历史分布，持续比较：实际花费是否已达到预估的数倍、消耗速度是否突然变快、按当前速度是否即将突破预算。例如一次只读调研通常需要 10～20 次 LLM 请求，但当前已经运行了 80 次仍没有进入汇总阶段——这本身就是值得告警的信号。
2. 信号二：Cache 命中是否符合预期 系统能够看到最终发给模型的输入，也能估算其中有多少是与上一轮相同的稳定前缀，从而得到一个产品侧预期：预计 Cache 命中比例 ≈ 可复用稳定前缀 token / 本次输入 token

这次的事故正是每一轮都是零 cache 命中——系统判断约 80% 输入是可复用前缀，服务端却连续返回 0% 或 10% 的缓存读取。如果当时能对这个偏差做告警，一定不会这么惨。它可能意味着提示词结构意外变化、历史上下文被重写、Cache 没有正确开启、网关或 SDK 没有完整透传 usage，或者当前渠道并不支持缓存能力。

假设DSH有做这个事情，那也许我们这件事情完全都不会发生，因为每次都是0 cache，这显然是不合理的。

当然，这种判断有两个前提：已确认模型和渠道支持 Cache 且已开启；用量遥测可信，能区分 Cache 读取、写入和普通输入。否则 cacheReadTokens = 0 只能被视为待排查的遥测信号，不能仅凭一次 0 值停止任务。但这件事情在产品发布前测试，其实就能够完全测试出来的。

2.5 随时可控：用户可以停止，也可以改变 Agent 的执行方式

告警的价值不只是让用户知道“出事了”，还要让用户能够立即采取行动。一个正在运行的 Agent，至少应该允许用户：

暂停任务、立即停止、查看已完成的结果、缩小任务或检索范围、禁止继续创建 subagent、切换到更经济的模型、追加一档固定金额或时间、保存当前状态稍后继续。

我们设想的可能会是这样三条：

1. “继续”不代表永久解除限制。 我们设想的是当用户在一次告警中选择继续，产品应该明确告诉他增加的是什么——再增加 ¥5、再运行 10 分钟、再允许 20 次请求。一次继续只进入下一档边界，不能让整个任务从此变成无限运行。但这个也许实现起来会比较困难
2. 停止之后，不应该继续产生新的消耗。 停止的第一原则是立即停止所有的模型请求、工具调用和 subagent 派发，系统不能为了“收尾”又默认启动一轮新的模型调用。之前见过，比如CodeX，主 Agent停止了过后，Sub Agent还在运行。
3. 结果可见，已完成的子任务结果、代码改动、已确认的事实与证据、可恢复的检查点，都应该在运行过程中就被持续记录——停止后只需要读取并展示现有状态，不应再产生新的模型费用。

2.6 账单可解释：“小票”要清晰具体

任务完成、中止或达到预算上限后，产品不应该只给出一个总金额。用户需要知道：实际花了多少、开始前预计是多少、钱主要花在哪些阶段、为什么高于或低于预期、启动了多少个 Agent、是否发生重试或模型升级、当前完成了什么还有什么没完成。

例如：

本次任务总费用：¥7.42 预计费用：¥2～¥5 LLM 请求：43 次 token 消耗：总 token多少？cache多少？ Agent：主 Agent 1 个，subagent 2 个 主要消耗：代码检索 46%、方案生成 31%、结果校验 18% 高于预估的原因：检索范围扩大、发生两次失败重试 当前结果：方案已完成，兼容性验证尚未完成

普通用户看到金额、原因和结果即可；专业用户可以进一步展开 token、模型、Cache 和每个 Agent 的明细。

“成本小票”不仅服务用户，也服务下一次预估：每次任务结束后的真实数据，可以反过来建立不同任务类型的 P50/P90/P99、不同模型的单位任务成本、预估与实际的偏差、哪些步骤最容易异常消耗、哪些告警真的帮用户省了钱。账单可解释不仅是事后审计，也是下一次提前感知的输入。

听到过这样一句话，用户不是来购买 token 的，用户购买的是结果和确定性。 我觉得说的很有道理，Token只是计费单价而已，但是真正想要的是一个可解释、可说明。就像你去买东西一样，你一样的，你可能不是很关心这个菜多少钱的单价，但是你关心的是最终是不是按照一个清晰的透明的价格来结算的。

03

回到案例：如果当时有这六个环节

如果当时已经有这样一套机制，整个过程可能会变成：用户选择执行模式并设置单次任务上限（事前控制）→ 系统展示同类任务的费用区间和潜在风险（提前感知）→ 用户看到已用金额、运行中 Agent 数量和最新预估（过程可见）→ 当 subagent 快速增加、上下文持续膨胀或 Cache 命中与预期明显不符时，系统主动说明异常（主动告警）→ 用户查看当前结果、停止、缩小范围或追加一档固定预算（随时可控）→ 无论完成还是停止，都能拿到已有结果和一张成本小票（账单可解释）。

这套机制未必能保证每个任务都很便宜，也不应该阻止用户在高价值任务上主动花更多钱。真正重要的是：即使用户愿意花 1000 元，也应该是在知道为什么、看见过程并明确同意之后，而不是 5 分钟后才从账单里发现。

04

结语：用户给出的是目标，不是空白支票

这次事件之后，我们最大的感受是：一个好的 Agent 产品，不能只有模型能力和任务完成率，随着 Agent 获得更多自主权，产品也必须建立与之匹配的成本边界，否则当真的用户来临时，也许一次的失败，就会导致你终身的口碑烂掉，毕竟这是钱呐。

成本控制不是一个财务功能，也不只是一个 token 优化问题。它是一套产品权限设计，也是一份用户信任协议。不然我可不敢用？

好的 Agent，不一定每次都花得最少，但每一次花费都应该事前可控、提前可感知、过程可见、异常有告警、随时能干预、账单可解释。

用户给出的是目标，不是空白支票。

-End-

原创作者｜张波