很多公司开始做 AI Agent 后，
第一个成本问题通常会变成：
「是不是该换便宜一点的模型？」
但 Asana 最近公开的一个 Browser Agent 实验，
提供了另一个答案：
先别急着换模型。
你的工作流本身，
可能就在一直重复花钱。
这是一个真实案例，不是假设公司
Asana 透过旗下：
StackAI
提供企业 AI Workflow Automation。
其中一种工作就是：
Browser Agent。
它可以替用户：
打开网站、
读页面、
填表、
收集数据，
再把结果带回工作流程。
问题是：
Browser Agent 每往前走一步，
都可能产生更多：
页面文字、
Screenshot、
Tool Result、
Conversation History。
如果这些东西处理得不好，
Agent 做同一件工作，
成本就会一路往上叠。
Asana 真正先问的不是「哪个模型最便宜？」
StackAI CTO Frank Hidalgo 想解决的是两件事：
Browser Agent 能不能更便宜？
以及：
能不能更快？
他让 GPT-6 Astra 在 Codex 里协助：
阅读 Codebase、
找出 Agent 怎么创建每一次 Model Request、
提出改善方案、
跑大量实验，
最后再比较结果。
Hidalgo 估计，
如果自己人工把整套研究做完，
可能需要：
1～2 个月。
实际这次大约：
一周。
但真正有价值的，
不是 AI 帮工程师省了一周还是一个月。
而是它找到了一个很不起眼的问题：
Context 一直被重新付钱。
第一个浪费点：固定 Prompt 有 Cache，但浏览历史没有
Browser Agent 每一步都要知道：
自己之前看过什么。
所以新的 Request 里，
可能会带着：
System Prompt。
Tool Definitions。
先前网页文字。
先前 Screenshots。
操作纪录。
StackAI 原本已经会 Cache：
固定的 Instructions
和：
Tool Definitions。
但愈来愈长的：
Browsing History
没有真正有效利用 Cache。
结果就是：
Agent 每走下一步，
又把大量前面已经看过的内容：
重新送一次。
Cache 为什么重要？
简单讲，
如果模型服务看到：
前面很长一段 Context
和上一个 Request：
完全相同，
某些模型可以直接用：
Cached Input。
Cached Input 通常比重新处理整段内容便宜。
但前提是：
前面那段东西真的没有被改掉。
这正是 StackAI 第二个问题。
第二个浪费点：Agent 几乎每一步都在改旧 History
StackAI 原本会：
丢掉旧 Screenshot。
裁掉较早的 Page Text。
目的是避免：
Context 无限变长。
直觉上这很合理。
问题是：
每次你改掉前面的 History，
整个 Request Prefix 就变了。
Cache 原本可以重用的部分，
也跟着被破坏。
所以：
有 Cache 功能
不代表：
Cache 真的有被大量使用。
这也是 Asana 实验里很值得一般企业记住的一点。
第三个浪费点：Screenshot 删得太勤
Browser Agent 很常靠 Screenshot 理解画面。
但图片 Context 也会增加成本。
所以原本做法是：
很快就把旧 Screenshot 移除。
Asana 后来测试另一种方法：
不要每一步都改 History。
而是先累积 Screenshot。
到一定数量，
再：
一次大量 Prune。
最佳测试方案之一是：
最多先保留：
20 张 Screenshot。
到门槛后，
再一次缩回：
最近一张。
这样中间约 19 次调用，
History 前段都可以保持稳定，
Cache 才比较容易真正命中。
第四个改变：反而让 Agent 记得更多
这点很反直觉。
很多人想降 Token，
第一个想法是：
「把 Context 删短一点。」
但 StackAI 测试的结果反而显示：
History 太小，
Agent 可能忘掉前面已经找到的东西。
然后：
重新找。
重新开页。
重新读。
甚至最后做不完。
团队比较了：
120,000 Characters
和：
480,000 Characters
两种 History Budget。
在部分较新的模型上，
120,000 Characters 根本不够。
GPT-6.1 Sol 在这个较小 Budget 下，
18 次测试只有：
3 次完成。
提高到：
480,000 Characters
后，
相关测试全部可以完成。
所以：
Context 少
不一定等于：
总成本低。
如果 AI 因为忘记前文而：
重复工作，
最后反而可能更贵。
他们怎么测，而不是只凭感觉？
Asana／StackAI 这次没有：
改完一次，
看到结果好像比较快，
就直接宣布成功。
正式研究跑了：
144 次。
测试：
4 个不同模型。
2 种 History Budget。
6 种 Caching／Screenshot Policy。
每一个条件再跑：
3 次。
之后还另外做：
12 次 Follow-up。
每个 Agent 做的也是：
同一个固定任务。
固定任务到底是什么？
Agent 要从一个公开 Demo Book Catalog，
替：
32 本书
各自收集：
6 个字段。
也就是总共需要找到：
192 个 Facts。
这点非常重要。
因为如果：
A 模型做简单任务，
B 模型做难任务，
最后比较：
Cost
根本没有意义。
Asana 把：
Task
固定。
再比较：
Cost。
Runtime。
Result Quality。
这才有办法知道：
到底是哪一个改动真的有效。
最后结果是多少？
在最佳 GPT-6.1 Sol Workflow 上，
平均每次 Run 的：
Estimated Model Cost 约 0.47 美元。
时间约：
4 分钟。
相较原本使用 Model B 的 Production Setup，
OpenAI／Asana 公布的比较是：
成本：
低 76 倍。
速度：
快 5 倍。
而最佳条件下，
Agent 仍然找到：
全部 192 个 Facts。
但「76 倍」一定要拆开看
这是整篇最重要的 Boundary。
不要看到：
76x
就理解成：
「把 Cache 打开，所有 AI Agent 都会便宜 76 倍。」
不是。
这个 76 倍比较的是：
原本 Production Workflow＋Model B
对上：
优化后 Workflow＋GPT-6.1 Sol。
它同时包含：
工作流优化
和：
模型差异。
如果只看同一个：
Model B，
Asana 的工作流优化把：
每次估算 Model Cost
从至少：
36.21 美元
降到：
1.24 美元。
大约是：
29 倍。
这已经非常大。
但它也证明：
headline 里的 76 倍，
不能全部归功于 Cache，
也不能全部归功于 GPT-6.1 Sol。
而且 36.21 美元的 Baseline 还有一个限制
部分原始 Run：
甚至在完成任务前，
就已经碰到：
Step Limit。
所以原本的：
36.21 美元
是：
至少。
这也代表研究比较不是：
「两套完全相同、每次都完美完成的正式产品帐单」。
它是一组特定：
Browser Benchmark
下的实验结果。
所以不能拿：
0.47 美元
直接套到：
你公司的客服 Agent、
采购 Agent、
研究 Agent
身上。
这篇真正值得小公司学的是什么？
不是：
立刻换成 GPT-6.1 Sol。
也不是：
照抄 480,000 Characters。
真正值得学的是：
当 AI Workflow 太贵时，
不要第一个就问：
「哪个模型单价最低？」
先拆四件事。
1. 同样的 Context 有没有一直重送？
例如：
公司规则。
产品手册。
前面已经读过的页面。
Tool Definitions。
Conversation History。
如果每一轮都重新付完整 Input Price，
那就要看：
Cache
有没有真正命中。
2. Agent 有没有因为忘记而重做？
把 Context 压得太小，
有可能：
少送 Token。
但如果 Agent 因此：
重开网站、
重查数据、
重读文档，
整体 Cost
反而更高。
所以不要只看：
每一次 Request 多长。
要看：
完成整件工作总共花多少。
3. 图片与 Screenshot 是不是每一步都在改？
Computer Use／Browser Agent
最容易出现这种情况。
画面一直变。
Screenshot 一直加。
又一直删。
如果每一步都改 History，
Cache 很难保持稳定。
真正值得测的是：
哪些画面一定要留？
多久整理一次？
能不能 Batch Pruning？
而不是：
看到图片很贵，
就全部删掉。
4. 最后有没有完成同一件事？
这是最重要的。
假设原本 Agent：
100 次有 95 次完成。
改完后成本少一半，
但：
100 次只剩 60 次完成。
那不能直接说：
成本下降 50%。
因为失败的 40 次：
还是得重跑、
人工接手
或重新处理。
真正要看的是：
Cost per Correct Completed Task。
不是：
单次 Token Cost。
小团队可以怎么抄这个方法？
不用做 144 次实验。
先从：
20 个固定案例
开始就可以。
挑一个你真的每天会跑的工作。
例如：
查 10 个竞品网站。
整理 20 张发票。
更新 15 笔 CRM。
处理 20 个客服问题。
然后固定：
输入。
完成条件。
答案格式。
再一次只改：
一个变量。
第一轮只记四个数字
成功率
20 次里，
真正完成几次？
平均成本
完成一次平均花多少？
平均时间
一个 Task 多久？
人工修正时间
AI 做完后，
人还要花多久收尾？
这四个数字比：
「Model X Benchmark 比 Model Y 高」
更接近：
企业真正的 ROI。
然后才去找 Bottleneck
如果成本高，
先问：
是不是 Context 重送？
如果时间长，
先问：
是不是 Agent 一直重复找？
如果成功率低，
先问：
是不是 History 太小、
工具不稳
或任务本身没有定义清楚？
如果人工修改很多，
先问：
是不是 AI 根本做错了最重要的那一步？
不同问题，
答案不一定都是：
换模型。
Asana 还做对一件很重要的事：完整保存每次 Experiment
这次 GPT-6 Astra 跑过的：
Requests、
Data Traces、
Results
都有留在：
Asana Command。
后面才能：
回头比对。
找异常。
产生 Ticket。
做 Pull Request。
让人 Review。
最后才进 Production。
这点对小公司同样重要。
不要只记：
「这次好像变快了。」
至少要留下：
版本。
Prompt。
模型。
设置。
Cost。
时间。
结果。
否则两周后：
你根本不知道是哪一个修改真正有效。
AI 帮忙优化 AI，也不代表人可以退出
Asana 这次真正的分工很清楚。
人做什么？
定义 Goal。
决定哪些方案值得测。
定义正确答案。
审查结论。
Review Production Change。
AI 做什么？
读 Code。
找可能的 Bottleneck。
创建测试。
大量跑 Experiment。
分析 Trace。
整理结果。
这是一个很典型的：
Human＋Agent
工作模式。
不是：
「GPT-6 Astra 自己决定怎么改 Production。」
这个案例最值得企业记住的一句话
当 AI Agent 开始真的大量跑，
最大的问题可能不再是：
它会不会做。
而是：
每成功做完一次，到底要多少钱？
所以 AI Workflow 从 Demo 进 Production 前，
至少要开始量：
成功率。
成本。
时间。
人工修改。
而不是只问：
「Agent 跑成功了吗？」
因为一个：
每次都能完成、
但一件工作花 30 美元
的 Agent，
和：
同样正确、
每次只花 0.50 美元
的 Agent，
商业上完全是两个不同产品。
Asana 这次最值得看的，
不是它得到：
76x。
而是它把：
「AI 太贵」
从一句抱怨，
拆成：
可以测、
可以比较、
可以找到原因
的工程问题。
如果你也想知道自己的工作里，哪一步最适合先交给 AI，留言「流程」。
推荐阅读
AI 商业案例｜2026/10/06：5 人市场情报团队怎么让 AI Agent 每天追 20 个网站？先设「来源／请求上限／超量就停」
AI 一分钟教学｜2026/09/23：Claude Code 跑完别只看答案，输入 /usage 用「Cache／Output／Turns」找出哪里在烧钱
