Asana 把单次成本砍到 1/76：省钱靠改调用

同一条浏览器工作流，同一个任务，单次成本从 36.21 美元降到 0.47 美元。换模型只贡献了其中一段，更大的一块来自「怎么调用」。

一、发生了什么

OpenAI 在 10 月 9 日发布了一个客户案例：Asana 通过它收购的 StackAI 平台，让客户不写代码就能搭出会浏览网页、填表、收集信息的工作流。这次被拿来开刀的是平台里的浏览器 Agent。

测试任务很具体：从一个公开演示目录里，为 32 本书各收集 6 个字段。这接近一部分客户真实在跑的工作流。

原来的生产配置（文里叫 Model B）跑一次至少 22.5 分钟，预估模型成本至少 36.21 美元，有些运行还没跑完就撞上了步数上限。

优化之后，换成 GPT-6.1 Sol，单次 0.47 美元、约 4 分钟。官方口径是便宜 76 倍、快 5 倍。

两个数字的分母不一样：76 倍比的是最初的 Model B 配置；后面那个 4 倍，比的是已经在 Sol 上优化过一轮的版本。看任何成本案例，第一步都是对准分母。

关键在中间那一步：只改工作流、不换模型，Model B 的单次成本就从 36.21 美元降到 1.24 美元，差了 29 倍。

剩下那段，来自更大的历史预算加上新的缓存与截图策略：在 Sol 上从 1.97 美元降到 0.47 美元，4 倍。其中 89% 的输入命中缓存，缓存价格是未缓存价格的 5%。

研究一共跑了 144 次：120k 和 480k 字符两档历史预算，配 6 种缓存与截图策略，在 4 个模型上各跑 3 次。

顺带一个细节：这项优化本身是 AI 做的。团队让 Codex 里的 GPT-6 Astra 读代码、设计实验、跑对比，原本预计 1 到 2 个月的工作，约 1 周完成。也正因为是它去翻代码，才挖到了「截图每步都变，导致缓存失效」这种不显眼的漏点。

二、跟你有什么关系

写 Agent 的工程师：你的账单大头很可能不是模型单价，是每一步都在重发的历史。先查这个，比换模型有效。

按 token 付费的产品负责人：成本结构决定定价。哪类请求占了支出大头，决定你该优化哪里。

采购 Agent 的人：供应商报价按「次」还是按「token」，差别可能有一个数量级。合同里写清楚计量方式，也要写清楚「一次运行」怎么定义——撞上步数上限算不算一次。

三、怎么用

1. 先量基线。 固定一个任务，记录每次运行的成本、时长、成功率。没有基线，省钱的数字都是别人家的。

1. 查缓存命中。 Asana 原来的问题是：指令和工具定义缓存了，不断增长的页面文本和截图没缓存，每一步都按全价重发。这是最常见的漏点。

1. 让前缀稳定。 缓存命中靠「前面那段不变」。历史每一步都在变，所以要先设计好哪些内容固定、哪些内容滚动。

1. 改截图策略。 他们的做法是让截图累积到 20 张再裁到最近 1 张，两次裁剪之间历史不变，缓存才有机会命中。

1. 最后才换模型。 顺序反了，你会以为是模型贵，其实是调用方式贵。

四、三个别信的说法

76 倍是换模型换来的。 不换模型已经省了 29 倍。剩下从 1.24 美元到 0.47 美元那一段，是换模型加缓存策略合起来的效果，不能全记在模型头上。把功劳记错，下次换一家还是会贵。

缓存就是把 prompt 存起来。 缓存要求前缀逐字节一致。截图和页面文本每步都变，不重新设计历史结构，缓存命中率上不去。

成本降了，质量一定降。 这次研究里，优化后的工作流每次都完成了任务并给出正确答案；历史预算小的配置，18 次运行只有 3 次产出答案。但样本只有 32 本书、6 个字段，换成你家的网页，结论要重测。

还有一句要说清楚：案例由 OpenAI 发布，用的也是 OpenAI 的模型，比较对象是匿名竞品。数字可信，选型结论仍要自己验。

这三个说法之所以流行，是因为它们都能省掉测量这一步。测量很枯燥，但 76 倍这种数字，只有在自己的任务上重算一遍，才知道能落下多少。

五、一句话结论

先把调用方式修好，再考虑换模型；顺序反了，钱要花两遍。

信息来源

1. Asana cuts model costs 76x in browser tests with GPT-6.1 Sol，OpenAI 客户案例，2026-10-09

功能与价格以官方公告为准。本文写于 2026 年 10 月 18 日。