Asana 用 GPT-6.1 Sol 把浏览器智能体成本压低 76 倍：一次由 Codex 驱动的工作流优化实验

2026 年 10 月 9 日，OpenAI 在官网发布了一篇与 Asana 有关的客户案例。数字很醒目：在一组浏览器智能体测试中，Asana 把估算的模型成本压到原来的七十六分之一，运行速度提高到五倍。优化后的工作流跑在 GPT-6.1 Sol 上，平均每次运行的估算模型成本为 0.47 美元，耗时约四分钟。对照基线是 Model B 上的原有生产配置。按这两个数字做简单换算，原配置每次运行的成本大约在 36 美元上下。先把话说在前面：这是厂商发布的案例，成本是「估算」，对比来自 Asana 自己设计的 144 次运行研究。它是一个值得认真对待的工程信号，却还不是可以直接套用的行业基准。故事的背景是 StackAI。Asana 收购了这个平台，客户可以用它在不写代码的情况下搭建工作流，让智能体打开网站、填写表单、收集信息。这类工作流单次看不出问题，但在 Asana 的规模下，每一点低效都会被乘上巨大的调用量。StackAI 的 CTO Frank Hidalgo 博士因此决定，让浏览器智能体更快、更便宜。他没有带着团队逐项手工排查，而是指挥 Codex 中的 GPT-6 Astra 去调查这个智能体、测试改进方案、再比较结果。他估计，这些工作如果由人手完成，需要一到两个月，而这一次大约一周就做完了。 案例中最有教学价值的是诊断环节。Hidalgo 先让 GPT-6 Astra 梳理代码库，解释智能体是如何拼出每一次模型请求的。它发现，智能体缓存了固定不变的指令和工具定义，却没有缓存不断增长的页面文本与截图历史。这个发现值得细想。浏览器智能体每走一步，都要把此前看到的页面内容连同新的截图再交给模型。历史越长，每一步要重新处理的输入就越多。如果这部分不能命中缓存，同样的内容就会在一次运行里被反复按全价计费，也会反复拖慢首个字符的返回时间。步骤越多，这笔浪费累积得越快，累计输入量的增长比步数本身更陡。以上是对机制的合理推断。OpenAI 公开的摘录没有列出全部改动的细节，我们不能替它补写每一项措施。 再看研究设计。Asana 的研究共做了 144 次运行，对象是 GPT-6.1 Sol 加上三个匿名的前沿模型，文中称为 Model A、B、C。这种设计的价值在于，模型选择和工作流改造被放进了同一张对比表。不过它也带来一个必须说清的解释问题：76 倍是「优化后的 Sol 工作流」对「Model B 上的原生产配置」，里面同时包含了换模型和改流程两个变量。把 76 倍全部记在模型头上，会夸大模型的作用。把它全部记在工作流头上，又忽略了模型本身的价格与速度差异。摘录里没有看到把两者拆开的对照，这正是读者应当追问的地方。另外，成本是估算值，会随各家定价调整而变化，样本也只有 144 次，结论的稳定性需要更多重复来检验。

这件事的第二层意义在于工作方式。Asana 的首席产品官 Arnab Bose 说，这就是人类与智能体团队在实践中的样子：工程师定方向，GPT-6 Astra 跑实验，结果经由 Command 进入生产。这句话里有一条清晰的分工线。方向、取舍和上线的责任仍在人手里，而最耗时的部分，也就是读代码、提假设、跑对照、整理数据，交给了智能体。实验的边际成本一旦降低，优化就不必再等到「有空的时候」，它可以成为常规动作。同时，价值的重心也移向评估本身：有没有一批可重复的任务，有没有可比的指标，有没有人愿意认真读完实验结果。没有这些，跑得再快的实验也只是产生更多噪声。 换个角度看，这个案例也提醒我们，智能体的成本并不只由模型单价决定。同样一次任务，决定账单的往往是请求如何被组装：哪些内容放在前面保持稳定，哪些内容每一步都在变，哪些截图真的有必要反复送入。当上下文里既有文字又有图像时，这种结构问题更容易被忽视，因为开发者看到的只是一次次成功的运行，账单却在后台悄悄放大。Hidalgo 让 Codex 先读懂请求的构造，再动手改，这个顺序是对的：先弄清钱花在哪里，再谈换哪个模型。对正在评估供应商的团队来说，这意味着不能只比较每百万词元的价格，还要在自己的真实任务上，比较每次完成任务的总花费与总耗时。这两项才是业务真正关心的数字。对业务而言，另一个值得记住的细节是 144 次运行本身。它说明团队没有凭感觉宣布胜利，而是用一批固定的运行去检验每一个改动。这种做法成本不高，却能挡住很多自我感觉良好的结论。

对行业而言，这个案例传递了三个信号。第一，浏览器智能体的竞争正在从「能不能做」转向「做一次要多少钱、多少分钟」，单次成本从几十美元降到不足一美元，才可能支撑每天成千上万次的企业调用。第二，提示缓存的命中结构应当成为智能体架构评审的固定检查项，尤其是那些会随步骤不断变长的上下文。第三，案例的目的之一，是让 Asana 能向客户提供更强的模型，也就是用省下的成本换取能力。对读者来说，最稳妥的做法是借鉴方法而不是搬运数字：先审计自己的请求里哪一部分没有被缓存，再用同一批任务做受控对比，把换模型和改流程分开测，最后以成功率与成本并列报告。成本降到七十六分之一固然漂亮，但只有在任务仍然做对的前提下，它才有意义。