Asana公布浏览器智能体实验，优化缓存显著降本

发生了什么

Asana通过144次实验比较4个模型与多种浏览历史处理策略。OpenAI案例称，优化后的GPT-6.1 Sol流程平均模型费用约0.47美元，较原生产配置低76倍、运行快5倍。比较同时改变了模型和工作流，不能把全部改善归给模型本身。1

这篇案例更有用的部分，是指出缓存与历史编辑怎样影响浏览器智能体的费用。

具体是什么

文章发现，原流程没有有效复用不断增长的网页文字和截图历史，并且频繁删改历史，进一步破坏缓存。实验据此调整历史保留与截图清理方式。1

对于自己的系统，可以把问题拆成两类：模型是否在做必要的工作，系统是否为已经做过的工作重复付费。一次答案正确，只能说明结果通过，无法说明过程没有浪费。

怎么用

先选一个稳定、可重复的浏览任务，保存原始请求、模型用量、工具轨迹和最终结果。必须确认每次采集的目标与字段相同，否则成本比较没有共同基础。

接着检查上下文变化。哪些内容每轮都保持不变，哪些内容只是追加，哪些清理动作会导致大量历史重新发送。把这些变化与实际缓存命中对应起来，而不是凭请求看起来相似就认定缓存生效。

分别测试保留更多文字、批量移除截图和调整缓存策略。每次记录正确字段数量、失败重试、完成时间和总费用。若某种方法更便宜但漏采数据，应视为质量下降，而不是单纯优化成功。

最后用另外一类页面验证。一个在图书目录上有效的策略，不一定适合长表单、动态页面或需要精细视觉判断的任务。

意味着什么

我的判断是，浏览器智能体的优化空间很大一部分存在于模型之外。上下文如何组织、页面观察怎样保留、失败后怎么恢复，都可能影响费用和速度。

这对小团队尤其有价值，因为不一定要重新训练模型，也能改善现有系统。先观察真实轨迹，往往比反复修改一句提示词更容易找到稳定收益。

如果准备对外宣传降本结果，应把基线、任务、模型和设置一起给出，让别人能判断这个数字适用于什么条件。

局限与风险

76倍与5倍对应案例中的具体配置和测试任务，不是浏览器自动化的普遍结果。1 更长历史也可能带来内存、延迟或无关信息问题。

本文没有复现实验。正式修改生产系统前，应保留旧策略、使用代表性任务回归，并确保日志不会无意保存账户凭据或不必要的客户数据。成本优化必须以任务完整性不受损为前提。