Asana 借 GPT-6.1 Sol 把浏览器智能体成本压低 76 倍

Asana 把一件很具体的工程问题做成了一个很有分量的案例。它旗下的 StackAI 平台让客户不用写代码，就能搭建会浏览网站、填写表单、收集信息的工作流。在 Asana 的规模下，这类浏览器智能体每一处小小的低效都会被成倍放大。StackAI 的 CTO Frank Hidalgo 博士想让它更快、更便宜，于是他让 Codex 里的 GPT-6 Astra 去调查这个智能体、测试改进方案并对比结果。Asana 公布的数据是：优化后的 GPT-6.1 Sol 工作流，平均估算模型成本为 0.47 美元，单次运行约四分钟，比原来跑在模型 B 上的生产配置便宜 76 倍、快 5 倍。他估计，这些工作靠人手要一到两个月，实际只用了大约一周。

问题出在上下文的构造方式上。GPT-6 Astra 先帮他梳理代码库，解释智能体如何为每次模型请求拼装内容。它发现智能体只缓存了固定的指令和工具定义，却没有缓存不断增长的浏览历史，也就是它一路收集的页面文本和截图。结果是每一次请求都要按全价把整段历史重新发送一遍。更麻烦的是，智能体几乎每一步都会丢掉较早的截图并裁剪文本。每一次编辑都会改动历史，缓存是按前缀匹配的，历史前面一变，后面全部失效。所以只给历史加缓存并没有用。再者，丢失这些信息还可能迫使智能体回头重读已经看过的页面，反而多花成本。这里的要点是，单点优化会互相抵消，必须把缓存、保留量和清理节奏当成一个整体来设计。

Hidalgo 审阅了 GPT-6 Astra 提出的修复方案，挑出三项来测试：把缓存扩展到智能体的浏览历史；提高可保留的文本量；改为成批移除截图，而不是每一步都移除。Astra 先做了快速试验，弄清哪些变量真正起作用。由于原有代码并不是为受控实验设计的，它又重构了代码，让同一套前端和后端可以并行支持多种工作流，每种工作流有自己的设置。随后它完成了完整研究：历史预算取 12 万和 48 万字符两档，搭配六种缓存与截图策略，每种组合在四个模型上各跑三次，总共 144 次运行。表现最好的策略是让截图累积到 20 张，再一次性收缩到只留最近一张。这样两次清理之间，较早的历史保持不变的时间更长，缓存命中也就更稳定。它与更大的历史预算结合，就成了最终的优化工作流。

实验设计本身也值得留意。每种配置执行同一项任务：从公开的演示目录中，为 32 本书各收集六个字段，这与部分 Asana 客户在 StackAI 上的实际用法接近。对照的四个模型是 GPT-6.1 Sol，以及另一家前沿实验室的三个模型。模型 A 是 2025 年秋发布的较小、较便宜的模型，价格是 GPT-6.1 Sol 的一半。模型 B 是原先生产环境使用的模型，2026 年夏发布，与 GPT-6.1 Sol 同价。模型 C 是模型 B 的更新版，2026 年秋发布，同样与 GPT-6.1 Sol 同价。按 0.47 美元和 76 倍推算，原配置单次成本约在 36 美元上下，这是我们根据公布数字做的推算，并非 Asana 披露的数值。流程上的闭环同样关键。GPT-6 Astra 负责运行工作流，检查请求、用量记录和输出，另有独立的模型会话复核它的工作。每个会话的请求、数据轨迹和结果，都记录在 Asana 的软件交付平台 Command 中，团队事后可以完整复查整项研究。随后，发现被整理成工单，再变成拉取请求，改动最终进入生产。Hidalgo 说，他会在睡前设定一个 /goal，第二天早上查看结果。Asana 的首席产品官 Arnab Bose 把它概括为人与智能体协作的实际样子：工程师定方向，GPT-6 Astra 跑实验，成果经由 Command 进入生产。

这个案例对行业的启示有三点。第一，智能体的成本主要由上下文工程决定，而不是模型单价。四个模型中有三个与 GPT-6.1 Sol 同价或更便宜，真正拉开差距的是缓存是否命中。第二，用智能体去优化智能体，前提是实验可重复、证据可追溯。Asana 先重构代码以支持受控实验，再把全部轨迹留在 Command 里，这比结论本身更值得学习。第三，需要谨慎看待数字：这是一项在单一任务、公开演示目录上的测试，成本是估算值，而非账单。它说明方法有效，但不能直接外推到所有浏览器工作流。对于正在把智能体推向生产的团队，更实用的做法是先检查自己的请求里哪些部分被缓存、哪些每步都在变，再用小规模对照实验验证。还有一层含义不应被忽略：这件事改变了工程团队时间的用法。一到两个月的手工研究被压缩到一周，省下的不只是工时，更是试错的勇气。过去，团队往往因为实验成本太高而不敢重构代码、不敢并行比较六种策略，只能凭经验挑一种上线。当智能体可以在夜里跑完实验、早上交出带证据的对比，工程师的角色就从亲手试错转向设定目标和审阅证据。这对审阅能力提出了更高要求：人必须看得懂请求记录、用量数据和输出，才能判断哪项改动值得合入。Asana 让独立的模型会话复核，并把全部轨迹存进 Command，正是为了让这种审阅有据可依。