Asana 的 StackAI 团队通过重设计提示缓存、浏览历史和截图清理策略，在使用 GPT-6.1 Sol 的浏览器代理测试中将估算模型成本降至每次 0.47 美元，运行速度约提高 5 倍，并将成本相比原配置降低约 76 倍。研究强调缓存命中率与历史管理对代理成本和性能的关键作用，同时提醒结果受限于特定任务与实验设置，需谨慎外推。
Asana旗下StackAI的一项浏览器代理测试显示，通过重新设计提示缓存、浏览历史和截图清理策略，代理在使用GPT-6.1 Sol时的估算模型成本降至每次运行0.47美元，运行时间约为4分钟。与原有生产配置相比，成本下降约76倍，运行速度提高约5倍。
这项结果并不是单纯更换模型带来的收益。Asana的工程团队发现，浏览器代理每次调用模型时都会重新发送工具定义、系统提示、网页文本和截图。只要历史记录在每一步都被修改，原本可以复用的缓存就会失效，代理也可能因为过早删除上下文而重复访问已经读过的页面。
相关案例最先由OpenAI的客户案例文章披露；StackAI随后在技术博客中公开了更多实验设置和限制。两篇文章的发布时间并不相同：OpenAI的客户案例列于2026年10月9日，StackAI技术文章显示为10月8日，但它们描述的是同一项研究链条。
代理成本的关键，不只在模型价格
Asana通过收购的StackAI平台，让客户构建能够浏览网站、填写表格和收集信息的工作流。对于这类代理，模型成本很大一部分来自不断增长的上下文，而不只是模型每百万个token的标价。
StackAI解释说，原有代理能够缓存固定的工具和系统提示，却没有有效缓存持续增长的网页历史。与此同时，系统几乎每一步都会删除旧截图、裁剪文本，从而改变请求前缀。由于缓存通常只能复用连续且未改变的前缀，这些操作使历史内容在几乎每次调用时都要按未缓存输入重新计费。
GPT-6.1 Sol的公开定价也说明了缓存的差异。按照OpenAI API定价页面，GPT-6.1 Sol的标准输入价格为每百万token 2美元，缓存输入为0.10美元，输出为10美元。缓存输入价格只有标准输入的二十分之一。在需要反复携带相同上下文的浏览器代理中，缓存命中率会直接影响单次任务的总成本。
不过，定价本身并不能解释Asana的全部结果。该公司是在改造历史管理策略后，才让更多输入真正进入缓存路径。
三项调整改变了实验结果
据StackAI披露，团队主要测试了三类改动。
第一，把缓存范围扩展到代理持续积累的浏览历史，并在最新的工具结果处设置缓存标记。第二，把历史预算从12万字符提高到48万字符，减少代理在每一步都裁剪文本的需要。第三，不再逐步删除截图，而是允许截图累积到20张后再批量清理，只保留最近的一张。
这种“追加为主、批量清理”的策略，让历史前缀可以在更长时间内保持不变。对缓存系统来说，少做频繁的小修改，往往比简单地打开缓存更重要。
实验使用GPT-6.1 Sol和另外三个未公开名称的前沿模型。研究团队在两个历史预算下测试六种缓存和截图策略，每种组合运行三次，共完成144次主要测试，另有12次后续测试。任务是从一个公开图书目录中，为32本书收集六项信息；每次运行的结果都与独立准备的参考答案进行比对。
76倍下降是怎样计算出来的
在未公开名称的Model B上，最佳配置把单次运行的估算成本从至少36.21美元降至1.24美元，下降约29倍。相同的优化工作流换用GPT-6.1 Sol后，成本进一步降至0.47美元。
单看GPT-6.1 Sol，较大历史预算配合新的缓存和截图策略后，成本从每次1.97美元降至0.47美元。StackAI称，89%的输入来自缓存，并按缓存价格计费。优化后的运行时间约为4分钟，而原有生产配置在Model B上至少需要约22.5分钟。
在完成率方面，历史预算也同样重要。在12万字符预算下，GPT-6.1 Sol的18次测试中只有3次产生了答案，多数运行触及步骤限制；提高到48万字符后，18次运行全部给出正确答案。StackAI称，最佳配置下的每次运行都找到了任务要求的全部192项事实。
这些数字仍然需要按照实验边界理解。研究规模有限，不同条件的运行次数只有三到四次，且每次任务的调用次数存在差异。StackAI也明确表示，这项研究能够说明总体趋势，但不足以精确区分只相差几个百分点的策略。
代理更快之后，人的注意力成为瓶颈
这项工作的另一个特点，是GPT-6 Astra并不只是被当作最终执行模型。StackAI CTO Frank Hidalgo让Astra在Codex中审查代码库、分析请求结构、设计实验、运行测试并检查结果。人类工程师负责设定目标、选择标准和复核结论。
StackAI称，原本可能需要一到两个月人工完成的调查，大约一周内完成。实验产生的请求、数据轨迹和结果被记录到Asana的Command平台，之后转化为工单和代码变更，再经过审查后上线。
这种分工显示，企业代理的效率提升并不只来自“让模型写更多代码”。更重要的是，模型可以协助建立实验基础设施、并行运行多个配置，再把不同运行结果集中起来比较。工程师的角色则从逐行执行任务，转向定义问题、审核证据和决定哪些变化可以进入生产环境。
AIFlux此前报道的LegalOn降低Codex成本案例也呈现了相似趋势：企业开始把模型调用当作需要分层、限速和预算管理的生产资源，而不是默认让所有任务使用最强模型。
缓存不能替代代理护栏
StackAI的研究还提醒，缓存优化并不意味着可以无限扩大代理的工作范围。长任务仍然会逐渐接近上下文上限，缓存一旦失效，后续调用可能重新按完整价格计费。步骤数、token数和单次运行成本上限，仍然是控制异常任务的重要护栏。
研究团队还发现，在部分后续测试中，完全不删除截图的策略反而有更低的单次调用成本。但这并不意味着截图永远不需要清理。对于更长的任务、更小的上下文窗口或缓存读取价格更高的模型，批量裁剪仍可能有价值。具体策略必须根据模型、任务长度和服务商计费方式测试，而不能简单照搬一个固定比例。
这也是“成本下降76倍”最容易被误读的地方。它代表的是特定代理、特定任务、特定模型和特定实验配置下的估算模型成本，不是所有浏览器代理的通用降本幅度；它也没有说明完整产品运营成本、工程维护成本或人工复核成本同样下降了76倍。
对于希望把浏览器代理投入生产的企业，真正需要建立的可能不是一张模型价格表，而是一套持续评估机制：每个任务使用了多少缓存输入，历史在何时被修改，代理是否重复访问页面，完成一次可靠结果需要多少调用，以及错误发生后能否回放和定位。
Asana表示，相关改动已经用于StackAI的浏览器导航，并计划把类似测试纳入平台评估，让客户和内部团队能够比较不同配置下的成本、运行时间和答案质量。随着代理能够并行运行越来越多实验，决定交付速度的因素也可能从“能否运行测试”转向“人类能否及时理解和审核这些测试结果”。
目前公开信息主要来自OpenAI和StackAI的企业案例及技术文章，尚未见独立机构对这项144次测试进行复核。因此，76倍成本下降、5倍速度提升和89%缓存命中率应视为该研究披露的实验结果，而不是经过外部审计的行业基准。