Asana 借助 GPT‑6.1 Sol，在浏览器测试中将模型成本降至原来的 1/76
Asana 借助 Codex 中的 GPT‑6 Astra，在测试中将浏览器智能体的成本降至原来的 1/76，速度提升至原来的 5 倍，从而为客户提供能力更强的模型。
1/76
优化后的 GPT-6.1 Sol 工作流将预估模型成本降至原来的
5 倍
优化后的 GPT-6.1 Sol 工作流将浏览器运行速度提升至原来的
0.47 美元
优化后的 GPT-6.1 Sol 工作流的平均预估模型成本
Asana 利用 Codex 中的 GPT‑6 Astra 开展实验，优化了基于 GPT‑6.1 Sol 的浏览器智能体工作流，将运行成本降至原来的 1/76，速度提升至原来的 5 倍。
Asana 通过其收购（在新窗口中打开）的 StackAI（在新窗口中打开） 平台，帮助客户实现跨业务应用的工作自动化。借助 StackAI，客户无需编写代码，即可构建能够浏览网站、填写表单和收集信息的工作流。以 Asana 的业务规模，这些工作流中再微小的低效环节也会积少成多。
Asana 的 StackAI 首席技术官 Frank Hidalgo 博士着手提升浏览器智能体的运行速度，并降低运行成本。他指导 Codex 中的 GPT‑6 Astra 分析这个智能体、测试改进方案并对比结果。据他估计，这项工作如果靠人工完成，需要一到两个月，而实际只花了约一周。
Asana 的研究共进行了 144 次运行测试（在新窗口中打开），测试对象包括 GPT‑6.1 Sol 和另外三个前沿模型，本文将它们称为模型 A、B 和 C。最终得到的 GPT‑6.1 Sol 优化工作流，平均每次运行的预估模型成本为 0.47 美元，耗时约四分钟。相比基于模型 B 的原有生产配置，成本降至原来的 1/76，速度提升至原来的 5 倍。
“这就是人类与智能体团队在实践中的协作方式。工程师确定方向，GPT-6 Astra 开展实验，再通过 Command 将成果部署到生产环境。这展现了 Asana 如何让人类与智能体组成团队、真正协同工作。”
为了快速推进，Hidalgo 首先使用 Codex 中的 GPT‑6 Astra 梳理代码库，并解释智能体如何构建每次模型请求。GPT‑6 Astra 发现，智能体缓存了固定指令和工具定义，却没有缓存不断累积的网页文本与截图历史，因此每次请求都会重新发送这些历史记录，并按全价计费。
智能体还几乎在每一步都会删除较早的截图并裁剪文本。每次修改都会改变历史记录，因此仅仅缓存历史记录并不能解决问题；而丢失这些信息，还可能迫使智能体重新访问已经读过的页面。
Hidalgo 审阅了 GPT‑6 Astra 提出的改进方案，并选出三项进行测试：
将缓存范围扩展至智能体的浏览历史
增加可保留的文本量
批量删除截图，而不是每一步都删除
GPT‑6 Astra 先通过快速测试，确定哪些变量会影响结果。由于原有代码并非为对照实验设计，它随后重构了代码，使一套前后端能够并行支持多个工作流，且各自使用独立设置。
Astra 执行了完整研究：将历史记录容量上限分别设为 12 万和 48 万字符，搭配六种缓存和截图策略，在四个模型上对每种组合各测试三次（见下表）。表现最佳的策略是让截图累积至 20 张，再删减至仅保留最新的一张。这样，两次删除操作之间的间隔更长，较早的历史记录也能更久地保持不变。这项策略与更大的历史记录容量相结合，构成了最终的优化工作流。每种配置都执行同一项任务：从一个公开的演示目录中，收集 32 本书中每本书的六个字段。这项任务代表了部分 Asana 客户在 StackAI 中运行的工作。
模型 | 描述 | 价格 |
|---|---|---|
模型 A | 另一家前沿实验室于 2025 年秋季发布的模型，规模更小、价格更低 | 价格为 GPT‑6.1 Sol 的一半 |
模型 B | 最初用于生产环境的模型，与模型 A 出自同一家实验室，于 2026 年夏季发布 | 与 GPT‑6.1 Sol 价格相同 |
模型 C | 模型 B 的更新版本，于 2026 年秋季发布 | 与 GPT‑6.1 Sol 价格相同 |
GPT‑6.1 Sol | OpenAI 的模型 |
GPT‑6 Astra 运行了这些工作流，检查请求、用量记录和输出，并由独立的模型会话复核工作。每个会话的请求、数据轨迹和结果都记录在 Asana 的软件交付平台 Command（在新窗口中打开） 中，方便团队事后审阅完整研究。研究发现先在 Command 中转为工单，再转为拉取请求，最终将这些改动部署到生产环境。
“如果靠我手动完成，需要一到两个月。借助 Codex 中的 GPT-6 Astra，只花了约一周：我睡前用 /goal 设置目标，早上再查看结果。”
对于模型 B，优化将每次运行的预估模型成本从至少 36.21 美元降至 1.24 美元，即原来的 1/29（原有配置的部分运行在完成前就达到了步数上限）。基于 GPT‑6.1 Sol 的优化工作流成本进一步降至 0.47 美元，仅为前者的 1/2.6。优化工作流的每次运行都完成了任务，并返回了正确答案。
3 次运行的平均值。≥：基线包含达到上限的运行，因此其平均值为下限。
右侧的两个倍数均以模型 B 优化配置为比较基准。模型 B 在本研究的阶段 1 运行，模型 C 和 Sol 6.1 在阶段 2 运行（以虚线分隔）。
仅看 GPT‑6.1 Sol，在采用更大的历史记录容量时，新的缓存和截图策略将每次运行的成本从 1.97 美元降至 0.47 美元，约为原来的四分之一。每次调用的成本约降至原来的三分之一，因为 89% 的输入来自缓存，而缓存输入的价格仅为未缓存输入的 5%。运行速度也更快了：模型 B 的原有配置至少需要 22.5 分钟，而 GPT‑6.1 Sol 的优化工作流仅需约四分钟。
3 次运行的平均值，误差线表示标准差。≥：平均值包含达到上限或未完成的运行，因此实际值至少为此数值。
柱形采用蓝色配色。请以“更大容量（48 万字符）”柱形为基准，比较缓存带来的效果。
运行标记和标准差误差线均根据原图近似还原，未获得原始运行数值和标准差。
3 次运行的平均值，误差线表示标准差。≥：平均值包含达到上限或未完成的运行，因此实际值至少为此数值。
柱形采用蓝色配色。请以“更大容量（48 万字符）”柱形为基准，比较缓存带来的效果。
运行标记和标准差误差线均根据原图近似还原，未获得原始运行数值和标准差。
这项研究还揭示了历史记录的管理方式如何影响智能体能否给出答案。为 GPT‑6.1 Sol 提供更多空间来保留浏览历史后，能给出答案的运行次数从较小容量下的 18 次中仅 3 次，增加到较大容量下的 18 次全部，而且答案均正确。在 Hidalgo 看来，其商业价值在于：让客户能够使用速度更快、能力更强的模型，同时将运营成本控制在可持续的水平。
“过去，成本限制了我们能为客户提供哪些模型来处理这些工作负载。提升智能体的效率后，我们既能为客户提供更好、更快的模型，也能降低自身的运营成本。”
Asana 已在 StackAI 中上线了浏览器导航功能的改进，并正在开发工具，让类似实验更容易复现。团队计划逐步将这类测试纳入平台评估，使客户和内部团队在配置智能体时，能够比较成本、运行时间和答案质量。
“交付速度已不再是瓶颈，人的注意力才是。我们正接近这样一个时代：每位工程师都像产品经理一样，带领一支智能体团队。”
Asana 目前正使用 Codex 中的 GPT‑6 Astra 在产品功能发布前进行测试：Astra 浏览平台、尝试不同输入，并向人工质量保证审核人员报告漏洞。Hidalgo 认为，这为一种新的软件开发生命周期奠定了基础：由多个云端智能体会话并行测试功能。
完整研究可在 Asana（在新窗口中打开） 和 StackAI（在新窗口中打开） 的博客上查阅。
