任务没变，账单为什么越跑越贵？
让 AI 打开商品目录、收集价格、整理成表，看起来是在不断往前走。可它每做一步，都可能重新读一遍之前的网页和截图。历史越长，重复读取越多；如果为了省空间频繁删改历史，还可能让原本便宜的缓存失效。
Asana 最近公布的浏览器 Agent 研究，值得看的正是这个矛盾：删掉一些内容，不一定更便宜；保留更多内容，也不一定更贵。 关键在于下一次请求有多少信息需要重新计算，以及任务是否真的做完。
这篇独立分析拆开研究的比较口径，再给出一套团队能用来审视账单和结果的方法。它不是 Onevium 的性能测试，也不承诺同样的降本幅度。
先把“76 倍”拆开
Asana 工程文章于 2026 年 10 月 8 日发布，OpenAI 案例于 10 月 9 日介绍了这项工作。研究在一个演示书店任务上比较了不同模型、历史容量和截图保留策略。
最醒目的“76 倍”比较了旧模型的原始配置与新模型的优化配置。它同时改变了流程和模型，不能被解释为换模型本身带来的收益。完整报告还给出同一模型内部的比较：Model B 的流程优化约为 29 倍；Sol 在相同较大历史预算下约为 4 倍。
这带来一个实际的采购问题：你的账单主要来自模型单价，还是来自反复发送相同材料、重复浏览和失败重试？如果没有拆开这些因素，换成便宜模型之后，仍可能因为做了更多步骤而花得更多。
缓存像读书时留下的书签
可以把一次请求想成一摞按顺序排列的材料：工作规则、最初的任务、第一页观察、第二页观察，以及刚拿到的新信息。缓存能够复用前面已经处理过且没有变化的部分。
下面是原创示意，不代表某个 API 的真实字段：
上次：规则 → 任务 → 页面 A → 页面 B
本次：规则 → 任务 → 页面 A → 页面 B → 页面 C
前面的材料保持不变
若删改页面 A 中的截图：
本次：规则 → 任务 → 页面 A′ → 页面 B → 页面 C
从这里开始，旧的连续前缀被打断
因此，“每轮只保留最新截图”有两个方向的影响：请求可能变短，复用的历史也可能变少。判断是否划算，需要同时看这两项，而不能只看发送的总长度。
这也解释了为什么缓存开关不是万能按钮。系统若一边写缓存，一边不断改写早先内容，就可能花了写入成本，却很少读到已有缓存。实际缓存规则、有效期和计费由所用服务决定，不能把一家服务的参数复制给所有模型。
少发一点与少做一遍，是两笔不同的账
假设一个虚构的采购助手要比较 12 个产品。它读到第 9 个时，前几个产品的价格已经被裁掉，于是又打开旧页面。即使每次调用便宜一些，重复访问也增加了模型调用、浏览器时间和失败机会。
反过来，什么都保留也有代价：无关页面、重复截图和走错路的记录会越积越多。一个陷入循环的 Agent，不能靠无限扩大历史容量来救。
团队可以分开记录三种成本：
| 观察项 | 要回答的问题 |
|---|---|
| 单次模型调用 | 哪些输入按原价、缓存写入价或读取价计费？ |
| 一次完整任务 | 总共调用多少次，有没有重复访问和重试？ |
| 一份可交付结果 | 人要补多少内容、复核多久，失败是否重新跑？ |
总 token 数只是其中一个观察量。对业务来说，更有用的是“得到一份合格结果，总共花了多少”。
读到信息，不等于交付了要求的结果
完整研究报告把“看到所需事实”“保留事实”“给出答案”和“总价算对”分别统计。报告指出，Sol 的回答给出了总价及部分摘要，没有交出任务所要求的完整表格。研究也说明最终答案调优不在其范围内。
这不否定缓存优化的工程价值，但提醒我们别把读取成功直接当成交付成功。一个采购团队通常需要逐项价格、来源与计算过程，仅有一个正确总数仍然难以复核。
在前面的虚构采购任务里，可以先写下验收条件：12 个产品不能缺项；每行包含名称、规格、币种、价格和来源；缺失值明确标出；不同币种不直接相加；总价能由明细重算。只有满足这些要求的输出，才进入成本比较。
这是本文提出的业务验收方法，不是对原研究做过的独立复现实验。
下一次试验，只改变一件事
如果你负责 Agent 系统，先固定任务、输入、模型和答案标准，再比较历史策略。不要同时换模型、改提示词、扩大预算，最后把所有收益归给其中一个动作。
一个可执行的试验计划是：
- 选一个可重复、已有参考答案的非敏感任务，保留原配置结果。
- 增加每次调用的用量记录，区分普通输入、缓存读取、服务确实提供的缓存写入及输出；缺失字段标为未知。
- 只调整一种历史保留策略，保留请求顺序与裁剪发生的位置。
- 重复运行，逐次记录完成情况、最终产物、耗时、模型费用与人工返工。
- 检查失败和最差的一次，再决定是否扩大使用。
预算与停止条件同时保留：超过约定费用、持续重复访问、无法核对来源时，停止并交给人处理。不要为了让缓存曲线好看，放任任务无限运行。
如果你使用的是成品 AI 工具，没有这些底层设置，可以要求保留逐项证据、明确交付格式并记录返工。不要照着研究去寻找产品里并不存在的缓存开关。
对“便宜了多少”，还应追问什么
研究覆盖一个 Agent 架构和一个任务，单个条件只有少量重复；最优配置是在比较后选出的。不同模型的阶段和协议也有差别。因此，这些结果支持进一步试验，不是所有业务任务的效果保证。
读类似案例时，用这四个问题筛掉误读：
- 比的是同一个模型，还是连模型一起换了？
- 便宜的运行是否完成了同样的交付要求？
- 费用是模型用量估算，还是包含浏览器、服务器和人工的总成本？
- 优势来自多数重复运行，还是挑出来最好的一次？
最后一个问题尤其影响预算。平均表现适合观察趋势，失败概率和最坏成本决定你是否能放心让任务无人值守。
团队真正该带走的判断
这项研究把注意力从“哪个模型更便宜”推进到了“整段工作是怎样执行的”。模型单价、历史管理、重复劳动和交付质量需要一起看。
先拿一个反复执行的小任务，保存输入和输出，写好合格标准，再开始比账单。使用 Onevium 的团队可以把任务材料与输出留在项目中供复核；本文并不声称 Onevium 提供研究里的底层缓存配置。相关操作见文件与结果检查。