GPT-6.1 Sol Prompt Cache 优化教程：Asana AI Agent 成本降低 76 倍的工程实践

一、为什么 AI Agent 的成本会越来越高？

传统 AI 聊天应用通常有一个比较简单的流程：

用户提问，模型回答。

但 AI Agent 完全不同。

一个浏览器 Agent 可能连续执行：

打开页面 → 读取内容 → 点击按钮 → 截图 → 分析页面 → 再次点击 → 再次截图 → 完成任务。

每次进行下一步操作，模型都需要一定的历史信息。

如果开发者不加控制，系统可能反复将大量相同的上下文提交给模型。

最终导致：

单次任务消耗的 Token 远远超过预期。

2026 年 10 月 8 日，Asana 发布了一篇值得 AI Agent 开发者认真研究的工程文章。

团队通过优化浏览器 Agent 的提示词缓存和历史管理策略，在特定评测环境中，使用 GPT-6.1 Sol 达到了：

约 76 倍成本下降，以及约 5 倍速度提升。

其中，约 89% 的输入内容通过缓存读取。

但需要明确：

这不是 GPT-6.1 Sol 在所有业务中天然带来的性能收益。

结果来自 Asana 对 Agent 历史管理、缓存策略和模型选择的组合优化。

二、Asana 原来的 Agent 遇到了什么问题？

Asana 的浏览器 Agent 需要处理网页文本、截图、工具结果和历史操作。

每次调用模型时，都可能重复包含：

• System Prompt；
• 工具定义；
• 用户任务；
• 网页信息；
• 页面截图；
• 历史执行过程。

部分信息本来可以重复利用。

但他们发现，原有 Agent 在每一步都会调整历史内容。

例如：

第一轮：

System Prompt
Tools
Screenshot A

第二轮：

System Prompt
Tools
Screenshot B

第三轮：

System Prompt
Tools
Screenshot C

如果系统不断删除旧截图、替换历史内容，即使前面已经出现过大量相同信息，缓存也可能无法充分命中。

结果就是模型反复处理近似内容。

这正是此次优化要解决的关键问题。

三、Prompt Cache 是什么？

Prompt Cache（提示词缓存）可以帮助模型服务复用之前处理过的输入前缀。

例如，一个长期运行的 Agent 可能每次都携带：

System Instructions
Tool Definitions
Business Rules

如果这些内容保持不变，缓存机制就有机会减少重复处理成本和延迟。

简化理解：

第一次请求：处理完整输入。

后续请求：复用可以命中的稳定前缀，处理新增内容。

但这并不是普通开发者想象中的：

“只要历史里出现过某些文字，就一定可以命中缓存。”

关键通常在于：

请求前缀能否保持稳定。

如果不断修改前面的消息、调整工具定义或插入额外内容，就可能破坏复用条件。

四、为什么删除旧截图反而可能导致成本增加？

这听起来有些反直觉。

减少历史信息，不是应该减少 Token 消耗吗？

从单次请求看，确实可能如此。

但对于具有缓存能力的长任务，需要综合考虑两个成本：

• 新输入的处理成本；
• 缓存输入的读取成本。

假设一个 Agent 有大量可以缓存的历史信息。

如果每一步都删除部分旧内容，原有缓存前缀就可能失效。

因此，尽管请求文本变短，缓存读取比例可能显著下降。

最终造成：

发送的 Token 更少，但按照正常输入价格重新处理的 Token 更多。

Asana 的研究正是围绕这一现象展开。

五、Asana 如何优化历史管理？

Asana 采用的一项重要策略是：

不要每次都修改历史，而是批量处理。

例如原来的策略：

产生截图
↓
删除上一张截图
↓
修改历史
↓
再次请求

优化以后：

产生截图
↓
保留历史
↓
产生更多截图
↓
继续复用缓存
↓
达到预定阈值
↓
批量压缩历史

Asana 在研究中测试了多种策略。

其中一项方案采用约 20:1 的截图批量清理比例，即先保留一组截图，再在达到清理节点时大幅减少截图数量。

这样可以在更多连续调用中保持历史前缀稳定。

