Agent 成本失控：5 分钟烧掉 1000 元，如何治理 token 消耗

原创 张波 2026-09-09 08:45 广东  关注腾讯云开发者，一手技术干货提前解锁👇    开发者公众号专属群聊 扫码加入获取更多一手教程、科技前沿报告 # 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- 原创作者｜张波 感谢你读到这里，不如关注一下？👇  📢📢来抢开发者限席名额！点击下方图片直达👇   扫码领取腾讯云开发者专属服务器代金券！   [](https://mp.weixin.qq.com/s?__biz=MzI2NDU4OTExOQ==&mid=2247697254&idx=1&sn=4c6c7051662b7a92a77ce80bec68af16&scene=21#wechat_redirect) [](https://mp.weixin.qq.com/s?__biz=MzI2NDU4OTExOQ==&mid=2247697030&idx=1&sn=961b696054ae4d9c0f9eda068564203e&scene=21#wechat_redirect) [](https://mp.weixin.qq.com/s?__biz=MzI2NDU4OTExOQ==&mid=2247697260&idx=1&sn=bbda847cb4e895e1ea99caf5acec9923&scene=21#wechat_redirect)  [跳转微信打开](https://wechat2rss.bestblogs.dev/link-proxy/?k=bb16cf4a&r=1&u=https%3A%2F%2Fmp.weixin.qq.com%2Fs%3F__biz%3DMzI2NDU4OTExOQ%3D%3D%26mid%3D2247697414%26idx%3D1%26sn%3D3672d692ba91de5791a6cff902c4484d)