Asana的StackAI平台让客户无需写代码就能构建浏览器工作流导航网站、填写表单、采集信息。规模一大单次运行中微小的低效就会被放大。StackAI CTO Frank Hidalgo用GPT-6 Astra在Codex中调查Agent、测试改进并对比结果把原本估计需要一到两个月的手工研究压缩到约一周。问题定位缓存漏掉了增长最快的部分Hidalgo先让GPT-6 Astra在Codex中梳理代码库解释Agent如何构造每一次模型请求。Astra发现Agent缓存了固定指令和工具定义但没有缓存不断增长的页面文本与截图历史因此每次请求都以全价重发这段历史。更麻烦的是Agent几乎每一步都会丢弃旧截图、裁剪文本。每次编辑都会改变历史所以单独缓存历史并不能解决问题而丢失这些事实又可能迫使Agent重新访问已经读过的页面。三项被选中的修复Hidalgo审阅Astra提出的修复方案后选择三项进行测试把缓存扩展到Agent的浏览历史提高可保留文本的数量批量移除截图而不是每一步都移除由于原代码并非为受控实验设计Astra先重构代码让一个前端和后端能并行支持多个工作流每个工作流有自己的设置。随后Astra执行了完整研究历史预算为120,000和480,000字符六种缓存与截图策略每种在四个模型上各测三次共144次运行。表现最好的策略允许截图累积到20张再回退到最近一张。这样在两次移除之间有更长的时间段保持早期历史不变。配合更大的历史预算它成为最终的优化工作流。每个配置执行同一任务从一个公开演示目录中为32本书各采集6个字段代表部分Asana客户在StackAI中运行的工作负载。成本与延迟结果对原生产模型Model B优化把估计模型成本从至少36.21美元部分原始运行在完成前就触及步数上限降到每次1.24美元降幅29倍。在GPT-6.1 Sol上的优化工作流再便宜2.6倍为0.47美元。优化工作流中的每次运行都完成了任务并返回正确答案。仅在GPT-6.1 Sol上配合更大的历史预算新的缓存与截图策略把成本从1.97美元降到0.47美元降低4倍。每次调用约便宜3倍因为89%的输入来自缓存而缓存价格仅为未缓存价格的5%。速度同样改善原始Model B设置至少22.5分钟GPT-6.1 Sol优化工作流约4分钟。历史管理还直接影响Agent能否给出答案。给GPT-6.1 Sol更大的浏览历史保留空间后产生答案的运行数从较小预算下的18次中3次提升到较大预算下的全部18次且答案均正确。工程可复用的降本路径从这项研究中可以提炼出几条对浏览器Agent通用的工程判断第一先审计请求构成。固定指令和工具定义通常早已被缓存真正吃掉成本的是随步骤增长的页面文本与截图历史。如果这部分没有缓存每次请求都在为重复内容付全价。第二缓存策略必须与历史编辑策略一起设计。如果Agent频繁裁剪或丢弃历史缓存命中率会被不断打断。Asana的解法是让历史在更长的时间段内保持不变再批量清理。第三历史预算不是越大越好但太小会直接损害任务完成率。18次运行中只有3次给出答案说明预算不足时Agent可能根本无法收敛。第四模型迁移和Agent优化是两件事。Model B优化后降29倍换到GPT-6.1 Sol再降2.6倍。两者叠加才达到76倍。第五实验基础设施值得提前投入。Astra先重构代码以支持并行工作流和独立设置才使144次受控运行成为可能。从实验到产品Asana已把浏览器导航的改动发布到StackAI并正在开发工具让类似实验更容易重复。团队计划把这种测试纳入平台评估让客户和内部团队在配置Agent时比较成本、运行时间和答案质量。Asana还在用GPT-6 Astra在Codex中做发布前产品测试Astra导航平台、尝试不同输入并向人工QA报告缺陷。Hidalgo把这视为新软件开发生命周期的基础多个云Agent会话并行测试功能。他的判断是发布速度不再是瓶颈人的注意力才是。