案例背景：StackAI 浏览器智能体与成本问题
Asana 通过其收购的 StackAI 平台帮助企业客户自动化跨业务系统的工作：客户用 StackAI 无代码构建能浏览网站、填表单、收集信息的工作流。这类浏览器智能体的运行成本由两部分构成——每一步都要把累积的页面文本与截图发给模型，步骤越多、账单越大。Asana 的业务规模放大了问题：单个工作流里的微小低效，乘上客户运行次数就是真金白银。
StackAI CTO Frank Hidalgo（博士）着手把浏览器智能体跑得更快更便宜。他的做法不是组队攻坚，而是把「调查这个智能体、测试改进方案、对比结果」整个交给 Codex 中的 GPT-6 Astra。据其估算，同样的工作人工需要一到两个月，实际约一周完成。案例发布于 10 月 9 日（OpenAI 案例页），Asana 自家的技术研究报告日期为 10 月 8 日——两份材料与第三方分析共同构成本文的信源基础。rohitai 的第三方分析在转述时特别强调了利益结构：这是 OpenAI 与 Asana 联合发布的厂商内容，所有数字为厂商自报。
人机分工：工程师定方向，智能体跑实验
这个案例的分工结构本身就是值得单独拆解的产出。Asana 首席产品官 Arnab Bose 的表述是：「工程师确定方向，GPT-6 Astra 开展实验，再通过 Command 将成果部署到生产环境。」
| 环节 | 承担方 | 具体动作 |
|---|---|---|
| 方向与取舍 | 工程师（Hidalgo） | 让 Astra 调查代码库并解释智能体如何构建每次模型请求；从 Astra 提出的修复方案中挑选三项进入测试 |
| 调查与假设生成 | GPT-6 Astra（Codex） | 梳理代码库，定位缓存缺口与截图处理策略问题，提出修复清单 |
| 实验基建 | GPT-6 Astra（Codex） | 重构代码，让一套前后端能并行跑多个带不同设置的工作流——原代码并不支持受控实验 |
| 执行与记录 | GPT-6 Astra + Command 平台 | 跑完 144 次运行；每次会话的请求、数据轨迹与结果全部记录在 Asana 自研的 Command 软件交付平台，事后可完整复盘 |
值得注意的工程判断：Astra 先跑快速测试确认哪些变量真正影响结果，再重构代码支持并行受控实验——先确认因果变量，再建实验设施，顺序反了会浪费大部分算力。这也是「智能体做研究」区别于「智能体做尝试」的分水岭。
三个低效点：缓存缺口、截图频删、文本裁剪
Astra 的调查定位了原始智能体的三个相互纠缠的低效点：
- 缓存缺口：智能体缓存了固定的指令与工具定义，却没有缓存不断增长的浏览历史（页面文本与截图）——每次请求都把整段历史按全价重新发送。
- 截图逐步删除：旧截图几乎每一步都被移除。
- 文本频繁裁剪：较早的文本几乎每一步都被修剪。
这三个问题相互锁死：截图与文本的每步编辑都会改变历史内容，导致就算缓存了历史也救不回来——缓存命中的前提是请求前缀保持不变。同时，丢掉早期事实还可能迫使智能体重访已经读过的页面，产生二次成本。理解这个纠缠结构，是理解后面实验设计的关键：三项修复必须一起上，单改一项可能无效甚至反向。
144 次实验的设计与结果拆解
正式研究的实验矩阵：2 个历史预算（12 万字符与 48 万字符）× 6 种缓存与截图策略 × 4 个模型 × 每组 3 次运行。任务固定为：从公开演示目录中为 32 本书各收集 6 个字段，代表 StackAI 客户的真实负载形态。四个模型中三个做了匿名化：
| 模型 | 描述 | 相对价格 |
|---|---|---|
| Model A | 其他前沿实验室的较小较便宜模型，2025 年秋发布 | GPT-6.1 Sol 的一半 |
| Model B | 原生产配置所用模型，与 A 同实验室，2026 年夏发布 | 与 GPT-6.1 Sol 同价 |
| Model C | B 的更新版本，2026 年秋发布 | 与 GPT-6.1 Sol 同价 |
| GPT-6.1 Sol | OpenAI | 基准价 |
结果按口径拆成三段，这也是本案例最值得学习的部分——76 倍不是一个单一动作的结果，而是两段降幅相乘：
| 配置阶段 | 单次预估成本 | 降幅口径 |
|---|---|---|
| 原始 Model B 生产配置 | 至少 36.21 美元 | 基线（含因触达步数上限而未完成的运行的开销） |
| 优化后的 Model B 配置 | 1.24 美元 | 工作流改造贡献约 29 倍（不换模型） |
| 优化后的 GPT-6.1 Sol 工作流 | 0.47 美元 | 换模型再贡献 2.6 倍，合计约 76 倍 |
耗时从原配置的至少 22.5 分钟降到约 4 分钟（5 倍）。rohitai 的第三方算术值得转述：以公布的取整数字相减，36.21 美元到 1.24 美元之间省下约 34.97 美元，1.24 到 0.47 之间只省 0.77 美元——降幅的大头发生在换模型之前。此外，仅隔离缓存策略对 GPT-6.1 Sol 本身的影响（大历史预算下），成本从 1.97 美元降到 0.47 美元（4 倍）；metallab 还注意到优化后的 Model C 达到 0.66 美元与 3.5 分钟——单看耗时它比 Sol 还快，76 倍差距的大头来自历史管理修复而非换模型。
把 76 倍读成「换个模型省了 76 倍」是这份数据最容易产生的误读。官方口径是两段相乘：29 倍（工作流）× 2.6 倍（模型）。对已有智能体管线的团队，前 29 倍几乎不依赖任何特定供应商——先做工作流审计，再谈换模型。
机制：为什么多留历史反而更省钱
三个修复方案的生效机制都指向同一个经济杠杆——提示缓存（prompt caching）的计价结构。按 OpenAI 当时（10 月 9 日核验）的定价：缓存命中的输入按普通输入的 5% 计费，而写入缓存比普通输入贵 25%。这个结构决定了「为缓存付费」只在后续被充分复用时才划算。
最优策略的形态印证了这个逻辑：让截图累积到 20 张后再削减到只留最近一张——在两次削减之间，早期历史保持不变，缓存前缀得以延续；配合 48 万字符的大历史预算，输入的缓存命中率达到 89%。imasters 的换算：由于 89% 的输入按 5% 计费，每次调用的输入成本约降为三分之一。同样的机制反过来也成立——案例特别记录了一个反直觉结果：只扩大历史缓存而不改截图逐步删除策略，在四个模型中的三个上反而更贵（大历史预算下）。频繁编辑历史会让缓存前缀反复失效，缓存的写入溢价变成纯损耗。
这条机制对所有「状态随步数累积」的智能体栈都适用，并非 OpenAI 专属：缓存不只属于静态系统提示；每步都修剪上下文是缓存的天敌；修剪批次化、保留前缀稳定，比激进省 token 更省钱。
可靠性发现：历史预算决定成败
案例中最容易被成本数字掩盖、但对生产最有分量的是可靠性结果：在 12 万字符的小历史预算下，GPT-6.1 Sol 的 18 次运行中只有 3 次产出完整答案；把历史预算提到 48 万字符后，18 次全部完成且答案正确。OpenAI 表示优化后的工作流每次运行都完成了任务并给出正确答案。
这个对照的工程含义是：激进裁剪上下文不仅没省钱，还让智能体完不成任务。上下文预算不是单纯的成本旋钮，而是任务成败的开关。Asana 同时保留了对步骤、token 与支出的上限控制，并警告更长或发散的任务可能表现不同——上限护栏与足够的历史预算需要并存，而不是二选一。
口径限制与六步复现清单
在把 76 倍写进任何内部汇报之前，必须先过一遍第三方分析标注的口径限制（主要来自 rohitai 对 Asana 技术报告的审读）：
- 成本口径：0.47 美元是预估的模型调用成本，不含服务器与沙箱开销；基线的「至少 36.21 美元」含未完成运行的开销——未完成运行在真实生产中是否常态，决定基线的代表性。
- 答案口径：最便宜配置曾在多数情况下返回摘要而非要求的完整表格——Sol 在作答时总数正确，但「正确的总数」与「可用的完整目录」是不同的交付物；最终答案的调优不在该研究范围内。
- 统计口径：每组主要条件仅 3 次重复，证据强度限于「这一个工作流」；跨模型运行的推理、工具与缓存设置并不完全一致；不能推广为模型排名，也不能承诺客户账单上的等效节省。
- 利益口径：OpenAI 案例与 Asana 报告均为厂商内容；研究中 GPT-6.1 Sol 的 2.6 倍优势恰是 OpenAI 的卖点，阅读时应把这一段视为厂商最优叙事。
剥离口径限制后，可复现的方法论可以压缩为六步：
- 审计请求结构：确认哪些部分被缓存、哪些每步全价重发——重点检查随步数增长的历史内容（页面文本、工具输出、截图）是否在缓存范围外。
- 定位破坏缓存前缀的操作：找出每步都在修改历史的逻辑（截图删除、文本修剪），这些操作让任何缓存策略失效。
- 设计受控实验矩阵：小规模快测确认关键变量，再并行跑「预算 × 策略」组合，每组至少 3 次重复；原代码不支持受控实验就先重构。
- 批量修剪代替逐步修剪：让历史内容累积到阈值后再一次性削减（本案例：截图累积 20 张后削到 1 张），换取缓存前缀的稳定窗口。
- 同时校验可靠性与成本：每种配置记录完成率与答案正确性——本案例显示小预算配置 18 次仅 3 次完成，单看成本会选出不能用的配置。
- 全程留痕：每次会话的请求、数据轨迹与结果进可回放的平台（Asana 用自研 Command），复盘与追责都依赖这条记录。
三条红线同样明确：其一，缓存命中单价 5% 的前提是前缀不变，任何「边跑边改历史」的模式下扩大缓存都可能更贵（本案例四模型中三个反例）；其二，成本优化不能越过可靠性验收——最便宜的配置可能交不出要求的产物；其三，模型间比较必须固定任务、预算与策略设置，本案例的跨模型结果混合了不同设置，只支持「工作流敏感度」结论，不支持模型优劣结论。
把案例放回本站脉络：R-CASE-29 的 CIO 省钱账本讨论了「关闭率乘以重开率」的成本落袋口径，R-CASE-26 的 Chatham Financial 复盘展示了模型分级路由的省法。Asana 这份案例补上了第三块拼图：在模型与平台选择之前，工作流层面的缓存与上下文管理是多数团队尚未动用的量级红利。值得跟踪的后续：Asana 是否会把优化后的工作流配置推广到全部 StackAI 客户并披露生产环境的实际账单变化——那是比测试环境 0.47 美元更接近真相的数字。目前官方及行业暂未披露更多细节，后续将持续跟进迭代动态。