63%的Agent上下文来自一个工具：真实数据揭示的成本陷阱

一位开发者对自己的AI Agent项目做了件很多人没做过的事：把每一次工具调用都量化测量。结果出乎意料——用得最频繁的工具，并不是花销最大的工具。

这个发现背后藏着一个被普遍忽视的成本结构问题，对任何构建或使用AI Agent的人都有参考价值。

真实数据，而非模型推演

作者强调，这些数字不是估算模型，而是直接从Agent自己的会话数据库里读出的真实工具调用记录。他甚至把快照时间精确固定在某日07:41 UTC，因为数据库是实时的，边写文章边变动。

63%的Agent上下文来自一个工具

从总量看，bash 工具的表现极为突出：

工具	调用次数	总字符数	占比
bash	3,210	5,147,190	63.4%
read	194	795,397	9.8%
web search (exa)	20	545,357	6.7%
web search (内置)	16	460,672	5.7%
fetch page	24	445,160	5.5%
其他全部	571	728,507	9.0%

bash 一个工具就贡献了全部上下文的63.4%，而网页搜索只占2%左右的调用量。乍看之下，优化方向似乎很明确——盯着bash就行了。但真相恰恰相反。

为什么排名会翻转

如果把同一张表按每次调用的成本（单次返回字符数）重新排序，顺序完全颠倒了：

bash           1,603 字符/次
grep           3,117
read           4,099
scrape a page  10,519
fetch a page   18,548
web search     27,267

bash 是整个循环里最便宜的工具，单次只返回1,603字符。它之所以能占到63%，纯粹是因为单次便宜 + 调用极其频繁。而一次网页搜索要吃掉27,267字符，是bash单次的约17倍。

作者由此提炼出一个关键公式：

上下文占比 = (调用频率) × (单次返回量)

问题在于，大多数人只盯着第一个因子（调用频率），所以永远优化不到真正痛的地方。你用得最多的工具，往往不是让你最心疼的那个。

工具名字看不见的隐藏成本

这篇文章里最让人警醒的数字，并不在上面那张图里。

跨越该项目的55个会话，token消耗分布如下：

类型	token数
输入	40,473,602
输出	1,587,482
缓存读取	561,271,443

上下文被重复读取的次数，大约是首次写入的14倍。

这意味着那8.1MB的工具输出根本不是只计费一次。它会在后续的每一轮对话里被反复读取、反复计费，直到上下文被压缩为止。

作者一针见血地指出：这正是把一个「便宜工具」变成「昂贵习惯」的乘数效应。一次 read 返回4,000字符，它会在之后的每一轮里再花掉4,000字符——永远持续，直到context被compact。单次成本低，不代表总账单低。

这里的「缓存读取」指的是大语言模型API中的 Prompt Cache（提示词缓存）机制。以Anthropic Claude为例，当连续多轮对话的上下文前缀完全相同时，API会自动识别并复用已计算过的KV Cache，收取比普通输入token低得多的「缓存读取」费率（通常是正常输入价格的10%左右）。但低费率并不等于免费——当一段4,000字符的工具输出在此后的20轮对话里每轮都被读取一次，即便每次只收正常价的十分之一，累计费用也会是首次写入的两倍。数据里561,271,443的缓存读取token是输入token的约14倍，正说明这个项目的会话普遍较长、上下文反复被重读。这也是为什么「压缩上下文」（context compaction）或定期清理工具输出，在长会话Agent中会有明显的降本效果。

作者做了什么调整

基于这些数据，作者按影响大小做了三件事：

1. 在工具层过滤，而不是过滤之后

用 grep | head -40，而不是grep出59,000字符再让模型去里面找它需要的那四行。工具层的过滤是免费且确定性的；让模型去忽略12,000字符，既不免费也不可靠。

2. 先数行，再读取

先 wc -l 看文件多大，再决定要不要全读。作者说大多数打开的文件只有40行，但他要打开400次——盲目全读会累积惊人的重复成本。

3. 批处理便宜工具，让昂贵工具保持稀少

这里有个反直觉的点：bash单次几乎免费，批处理它省不下什么。真正的杠杆在于少调用昂贵工具。网页搜索一次27,000字符，唯一有效的手段就是「调用得更少」。

作者坦承第3点自己做得并不好——网页类工具占了输出量的20%，但带来的价值可能只有15%。他说得很实在："这张图是一张成绩单，不是一份策略。"

这三条调整背后有一个共同的设计原则：在信息进入上下文之前就减小它的体积，而不是在进入之后再依赖模型去「忽略」冗余部分。这与LLM的计费方式直接相关——API通常按实际传入的token数量计费，模型是否真正「用到」这些token并不影响账单。更关键的是，即便模型能够识别并忽略噪音，那些冗余token依然会占据有限的上下文窗口，挤压可用于推理的空间，并在后续每一轮对话中持续产生缓存读取费用。因此「工具层过滤」不只是省钱技巧，也是提升Agent推理质量的工程实践：输入越精炼，模型的注意力机制越能集中在真正相关的信息上。

你应该先做的最简单版本

好消息是，你根本不需要数据库来复现这个分析。打开你自己Agent的日志，按工具输出大小排序即可。

如果最大的那个工具不是你以为的那个，这本身就是全部的发现。

作者唯一提醒不要信任的，是「只有token总量、没有单次成本列」的图表。总量告诉你字节在哪里，但不告诉你哪个习惯真正昂贵。要同时测量「频率」和「单次成本」两个维度，才能看清问题的全貌。

对Agent开发者的启示

这篇实测给构建LLM Agent的开发者几点可直接落地的思考：

缓存读取是真正的大头。在长会话场景下，上下文的重复计费可能是输入token的十几倍，这才是优化ROI最高的地方。
测量先于优化。凭直觉判断哪个工具贵，几乎必错。真实日志会推翻你的假设。
工具设计应内置过滤。让工具返回精炼结果，远比指望模型「自己忽略噪音」更可靠、更省钱。

在Agent应用大规模落地的当下，context成本不再是抽象概念，而是直接写在账单上的真金白银。学会读自己的会话日志，可能是每个Agent开发者的必修课。