先看证据
先看清 76 倍的比较对象
Asana 发布了一项 StackAI 浏览器代理优化案例：该代理面向无需编写代码的业务工作流，能够浏览网站、填写表单和收集信息。StackAI CTO Frank Hidalgo 让 GPT-6 Astra 在 Codex 中检查代理代码、设计实验并比较结果，目标是在不降低答案质量的前提下减少运行成本和时间。优化后的 GPT-6.1 Sol 工作流平均每次估算模型成本为 0.47 美元，运行约 4 分钟。
醒目的“便宜 76 倍、快 5 倍”，比较的是优化后的 Sol 工作流与原生产配置使用的 Model B，而不是同一模型优化前后的差距。拆开看，Model B 从每次至少 36.21 美元降至 1.24 美元，降幅约 29 倍；Sol 自身则从 1.97 美元降至 0.47 美元，约 4 倍。报告称 Sol 的原基线存在触及步数上限的运行，因此成本和速度对比是近似值，基线成本、耗时也按下限处理。
上下文怎样被改写，决定缓存能否复用
问题出在请求历史的组织方式。代理原本会缓存固定的指令和工具定义，却没有缓存不断增长的网页文本与截图历史，于是每次调用都要重新发送这些内容。与此同时，它几乎每一步都会裁剪旧文本、删除旧截图，让请求中的历史反复变化；即使内容大体相同，连续不变的前缀被打断，也很难继续复用缓存。
优化思路不是简单地“多开缓存”，而是让已读历史尽可能保持原样，并把缓存扩展到浏览历史。缓存依赖请求里连续不变的前缀，旧内容频繁改写会削弱命中。Sol 的缓存输入价格是未缓存输入的 5%，最佳配置中 89% 的输入来自缓存，因此历史如何保留，直接变成了成本设计的一部分。
批量清理截图，换取更稳定的历史
工程师选了三个方向测试：缓存浏览历史、增加可保留文本量，以及不再每一步都删除截图。结果最好的 Sol 配置把历史预算从 12 万字符提高到 48 万字符，并让截图最多累积到 20 张，再一次性缩减到最近的 1 张。这样做不是为了永久保存所有截图，而是减少两次清理之间对旧历史的改动。
更长的历史预算也关系到任务能否完成。在 12 万字符预算下，Sol 18 次运行中只有 3 次产出答案；提高到 48 万字符后，18 次都完成并给出正确答案。这个结果提醒技术负责人，压缩上下文虽然可能降低单次输入量，但如果丢掉完成任务所需的信息，代理就可能重访页面，甚至无法交付答案。
144 次实验把优化变成可比较的工程问题
这次主实验不是单次演示，而是一个可对照的配置矩阵：4 个模型、6 种缓存与截图策略、2 种历史预算，每个条件运行 3 次，共 144 次。所有配置执行同一项任务：从公开演示书籍目录的 32 本书中，各提取 6 项信息，也就是收集 192 个事实。另有 12 次不删除截图的后续测试，帮助团队继续检查截图处理策略。
实验框架本身也需要改造，因为原有代码并不适合受控比较。GPT-6 Astra 协助重构前后端，让多种工作流可以并行运行、各自采用不同设置，并检查请求、使用记录和输出；工程师则审阅方案与结论。Asana 称手工研究估计需要一到两个月，这轮工作约一周完成。关键不在于把这段时间差当作普遍生产力指标，而在于代理参与了实验执行和分析，人仍负责确定问题、选择改动和审核结果。
可迁移的是排查顺序，不是 76 倍承诺
对运行浏览代理的团队，这个案例给出了一条实际排查顺序：先追踪每次请求重复发送了多少历史，再观察缓存命中、运行成本、耗时和任务完成率如何随历史策略变化。只有在同一任务、可比较的配置下做小规模对照，团队才能分辨节省来自缓存、上下文预算、截图清理，还是模型本身。案例也表明，工作流优化可能为选用能力更强的模型腾出成本空间，但这不等于模型越强就必然更便宜。
外推边界同样明确。测试只覆盖一个书籍目录演示任务，每个条件运行三次，不能说明其他客户工作流会获得相同降幅；原生产基线还受到步数上限影响。因而，76 倍更适合作为“检查上下文重复与历史改写”的线索，而非预算预测。落地时应先用目标业务任务复现实验，同时核对答案质量、完成率和缓存成本，再决定是否调整历史预算或模型配置。