编程 Agent 的额度，其实是一种 SLA
#博客更新
先说结论
编程 Agent 的额度，我越来越倾向于把它当成一种 SLA，而不是订阅页面上的赠品。
因为聊天产品被限流时，用户通常只是晚一点得到一个回答；编程 Agent 被限流时，可能正好停在：
● 已经改了几个文件，但还没跑完测试
● 子 Agent 已经启动，但主任务还没有汇总
● 上下文压缩刚做完，下一步还没执行
● 一次部署正在等待最后一个检查
这时候额度变化不是“少聊几句”，而是直接影响任务的连续性和恢复成本。
最近 OKP 记录了 Anthropic 和 OpenAI 编程产品在同一时间窗口里的额度讨论：Anthropic 侧的公开信息涉及 Claude Code 周额度从临时增加调整为较小的永久增加；OpenAI 侧则出现了“重置付费用量、优化 token 消耗”的公开公告和社区解读。社区把它概括成“额度暗砍”和“重置更耐用”，讨论热度很高。
这里必须区分三层事实：
1. 厂商正式公布的政策
2. 社区根据账户体感做出的观察
3. 用户自己在某个模型、套餐和时间窗口里的实测
这三层不能混成一句“某家把额度砍了”。但它们共同说明了一个问题：Agent 的容量边界已经是产品契约的一部分。
价格和额度不是一回事
很多产品页面只展示月费和模型名称，用户却真正受到下面这些变量影响：
一个“很便宜但经常在长任务中途停下”的 Agent，实际成本可能高于一个单价更高、但一次能完成任务的 Agent。
为什么编程任务特别依赖连续性
编程 Agent 不是只返回一段文字。它通常维护一条执行链：
每一步都可能触发新的模型请求和工具调用。额度在这条链中间耗尽，会留下一个不完整但已经产生副作用的现场。
从用户角度看，真正关心的不是“今天还能发送多少条消息”，而是：
● 这个任务还能不能完成
● 被打断后恢复要不要重新解释
● 已经改动的文件是否能安全保留
● 额度恢复前我能不能继续做别的任务
● 有没有明确的剩余容量提示
所以编程 Agent 的用量指标应该更接近任务维度，而不是消息维度。
我会定义哪些容量指标
1. 可用请求预算
不是总 token 数，而是当前时间窗口还能发起多少次有效模型请求。工具调用、重试和子 Agent 都应该计入。
2. 上下文预算
同样一个模型，在短会话和长会话中的成本完全不同。需要区分：
● 当前输入 token
● 输出 token
● cache hit / miss
● 压缩或历史重建产生的额外输入
● 子 Agent 是否重复携带上下文
Claude Code 官方文档已经提供
3. 时间窗口
“每周额度”太粗了。实际产品至少应该说明：
● 五小时窗口如何计算
● 周窗口何时重置
● 多设备是否共享
● 聊天、Cowork 和 Code 是否共享
● 失败请求是否占用额度
● 重置是否立即生效
4. 连续任务保证
这是最容易被忽略的指标。一个任务如果已经开始执行，额度不足时产品应该有明确策略：
直接返回一个模糊的“达到限制”并丢掉上下文，是最差的处理方式。
5. 资源归属
如果一个主 Agent 开了三个子 Agent，额度应该能回答：
否则用户看到的总数无法指导下一次决策。
额度变化为什么会伤信任
价格调整至少是一个容易理解的数字：每月从 20 变成 25。额度调整更难，因为用户要通过长时间使用才能发现变化。
最伤信任的不是额度少，而是这几种不确定：
● 页面写着“无限”，但长任务会在不透明的地方停下
● 同一个任务今天能完成，明天突然只做到一半
● 额度条跳动，但没有解释是输入、输出、重试还是并发造成的
● 重置时间和用户看到的时间不一致
● 失败请求是否扣费没有说明
编程 Agent 的用户本身就在把真实工作交给系统。他们会容忍模型偶尔犯错，但很难接受容量边界不可预测。
如果是我来做 Agent 产品
我会把额度设计成一个可观察、可恢复的状态机，而不是一个藏在后端的计数器：
具体做法是：
1. 任务开始时估算一个区间，不假装精确
2. 接近阈值时提前提醒，而不是等请求失败
3. 保留最近一次可恢复 checkpoint
4. 把备用模型和备用 provider 当成正式路径
5. 记录每次 fallback 的原因和额外成本
6. 额度耗尽时保留任务状态、已改文件和待办步骤
7. 让用户能看到 reset 时间和当前任务的预计消耗
这和我们在做 Pi/cohub 时关注的事情是一致的：Agent 不是一次回答，而是一段可能持续很久的工作。工作系统必须知道自己何时应该继续，何时应该停下来等人。
用户自己能做什么
在服务商策略无法改变时，我会采用几条保守策略：
把长任务拆成可恢复阶段
不要让一个会话同时负责分析、实现、测试和部署。每个阶段写出明确产物，下一阶段从文件和 checkpoint 接着走。
给强模型留预算
机械搜索、格式修改、简单测试可以用便宜模型；设计方案、跨文件重构和最终审查留给强模型。关键不是永远用最强模型，而是不要在低价值步骤把预算消耗完。
记录自己的任务成本
我会记录：
一两周之后，才能知道自己真正买的不是“多少 token”，而是多少个完成的任务。
预留故障转移路径
如果一个模型或 provider 是唯一入口，额度一变，整个工作流就会被带走。能接 OpenAI 兼容接口、能保留 transcript、能切换模型的 Agent，抗波动能力会更好。
本地模型也有额度
本地部署看起来没有服务商 quota，但它有自己的容量边界：
● 显存和系统内存
● 磁盘吞吐
● 并发 slot
● 温度和功耗
● 长上下文的速度衰减
● 模型加载和切换时间
我上一篇写 Qwen3.8-Flash-Next 时就提到过：模型“能加载”不等于“能生产”。本地 Agent 的内存和吞吐其实也是一种 SLA，只是承诺方从云服务商变成了自己的机器和推理后端。
最后
编程 Agent 的额度不是一个抽象的套餐数字。它决定了一个正在修改真实代码的系统能不能把事情做完。
所以我希望未来的 Agent 产品页面少写一点“无限”，多写几件更有用的事：
● 一个任务大概能跑多久
● 额度在什么情况下会消耗
● 接近上限时会怎么处理
● 中断后能不能恢复
● 备用路径是什么
SLA 的核心不是承诺永远不出问题，而是出问题时边界清楚、状态保留、用户知道下一步该怎么办。
这对编程 Agent 尤其重要。
参考资料
● Anthropic：Manage costs effectively
● OKP：Anthropic 与 OpenAI 编程模型额度政策
● OKP：ChatGPT 停机与 Codex 用户迁移讨论
● OKP：Codex 生态持续扩张
● 模型发布只是开始：Qwen3.8-Flash-Next 与 runtime
via 棒无
#博客更新
先说结论
编程 Agent 的额度，我越来越倾向于把它当成一种 SLA，而不是订阅页面上的赠品。
因为聊天产品被限流时，用户通常只是晚一点得到一个回答；编程 Agent 被限流时，可能正好停在：
● 已经改了几个文件，但还没跑完测试
● 子 Agent 已经启动，但主任务还没有汇总
● 上下文压缩刚做完，下一步还没执行
● 一次部署正在等待最后一个检查
这时候额度变化不是“少聊几句”，而是直接影响任务的连续性和恢复成本。
最近 OKP 记录了 Anthropic 和 OpenAI 编程产品在同一时间窗口里的额度讨论：Anthropic 侧的公开信息涉及 Claude Code 周额度从临时增加调整为较小的永久增加；OpenAI 侧则出现了“重置付费用量、优化 token 消耗”的公开公告和社区解读。社区把它概括成“额度暗砍”和“重置更耐用”，讨论热度很高。
这里必须区分三层事实：
1. 厂商正式公布的政策
2. 社区根据账户体感做出的观察
3. 用户自己在某个模型、套餐和时间窗口里的实测
这三层不能混成一句“某家把额度砍了”。但它们共同说明了一个问题：Agent 的容量边界已经是产品契约的一部分。
价格和额度不是一回事
很多产品页面只展示月费和模型名称，用户却真正受到下面这些变量影响：
一个“很便宜但经常在长任务中途停下”的 Agent，实际成本可能高于一个单价更高、但一次能完成任务的 Agent。
为什么编程任务特别依赖连续性
编程 Agent 不是只返回一段文字。它通常维护一条执行链：
理解需求
→ 定位代码
→ 制定计划
→ 修改文件
→ 运行测试
→ 读取错误
→ 修复
→ 再测试
→ 汇总结果
每一步都可能触发新的模型请求和工具调用。额度在这条链中间耗尽，会留下一个不完整但已经产生副作用的现场。
从用户角度看，真正关心的不是“今天还能发送多少条消息”，而是：
● 这个任务还能不能完成
● 被打断后恢复要不要重新解释
● 已经改动的文件是否能安全保留
● 额度恢复前我能不能继续做别的任务
● 有没有明确的剩余容量提示
所以编程 Agent 的用量指标应该更接近任务维度，而不是消息维度。
我会定义哪些容量指标
1. 可用请求预算
不是总 token 数，而是当前时间窗口还能发起多少次有效模型请求。工具调用、重试和子 Agent 都应该计入。
2. 上下文预算
同样一个模型，在短会话和长会话中的成本完全不同。需要区分：
● 当前输入 token
● 输出 token
● cache hit / miss
● 压缩或历史重建产生的额外输入
● 子 Agent 是否重复携带上下文
Claude Code 官方文档已经提供
/usage、prompt cache、团队 spend limit 和 OpenTelemetry 等用量观察手段。这个方向是对的：用户至少要能知道容量花在哪里。3. 时间窗口
“每周额度”太粗了。实际产品至少应该说明：
● 五小时窗口如何计算
● 周窗口何时重置
● 多设备是否共享
● 聊天、Cowork 和 Code 是否共享
● 失败请求是否占用额度
● 重置是否立即生效
4. 连续任务保证
这是最容易被忽略的指标。一个任务如果已经开始执行，额度不足时产品应该有明确策略：
继续当前任务
或切换备用模型
或保存 checkpoint 后暂停
或请求用户补充额度
直接返回一个模糊的“达到限制”并丢掉上下文，是最差的处理方式。
5. 资源归属
如果一个主 Agent 开了三个子 Agent，额度应该能回答：
主任务用了多少
子任务 A 用了多少
重试用了多少
哪个工具产生了最多上下文
否则用户看到的总数无法指导下一次决策。
额度变化为什么会伤信任
价格调整至少是一个容易理解的数字：每月从 20 变成 25。额度调整更难，因为用户要通过长时间使用才能发现变化。
最伤信任的不是额度少，而是这几种不确定：
● 页面写着“无限”，但长任务会在不透明的地方停下
● 同一个任务今天能完成，明天突然只做到一半
● 额度条跳动，但没有解释是输入、输出、重试还是并发造成的
● 重置时间和用户看到的时间不一致
● 失败请求是否扣费没有说明
编程 Agent 的用户本身就在把真实工作交给系统。他们会容忍模型偶尔犯错，但很难接受容量边界不可预测。
如果是我来做 Agent 产品
我会把额度设计成一个可观察、可恢复的状态机，而不是一个藏在后端的计数器：
┌──────────────┐
│ task running │
└──────┬───────┘
│ budget low
┌──────▼───────┐
│ warn user │
└──┬─────┬─────┘
│ │
┌────────▼┐ ┌─▼──────────┐
│ fallback │ │ checkpoint │
│ model │ │ and pause │
└────┬─────┘ └─────┬──────┘
│ │
└──────┬───────┘
▼
task continues
具体做法是：
1. 任务开始时估算一个区间，不假装精确
2. 接近阈值时提前提醒，而不是等请求失败
3. 保留最近一次可恢复 checkpoint
4. 把备用模型和备用 provider 当成正式路径
5. 记录每次 fallback 的原因和额外成本
6. 额度耗尽时保留任务状态、已改文件和待办步骤
7. 让用户能看到 reset 时间和当前任务的预计消耗
这和我们在做 Pi/cohub 时关注的事情是一致的：Agent 不是一次回答，而是一段可能持续很久的工作。工作系统必须知道自己何时应该继续，何时应该停下来等人。
用户自己能做什么
在服务商策略无法改变时，我会采用几条保守策略：
把长任务拆成可恢复阶段
不要让一个会话同时负责分析、实现、测试和部署。每个阶段写出明确产物，下一阶段从文件和 checkpoint 接着走。
给强模型留预算
机械搜索、格式修改、简单测试可以用便宜模型；设计方案、跨文件重构和最终审查留给强模型。关键不是永远用最强模型，而是不要在低价值步骤把预算消耗完。
记录自己的任务成本
我会记录：
任务名称
开始/结束时间
模型
请求次数
是否发生压缩
是否发生重试
最终是否完成
一两周之后，才能知道自己真正买的不是“多少 token”，而是多少个完成的任务。
预留故障转移路径
如果一个模型或 provider 是唯一入口，额度一变，整个工作流就会被带走。能接 OpenAI 兼容接口、能保留 transcript、能切换模型的 Agent，抗波动能力会更好。
本地模型也有额度
本地部署看起来没有服务商 quota，但它有自己的容量边界：
● 显存和系统内存
● 磁盘吞吐
● 并发 slot
● 温度和功耗
● 长上下文的速度衰减
● 模型加载和切换时间
我上一篇写 Qwen3.8-Flash-Next 时就提到过：模型“能加载”不等于“能生产”。本地 Agent 的内存和吞吐其实也是一种 SLA，只是承诺方从云服务商变成了自己的机器和推理后端。
最后
编程 Agent 的额度不是一个抽象的套餐数字。它决定了一个正在修改真实代码的系统能不能把事情做完。
所以我希望未来的 Agent 产品页面少写一点“无限”，多写几件更有用的事：
● 一个任务大概能跑多久
● 额度在什么情况下会消耗
● 接近上限时会怎么处理
● 中断后能不能恢复
● 备用路径是什么
SLA 的核心不是承诺永远不出问题，而是出问题时边界清楚、状态保留、用户知道下一步该怎么办。
这对编程 Agent 尤其重要。
参考资料
● Anthropic：Manage costs effectively
● OKP：Anthropic 与 OpenAI 编程模型额度政策
● OKP：ChatGPT 停机与 Codex 用户迁移讨论
● OKP：Codex 生态持续扩张
● 模型发布只是开始：Qwen3.8-Flash-Next 与 runtime
via 棒无
Claude Code Docs
Manage costs effectively - Claude Code Docs
Track token usage, set team spend limits, and reduce Claude Code costs with context management, model selection, extended thinking settings, and preprocessing hooks.
Agent 开始自己省 token：Grok Bot 的成本优化意味着什么
#博客更新
先说结论
Agent 产品开始主动宣传“自动省 token”，说明一个变化：token 成本已经从后台指标，变成了用户能感知的产品功能。
9 月 1 日，Grok Bot 的官方更新里连续出现两条相关信息：一条是
这里要先说清楚：官方目前公布的是“即将加入自动优化”的方向，没有给出统一的节省比例、具体算法或所有任务上的成本承诺。所以这篇不是 Grok Bot 的节省效果评测，而是想回答一个更实际的问题：
Agent 的账单不是一次请求
普通聊天产品的成本大致是一问一答：
Agent 完成一个任务时，通常是这样：
如果第
真正让账单变大的，往往不是某一个回答特别长，而是请求次数和重复上下文太多。
一个看起来只需要“改一个按钮”的任务，可能包含：
● 每一轮都重新发送项目规则
● 工具返回完整日志，而不是摘要
● 模型反复读取同一个大文件
● 截图或网页状态被当成高 token 的视觉输入
● 失败后没有明确停止条件
● 多个子 Agent 各自携带一份重复上下文
所以 Agent 的成本优化不能只做成一个“换小模型”的开关。
Grok Bot 的信号为什么值得看
Grok Bot 不是单纯的聊天框。它被描述成拥有自己的电脑，可以进入 Gmail、Salesforce、LinkedIn 等服务执行任务。这样的 Agent 一旦进入重度使用阶段，token 消耗会和任务链路绑定：
早期产品最容易宣传“它能做什么”；到了用户真的拿它跑工作之后，问题会变成：
● 这个任务大概花多少钱
● 为什么同样的任务今天比昨天贵
● Agent 是不是在重复读相同内容
● 失败重试有没有上限
● 我能不能在任务中途切换到更便宜的模型
“自动 token optimization”回应的其实是这些问题，而不只是模型推理速度。
成本优化应该分五层
第一层：不要重复发送不变的东西
最简单、收益通常也最稳定的是上下文去重：
● system prompt 保持稳定，尽量命中 prompt cache
● 项目规则按需加载，不要每一轮全文拼接
● 工具结果只保留模型真正需要的字段
● 同一文件的内容在一个 turn 内复用，不要重复读取
这层优化不改变模型能力，只减少重复搬运。
第二层：让工具返回“可用结果”
很多 Agent 贵，不是模型太爱思考，而是工具返回了太多原始材料。
例如一个 shell 工具可以返回 2 万行日志，也可以返回：
原始日志应该保存在可追溯的外部记录里，模型上下文只拿摘要和定位信息。这样既省 token，也让模型更容易抓住真正的错误。
第三层：不同阶段用不同模型
不是所有步骤都需要同一档模型：
这里有一个重要前提：切换模型不能让上下文重新完整上传一遍，否则省下来的输出费用可能被输入费用吃掉。
第四层：给循环设置预算
Agent 的循环应该有明确的预算，而不是“直到模型觉得完成了”。
达到预算之后，不一定要直接失败。可以按任务类型选择：
● 保存当前状态，等待用户继续
● 切换到便宜模型做收尾
● 只执行验证，不再扩展范围
● 给用户展示目前完成了什么、还差什么
第五层：把成本变成可观察数据
“感觉今天很贵”不是可调试的指标。至少要记录：
● 每个任务的总 token 和总费用
● 每一步的输入/输出/cache 命中
● 工具调用次数和工具结果大小
● 重试次数
● 每个模型在任务中的占比
● 成功任务的单位成本
● 失败任务已经消耗的成本
我会特别关注两个数字：
前者告诉你系统完成一件事要付出什么，后者告诉你用户在 Agent 还没完成之前已经被消耗了多少预算。
“省 token”不能变成“少做工作”
成本优化有一个很容易踩的坑：把任务结果变差，换成账单变好。
例如：
● 过度压缩工具结果，丢掉关键错误
● 为了少发请求，跳过验证步骤
● 强行缩短上下文，让模型重新猜项目背景
● 在复杂任务中途切到小模型，导致返工
● 把多次尝试隐藏掉，让用户看不到实际成本
所以优化目标不应该是：
而应该更接近：
也就是在完成率、安全性和可恢复性不下降的前提下，减少成本。
云端 Agent 和本地 Agent 的成本不一样
Grok Bot 这类云端 Agent 主要面对的是服务端 token 成本和用户套餐成本。Pi/cohub 这类运行时还要考虑另一种成本：
● 云端 API token
● 浏览器/容器运行时间
● 文件存储和日志保留
● 多 Agent 并发
● 本地模型的显存、内存和电力
本地模型看起来没有 API 账单，但“把一个 100GB 模型留在内存里跑一整天”也不是零成本。只是成本从按 token 计费，换成了固定设备成本和吞吐成本。
因此我不太相信一个统一的“每百万 token 多少钱”能够描述 Agent 的真实价格。更合理的单位可能是：
从产品角度，我会怎么做
如果我要给 Agent 加成本控制，不会只在设置页放一个 slider。我会做四件事：
1. 任务开始前给区间估算：告诉用户这是短任务、长任务还是可能持续运行的任务
2. 任务进行中显示消耗趋势：不要求精确到最后一分钱，但要能看出是否进入异常循环
3. 预算触顶时优雅降级：保存状态、切换模型或请求用户确认，不要突然丢掉整个任务
4. 事后给出可解释账单：哪些步骤最贵、哪些工具产生了大量上下文、哪些重试没有收益
这比单纯说“我们自动优化了 token”更值得信任。用户不一定需要知道每个内部算法，但需要知道 Agent 为什么花钱。
最后
Grok Bot 这次把 token 优化放到公开产品更新里，我觉得是一个很重要的信号：Agent 的下半场不是只比谁更会做事，也要比谁更会控制做事的成本。
一个 Agent 如果只能偶尔完成一次漂亮演示，却让用户不敢把真实工作交给它，它仍然只是 demo。
真正好用的 Agent，应该让人知道它正在做什么、还会花多少、出了问题能不能停在一个可恢复的位置。
省 token 只是手段。让用户敢把任务交给你，才是目的。
参考资料
● Grok Bot：OKP 最新产品更新与 token 优化信号
● Grok Bot 产品页
● 模型的新货架：从 Grok 4.6 上架 Pi 说起
● Anthropic：Manage costs effectively
via 棒无
#博客更新
先说结论
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_task
cost_before_user_abandonment
前者告诉你系统完成一件事要付出什么，后者告诉你用户在 Agent 还没完成之前已经被消耗了多少预算。
“省 token”不能变成“少做工作”
成本优化有一个很容易踩的坑：把任务结果变差，换成账单变好。
例如：
● 过度压缩工具结果，丢掉关键错误
● 为了少发请求，跳过验证步骤
● 强行缩短上下文，让模型重新猜项目背景
● 在复杂任务中途切到小模型，导致返工
● 把多次尝试隐藏掉，让用户看不到实际成本
所以优化目标不应该是：
minimize tokens
而应该更接近：
minimize cost
subject to successful completion, safety, and recoverability
也就是在完成率、安全性和可恢复性不下降的前提下，减少成本。
云端 Agent 和本地 Agent 的成本不一样
Grok Bot 这类云端 Agent 主要面对的是服务端 token 成本和用户套餐成本。Pi/cohub 这类运行时还要考虑另一种成本：
● 云端 API token
● 浏览器/容器运行时间
● 文件存储和日志保留
● 多 Agent 并发
● 本地模型的显存、内存和电力
本地模型看起来没有 API 账单，但“把一个 100GB 模型留在内存里跑一整天”也不是零成本。只是成本从按 token 计费，换成了固定设备成本和吞吐成本。
因此我不太相信一个统一的“每百万 token 多少钱”能够描述 Agent 的真实价格。更合理的单位可能是：
每个成功任务的成本
每个有效工具动作的成本
每个可恢复工作小时的成本
从产品角度，我会怎么做
如果我要给 Agent 加成本控制，不会只在设置页放一个 slider。我会做四件事：
1. 任务开始前给区间估算：告诉用户这是短任务、长任务还是可能持续运行的任务
2. 任务进行中显示消耗趋势：不要求精确到最后一分钱，但要能看出是否进入异常循环
3. 预算触顶时优雅降级：保存状态、切换模型或请求用户确认，不要突然丢掉整个任务
4. 事后给出可解释账单：哪些步骤最贵、哪些工具产生了大量上下文、哪些重试没有收益
这比单纯说“我们自动优化了 token”更值得信任。用户不一定需要知道每个内部算法，但需要知道 Agent 为什么花钱。
最后
Grok Bot 这次把 token 优化放到公开产品更新里，我觉得是一个很重要的信号：Agent 的下半场不是只比谁更会做事，也要比谁更会控制做事的成本。
一个 Agent 如果只能偶尔完成一次漂亮演示，却让用户不敢把真实工作交给它，它仍然只是 demo。
真正好用的 Agent，应该让人知道它正在做什么、还会花多少、出了问题能不能停在一个可恢复的位置。
省 token 只是手段。让用户敢把任务交给你，才是目的。
参考资料
● Grok Bot：OKP 最新产品更新与 token 优化信号
● Grok Bot 产品页
● 模型的新货架：从 Grok 4.6 上架 Pi 说起
● Anthropic：Manage costs effectively
via 棒无
当视频模型开始生成界面：Runway Solaris 观察
#博客更新
先说结论
8 月 31 日，Runway 发布了 Solaris 研究预览，并把它称为 Interface World Model。
官方描述很大胆：这不是一个普通的视频生成器，而是一种新型“操作系统”，窗口、菜单、滑杆等界面由视频模型实时生成，方向包括场景化视频、游戏界面、创意工具和产品原型。
我对这件事的判断是：如果 Solaris 的可操作性能够成立，它改变的不是“视频能生成得更漂亮”，而是界面本身可能不再是预先写好的组件集合。
但现在还不能把它写成成熟产品。当前公开信号主要来自 Runway 官方账号和一个 X List 旁证，公测资格、API、状态持久化和独立测试都没有明确资料。下面是方向分析，不是能力评测。
过去的界面是什么样的
我们熟悉的软件界面有一个稳定假设：
一个按钮是一个 DOM 节点，一个滑杆有明确的数值，一个菜单项对应一条路由。即使界面由游戏引擎或 Canvas 绘制，背后通常仍然有一套确定的 UI 状态机。
传统的生成式 AI 主要生成的是内容：
它可以生成一个看起来像软件的画面，但这个画面通常只是结果，不是一个可以持续操作、保存状态、撤销和再次打开的应用。
Solaris 想挑战的是中间那条边界：
如果这条循环稳定，界面就不再只是“渲染数据”，而变成了模型对世界状态的一种实时投影。
它和 GUI Agent 不是一回事
最近也有很多 GUI Agent：模型看屏幕，点击按钮，输入文字，拖动鼠标。这些系统通常是在已有界面上行动。
可以这样对比：
所以不能因为两者都“会用界面”，就把 Solaris 当成另一个 computer-use 模型。它更接近：模型不仅使用工作台，还参与生成工作台。
真正困难的不是画出一扇窗
从演示画面看，窗口、菜单和滑杆并不难想象。真正难的是这些东西必须具备软件的性质。
1. 状态要持久
用户拖动滑杆之后，数值应该进入某个可恢复的状态，而不是下一帧又随机回去。
如果状态只存在模型的短期上下文里，它就更像一次互动幻觉，而不是应用。
2. 动作要可重复
同样的点击在同样的状态下，应该产生相同或可解释的结果。视频模型天然带有生成随机性，而软件交互依赖确定性。
这会要求系统把“视觉帧”和“真实状态”分开：
如果没有状态层，用户看到的按钮和系统真正接受的动作可能不是一回事。
3. 界面要能被机器理解
固定 UI 有 DOM、Accessibility Tree、语义标签和键盘焦点。模型生成的界面如果只有像素，接入自动化、辅助功能和测试都会变得困难。
一个真正可用的 Interface World Model，至少需要回答：
● 当前有哪些控件
● 每个控件的语义是什么
● 哪些控件可以操作
● 操作会改变哪些状态
● 屏幕阅读器和键盘如何访问它们
“看起来像按钮”不等于“它是一个按钮”。
4. 延迟必须足够低
普通视频生成可以等几秒甚至几分钟。界面交互不能每次点击都等一段完整视频生成。
用户会期待：
因此 Solaris 更像实时世界模型，而不是离线视频模型。它要解决的不是单次画质，而是连续生成、状态更新和输入响应之间的延迟。
5. 失败要能撤销
固定应用里的错误操作通常可以 undo、回退或重新加载。生成式界面如果把每次状态变化都当成新一帧，就必须有明确的历史：
否则用户很难知道一次错误是模型生成错了，还是自己的操作真的改变了数据。
我会怎样评估它
如果 Solaris 之后开放试用，我不会先截几张好看的图，而会做一套重复性测试。
我尤其关注“同一个任务跑十次”的成功率。生成界面最容易在单次演示里看起来惊艳，真正决定它是不是产品的是第十次还能不能找到同一个按钮。
它可能先在哪些地方成立
游戏
游戏本来就接受动态世界和非固定界面。模型生成一个场景化的控制层，可能比在办公软件里生成表单更自然。但游戏仍然需要物理规则、存档、碰撞和多人同步，视觉生成不能替代底层状态机。
创意工具
创作工具的界面本来就经常围绕当前任务变化。用户在做分镜、调色或构图时，需要的控件不一样，动态生成一个任务专用工作台有实际价值。
产品原型
这是最容易落地的方向：不是直接替代生产软件，而是让用户用自然语言快速得到一个可交互的原型。这里对确定性的要求相对低，但仍然需要能保存和分享。
场景化学习
教学界面、模拟实验和可视化解释也可能受益。模型不只是给一段答案，而是根据用户的理解程度生成一套可以探索的界面。
也要警惕一个误区
“界面由模型生成”不代表界面一定更好。
固定组件的价值就在于稳定、可预测、可测试。动态生成会带来新的成本：
● 用户每次打开都看到不同布局
● 团队无法复用操作教程
● 自动化脚本容易失效
● 产品问题难以复现
● 视觉一致性和品牌规范变复杂
● 安全敏感的操作可能被模型藏在不明显的位置
所以我不期待所有软件都变成生成界面。更现实的形态可能是：稳定的底层状态和权限 + 针对当前任务生成的工作台视图。
最后
Runway Solaris 目前还是研究预览，很多关键问题没有答案。它值得关注，不是因为一条视频里出现了会动的菜单，而是因为它把一个问题摆到了台面上：
现在先等它从演示里出来，给别人真正点几下。
参考资料
● Runway 官方研究页面
● Runway 官方网站
● OKP：Runway 发布 Solaris
● 阿里 Qwen-UI-Agent 信号（相关背景）
via 棒无
#博客更新
先说结论
8 月 31 日，Runway 发布了 Solaris 研究预览，并把它称为 Interface World Model。
官方描述很大胆：这不是一个普通的视频生成器，而是一种新型“操作系统”，窗口、菜单、滑杆等界面由视频模型实时生成，方向包括场景化视频、游戏界面、创意工具和产品原型。
我对这件事的判断是：如果 Solaris 的可操作性能够成立，它改变的不是“视频能生成得更漂亮”，而是界面本身可能不再是预先写好的组件集合。
但现在还不能把它写成成熟产品。当前公开信号主要来自 Runway 官方账号和一个 X List 旁证，公测资格、API、状态持久化和独立测试都没有明确资料。下面是方向分析，不是能力评测。
过去的界面是什么样的
我们熟悉的软件界面有一个稳定假设：
固定组件
+ 固定状态
+ 固定事件处理
+ 固定数据模型
= 可操作应用
一个按钮是一个 DOM 节点，一个滑杆有明确的数值，一个菜单项对应一条路由。即使界面由游戏引擎或 Canvas 绘制，背后通常仍然有一套确定的 UI 状态机。
传统的生成式 AI 主要生成的是内容：
提示词 → 图片 / 视频 / 音频
它可以生成一个看起来像软件的画面，但这个画面通常只是结果，不是一个可以持续操作、保存状态、撤销和再次打开的应用。
Solaris 想挑战的是中间那条边界：
意图
→ 模型生成当前界面
→ 用户动作
→ 模型理解动作后的世界状态
→ 生成下一帧界面
如果这条循环稳定，界面就不再只是“渲染数据”，而变成了模型对世界状态的一种实时投影。
它和 GUI Agent 不是一回事
最近也有很多 GUI Agent：模型看屏幕，点击按钮，输入文字，拖动鼠标。这些系统通常是在已有界面上行动。
可以这样对比：
所以不能因为两者都“会用界面”，就把 Solaris 当成另一个 computer-use 模型。它更接近：模型不仅使用工作台，还参与生成工作台。
真正困难的不是画出一扇窗
从演示画面看，窗口、菜单和滑杆并不难想象。真正难的是这些东西必须具备软件的性质。
1. 状态要持久
用户拖动滑杆之后，数值应该进入某个可恢复的状态，而不是下一帧又随机回去。
动作 A
→ 状态 S1
→ 关闭界面
→ 重新打开
→ 仍然得到 S1
如果状态只存在模型的短期上下文里，它就更像一次互动幻觉，而不是应用。
2. 动作要可重复
同样的点击在同样的状态下，应该产生相同或可解释的结果。视频模型天然带有生成随机性，而软件交互依赖确定性。
这会要求系统把“视觉帧”和“真实状态”分开：
可生成的显示层
↓
可验证的状态层
↓
可执行的动作层
如果没有状态层，用户看到的按钮和系统真正接受的动作可能不是一回事。
3. 界面要能被机器理解
固定 UI 有 DOM、Accessibility Tree、语义标签和键盘焦点。模型生成的界面如果只有像素，接入自动化、辅助功能和测试都会变得困难。
一个真正可用的 Interface World Model，至少需要回答：
● 当前有哪些控件
● 每个控件的语义是什么
● 哪些控件可以操作
● 操作会改变哪些状态
● 屏幕阅读器和键盘如何访问它们
“看起来像按钮”不等于“它是一个按钮”。
4. 延迟必须足够低
普通视频生成可以等几秒甚至几分钟。界面交互不能每次点击都等一段完整视频生成。
用户会期待：
按下按钮
→ 立即看到反馈
→ 状态逐步稳定
因此 Solaris 更像实时世界模型，而不是离线视频模型。它要解决的不是单次画质，而是连续生成、状态更新和输入响应之间的延迟。
5. 失败要能撤销
固定应用里的错误操作通常可以 undo、回退或重新加载。生成式界面如果把每次状态变化都当成新一帧，就必须有明确的历史：
S0 → S1 → S2 → S3
↑
undo / fork
否则用户很难知道一次错误是模型生成错了，还是自己的操作真的改变了数据。
我会怎样评估它
如果 Solaris 之后开放试用，我不会先截几张好看的图，而会做一套重复性测试。
我尤其关注“同一个任务跑十次”的成功率。生成界面最容易在单次演示里看起来惊艳，真正决定它是不是产品的是第十次还能不能找到同一个按钮。
它可能先在哪些地方成立
游戏
游戏本来就接受动态世界和非固定界面。模型生成一个场景化的控制层，可能比在办公软件里生成表单更自然。但游戏仍然需要物理规则、存档、碰撞和多人同步，视觉生成不能替代底层状态机。
创意工具
创作工具的界面本来就经常围绕当前任务变化。用户在做分镜、调色或构图时，需要的控件不一样，动态生成一个任务专用工作台有实际价值。
产品原型
这是最容易落地的方向：不是直接替代生产软件，而是让用户用自然语言快速得到一个可交互的原型。这里对确定性的要求相对低，但仍然需要能保存和分享。
场景化学习
教学界面、模拟实验和可视化解释也可能受益。模型不只是给一段答案，而是根据用户的理解程度生成一套可以探索的界面。
也要警惕一个误区
“界面由模型生成”不代表界面一定更好。
固定组件的价值就在于稳定、可预测、可测试。动态生成会带来新的成本：
● 用户每次打开都看到不同布局
● 团队无法复用操作教程
● 自动化脚本容易失效
● 产品问题难以复现
● 视觉一致性和品牌规范变复杂
● 安全敏感的操作可能被模型藏在不明显的位置
所以我不期待所有软件都变成生成界面。更现实的形态可能是：稳定的底层状态和权限 + 针对当前任务生成的工作台视图。
最后
Runway Solaris 目前还是研究预览，很多关键问题没有答案。它值得关注，不是因为一条视频里出现了会动的菜单，而是因为它把一个问题摆到了台面上：
界面究竟是程序的固定外壳，还是模型理解世界后生成的一种临时视图？我暂时不会把它叫作“下一个操作系统”。但如果它能把生成画面、真实状态、语义操作和持久化历史接在一起，那它可能会成为一种新的软件入口。
现在先等它从演示里出来，给别人真正点几下。
参考资料
● Runway 官方研究页面
● Runway 官方网站
● OKP：Runway 发布 Solaris
● 阿里 Qwen-UI-Agent 信号（相关背景）
via 棒无
Runway
AI Video Research & Innovation | Runway AI
Explore Runway's AI research in video generation, world models and generative AI. Read about Gen-4, Aleph, Act-Two and our latest breakthroughs.
