Asana 浏览器代理测试：使用 GPT-6.1 Sol 将模型成本降低 76 倍
Asana 表示，在工程师改变浏览历史的保留和缓存方式后，其浏览器代理的成本降低至原来的 1/76，速度提升了五倍。Asana 浏览器代理测试使用 Codex 中的 GPT-6 Astra 调查系统、运行实验并分析追踪记录。随后，GPT-6.1 Sol 在优化后的工作流程中实现了最低的预估模型成本。
这一核心结果看似是模型的胜利，但更重要的发现关乎代理架构。Asana 调整了代理移除截图的时机、扩大历史记录额度，并缓存不断增长的先前步骤记录。这些改变在保留代理完成任务所需信息的同时，减少了重复处理。
这一差异对评估浏览器代理的所有公司都很重要。团队即使换用成本更低的模型，仍可能因糟糕的上下文管理而浪费 token。反过来，团队也可以选择能力更强的模型、保留恰当的历史记录，并降低总体运营成本。Asana 的实验让这两种策略直接展开比较。
Asana 浏览器代理研究改变的不只是模型
Asana 最大的提升来自围绕模型重新设计工作流程，而不只是用一个模型替换另一个模型。
该公司于 2026 年 10 月 8 日发布结果，随后 OpenAI 于 10 月 9 日发布了一篇案例研究。这项工作聚焦于 StackAI 内部的一款浏览器代理；StackAI 是 Asana 于 2026 年早些时候收购的无代码自动化平台。
StackAI 让客户创建可在网站间导航、收集信息并在业务应用中完成表单的代理。这些工作流程类似人类浏览行为，但底层代理会反复将指令、工具、页面文本、截图和先前操作发送给模型。
这种反复传递上下文会形成昂贵的模式。每一步都会比前一步包含更多历史记录。如果较早的内容持续变化，服务提供商就无法可靠地复用其缓存表示。
Asana 最初的代理会缓存固定指令和工具定义，却无法有效缓存不断增长的浏览历史。该代理还会移除旧截图并频繁裁剪文本，从而改变请求中较早的部分。
这些编辑破坏了稳定前缀，即连续模型请求之间保持不变的共同开头。一旦该前缀发生变化，大量浏览历史就必须重新处理。
Asana 的 StackAI 首席技术官 Frank Hidalgo 指导 Codex 中的 GPT-6 Astra 检查这一行为。该模型梳理了代码库，审查请求的组装方式，并识别出值得测试的变量。
Asana 表示，这项研究涵盖了四个前沿模型的 144 次主要运行。它测试了六种缓存和截图策略、两种历史记录额度，以及每种条件下的三次运行。该公司之后还进行了规模较小的后续测试。
每种配置都接收了相同任务：浏览器代理必须从一个公开演示目录中，为 32 本书分别收集六个字段。这意味着代理要找到 192 项事实，同时保留足够的上下文以返回正确的最终答案。
这些模型包括 GPT-6.1 Sol 以及三种匿名替代方案。Asana 将这些系统称为模型 A、B 和 C。模型 B 驱动最初的生产配置，而模型 C 则代表来自同一提供商的较新模型。
Asana 未披露这些提供商，限制了直接的竞争比较。不过，该公司表示，优化后的 GPT-6.1 Sol 工作流程成本仅为原始模型 B 配置的 1/76，完成速度也快约五倍。
该公司此后已在 StackAI 中发布这些浏览器导航改动。这使这项工作从实验室比较转变为生产环境改动，不过 Asana 尚未发布广泛的客户层面性能数据。
为什么提示词缓存成为决定性机制
决定性变量在于，代理能否在调用之间保持大部分累积历史不变。
提示词缓存会存储与未变化提示词前缀相关的可复用计算状态。后续请求可以复用这一状态，而不必从头处理同一份材料。
缓存并不存储可供重放的最终答案。模型仍会处理新内容并生成新响应，只是避免对保持完全相同的合格上下文重复工作。
OpenAI 的提示词缓存指南建议将稳定的指令和参考资料置于变化内容之前。它还建议应用程序追加对话历史，而不是反复改写先前轮次。
Asana 最初的设计在浏览器运行期间违背了第二项原则。几乎每一步中，它都会移除一张较早的截图，有时还会裁剪旧文本。因此，下一次请求的历史记录中间部分发生了变化。
仅缓存固定的系统提示词无法覆盖最大来源的重复输入。浏览器代理会在任务推进过程中累积页面文本、截图、观察结果和工具输出。
Asana 测试了一种称为批量裁剪的不同策略。裁剪是指在累积历史变得过大之前删除较旧的上下文。在选定策略下，代理最多保留 20 张截图，然后将其缩减为最新的一张。
这种方法创造了更长的仅追加历史区间。代理可以在末尾添加新的观察结果，而无需在每一步修改先前内容。因此，每个请求中可供复用的部分更多。
优化后的工作流程还将文本历史额度从 120,000 个字符提高到 480,000 个字符。这为代理保留此前收集到的事实提供了更多空间，而不是将其丢弃。
更大的额度对任务完成率产生了重要影响。根据 Asana 的数据，在较小历史设置下，GPT-6.1 Sol 在 18 次运行中仅有三次生成了答案；在较大设置下，它在全部 18 次运行中都给出了答案。
Asana 表示，这些较大历史记录运行中的每一次都返回了正确答案。这一结果挑战了“积极压缩上下文总能提升代理效率”的假设。
删除上下文会减小请求的即时规模，但也可能迫使代理重新访问页面、重复工具调用，或在缺少早前证据的情况下继续执行。删除操作改变请求前缀时，也可能破坏缓存复用。
因此，最佳策略取决于任务的总体经济性。团队必须考虑输入处理、重复导航、完成率、响应质量，以及失败运行的恢复成本。
Asana 报告称，在优化设置下，GPT-6.1 Sol 89% 的输入来自缓存。这一比例解释了为何能力更强的模型能够成为完整任务中测试成本最低的选项。
这正是 Asana 浏览器代理结果背后的核心机制。该公司并非仅要求模型使用更少 token，而是重组工作流程，使重复 token 的处理成本变得更低。
更多上下文帮助代理可靠完成任务
最便宜的请求，并不总是最便宜的完整工作流程的一部分。
代理构建者通常将上下文视为必须最小化的资源。由于长提示词会增加输入处理成本，也可能接近模型的上下文上限，这种看法不无道理。
浏览器代理让计算变得更复杂。它们此前的观察结果充当工作记忆。删除地址、产品属性、警告信息或导航结果，可能导致代理无法完成最终答案。
较小的历史记录额度对某些模型尤其不利。Asana 报告称，在该条件下，模型 C 在 18 次运行中没有返回任何答案；GPT-6.1 Sol 仅返回了三次答案。
这些失败并不证明模型缺乏通用浏览能力。更大的历史记录额度改变了结果。在获得足够空间保留必要记录后，这两个模型都在每次运行中给出了答案。
这一结果支持更广泛的工程原则：上下文策略必须匹配模型和任务。单一的通用 token 限制无法在不同系统中产生等效行为。
模型消耗上下文的速度可能不同，因为它们会生成不同的描述、工具调用和推理轨迹。一种代理可能在少量操作后就达到裁剪阈值，另一种则可能持续更久。
Asana 发现，更新或能力更强的模型并不会自动更高效地使用较小额度。在测试工作流程中，模型 C 开始裁剪历史记录的时间远早于模型 A。
实验还发现，仅有缓存还不够。在较大历史记录额度下，四个模型中有三个模型在不采用批量裁剪时，启用缓存的成本反而高于不启用缓存。
这一结果看似矛盾，直到考虑请求结构。应用程序持续改写希望复用的材料时，缓存的价值就十分有限。系统为处理变化的历史记录付出成本，却无法获得足够多的未来缓存命中。
Asana 选择的策略协调了三项决策：缓存历史记录、更长时间地保留仅追加序列，以及在必须裁剪前提供更大的额度。
后续测试提出了另一个问题。Asana 测试了保留所有截图而非裁剪截图的配置。在这一特定任务中，一些配置实现了低于所选策略的单次调用成本。
该公司并未将此视为裁剪应当被取消的证据。更长的工作流程可能会超出上下文上限，而某些提供商会对缓存操作收取更高费用。陷入不必要浏览的代理也需要明确边界。
Asana 建议对步骤数、token 和总运行成本设置上限。这些限制可防止出错或困惑的代理无限扩展其历史记录。压缩，即用较短摘要替换较旧历史记录，则提供了另一种选择。
压缩也有自身权衡。它会缩小上下文规模，但会改变较早的提示词，从而可能破坏缓存复用。摘要还可能遗漏后来变得重要的细节。
因此，团队需要在活跃提示词之外保留记录。Asana 在其软件交付平台 Command 中记录了请求、追踪记录和结果。工程师及其他代理随后可以审查完整实验。
持久记录也支持建立一个可搜索的知识库。活跃代理只接收当前步骤所需的上下文，而审查人员仍可访问完整证据链。
这种分离有助于团队区分模型记忆与组织记忆。代理的工作上下文应保持有界，而实验记录应足够详尽，以便复现决策并调查故障。
GPT-6 Astra 将评估工作转化为代理任务
Asana 使用一个模型改进系统，并使用另一个模型运行优化后的生产工作流程。
GPT-6 Astra 在 Codex 中充当研究和工程代理。GPT-6.1 Sol 则作为浏览器代理的运行时模型之一。这些角色应被视为彼此独立，否则容易对结果作出误导性解读。
Hidalgo 制定了研究方向，并挑选出值得测试的拟议改动。GPT-6 Astra 审查代码、为请求添加监测、开展初步试验，并识别出具有显著影响的变量。
现有代码并非为受控对比而设计。Asana 表示，Codex agent 重构了系统，使共享的前端和后端能够并行支持多种实验工作流。
随后，GPT-6 Astra 启动研究、分析使用记录并对比输出。独立的模型会话审查了部分工作，而人类则评估结论并批准生产环境变更。
Asana 估计，该项目原本需要一到两个月的人工工作。采用 Codex 工作流后，这项调查大约一周便完成了。
这一说法来自公司自身，而非独立评估。它描述的也是一个由熟悉该系统的技术高管主导的工程项目。其他团队不应假定自己也能获得同样的工期缩短。
不过，这一工作流展示了编程 agent 使用方式的一项重要变化。该 agent 不仅仅是根据已完成的规格说明实现功能，它还参与设计并执行了一项实证调查。
这项调查产出了追踪记录、实验结果、工单和拉取请求。在这些变更进入 StackAI 生产环境之前，这些产物都经过了 Command。
这一过程的重要性高于“AI agent 完成了大部分机械性工作”的说法。没有稳定的记录，审查者就无法可靠地判断运行了哪种配置、它为何失败，或报告的改进是否经受住了代码变更的考验。
Asana 研究称，人类设定了目标和评估标准，也审查了研究结果。编程 agent 则扩大了团队在这些决策之间能够开展实验的规模。
Hidalgo 描述了一种惯例：睡前设定目标，次日早晨审查结果。这种异步模式将 agent 的运行时间转化为一种工程资源。
它也改变了瓶颈所在。当实验变得容易生成时，人类必须投入更多时间来选择有效的问题、核查测量结果，并排除误导性结论。
风险在于自动化实验噪声。agent 可以生成大量运行记录，却未必能产生有力证据。重复测试仍然容易受到基准设计、隐藏任务差异和评分错误的影响。
Asana 通过使用固定任务和独立准备的参考答案，降低了部分风险。它还记录了提供商自身的使用计数器，而非根据文本长度估算 token 消耗量。
该公司对大多数配置只进行了三次重复试验。Asana 明确表示，这项研究揭示的是总体模式，而非几个百分点的可靠差异。
这一限定十分重要。76 倍和 5 倍的对比幅度足以值得关注，但它们同时结合了架构和模型变更。它们并未单独证明 GPT-6.1 Sol 具有普遍优势。
Asana 的内部结果显示，Model B 在获得优化后的工作流后也有显著提升。在 GPT-6.1 Sol 进一步降低成本之前，架构已贡献了主要部分的收益。
76 倍说法未能证明什么
已发布的结果构成了令人信服的工程证据，但并非对浏览器 agent 市场的中立基准测试。
该研究在一个公开图书目录上使用了一项结构化任务。每次运行遵循相同目标，并收集相同字段集合。真实的企业浏览通常涉及身份验证、不断变化的布局、模糊指令，以及从意外对话框中恢复。
擅长重复提取的工作流，在采购、支持、合规或内部运营场景中可能表现不同。这些任务可能需要跨多个系统进行判断，而不是反复从类似页面收集信息。
Asana 的浏览器 agent 测试还将 GPT-6.1 Sol 与三种匿名模型进行了比较。读者无法检查各提供商的特定设置，也无法确定每种替代方案在独立优化后会有何表现。
Asana 表示，在研究期间，Models B、C 和 GPT-6.1 Sol 的标准定价大致相当。Model A 被定位为成本更低的替代方案。公开文章没有透露它们的名称。
这种匿名性使结果无法成为一份清晰的模型排行榜。它也避免研究滑向缺乏足够试验支持的供应商比较。
最大的头条对比，是将优化后的 GPT-6.1 Sol 工作流与运行在 Model B 上的原始生产配置进行比较。两个变量同时发生变化：模型和 agent 架构。
一项更聚焦的比较发现，在 GPT-6.1 Sol 内部应用新策略后，成本降低了四倍。剩余差异则来自于将这一优化系统与较旧的生产基线进行比较。
这并不会削弱结果，而是改变了结论。该研究支持将有能力的模型与具备上下文感知能力的架构结合，而不是将切换模型视为完整解决方案。
运行时间提升五倍也有类似的限定。一些原始 Model B 运行在完成之前就达到了步骤上限。因此，它们测得的时长仅代表完成完整任务所需时间的下限。
完成质量同样需要持续观察。Asana 报告称，所有最佳条件下的运行都找到了所需事实并给出了正确答案。公开材料并未包含客户工作负载或长期错误率。
由于完整研究依赖 Asana 的实现和追踪记录，独立复现仍然有限。该公司分享了其方法和一份更完整的研究，但外部团队仍需建立自己的任务套件。
该公司收购 StackAI 也使其对结果具有商业利益。Asana 于 2026 年 5 月完成了对 StackAI 的收购，以扩展跨系统 agent 工作流。
OpenAI 同样有兴趣展示 GPT-6 Astra 和 GPT-6.1 Sol 如何支持企业 agent。两份一手资料都提供了有价值的技术细节，但都不构成独立的行业审计。
运营条件也可能改变结果。缓存可用期有限。并发客户可能拥有不同的历史记录，而个性化上下文会减少可共享材料的数量。
隐私要求可能限制哪些内容能够进入模型上下文。安全团队还需要对浏览过程中收集的截图、凭据、客户记录和敏感信息进行控制。
缓存不会免除这些义务。它改变的是计算和计费行为，而不是数据治理的必要性。团队仍需要保留政策、访问控制、审计追踪和故障处理机制。
因此，正确的结论应当是有条件的。Asana 为一个特定浏览器 agent 找到了高价值优化，并将其投入生产。其他团队应将这一机制视为可验证的假设。
下一项测试是跨真实客户工作流的表现
接下来的三个信号将显示，Asana 的结果会成为可复用的运营模式，还是仍只是一项强有力的内部案例研究。
第一个信号是更广泛的评估覆盖范围。Asana 表示，它正在开发工具，使客户和内部团队能够在配置 agent 时比较成本、运行时间和答案质量。
这些评估需要覆盖结构化目录提取之外的任务。有用的测试套件应包括不断变化的网站、需要身份验证的应用、部分失败、较长的导航路径，以及停止点存在歧义的指令。
如果相同的历史策略能改善这些工作流，那么以架构为主导的优化理由就会更强。如果收益缩小，Asana 所选的配置可能与重复性提取高度绑定。
第二个信号是来自生产环境采用的证据。Asana 已将浏览器导航变更部署至 StackAI，但尚未公布汇总的客户结果。
完成率应当比单次调用成本更重要。如果客户必须重新运行作业，或手动修复不完整输出，那么更便宜的请求价值有限。
团队还应关注来自缓存的输入占比、任务时长中位数、步骤上限失败，以及人工干预率。这些指标能够揭示优化设计能否经受可变生产流量的考验。
第三个信号是竞争模型提供商和 agent 平台如何回应。提示词缓存已经成为产品功能，但应用架构决定了开发者能否从中受益。
提供商可以通过更长的缓存保留时间、更好的诊断能力、更低的缓存输入费率和更清晰的使用数据展开竞争。agent 框架则可以公开历史策略，而无需迫使每位客户构建自定义监测系统。
OpenAI 将 GPT-6.1 Sol定位为一款能以低于 GPT-6 Astra 的运营成本完成高能力 agentic 工作的模型。Asana 的研究为这一定位提供了具体的应用案例。
然而，最强的竞争压力将落在 agent 软件团队身上。客户将越来越期待平台能自动优化完整任务成本，而不仅仅提供一个模型选择器。
成熟的平台应根据观察到的行为推荐上下文限制。它应能识别破坏缓存的编辑、比较策略，并在裁剪导致 agent 重访早期页面时发出警告。
它还应保留足够的外部证据，供人类审计结果。浏览器 agent 需要有边界的工作记忆，而组织则需要完整的运营记录。
Asana 计划将类似测试纳入其评估系统。它还在 Codex 中使用 GPT-6 Astra 来浏览产品功能、尝试不同输入，并向人类审查者报告 bug。
这一扩展让故事超越了单一浏览器 agent。Asana 正在测试工程 agent 能否持续评估其他 agent 和产品功能。
机遇很明确。自动化实验可以评估的配置数量，远超小型工程团队手动测试所能覆盖的范围。它也能缩短从追踪分析到经审查代码变更的路径。
约束同样明确。当 agent 能持续生成实验、发现和补丁时，人类注意力会成为稀缺资源。团队必须决定哪些结果值得信任并投入生产环境。
对开发者而言，眼下的行动是衡量完整任务，而不是孤立调用。在真实条件下记录缓存命中率、完成质量、运行时间、重试情况和人工修复工作。
对企业采购方而言，应询问供应商的 agent 如何管理不断增长的历史记录。仅凭模型名称无法揭示周边系统是保留了有用上下文，还是反复为处理它付费。
对知识工作者而言，这一变化有望带来更快、更有能力的浏览器自动化。其价值将取决于 agent 能否在不暴露敏感数据、也不在不必要步骤中偏航的前提下保留必要事实。
Asana 的浏览器 agent 结果有力地表明，在每一次 agent 评估中，上下文设计如今都应与模型选择并列考量。下一个问题是，这一经验是否能适用于客户真正希望自动化的那些复杂工作流。
