浏览器代理降本的缓存改造思路

原文要点

Asana 的 StackAI 团队让 GPT-6 Astra 在 Codex 里排查浏览器代理：代理只缓存了固定指令和工具定义，逐步增长的页面文本和截图历史每次都全价重发；而且几乎每步都裁剪文本、丢旧截图，导致历史被改动，缓存也失效。选定三项改造测试：缓存扩展到浏览历史、增大文本保留量、截图攒到 20 张再裁回最近 1 张。对照实验用 12 万和 48 万字符两档历史预算、6 种缓存与截图策略、4 个模型各跑 3 次，任务是采集 32 本书各 6 个字段。作者称优化后每次运行估算模型成本 0.47 美元、约 4 分钟，比原生产配置便宜 76 倍、快 5 倍；89% 输入命中缓存，缓存价是全价的 5%；大历史预算下 18 次运行全部产出正确答案，小预算只有 3 次。

这次做成什么

把一个自己的浏览器/网页代理的提示词组装方式改造成“缓存友好”：让请求前缀保持稳定、让历史只追加不改写、让截图批量退役，并用同一任务多配置对照验证。以下练习任务与数据为本站独立设计，效果数字均归作者称，不保证复现。

准备什么

• 一个你自己能改代码的网页浏览代理（能逐步记录页面文本和截图并重发给模型）
• 所用模型 API 支持提示词缓存计费（缓存命中输入价更低），并能从账单或用量记录看到缓存命中率
• 一个可重复执行的小型采集任务用于对照实验
• 能记录每次运行的成本、耗时和是否正确产出答案

具体怎么做

1. 先诊断请求是怎么拼的

   让编码代理（或自己）梳理代码：每次发给模型的请求包含哪些部分。重点看三处——固定指令和工具定义是否放在最前面且被缓存；浏览历史是否每步全量重发；是否存在每步裁剪文本或删截图的逻辑，因为这种改动会让整个历史前缀变化，缓存全部失效。

2. 把历史改成只追加的缓存段

   重构请求组装：固定指令 + 工具定义在前，其后是只追加不回改的浏览历史段。文本保留上限放大（实验中作者用 12 万与 48 万字符两档对照）；截图不再每步删，而是攒到约 20 张时一次性裁回最近 1 张，这样两次裁剪之间的历史前缀保持逐字节不变，缓存才能命中。

3. 改造成支持并行对照实验

   把配置抽出来：历史预算、截图退役策略、缓存开关各做成可配参数，一套前后端同时跑多个配置，每个配置跑至少 3 次取平均，避免单次波动误导结论。

4. 用同一任务跑对照并记录

   每个配置执行同一个任务（比如从一个公开演示商品目录采集固定字段）。记录每次运行的估算成本、耗时、是否产出答案、答案是否正确、输入中缓存命中占比。

5. 选最优配置上线并持续监控

   选成本、速度、完成率综合最优的组合上线。把每次运行的成本曲线和缓存命中率纳入监控，防止后续改动悄悄破坏前缀稳定性。

可直接复制的材料

{
  "request_layout": [
    {"segment": "static_instructions", "cacheable": true, "note": "系统指令与工具定义，固定不变放最前"},
    {"segment": "browsing_history_append_only", "cacheable": true, "note": "页面文本与截图引用只追加，不回改不逐条删除"},
    {"segment": "latest_observation", "cacheable": false, "note": "本步最新观察，放在最后"}
  ],
  "history_char_budget": 480000,
  "screenshot_policy": {"mode": "batch_evict", "accumulate_to": 20, "evict_down_to_recent": 1},
  "text_trimming": "disabled_within_budget"
}

config,run,est_cost_usd,duration_min,answered,answer_correct,cache_hit_pct
baseline_trim_every_step,1,1.97,9.2,true,true,12
baseline_trim_every_step,2,2.11,10.1,true,false,9
baseline_trim_every_step,3,1.89,8.7,true,true,14
history480k_batch20,1,0.52,4.3,true,true,88
history480k_batch20,2,0.47,3.9,true,true,90
history480k_batch20,3,0.49,4.1,true,true,89

输入与输出示例

本站虚构演示数字，仅示意记录与比较方式，非实际运行结果，也不代表你项目的收益比例。

输入

任务：从练习用公开演示书目录采集 32 本书的书名、作者、价格、库存、评分、简介六个字段；对比两个配置：A=每步裁剪历史，B=48 万字符预算+截图攒 20 张批量退役。

对应输出

记录表示意：配置 A 三次平均成本 1.99 美元、平均 9.3 分钟、3/3 产出答案；配置 B 三次平均 0.49 美元、4.1 分钟、3/3 产出且全部正确，缓存命中约 89%。结论：B 成本低约 4 倍且更快。

做完检查这些

• 改造后连续多步请求中，固定指令与历史段的前缀逐字节一致，缓存命中率显著上升（作者案例中达 89%）
• 截图不再是每步删除，而是积累到阈值后批量处理
• 同一任务下，新配置的成本和耗时低于基线，且答案正确率不下降
• 增大历史预算后，之前因历史被裁而产不出答案的运行能够完成

容易卡住的地方

• 只缓存历史但不停止每步裁剪是无效的：任何对历史的回改都会改变前缀，作者明确指出单独缓存历史帮不上忙
• 文本保留量过小会让代理忘记已读页面而重复访问，作者实验中小预算 18 次只有 3 次产出答案
• 76 倍、5 倍、0.47 美元是作者在特定任务和模型组合上的结果，你的收益取决于任务形态和缓存定价，勿当作承诺
• 缓存定价依服务商而定（作者案例中缓存输入价为全价 5%），先确认你的模型是否提供类似计费