团队还将用于测试的历史容量从 120,000 字符提高到 480,000 字符，减少过早截断造成的缓存失效。

这里提到的是 Asana 测试中的字符预算，不应直接当成 GPT-6.1 Sol 的官方 Token 上下文上限。

六、为什么更长的上下文反而可能更便宜？

这也是此次案例最值得开发者思考的一点。

传统开发思路：

减少上下文长度 = 降低成本。

但在缓存命中率较高的场景中，这个等式并不总是成立。

例如：

方案 A：

每次请求都经过大量历史改写。

输入虽然较短，但大部分需要按非缓存价格处理。

方案 B：

请求包含更长的稳定历史。

虽然输入 Token 更多，但很大一部分能够通过缓存读取。

如果缓存读取价格明显低于常规输入价格，方案 B 的综合成本就可能更低。

当然，这并不代表可以无限制增加历史。

过长的上下文仍然可能增加内存负担、超过模型限制，或让模型在大量无关信息中降低执行效率。

正确目标是：

让有价值、可重复利用的历史保持稳定，同时适时清理无关信息。

七、Asana 做了哪些测试？

Asana 官方披露，这项研究比较了四类模型配置，包括 GPT-6.1 Sol 和三种匿名前沿模型。

研究对六种缓存与历史管理策略、两种上下文预算进行测试。

每组条件重复运行三次。

总计进行了 144 次主要运行，随后又完成 12 次补充测试。

团队按照各模型对应的 Token 计费规则计算成本，并使用事先准备的标准答案评估结果。

在最终优化条件下：

• GPT-6.1 Sol 的运行成本较原有生产配置约降低 76 倍；
• 运行速度约提高 5 倍；
• 输入缓存读取比例达到约 89%。

此外，Asana 报告原有生产模型在优化条件下也能实现显著改善。

这说明：

优化缓存结构本身，就是关键收益来源之一。

因此不能简单把 76 倍收益归因于更换模型。

八、怎样计算自己的 Agent 缓存成本？

开发者可以从下面三个指标入手：

1. 普通输入 Token

未命中缓存，需要正常处理的输入。

2. 缓存输入 Token

满足缓存复用条件的输入。

3. 输出 Token

模型生成的内容，包括适用计费规则下的推理与输出消耗。

可以用一个简化公式理解：

总成本 =
普通输入Token × 普通输入单价
+
缓存输入Token × 缓存读取单价
+
输出Token × 输出单价

真实计费还可能包含长上下文价格、缓存写入、服务等级及工具费用。

一个简单的示例

假设某服务：

普通输入价格为每百万 Token 2 美元。

缓存读取价格为每百万 Token 0.2 美元。

某次任务输入 100 万 Token，其中 80% 命中缓存。

那么普通输入：

200,000 Tokens

费用约：

$0.40

缓存输入：

800,000 Tokens

费用约：

$0.16

输入合计：

$0.56

如果全部按正常输入价格处理：

$2.00

两者会存在明显差异。

以上单价仅为演示缓存机制的假设数字，不代表 GPT-6.1 Sol 当前的正式计费报价。

九、如何在 Agent 中设计稳定的 Prompt 前缀？

建议采用明确的提示词顺序。

例如：

System Prompt
↓
Tool Definitions
↓
Stable Business Rules
↓
Project Context
↓
Conversation History
↓
New Tool Results

这样更容易维持稳定内容位于前面、新增信息位于后面的结构。

开发者应尽量避免：

每次请求都重新排列工具定义。

每轮动态重写 System Prompt。

在历史消息开头插入时间戳。

随意删除较早但仍在缓存窗口中的工具结果。

当然，实际缓存行为取决于模型提供商和 API 支持情况。

因此不能把固定消息顺序当成保证 100% 缓存命中的规则。

十、一个简单的 Agent 历史管理示例

下面演示如何区分稳定消息和动态消息。

SYSTEM_PROMPT = """
You are a browser automation assistant.

Follow the user's instructions.
Do not perform destructive actions
without explicit approval.
"""

stable_messages = [
    {
        "role": "system",
        "content": SYSTEM_PROMPT
    }
]

history = []

def build_messages(user_message):
    return (
        stable_messages
        + history
        + [
            {
                "role": "user",
                "content": user_message
            }
        ]
    )

