Asana 的 StackAI 平台让客户用低代码方式构建浏览器自动化工流：打开网页、填表、收集信息。这类 agent 每次请求都要携带不断增长的页面文本和截图历史，量一大，成本和时间都会明显放大。StackAI CTO Frank Hidalgo 让 GPT-6 Astra in Codex 去调查这个浏览器 agent、提出改进并跑实验对比；他估计这活儿手工做要一到两个月，结果用 agent 大约一周完成。

GPT-6 Astra 先梳理代码库，发现 agent 只缓存了固定指令和工具定义，没有缓存随任务增长的页面文本与截图历史，所以每次请求都按全价重新发送这些历史；同时 agent 几乎每一步都在丢旧截图、裁剪文本。每次改动都会改变历史，所以单纯缓存历史没有用，丢失的事实还可能让它重新访问已经读过的页面。

Hidalgo 选了三个修复方向：把缓存扩展到浏览历史；提高文本保留量；批量删除截图而不是每步都删。由于原代码不适合做控制实验，GPT-6 Astra 先重构代码，让一个前端/后端可以并行支撑多套 workflow，每套有独立设置，然后跑了一个 144 次运行的研究：2 个历史预算（120,000 和 480,000 字符）× 6 种缓存与截图策略 × 4 个模型 × 3 次重复。任务是同一个：从公开 demo 目录里给 32 本书各收集 6 个字段，和部分 StackAI 客户跑的工作流类似。

最优策略是让截图累积到 20 张后再一次性砍到只剩最近 1 张，这样两次清理之间历史保持稳定，配合更大的历史预算就形成新工作流。效果上，Model B 上的原生产配置估算模型成本至少 $36.21（有些 run 到步数上限还没结束，所以是下界），优化后在 Model B 上降到 $1.24，约 29x；再把工作流切到 GPT-6.1 Sol，降到 $0.47，比原配置便宜 76x。单次运行耗时从至少 22.5 分钟降到约 4 分钟，提速 5 倍。单独看 GPT-6.1 Sol，在大历史预算下，新缓存与截图策略把成本从 $1.97 压到 $0.47；每次调用成本约为原来的 1/3，因为 89% 的输入来自缓存，缓存价格为未缓存时的 5%。历史预算也影响能否出结果：小预算下 GPT-6.1 Sol 18 次里只有 3 次产出答案；大预算下 18 次全部产出答案，且都正确。所有优化后的 run 都完成任务并返回正确答案。

这次实验的每个会话请求、数据痕迹和结果都记录在 Command（Asana 的软件交付平台）里，随后转成 ticket、pull request，最终上线。Asana 已经把这套改动发布到 StackAI 的浏览器导航，并计划把类似测试做成平台内建的评估，让客户和内部团队配置 agent 时直接比较成本、运行时间和答案质量。Asana 现在也用 GPT-6 Astra in Codex 在发布前测试产品功能：Astra 在平台上操作、尝试不同输入、向人类 QA 报 bug。