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

2026年10月9日，OpenAI 发布了一个企业案例：工作管理软件公司 Asana 借助 Codex，在测试中把自家浏览器智能体的运行成本降低了 76 倍，速度提升了 5 倍。案例标题还点出了 GPT-6.1 Sol 这个模型。按 OpenAI 的说法，成本和速度改善之后，Asana 就能把能力更强的模型提供给客户使用，而不必为了控制开销而退回到较弱的模型。需要说明的是，这些数字来自测试环境，并且由合作方公开发布，并不等于所有线上流量的平均表现。原文摘要没有披露基线是什么、任务集有多大、成功率有没有变化，这些都是解读 76 倍这个数字时必须先问清楚的前提。

要理解这个数字为什么有分量，先看浏览器智能体是怎么工作的。它通常在一个循环里反复执行：读取当前页面，可能是网页结构，也可能是截图；让模型决定下一步；执行点击、输入或跳转；再读取新的页面状态。每走一步都要调用一次模型，而且页面内容往往很长，输入的词元数量很大。一个任务如果需要几十步，总成本就是步数乘以单步成本，两项都会随任务复杂度放大。所以成本下降这么多，很难靠单一手段做到，更可能是多项优化叠加的结果。比较合理的方向有几个：压缩送给模型的页面表示，只保留与任务相关的元素；减少无效探索和重复尝试，让步数变少；把反复出现的固定流程固化成确定性的程序，不再每次让模型从头推理；利用缓存复用不变的上下文；以及让更新的模型用更少的步骤完成同样的事。Codex 是 OpenAI 的代码智能体，这个案例把它放在优化链条里，说明它很可能承担了分析轨迹、重写工具和脚本、验证改动这类工程工作。这一点是根据案例标签做出的推断，具体分工以原文为准。更值得注意的是思路上的转变：以前团队靠人工调提示词和流程来省钱，现在可以让代码智能体去优化另一个智能体。

这件事对不同角色的影响并不一样。对 Asana 这类协作软件公司来说，浏览器智能体的价值在于替用户操作产品界面和关联系统，把跨页面、跨工具的琐碎步骤自动化。这类功能一旦按调用量计费，成本就直接吃掉毛利，所以单次任务便宜几十倍，意味着可以把智能体从少数高价值场景推广到日常高频场景，也可以把省下来的预算用来换更强的模型，这正是案例强调的结果。对 OpenAI 来说，这是一个同时展示模型和 Codex 的样板：模型负责执行，代码智能体负责优化，两者形成闭环，有利于说服企业客户相信智能体可以规模化部署。对竞争对手来说，压力主要在两处。一是做浏览器自动化和计算机操作的同类产品，它们同样面对步数多、上下文长的成本结构，如果不能给出类似的降本路径，在企业采购中会显得偏贵。二是其他模型厂商，它们需要拿出自己的可复现案例，而不只是基准测试分数。对企业客户来说，这个案例也提供了一个判断方法：评估智能体项目时，不要只看模型能力，更要看单次任务的真实成本和时延，因为这两项决定了功能能不能长期开着。

接下来有几个信号值得持续观察。第一，OpenAI 或 Asana 是否会补充方法细节，包括基线配置、任务类型、成功率、失败时的回退方式，以及 76 倍和 5 倍在线上环境是否成立。如果成功率在降本后保持不变甚至上升，这个案例的含金量会高得多；如果只在简单任务上成立，结论就要打折扣。第二，类似的降本做法能否被复制到其他公司。如果它依赖的是通用手段，比如压缩上下文、固化流程、让代码智能体做优化，那么会很快扩散；如果高度依赖 Asana 自身产品的结构，推广空间就有限。第三，定价和模型分层会不会随之调整，也就是厂商是否会把更强的模型以更低的有效价格提供给智能体场景。第四，安全和可靠性的问题不会因为便宜而消失，浏览器智能体能代用户操作真实系统，权限边界、误操作的可追溯性和人工确认机制，仍然是企业上线时的硬门槛。总体看，这个案例说明智能体落地的主要矛盾正在从能不能做，转向做得起、做得快、做得稳，而谁能系统化地解决后两项，谁就更有机会拿下企业市场。