Asana 用 GPT-6 Astra 在 Codex 中重构浏览器 Agent，测试中模型成本降低 76 倍、速度提升 5 倍
来源OpenAI Blog查看原文
速览
- Asana 用 GPT-6 Astra 在 Codex 中改造浏览器 Agent
- 测试结果显示成本降低 76 倍、速度提升 5 倍
- 优化目的是让客户用上更强的模型
- OpenAI 以客户案例形式对外披露该结果
- 原文未披露技术细节与测试口径
OpenAI 博客披露，Asana 借助 Codex 中的 GPT-6 Astra 对其浏览器 Agent 进行优化，在测试中把模型成本压低了 76 倍，速度提升了 5 倍。Asana 的目的是借此向客户提供能力更强的模型。原文仅给出这一组结果数据，未说明具体的技术路径、测试环境、成本口径以及上线时间。
关键事实
- Asana 使用 Codex 中的 GPT-6 Astra 优化其浏览器 Agent
- 测试中模型成本降低 76 倍
- 测试中速度提升 5 倍
- Asana 的目标是向客户提供能力更强的模型
- 该消息由 OpenAI 官方博客发布
本站视角
对国内做浏览器 Agent 和 RPA 的团队来说，这条消息的价值不在「Asana 省了钱」，而在于它给出了一个可参照的量级：如果成本真能下降两个数量级，那么过去因为单任务成本过高而被砍掉的长链路场景——跨站点比价、批量表单填写、后台数据抓取——会重新变得可算账。做 Agent 的团队应当把注意力放在 Asana 是怎么做到的，而不是结果本身，因为成本下降通常来自三处：把大模型调用替换为更小或更专用的模型、减少无效的模型往返（例如把确定性操作交给代码而非模型）、以及缓存与批处理。我们认为，OpenAI 选择在这个时间点放出该案例，带有明显的产品营销动机——它要证明 GPT-6 Astra 加 Codex 不只是能力更强，而是单位任务更便宜，这直接回应了企业客户对 Agent 成本失控的顾虑。但需要指出的是，原文只有一句话，既没有基线定义，也没有第三方验证，76 倍这个数字在缺少口径的情况下不宜直接引用为行业基准。对中文开发者更现实的做法是：在自己的任务集上复现类似的优化思路，先测出单任务成本与延迟的基线，再判断是否值得迁移到新模型。
背景与影响
浏览器 Agent 长期受制于两件事：每一步操作都要调用模型，token 消耗随任务步数线性甚至更快增长；同时多步推理带来的延迟会直接拖慢交互体验。Asana 作为项目管理与协作软件厂商，把 Agent 放进浏览器场景，意味着它面对的是高频、长链路、对响应速度敏感的任务，成本与延迟的压力会比单轮对话类产品更大。OpenAI 把这一案例放在自家博客上，通常意在说明 Codex 与 GPT-6 Astra 组合在真实生产工作负载中的性价比——76 倍与 5 倍这两个数字如果成立，意味着原先因成本过高而无法规模化的浏览器自动化任务，可能进入可商用区间。需要观察的是，这类厂商案例往往只公布最优结果，缺少基线说明：76 倍是相对哪一版模型、哪一套 prompt 或哪条流水线，5 倍是端到端延迟还是单步推理，原文均未交代。
本文由 AI 辅助整理自公开信源，事实部分以原文为准；「本站视角」一节为编辑部判断，欢迎指正。版权归原作者所有，如有异议请联系我们。