GPT-6.1 Sol 的 76x Browser-Agent 结果：Asana 究竟测量了什么

Asana 于 2026 年 10 月 8 日发布了一项浏览器代理成本研究，GPT-6.1 Sol 的开发者第二天写了一篇报道，标题为“Asana 在浏览器测试中将模型成本降低 76 倍，使用 GPT-6.1 Sol。”这个 76 倍从有人实际测量过的意义上说是真实的，但它不是关于 GPT-6.1 Sol 价格的事实。它是关于当你修复浏览器代理上损坏的提示缓存，然后更换其背后的模型时会发生什么的事实。同样的优化在 Asana 已经投入生产的模型上运行——它称之为 Model B——本身就使成本降低了 29 倍。GPT-6.1 Sol 提供了剩下的 2.6 倍。这些实验由在 Codex 中工作的 GPT-6 Astra 运行，而基线背后的模型是竞争对手的模型，Asana 称之为 Model B，因此同一供应商的两个层级和一个未具名的竞争对手都出现在这个故事中。接下来要区分的是：结果中哪部分是你周一就能照搬的，哪部分属于 Asana 的特定技术栈。

精确表述的比较

Asana 在这方面的技术栈是 StackAI——它收购的工作流自动化平台——运行着一个浏览器代理，无需代码即可浏览网站、填写表单并收集信息。测试任务范围窄而具体：从公开的演示目录中为 32 本书各收集六个字段。这代表了部分客户实际运行的任务，而且规模也足够小，144 次运行的研究一周内就能完成。

设计是六种缓存和截图策略、两种历史预算，每种条件三次运行，跨四个模型——共 144 次运行，外加一次 12 次运行的后续测试。成本根据每个提供商自己的 token 计数器计算，每个答案都对照独立准备的参考答案评分。四个模型是三个未命名的前沿模型（模型 A、B 和 C）以及 GPT-6.1 Sol。模型 A 是来自另一家实验室的更小、更便宜的模型，于 2025 年秋季发布，定价是 GPT-6.1 Sol 的一半。模型 B 是当时投入生产的模型，与 A 来自同一实验室，于 2026 年夏季发布，定价与 GPT-6.1 Sol 相同。模型 C 是模型 B 的更新版本，于 2026 年秋季发布，定价也与 GPT-6.1 Sol 相同。这三者在两份报告中都未具名，因此读者无法复现这一比较——在你把 29 倍当作关于别人模型的数字之前，这一点值得了解。这些是 Asana 和 OpenAI 公布的数据，而非经过独立审计的数据。

成果阶梯，全部是 Asana 自己的数字：

• 在 Model B 上的基线生产 — 每次运行至少 $36.21，每次运行至少 22.5 分钟。部分基线运行在完成前就达到了步数上限，因此该均值只是下限，而非真正的平均值。

• Model B，优化后的智能体——每次运行 $1.24，比基线快 4 倍，成本降低 29 倍。

• GPT-6.1 Sol，同一个优化后的智能体——每次运行 $0.47，约四分钟，成本降低 76 倍，速度提升 5 倍。

• GPT-6.1 Sol，修复前后对比——每次运行从 $1.97 降至 $0.47，仅靠缓存和修剪更改就减少了 4 倍。

由于基线是一个下界，76x 本身就是一个下限。诚实的解读是“至少 76x”，而不是“76x”。

实际发生了什么变化，以及为什么这不是模型功能

该机制是提示缓存的运作原理，值得理解，因为它可以迁移到你在任何模型上运行的任何智能体。浏览器智能体在每次模型调用时都会重新发送其工具、系统提示以及不断增长的页面文本和截图历史记录。提示缓存会对重复部分提供折扣，但仅针对最长的未变前缀——一旦请求中间的任何内容发生变化，复用就会从该点起失效。

Asana 的生产智能体有两个相互叠加的缺陷。它缓存了固定的指令和工具定义，却没有缓存浏览历史。而且它几乎每一步都会编辑这段历史：每次都丢弃上一张截图，并裁剪较早的文本以适应历史预算。每一次编辑都会使前缀失效，因此即便开启了缓存也几乎毫无用处。Asana 的文章指出，在所测试的模型上，缓存读取的成本是标准输入价格的 0.05 倍到 0.1 倍——所以回报很大，而这个智能体却在系统性地拒绝它。

这个修复分为两部分。首先，也要把历史缓存起来，并在最新的工具结果上放置缓存标记。其次，不要每次调用都修改它：保留截图，并按 20:1 的比例分批清理，这样智能体最多保留 20 张，然后再缩减到最近的一张。之后大约连续 19 次调用都会复用未更改的前缀。将历史预算从 120,000 个字符提高到 480,000 个字符，这样旧文本就不再被裁剪，算术也就说得通了：在 GPT-6.1 Sol 上，每次调用的成本大约降低到三分之一，因为 89% 的输入来自缓存。

这里最重要的发现是一个否定性的结论。在更大的预算下，不进行批量剪枝就缓存历史记录，其成本更高——在四个模型中的三个上，它比完全不缓存还要高；缓存被不断重写，却极少被读取。启用缓存基础设施却不遵循只追加的历史记录纪律，等于白白支付一笔写入溢价。这种失败模式与模型无关，也正是同一个修复让模型 B 提升了 29 倍的原因。

模型选择真正奏效之处

