Asana 用 GPT-6.1 Sol 將瀏覽器智能體成本降低 76 倍

据 OpenAI 于 2026 年 10 月 9 日发布的案例，项目管理软件公司 Asana 使用 Codex 对自己的浏览器智能体做了一次重构。官方给出的核心结果有两个：在测试中，改造后的智能体成本降低了 76 倍，运行速度提升了 5 倍。更关键的是这笔账的去向。成本大幅下降之后，Asana 可以在产品里为客户提供能力更强的模型，而不必在价格和效果之间硬做取舍。标题中提到的 GPT-6.1 Sol 是这次案例涉及的模型。需要说明的是，原文给出的是测试环境下的对比结果，具体的任务集、基线配置和计费口径，目前公开的信息并没有展开，读者不宜把 76 倍直接当作所有场景下的通用收益。

要理解这个数字为什么有分量，需要先看浏览器智能体的成本结构。这类智能体通常要在网页上完成多步操作：读取页面内容，判断下一步，点击或输入，再读取新的页面状态，如此循环。每一轮都要消耗模型的输入与输出，页面越复杂，上下文越长，单步成本越高。总成本大致由三个因素相乘：单步消耗的词元数量、完成任务所需的步数，以及所选模型的单价。速度也是同一个道理，步数越多，模型调用越多，等待越久。因此，成本和速度往往是同方向变化的两个指标。一次改造若能同时压低这两项，最合理的解释是整体流程变短了、每一步送给模型的信息变少了，或者两者兼有。至于 Asana 具体动了哪些环节，原文摘要没有披露，这里只能做这样的结构性推断。值得注意的是，这次改造是在 Codex 中完成的。Codex 是 OpenAI 的编码智能体，这意味着重构工作本身由代码智能体参与推进。这是一个有意思的闭环：用智能体去改造另一个智能体，并以成本和速度作为可量化的验收标准。

对行业而言，这个案例传递的信号有几层。第一，对企业软件厂商来说，智能体能否规模化上线，往往不取决于演示效果，而取决于单次任务的成本能否被订阅价格覆盖。Asana 这类按席位收费的 SaaS 公司，如果每次智能体调用都烧掉可观的推理费用，毛利会被迅速侵蚀。成本下降一个数量级以上，才可能让智能体从少数人试用变成全员默认功能。第二，成本下降并没有被简单地转化为利润，而是被用来升级模型。这反映出一种常见的产品策略：先通过工程优化腾出预算，再把预算投向更强的模型，以获得更高的任务成功率。第三，对 OpenAI 而言，这是一个把模型、Codex 与企业客户落地绑在一起的样板案例。它在向市场表明，卖点不只是更强的模型，还包括帮助客户把智能体做得更便宜、更快的整套工具链。对竞争对手如 Anthropic、Google 以及各类浏览器自动化初创公司来说，这意味着比拼的重点正在从单纯的基准分数，转向每个完成任务的实际成本和延迟。

接下来有几个信号值得持续观察。首先是披露的细节。如果 Asana 或 OpenAI 后续公开更多技术说明，比如测试任务的类型、改造前后的步数与词元用量、是否改变了页面信息的表示方式，就能判断这 76 倍里有多少来自可复用的方法，有多少只是针对 Asana 自身场景的特例。其次是生产环境的数据。测试里的成本与速度不一定等于线上表现，真实用户的任务更杂、网页更不稳定，成功率和重试次数会直接影响最终成本。再次是客户侧的变化：Asana 提供给客户的更强模型，是否会体现在任务完成率、可处理流程的复杂度，或定价与套餐设计上。最后，行业层面可以看这套打法是否被复制。如果更多企业软件公司也用代码智能体来系统性地重构自家智能体，并以成本和延迟为硬指标，那么智能体的竞争就会进入工程效率阶段。到那时，谁能持续把单次任务成本压低，谁就更有底气把更强的模型交给用户。