企业协作平台 Asana 近日公布了一组扎眼的工程数据：旗下 StackAI 平台的网页自动化 Agent 在切换至 OpenAI 的 GPT-6.1 Sol 之后，单次任务预估模型成本从至少 36.21 美元骤降至 0.47 美元，降幅高达 76倍，执行耗时也从超过 22.5 分钟压缩至约 4 分钟。
这则被官方包装为新一代模型实力的案例，很容易让外界得出新模型性价比暴涨 76 倍的简单结论。然而穿透公关包装后的技术底牌表明，这是一场由工程重构主导的算力成本战役：所谓的 76 倍降幅中，29倍 来自底层提示词前缀缓存策略的重写，GPT-6.1 Sol 相比同代竞品带来的实际模型红利只有 2.6倍。
拆解76倍降幅：工程重构拿走大头，模型贡献仅占两成半
要看清这场测试的底牌，必须把 76 倍的复合数字拆开算账。在 Asana 的基准测试中，单一任务是从公开演示目录中抓取 32 本图书的各 6 个字段，模拟企业客户在表单填写和跨系统数据搬运中的真实负载。
原始生产环境采用的是某前沿实验室 2026 年夏季发布的 Model B。在未做深层架构调优前，单次抓取成本保底为 36.21 美元，耗时超过 22.5 分钟。需要指出的是，该基准包含因超时或打满步数上限而被迫中断的会话，因此 36.21 美元只是系统记录到的保守下限。
当工程师仅对 Model B 所在的工作流实施前缀缓存与上下文修剪优化后，单次运行成本便从至少 36.21 美元直线跌落至 1.24 美元。这意味着仅凭工程架构的重写，团队就已经兑现了 29倍 的成本缩减。
随后，团队在相同的优化架构下将模型换为 GPT-6.1 Sol，成本进一步降至 0.47 美元。与优化后的 Model B 相比，GPT-6.1 Sol 带来的实际提升幅度是 2.6 倍。将 29 倍的工程重构收益与 2.6 倍的模型切换收益相乘，才拼凑出公关稿里醒目的 76 倍。
对于正在规划 Agent 落地预算的工程团队而言，这种拆解意味着不能寄希望于直接采购一个新 API 就能自动削减账单。如果系统本身的工程设计存在缺陷，无论接入多强大的模型，都会在低效的上下文中空耗预算。
反直觉的上下文管理：越想省 Token，前缀缓存越被击穿
浏览器 Agent 在运行时需要频繁捕获页面 DOM 文本与屏幕渲染截图。随着导航步数增加，输入 Token 会呈阶梯式膨胀。各大模型厂商虽然均上线了前缀缓存机制，对完全一致的历史输入给予低至原价 5% 的折扣，但多数 Agent 架构在实际运行中几乎无法吃到这一红利。
精简上下文的传统工程直觉，在长文本前缀缓存机制面前反而成了昂贵的负债。
StackAI 团队最初的技术瓶颈恰恰出在看似合理的优化手段上。旧架构虽然缓存了固定的系统指令与工具定义，但每执行一步操作，程序都会动态修剪旧网页的冗余文本，并立刻丢弃上一轮的页面截图以节省空间。
这种操作破坏了前缀的一致性。大模型的前缀缓存依赖输入文本的严格对齐，只要中间插入、删改了一段文本或替换了一张图片，后续内容的缓存哈希就会全部失效。Agent 每次请求都不得不以全额单价重新向 API 发送数百 KB 甚至数 MB 的全量历史，账单自然迅速失控。此外，由于早期页面信息被过早剪除，Agent 一旦迷失方向，必须重新发起网络请求重复访问同一页面，拉长了整个任务的耗时。
StackAI CTO Frank Hidalgo 采取了反直觉的治理手段：
首先，将整个浏览交互的上下文历史整体纳入缓存；
其次，不仅不缩减文本，反而将历史文本预算从 12 万字符直接拉高四倍至 48 万字符；
第三，改变单步丢弃截图的逻辑，允许截图连续累积，直到达到 20 张时才一次性剔除旧图，仅保留最新一张。
这种批量修剪的方式，让前缀在长达数十个交互步数内保持稳定不变。在最终的 GPT-6.1 Sol 优化方案中，单次调用的输入 Token 有 89%命中缓存，而这部分 Token 的计费价格只有未缓存常规价格的 5%。更为宽裕的历史预算也避免了关键信息的丢失，在 48 万字符预算下，所有 18 次测试均顺利拿到正确答案，而在 12 万小预算配置下，这一成功指标仅为 3 次。
- 建议.设计长上下文多步 Agent 时，宁可增加结构化冗余，也要优先维护输入前缀的不可变性，用极高的缓存命中率抵消长文本的基准单价。
自动化开发闭环与未经验证的基准盲区
除了成本模型本身的演变，这起案例呈现的另一个值得关注的信号是研发流程本身的重构。面对长文本预算与修剪策略构成的复杂测试矩阵，传统人工排查与验证通常需要投入工程师一到两个月的时间。
本次测试矩阵包含 144 次系统运行与 12 次追踪实验。Hidalgo 并没有亲自写测试套件，而是通过 Codex 调动 GPT-6 Astra 梳理代码库，自动重构了前后端以支持多配置并发跑测。工程师只需在睡前配置任务目标，GPT-6 Astra 即可自主完成参数遍历、统计用量、并通过内部的交付平台生成 Pull Request，最终上线生产环境。这套闭环将原本数月的实验周期压缩到了大约一周。
| 对比模型 | 厂商定位 | 相对价格标杆 | 优化后单次预估成本 |
|---|---|---|---|
| Model A | 2025年秋发布较小模型 | GPT-6.1 Sol 的一半 | 未采用（基线未达标） |
| Model B | 2026年夏发布主力模型 | 与 GPT-6.1 Sol 同价 | $1.24（原基准 ≥$36.21） |
| Model C | 2026年秋 Model B 升级版 | 与 GPT-6.1 Sol 同价 | 成本相近但耗时更长 |
| GPT-6.1 Sol | OpenAI 旗舰模型 | 基准参考系 | $0.47（提速5倍至约4分钟） |
不过，在审视该案例时同样需要警惕测试环境的局限性。参与横向对比的 Model A、Model B 与 Model C 均隐藏了真实名称，测试又属于 OpenAI 与 Asana 的联合宣传材料，难以完全排除针对 GPT-6.1 Sol 优势场景筛选任务的可能性。
此外，抓取 32 本图书的表单与列表属于高度结构化的受控场景。StackAI 官方在附带说明中也承认，每项策略分支仅跑了 3 至 4 次样本，主要是确认数量级上的宏观走向，无法作为评估细微性能差异的严密统计依据。真实企业环境下的网页充斥着复杂的动态渲染反爬机制、非预期弹窗以及跨域验证，在这些极端场景下，大容量前缀缓存是否仍能保持近九成的命中率，依然需要经过更大规模商业负载的检验。
- 风险.受控基准中的前缀稳定性极高，但在面对高频重定向、多弹窗及混乱 DOM 的生产环境中，缓存前缀容易被频繁打断，账单降幅可能远达不到 76 倍的理想状态。