Asana浏览器代理成本降76倍

看到Asana这个案例，我第一反应是：模型成本优化终于从后端推理卷到了浏览器端。他们用GPT-6 Astra在Codex里跑了一轮改造，把浏览器代理的调用成本压到了原来的七十六分之一，速度还快了五倍。这个数字放在两年前根本不敢想，那时候大家还在纠结要不要为了省token把上下文砍到最短。

具体做法其实不复杂，核心是把原本需要大模型反复推理的步骤，拆成更小的确定性任务交给Codex执行。浏览器代理最烧钱的地方在于每一步都要重新理解页面结构，Asana应该是把页面解析和动作规划做了缓存和复用，让Astra只处理真正需要语义判断的环节。这种思路对做RPA或者自动化测试的团队很有参考价值，不一定非要换模型，把调用链路重新设计一遍就能省出数量级。我比较在意的是他们提到「给客户提供更强模型」这个目标。成本降下来之后，原本因为太贵而不敢开放的复杂功能就可以放出来了。比如让代理处理多轮表单填写、跨页面数据核对，这些场景以前按调用量算账根本划不来。现在成本结构变了，产品设计空间也跟着变大，这可能是比单纯省钱更值得关注的地方。不过也要泼一点冷水。七十六倍这个数字大概率是在特定测试集上跑出来的，真实用户环境里的页面复杂度、网络延迟、反爬策略都会吃掉一部分收益。而且把逻辑拆到Codex里执行，调试和可观测性会变得更麻烦，出了问题定位链路比单体大模型长得多。我的判断是，浏览器代理接下来会分两条路走：一条是继续堆大模型能力，另一条就是Asana这种工程优化路线。对大多数做跨境工具或者SaaS的团队来说，后者更现实，毕竟不是谁都有预算无限烧token。先把调用链路拆明白，再谈模型选型，顺序别搞反了。