实际运行时，应按照目标 API 的消息协议构建请求。

当历史逐渐增加，可以把旧记录移到摘要层或任务记忆中。

但不要简单地在每次调用时重新压缩全部历史。

合理策略可以是：

稳定提示词
+
近期完整历史
+
定期生成的历史摘要
+
当前任务结果

该结构只是通用工程示意，不会自动启用某一家模型的 Prompt Cache。

十一、什么时候应该清理 Agent 上下文？

可以关注以下条件：

达到上下文预算

当前任务历史接近系统为该任务设置的预算。

信息已失效

例如旧网页截图已经不再代表当前页面。

任务阶段发生变化

例如从网页搜索转向最终报告生成。

任务出现大量重复

反复保存相同工具结果会造成浪费。

可能影响准确性

过多旧信息让模型无法明确当前目标。

这里的核心原则是：

不是完全不清理，而是减少高频、无必要的历史修改。

十二、如何建立 Agent 成本监控？

一个成熟的 AI Agent 平台应记录：

尤其需要关注：

每成功任务成本。

如果某个模型非常便宜，但经常失败，需要重复执行十几次，就不一定具有真实成本优势。

反过来，某个模型 Token 单价较高，但任务成功率更好，也可能降低总体费用。

十三、这对 AI API Gateway 有什么启示？

过去很多 API Gateway 的主要功能是：

请求转发、限流、鉴权、计费、日志和模型路由。

但 Agent 系统的成本结构更加复杂。

未来网关可能需要进一步理解：

• 请求上下文；
• 缓存命中；
• 多轮会话；
• 工具调用；
• 任务级成本；
• 模型切换；
• 成功率与重试。

因此，一个只记录 Token 单价的网关，并不足以全面衡量 AI Agent 的实际成本。

更值得发展的方向是：

模型调用成本管理 → 完整任务成本治理。

十四、开发者应该如何复现这类优化？

推荐从一个已有 Agent 工作流中选取代表性任务。

例如：

自动打开网页、提取数据、填写测试表单、生成报告。

然后保持任务和测试环境不变，分别比较以下方案：

方案 A： 每轮删除旧截图。

方案 B： 保留更多完整历史。

方案 C： 达到阈值后批量清理历史。

方案 D： 使用固定的历史摘要策略。

记录每组实验的 Token 消耗、缓存命中率、执行时间和成功率。

最好重复运行多次，减少偶然因素。

对于涉及页面状态变化的 Agent，测试时还应保持数据与网页环境尽可能一致。

不要只观察一次任务的表现就决定正式上线。

十五、GPT-6.1 Sol 是否适合所有 Agent？

不一定。

对于大量浏览器操作、复杂 Coding 和多轮工具调用，GPT-6.1 Sol 值得进入评测范围。

但简单分类、短摘要、低风险问答等任务，可能不需要相同级别的模型。

选择模型时，建议同时评估：

• 每次模型调用成本；
• 整个任务总成本；
• 完成任务所需步骤；
• 缓存复用；
• 任务正确率；
• 响应速度。

Asana 的案例说明，在正确的架构与缓存策略下，更强模型也可能带来更低的整体任务成本。

但这并不是所有项目都能复制的固定收益。

十六、总结：真正需要优化的，是 Agent 的完整执行过程

Asana 的研究提供了一个重要启示：

AI Agent 成本优化，不只是换一个便宜模型。

提示词历史怎么保存、什么时候清理截图、缓存能否复用、模型是否需要重复执行，都可能显著影响最终费用。

对于开发者来说，更合理的优化顺序是：

先观察数据，再分析重复开销，然后调整历史和缓存策略，最后通过统一测试比较模型。

GPT-6.1 Sol 在 Asana 案例中的表现，证明了模型选择和工程优化结合的重要性。

未来 AI Agent 的竞争，可能不只是模型在单次请求里有多聪明。

而是：

谁能够在保证任务质量的前提下，以更低的成本、更快的速度完成完整工作。

版权信息： 本文由界智通(jieagi)团队编写，图片、文本保留所有权利。未经授权，不得转载或用于商业用途。