Asana 借助 GPT-6.1 Sol，瀏覽器智慧體成本降低 76 倍

据 OpenAI 发布的客户案例，项目管理软件公司 Asana 在 Codex 中使用 GPT-6.1 Sol，对自家的浏览器智能体做了改造。在测试中，这个智能体的运行成本降低了 76 倍，速度提升了 5 倍。Asana 表示，成本和速度的改善让公司有空间向客户提供能力更强的模型，而不必为每一次调用付出过高的代价。这篇案例发布于 2026 年 10 月 9 日。需要说明的是，公开材料给出的是测试环境下的结果，具体的测试任务集、基线模型和计费口径并未在摘要中展开，所以这两个倍数更适合当作量级信号，而不是可以直接套用到其他场景的承诺。

要理解这个数字为什么重要，先要看浏览器智能体的成本是怎么构成的。这类智能体通过读取网页的结构或截图，决定下一步点击什么、输入什么，再读取新的页面状态，如此循环，直到任务完成。一次任务往往要经过十几步甚至几十步，每一步都要把页面内容和历史上下文重新送入模型，所以输入的词元数量很大，延迟也会逐步累积。成本与速度因此是同一个问题的两面：步骤越多、上下文越长，花费越高，用户等待的时间也越长。把成本压低两个数量级，通常不是单靠换一个更便宜的模型就能做到的，更可能来自几个因素叠加：新模型在同样任务上用更少的步骤完成，对页面信息的理解更准，出错后重试的次数更少；同时，围绕模型的工程也可以重写，比如裁剪送入模型的页面内容、复用缓存的上下文、把能用确定性代码完成的环节从模型调用里剥离出来。Asana 在 Codex 中完成这项工作，说明编码智能体本身也参与了这次重构，也就是用 AI 工具去改造 AI 产品的运行效率。这里的 76 倍是否主要来自模型本身，还是来自工程改造，公开信息并没有拆分，这一点值得保持审慎。

从商业角度看，这个案例触及的是智能体产品最现实的矛盾。企业软件厂商想把智能体做成产品功能，但按次计费的模型调用成本，可能让一个看上去很酷的功能在大规模使用时变成亏损项。当单位任务成本下降到原来的几十分之一，几件事会同时改变。第一，功能可以默认对更多用户开放，而不是锁在高价套餐里。第二，厂商有余量在关键任务上选用更强的模型，用省下来的预算换取更高的成功率，这正是 Asana 所说的向客户提供更强大模型的含义。第三，速度提升五倍会直接改变交互形态：几秒内完成的操作可以嵌入日常工作流，而需要等待几分钟的操作只能做成后台任务。对 Asana 这样的工作管理平台来说，浏览器智能体的价值在于替用户跨系统完成重复性操作，比如整理任务、同步状态、在没有开放接口的网页工具之间搬运信息，这类场景对延迟和单次成本都非常敏感。

对行业格局的影响可以从三个层面来看。对模型供应商而言，客户案例已经不再只展示基准测试分数，而是展示每个任务的真实花费和耗时，这说明竞争的重点正在从最强模型转向性价比最高的可用模型。对同类企业软件公司而言，Notion、Atlassian、Salesforce 等同样在推进智能体功能，成本曲线一旦被证明可以大幅下探，各家就很难再用高昂的推理成本来解释自己的定价，智能体功能会更快地变成标配，差异将转移到数据、权限与工作流的整合深度上。对独立的浏览器智能体创业公司而言，压力会更大：当大型平台自己就能以很低的成本运行智能体，并且天然掌握用户的业务数据，通用型的浏览器自动化工具就需要在可靠性、覆盖面或垂直场景上拿出更明确的优势。另外，Codex 这类编码智能体在案例中的出场也值得留意，它意味着模型供应商正在把开发工具和模型本身捆绑销售，用同一套产品帮客户完成从构建到优化的闭环。

接下来有几个信号值得持续观察。其一，Asana 或 OpenAI 是否会披露更细的数据，比如任务成功率、测试样本规模、与旧方案的对比条件，以及成本下降中模型与工程各自的贡献，这些信息决定了案例的可复制程度。其二，成本下降是否会反映到面向客户的价格与套餐上，如果智能体功能随之开放给更多用户，就说明节省确实转化成了产品策略，而不只是内部利润。其三，浏览器智能体的可靠性问题仍然存在，网页改版、登录验证、权限边界和误操作的风险，不会因为成本降低而自动消失，企业客户最终会用稳定性和可审计性来评价这类功能。其四，其他模型厂商是否会以类似的成本与速度数据回应，行业可能很快进入以单位任务成本为核心的新一轮比拼。总体来看，这个案例的价值不在两个倍数本身，而在于它提示了一个方向：当智能体的运行成本下降到足够低，它才有可能从演示变成每天被大量使用的基础功能。