Agent 开始自己省 token：Grok Bot 的成本优化意味着什么
先说结论
Agent 产品开始主动宣传“自动省 token”，说明一个变化：token 成本已经从后台指标，变成了用户能感知的产品功能。
9 月 1 日，Grok Bot 的官方更新里连续出现两条相关信息：一条是 Grok @Bot upgrades，另一条是 Automatic token optimization to lower your Grok @Bot cost will be added soon。按 OKP 的追踪数据，两条帖子分别获得了 16,505 和 18,789 个赞。
这里要先说清楚：官方目前公布的是“即将加入自动优化”的方向，没有给出统一的节省比例、具体算法或所有任务上的成本承诺。所以这篇不是 Grok Bot 的节省效果评测，而是想回答一个更实际的问题：
一个 Agent 到底为什么会贵，以及成本优化应该放在哪一层。
Agent 的账单不是一次请求
普通聊天产品的成本大致是一问一答：
一次输入 + 一次输出 = 一次成本Agent 完成一个任务时，通常是这样：
理解任务 → 读文件 → 调工具 → 看结果 → 修改计划 → 再调工具 → 重试 → 验证 → 总结如果第 i 次模型请求的输入、输出、缓存和工具开销分别是 I_i、O_i、K_i、T_i，一个任务的粗略成本可以写成：
C_task = Σ (I_i × p_in + O_i × p_out + K_i × p_cache + T_i)真正让账单变大的，往往不是某一个回答特别长，而是请求次数和重复上下文太多。
一个看起来只需要“改一个按钮”的任务，可能包含：
- 每一轮都重新发送项目规则
- 工具返回完整日志，而不是摘要
- 模型反复读取同一个大文件
- 截图或网页状态被当成高 token 的视觉输入
- 失败后没有明确停止条件
- 多个子 Agent 各自携带一份重复上下文
所以 Agent 的成本优化不能只做成一个“换小模型”的开关。
Grok Bot 的信号为什么值得看
Grok Bot 不是单纯的聊天框。它被描述成拥有自己的电脑，可以进入 Gmail、Salesforce、LinkedIn 等服务执行任务。这样的 Agent 一旦进入重度使用阶段，token 消耗会和任务链路绑定：
任务越长 → 工具调用越多 → 上下文重复越多 → 重试机会越多 → 成本越难预测早期产品最容易宣传“它能做什么”；到了用户真的拿它跑工作之后，问题会变成：
- 这个任务大概花多少钱
- 为什么同样的任务今天比昨天贵
- Agent 是不是在重复读相同内容
- 失败重试有没有上限
- 我能不能在任务中途切换到更便宜的模型
“自动 token optimization”回应的其实是这些问题，而不只是模型推理速度。
成本优化应该分五层
第一层：不要重复发送不变的东西
最简单、收益通常也最稳定的是上下文去重：
- system prompt 保持稳定，尽量命中 prompt cache
- 项目规则按需加载，不要每一轮全文拼接
- 工具结果只保留模型真正需要的字段
- 同一文件的内容在一个 turn 内复用，不要重复读取
这层优化不改变模型能力，只减少重复搬运。
第二层：让工具返回“可用结果”
很多 Agent 贵，不是模型太爱思考，而是工具返回了太多原始材料。
例如一个 shell 工具可以返回 2 万行日志，也可以返回：
{ "exitCode": 1, "stderr": "TypeError: ...", "relevantFiles": ["src/app.ts:42"], "tail": "..."}原始日志应该保存在可追溯的外部记录里，模型上下文只拿摘要和定位信息。这样既省 token，也让模型更容易抓住真正的错误。
第三层：不同阶段用不同模型
不是所有步骤都需要同一档模型：
| 阶段 | 更看重什么 | 可以考虑 |
|---|---|---|
| 任务分类 | 低延迟、低成本 | 小模型 |
| 文件定位 | 稳定工具调用 | 中等模型 |
| 方案设计 | 推理质量 | 强模型 |
| 机械改写 | 结构遵循 | 便宜模型 |
| 最终验证 | 减少漏错 | 强模型 |
这里有一个重要前提：切换模型不能让上下文重新完整上传一遍，否则省下来的输出费用可能被输入费用吃掉。
第四层：给循环设置预算
Agent 的循环应该有明确的预算，而不是“直到模型觉得完成了”。
type TaskBudget = { maxSteps: number; maxInputTokens: number; maxOutputTokens: number; maxWallTimeMs: number;};
function canContinue(state: TaskState, budget: TaskBudget): boolean { return ( state.steps < budget.maxSteps && state.inputTokens < budget.maxInputTokens && state.outputTokens < budget.maxOutputTokens && state.elapsedMs < budget.maxWallTimeMs );}达到预算之后，不一定要直接失败。可以按任务类型选择：
- 保存当前状态，等待用户继续
- 切换到便宜模型做收尾
- 只执行验证，不再扩展范围
- 给用户展示目前完成了什么、还差什么
第五层：把成本变成可观察数据
“感觉今天很贵”不是可调试的指标。至少要记录：
- 每个任务的总 token 和总费用
- 每一步的输入/输出/cache 命中
- 工具调用次数和工具结果大小
- 重试次数
- 每个模型在任务中的占比
- 成功任务的单位成本
- 失败任务已经消耗的成本
我会特别关注两个数字：
cost_per_successful_taskcost_before_user_abandonment前者告诉你系统完成一件事要付出什么，后者告诉你用户在 Agent 还没完成之前已经被消耗了多少预算。
“省 token”不能变成“少做工作”
成本优化有一个很容易踩的坑：把任务结果变差，换成账单变好。
例如：
- 过度压缩工具结果，丢掉关键错误
- 为了少发请求，跳过验证步骤
- 强行缩短上下文，让模型重新猜项目背景
- 在复杂任务中途切到小模型，导致返工
- 把多次尝试隐藏掉，让用户看不到实际成本
所以优化目标不应该是：
minimize tokens而应该更接近：
minimize costsubject to successful completion, safety, and recoverability也就是在完成率、安全性和可恢复性不下降的前提下，减少成本。
云端 Agent 和本地 Agent 的成本不一样
Grok Bot 这类云端 Agent 主要面对的是服务端 token 成本和用户套餐成本。Pi/cohub 这类运行时还要考虑另一种成本：
- 云端 API token
- 浏览器/容器运行时间
- 文件存储和日志保留
- 多 Agent 并发
- 本地模型的显存、内存和电力
本地模型看起来没有 API 账单，但“把一个 100GB 模型留在内存里跑一整天”也不是零成本。只是成本从按 token 计费，换成了固定设备成本和吞吐成本。
因此我不太相信一个统一的“每百万 token 多少钱”能够描述 Agent 的真实价格。更合理的单位可能是：
每个成功任务的成本每个有效工具动作的成本每个可恢复工作小时的成本从产品角度，我会怎么做
如果我要给 Agent 加成本控制，不会只在设置页放一个 slider。我会做四件事：
- 任务开始前给区间估算：告诉用户这是短任务、长任务还是可能持续运行的任务
- 任务进行中显示消耗趋势：不要求精确到最后一分钱，但要能看出是否进入异常循环
- 预算触顶时优雅降级：保存状态、切换模型或请求用户确认，不要突然丢掉整个任务
- 事后给出可解释账单：哪些步骤最贵、哪些工具产生了大量上下文、哪些重试没有收益
这比单纯说“我们自动优化了 token”更值得信任。用户不一定需要知道每个内部算法，但需要知道 Agent 为什么花钱。
最后
Grok Bot 这次把 token 优化放到公开产品更新里，我觉得是一个很重要的信号：Agent 的下半场不是只比谁更会做事，也要比谁更会控制做事的成本。
一个 Agent 如果只能偶尔完成一次漂亮演示，却让用户不敢把真实工作交给它，它仍然只是 demo。
真正好用的 Agent，应该让人知道它正在做什么、还会花多少、出了问题能不能停在一个可恢复的位置。
省 token 只是手段。让用户敢把任务交给你，才是目的。