Asana 浏览器 Agent 案例：GPT-6.1 Sol 与历史缓存怎样降低成本

Asana 的浏览器 Agent 降本案例说明：多步骤自动化的成本，既取决于模型，也取决于页面历史和截图如何保存。官方研究在固定采集任务中，将优化后的 GPT-6.1 Sol 工作流与原生产方案比较，报告估算模型成本降至约 1/76，运行速度约为原来的 5 倍。

案例来源与时间

• 官方案例发布：2026 年 10 月 9 日；本站核对：2026 年 10 月 13 日。
• 本文为官方案例的中文摘要与本站实施建议。数据来自 OpenAI 与 Asana 披露，本站未复测。
• OpenAI 官方案例；Asana 研究说明。

实际解决了什么问题

该 Agent 用于网页导航与信息采集。团队发现，历史页面内容不断被重新发送，频繁删改旧截图又破坏缓存复用。优化包括让历史更稳定、扩大保留预算，以及成批清理截图。

研究包含 144 次主要运行，任务是从演示书目采集 32 本书的六个字段。优化后的 GPT-6.1 Sol 工作流估算模型成本约为每次 0.47 美元，耗时约四分钟。这里的比较同时涉及模型与工作流变化；同一模型的成本优化约为四倍，不能把 76 倍解释成单纯换模型的收益。

怎么借鉴到自己的浏览器 Agent

以下是本站建议的验证方法，并非 Asana 的额外已披露流程。

1. 选定一组可重复、获准访问的页面，固定要采集的字段，先人工准备正确答案。
2. 保存每次调用的输入量、缓存命中、输出量、重试次数、完成时间和字段准确率。
3. 在同一个模型上比较逐步删截图、批量整理历史两种策略，先看上下文管理的影响。
4. 再比较其他模型，保持网站、任务、成功条件和成本计价口径相同。
5. 给失败运行设置步数和费用上限；页面卡住时停止并记录原因，避免反复访问。

适用条件与限制

适合网页信息采集、后台表单和多步骤浏览器任务的评估。该实验来自固定演示目录，每个主要配置重复次数有限，也没有覆盖所有网站的登录、验证码和页面变更。因此，上线预算应使用自己的任务数据，不能直接套用 0.47 美元。

浏览器环境、代理费用、人工复核和维护成本，也应另行计入。自动化采集还要遵守目标站点的访问规则。

继续选型

查看 GPT-6.1 Sol 模型资料，或浏览更多智能体与自动化案例。