文章正文按原文语言展示。
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 的额外已披露流程。
- 选定一组可重复、获准访问的页面，固定要采集的字段，先人工准备正确答案。
- 保存每次调用的输入量、缓存命中、输出量、重试次数、完成时间和字段准确率。
- 在同一个模型上比较逐步删截图、批量整理历史两种策略，先看上下文管理的影响。
- 再比较其他模型，保持网站、任务、成功条件和成本计价口径相同。
- 给失败运行设置步数和费用上限；页面卡住时停止并记录原因，避免反复访问。
| 观察项 | 用它判断什么 |
|---|---|
| 每个成功任务的总费用 | 便宜调用是否被重试抵消 |
| 已正确采集的字段比例 | 历史裁剪是否丢失证据 |
| 缓存输入占比 | 保存历史是否真正带来复用 |
| 最慢运行与失败运行 | 平均值是否掩盖高成本尾部 |
适用条件与限制
适合网页信息采集、后台表单和多步骤浏览器任务的评估。该实验来自固定演示目录，每个主要配置重复次数有限，也没有覆盖所有网站的登录、验证码和页面变更。因此，上线预算应使用自己的任务数据，不能直接套用 0.47 美元。
浏览器环境、代理费用、人工复核和维护成本，也应另行计入。自动化采集还要遵守目标站点的访问规则。