浏览器代理每走一步都可能把页面文字、截图、工具定义和先前操作重新发给模型。直觉上，想省钱就换更便宜的模型，或者尽快删掉旧截图。Asana与OpenAI在10月8日至9日公布的案例，恰好说明这种直觉并不总对。Asana旗下StackAI团队把代理的历史记录缓存方式、截图裁剪节奏和上下文预算一起改动后，在一项受控测试里，优化后的GPT-6.1 Sol流程平均单次模型成本约0.47美元，运行时间约4分钟；与原先使用另一款同价位模型的生产配置相比，估算成本低76倍、速度约快5倍。标题里的倍数很醒目，但它首先是一个特定任务、特定对照组的实验结果，不是所有浏览器代理通用的降本承诺。
这个案例不同于单纯展示“AI帮工程师写代码”。StackAI CTO Frank Hidalgo把问题交给GPT-6 Astra在Codex里研究：先梳理请求是如何构造的，再记录每一步成本，做不同缓存策略和历史预算的对照。人负责定目标、选择方案和审核变更，模型承担大量试验与分析。Asana说，原本估计要一到两个月的研究，一周左右完成；但真正值得同行复用的不是工期口号，而是它留下的实验设计和每一步请求记录。
缓存失效，问题不在缓存开关本身
原代理已经缓存固定提示词和工具定义，却没缓存不断增长的网页历史。更麻烦的是，它几乎每步都删去旧截图、裁剪旧文字。很多模型服务的提示词缓存只复用最长不变前缀；早期历史一旦被修改，后面的大段内容也会失去复用机会。这样看，删内容虽然让单次请求短一点，却可能让同一段信息反复按原价输入。代理还可能因为删掉关键事实重新访问页面，增加步骤和等待。优化重点因此从“尽量短”变成“尽量稳定、只在必要时成批删改”。
团队测试的改法有三项：把缓存覆盖到浏览历史；把历史预算由12万字符扩至48万字符；截图累积到一定数量后再成批裁剪，最佳条件下最多保留20张，然后缩回最近一张。它们的组合并非越大越好，而是让较长的一段请求在连续步骤里保持不变，便于重复读取缓存。Asana公布的实验覆盖四款模型、两档预算、六种缓存和截图策略，每个条件重复三次，总计144次运行，另有12次补充测试。任务固定为从公开演示图书目录里为32本书收集各六项资料。这样做可以比较成本、速度和正确性，却不能自动代表所有网站、登录场景或长时任务。
数据也揭示了“模型选择”和“流程优化”的分量。对于原生产配置使用的Model B，优化流程把单次估算成本从至少36.21美元降至1.24美元，约29倍。再换到优化配置下的GPT-6.1 Sol，成本降到0.47美元；在Sol自身的同一预算里，改变缓存与截图策略又把成本从1.97美元降至0.47美元，约四倍。原始配置有部分运行在步数上限前未完成，所以“至少36.21美元”是下界，76倍比较也受这个对照设置影响。若把整个改善都归功于某个新模型，会把工程上的主要发现掩盖掉。
完成率同样重要。Asana说，在较小历史预算下，GPT-6.1 Sol的18次运行只有三次产生答案；扩大预算后，18次均给出正确答案。这个任务有192个事实点要收集，代理若过早忘掉页面内容，即使单步便宜也可能无法完成。优化后约89%的输入由缓存读取，其价格只是未缓存输入的一小部分。测试里的答案由独立准备的参考结果评分；不过每个条件重复次数有限，个别几百分点差异不能读成精确规律，文章提供的折线图也不是原始逐次数据的完整公开表。
从实验结果到产品，边界仍要留着
Asana称，相关浏览器导航改动已进入StackAI产品；团队还在开发更方便重复此类实验的工具。记录请求、轨迹和结果的Command平台在这里是证据仓库：实验发现转为工单、代码审查和发布，而不是让一次看似成功的代理回答直接决定上线。对于要复刻这套办法的团队，先检查自己的请求前缀是否频繁变化，再比较缓存命中、单次成本、总步骤、正确率和失败率，比照搬“20张截图”这个数字更可靠。缓存价格、模型上下文与任务长度变化时，最佳阈值也会变。
案例还提到一次反常发现：在这项任务里完全不裁剪截图，部分模型的单次调用成本甚至比最佳分批方案更低。这不意味着永远无需裁剪；长期运行会遇到上下文上限、漂移和缓存失效，仍需要步骤、令牌与总费用上限。原研究没有测试所有真实客户工作流，也未证明大规模部署后的平均账单会按同样倍数下降。其真正的启发是，代理成本不仅由模型标价决定，更由输入历史如何增长、何时改变和是否需要返工决定。若一套系统不能把每次请求和结果留下来，团队甚至无法知道“便宜”究竟来自哪里。