剔除工作流修复，进行同类比较：在同一个优化后的智能体上，GPT-6.1 Sol 的运行成本比 Model B 低 2.6 倍，而两者的标价相同。多出来的因素在于缓存命中行为，而不是价目表。Sol 有 89% 的输入是从缓存中读取的；Asana 并未公布 Model B 的对应比例，因此这个 2.6 倍是一个实测结果，没有公开的拆解。应将其理解为"这个模型在这类工作负载上更好地利用了缓存"，而不是相对某个我们无法具名的模型的普遍 2.6 倍优势。

运行时层面的结论毫不含糊：比基线快 5 倍，优化后的 Sol 工作流大约只需四分钟，而基线至少需要 22.5 分钟。对于按 token 计费的智能体而言，速度关乎成本，因为一个循环往复的慢模型要为其循环买单。

对于任何要做成本核算的人来说：GPT-6.1 Sol 的标准 API 价格为每百万输入 token 2.00 美元、每百万缓存输入 token 0.10 美元、每百万输出 token 10.00 美元，其缓存读取折扣为输入费率的 0.05 倍——这是 OpenAI 当前价目表上最深的折扣。GPT-6 Astra 是在 Codex 中承担工程工作的模型，其输入为 10.00 美元、输出为 50.00 美元，这正是 OpenAI 发布时反复强调的五倍差距。这项研究之所以得出 0.47 美元的单次运行成本而非 2 美元，原因不在费率表，而在于一个高度重复的请求中有 89% 是按输入费率的二十分之一计费的。对于缓存密集型的智能体而言，折扣这一项的作用比标价更大，而在我们自己的目录中，供应商标价是原样传递、加价 0%，因此供应商调整缓存输入计价，你的账单当天就会跟着变。

研究中的另一个数字：历史预算决定了智能体到底会不会作答。

每次运行成本是人人都会引用的数字，但这项研究更有用的结果在于可靠性，而这正是运营者应当首先关注的。

• 在 120,000 字符的预算下，模型 C 在 18 次运行中一次都没有作答，而 GPT-6.1 Sol 在 18 次中有 3 次作答——大多数运行都触及了步数上限，未能给出答案。

• 在 48 万个字符的长度下，两个模型上的每次运行都给出了回答，且每次回答都正确。

• 较新的模型更快地耗尽了较小的预算：模型 C 在第 10 次调用时首次裁剪了其历史记录，模型 A 则是在第 64 次调用时。

• 在优化后的工作流中，每一次运行都完成了任务并返回了正确答案，而且每个模型上的每一次最佳条件运行都遇到了它本应收集的全部 192 条事实。

这与“更便宜”是两码事。在能力足够的模型上设置过小的历史预算，会造出一个因空间耗尽而失败的智能体，而且它会因触及步数上限而失败，而这是代价最高的失败方式——你为整轮运行付费，却什么也得不到。提高预算会提高每次调用的成本，但会降低每次回答的成本，而后者才是生产环境负责人唯一该跟踪的数字。如果你正在为这样的智能体评估一个尚未经过验证的模型，低风险的做法是让生产路由继续使用你信任的模型，把新模型放在故障转移或分流路由之后，这样因步数上限而发生的失败就会表现为一个路由事实，而不是一次事故。本次对比中的每一个模型都可以通过一个 API 访问 200+ 模型，且供应商的目录价原样透传，这也让缓存读取折扣可以在同一张账单上跨供应商比较，而不必去翻五个仪表盘。

按顺序，从中应吸取什么

如果你运行浏览器智能体或计算机使用智能体，在查看费率卡之前，Asana 研究中的三个杠杆值得拉动：

• 让请求前缀仅支持追加。任何在每次调用时对历史记录中间部分的修改，都会使从该点往后的缓存复用归零。

• 分批剪枝。Asana 的后续研究发现，在 Model B 和 GPT-6.1 Sol 上，保留每张截图时每次调用的成本比最佳剪枝条件低 1.2 倍，在 Model C 上则低约 5%。对于长任务、小上下文窗口和高昂的缓存读取而言，剪枝依然重要——但 20:1 的批处理比例之所以站得住脚，关键在于缓存稳定性，而非截图本身。

• 为每个模型单独设置历史预算，并对照你的步数上限加以核对。适合某一个模型的预算，可能会让下一个模型不够用。

研究中的两条护栏很容易被忽略，但不该被忽略。没有一次运行达到 480,000 字符的预算，因此预算从未限制这些运行——但一个漂移的智能体会不断逼近其上下文上限，而如果缓存失效，每次调用都要付全价。对每轮运行的步数、token 数和成本设上限，才能约束一次糟糕的运行。另外，该研究每种条件使用三到四次运行，且调用次数可变；Asana 自己表示，这足以显示大致模式，但不足以区分相差几个百分点的条件。不要从中解读出 5% 的差异，并据此重建你的流水线。

真正新的部分，以及并非如此的部分

这套设置的注意事项值得直白说明：四个模型，其中三个未具名，一个范围狭窄的 32 本书任务，Asana 自己的插桩计数器，以及一份由供应商自己撰写并承载结果的报告。这里没有任何内容在 Asana 之外被复现过。但机制已被完整说明——仅追加的历史、在最后一个工具结果上设置缓存标记、批量剪枝、更大的预算、用提供商的计数器测量缓存读取——而且这类发现即使被归因于错误的实验室也依然成立。76x 是 Asana 工作负载上的 Asana 数字。它值得一读，是因为它展示了一条你可以在一个下午内验证的规则：一个每一步都编辑自己历史的智能体，正在为一段它已经进行过的对话支付全价。