这是群里一位小伙伴提出来的问题，他的OpenClaw小龙虾跟Hermes Agent爱马仕目前存在这样的情况。

随便发送一句“你好”，token输入消耗1.6-1.7万，而输出消耗token仅为几十，即便删除掉了一些Skill的加载，情况依然如此：

（图片来源自群友真实截图）

如此异常是非常具有代表性的，正好借此话题给大家从头捋一下，当前市面上的AI Agent究竟是在哪些方面会消耗token，到底把钱花到哪里了。

遇到只发送一句“你好”这样简单的对话任务，token消耗依旧庞大的异常情况，小白用户该如何去排查出问题的原因，以及如何解决此类问题。

AI Agent有哪些token消耗高的原因

以下所列举出来的原因，基本上算是比较常见的，但不能说完全百分之百覆盖，老马只是尽可能的把发生概率较高的因素进行总结。

一、任务本身的复杂程度

你交给Agent的任务越复杂，token消耗得就越多。比如任务一是总结这篇文章。任务二是阅读20篇文章，交叉对比观点，查资料验证，写成5000字公众号。

这两个任务就完全不是一个级别，第二个一定更贵，因为它需要读更多资料，调更多工具，保留更多上下文，输出更长内容，可能还要多轮推理。

二、输入的内容太多

很多人以为token消耗高是因为模型回答太长，其实很多时候是因为喂进去的内容太多。

这里面喂进去的内容，不是只有你的任务提示词，还包括了你任务所在的项目文件夹里面的所有文件等内容。

比如你让Agent分析本地正在开发的一个项目，这个项目本身是有一个文件夹，文件夹里面有代码文件，Markdown文件等。

它就有可能把项目目录里面的文件内容，README文档，需求文档，设计文档，日志和报错，历史对话，工具说明，系统提示词全塞进上下文。

这样模型还没开始回答，已经读了几万token，你的输入就消耗掉了几万token，而你自己却觉得不对，你的提示词只写了一句话，就是让Agent分析一下这个项目而已。

三、自带或安装工具太多

Agent每次请求模型时，往往要告诉模型我有哪些工具可以用。工具越多，这段说明就越长。

如果一个Agent挂了50个工具，哪怕你只是问一句今天星期几，它也可能带着一堆工具说明去问模型。

以爱马仕为例，Hermes Agent内置52个工具，每次请求都要把完整工具 schema（工具模式定义）塞进上下文。

工具跟Skill有异曲同工之妙，Skill安装得太多，每次提交任务给Agent的时候，它都有可能去读一下说明书，看看哪个Skill能用上，这也是在消耗token。

四、历史会话太长

你在一个会话里聊了很久，Agent可能每次都带着前面所有内容继续问模型。你上午让它写代码，下午让它写公众号，它可能还背着上午的代码上下文。

虽然现在Agent都会自己去压缩会话的上下文，但自动压缩都是达到Agent本身设定的阀值才能触发，没触发之前，上下文就一直在增大。

以小龙虾为例，OpenClaw默认设定在70%-90%的紧张状态时，才会自动摘要会话，达到90%以上的危险状态，才会激进地压缩会话上下文：

因此，你也不可能说聊一句，就去手动运行命令压缩一句。或者安排完一个任务，就马上新建一个会话，这不现实，有时候一个任务的完成，是需要多轮对话的。

这样就存在一定量的上下文，总是被挂载着去输入给大模型，而这个上下文体量是逐步在增大的，直到任务完成，你才可能去手动压缩或者新建会话。

五、缓存命中率低

这个问题解释起来就有点复杂，缓存命中率低，它即跟Agent框架的设计低效有关系，也跟你所接入的大模型服务商的prompt cache（提示词缓存）机制有关系。

从Agent框架层面来看，主要看以下几点：

1、system prompt（系统提示词），工具列表，skill列表有没有经常改变。

2、当前时间有没有放在prompt开头，动态文件列表有没有放在前面，会话有没有重启，模型有没有切换。

3、子Agent有没有每次新建了上下文，上下文压缩有没有重建了prompt。

如果都是有，那说明Agent框架层每次给到大模型的这本说明书都是不一样的，大模型想缓存都缓存不了。

正常来说，我们不是频繁地去修改Agents.md这样的系统提示词配置文件，或者更换模型接入和重启会话，安装卸载工具和skill，同时运行着多个子Agent且会话老是重置，一般不会出现这类问题。

从大模型层面来看，则更为复杂一些：

1、不是所有模型都支持缓存，有些模型支持prompt cache，有些不支持。有些支持，但只对特定 API、特定模式、特定长度生效。

比如同样是聊天请求，A模型支持自动缓存，B模型不支持，C模型支持但门槛很高，D模型支持但后台不显示命中详情：

以上分析来自于小龙虾自己对配置文件的字段判断，不代表模型的真实情况。真实情况你还得去翻阅自己接入的模型名称，对应的官方文档。

2、缓存是有最低长度门槛的，很多缓存不是你发100个token就缓存。它可能要求前缀达到一定长度才会缓存。

也就是说短的prompt不一定触发缓存，长的prompt才可能触发缓存。比如发送一句你好，虽然总输入1.7万，但如果那1.7万被框架拆成不同结构，或者可缓存前缀不满足规则，也可能命中不好。

3、缓存通常看前缀是否一致大多数prompt cache更喜欢稳定前缀。

比如：

A = system prompt + tools + skills + 用户消息

B = system prompt + tools + skills + 新用户消息

如果前面三部分完全一致，缓存容易命中。

但如果变成：

A = 当前时间 + system prompt + tools + 用户消息

B = 新当前时间 + system prompt + tools + 用户消息

开头的前缀不同，缓存可能直接废掉。这里跟Agent和模型服务商都有关系。Agent负责把稳定内容放前缀，服务商决定前缀一致到什么程度才算命中。

4、缓存不是永久的，有的服务商缓存只保留几分钟，有的保留更久。你第一次请求和第二次请求间隔太久，就可能存在缓存过期。

所以同样发送了两次你好，间隔10秒可能命中，间隔2小时可能不命中。这不是Agent框架的设计问题，而是服务商缓存生命周期问题。

5、不同服务商计费规则不同，有的服务商cached tokens（缓存tokens）明确打折。有的cache read（缓存读取）和 cache write（缓存写入）各自有不同的成本和优惠。

有的只显示总input tokens（输入tokens），不显示cached tokens（缓存tokens），有的通过中转平台后信息不完整。

所以你不能只看input tokens（输入tokens）是1.7万，还要看cached tokens（缓存tokens）是多少。

如果input是1.7万，但cached是1.6万，这就不算贵。如果input是1.7万，cached是0，那才是真贵。

之所以要讲以上的计费规则，主要是前文提到的小伙伴的截图，里面只有input跟output，仅有输入和输出的token数值，并没有cached的数值。

这就有两种可能性，一种是服务商不显示cached tokens，另外一种就是服务商不支持缓存。

6、模型切换会影响缓存。缓存一般和大模型有关。比如你第一次发送任务用模型A，第二次用模型B，大概率就不能复用同一个缓存。

哪怕同一家公司，不同模型之间也未必共享缓存。所以如果你频繁切模型，缓存命中率会下降。

7、API参数变化也可能影响缓存，有些服务商缓存不只看prompt，还可能受model，temperature，tools，system，messages，thinking/reasoning等参数的影响。

尤其是通过聚合平台、中转站中转网关时，请求可能被改写，缓存表现就更不稳定。

8、服务商可能只缓存特定部分，不是所有内容都等同于可缓存。有些会更容易缓存，比如system prompt，工具定义，长文档前缀，静态上下文。

不容易缓存的一般是最新用户消息，工具返回结果，动态时间，临时文件列表，子Agent的临时上下文。所以即使总输入很大，也要看里面有多少是属于可缓存的稳定前缀。

总而言之，token消耗成本高，不只要看Agent会不会省，也要看模型服务商会不会缓存。

Agent负责把上下文排得更稳定，模型服务商负责识别并复用这些稳定的前缀。前者做不好，缓存命不中。后者规则严、有效期短、不支持缓存，也一样不命中。

六、工具返回内容太大

Agent在调工具之后，工具处理所产生的结果内容也会塞回到模型里面去。比如浏览器返回整页HTML，搜索返回几十条结果，终端返回几千行日志等等，这些都会变成token的消耗。

七、子Agent太多

以前有非常多的小伙伴喜欢老马写一些多Agent怎么创建，怎么设计的文章，好像养小龙虾跟养马，不搞一个多Agent团队就显得很低档的感觉。

多Agent听起来很厉害，但其实每个子Agent都可能是一套新的上下文。一个主Agent开了三个子Agent的情况下，有时候不是省时间，而是同时在烧三份的token。

你看似只发送了一句你好这么简单的一个任务，但如果同时开了好几个子 Agent，那token的消耗成本肯定上去。

八、输入输出要求太长

如果你让Agent去写一篇5000字的公众号文章，那输出的token一定是高的，这个没啥好说的。

反过来也是如此，如果你把一篇5000字的公众号文章，丢给Agent去分析或者提炼关键知识点，那输入的token就会高。

九、Agent在反复试错

这个其实是一个比较玄学的问题，老马之前也遇到过，老马的问题是大模型在反复尝试自己有没有权限去使用命令和工具。

而当时因为配置文件的权限开启问题，部分插件存在兼容性问题导致不可用，让大模型在这两个版块上兜了不少圈子，来来回回去尝试，纯浪费token。

当然还有就是Agent如果没理解任务，可能会搜索错方向，打开错网页，读错文件，运行错命令，失败后重试，继续重复绕路，同样是在浪费token。

十、模型选择不对

贵的大模型用来干最难的活，便宜的大模型用来干日常简单的活，这个道理相信大家都懂。

但为什么还要说，就还是有些小白用户一看token账单，搞不清楚为啥费用那么高。如此简单的问题，一般原因就出在模型没有选对，干了不该干的活，纯属浪费。

通过以上十个常见token消耗高的原因总结，相信大家已经有了一个基本的了解。这属于科普扫盲式的介绍，先把原因给大家列举清楚。

那问题又来了，开头提到的小伙伴所面临的问题，他也自己去排查了，把该删的Skill都删了，为啥还是没解决？

考虑到大部分养虾养马的普通用户，是不可能从源码和日志的层面去排查问题的原因。最简单的操作方式，就是跟你的小龙虾和马对话，让它们给你去排查。

因此下面老马将以开头提到小伙伴遇到的问题为例，按步骤说明一下如何去排查，一步步让小龙虾和马把问题的原因揪出来。

AI Agent token消耗高的原因排查

首先在任何对话窗口或渠道都可以进行操作，对话的方式仍是采用自然语言，你的目的就是把OpenClaw和Hermes Agent当成一个人来质问：

你刚才为什么花了这么多token？

你这次请求里带了哪些东西？

哪些是必须的，哪些可以关掉？

我怎么让你用更少token完成同样任务？

以上所列出来的就是对话的提问形式，当然这是通用的，并不针对开头小伙伴的案例，老马只是贴出来方便大家理解一下核心思路。

虽然Agent不一定能看到所有底层真实请求，但它通常知道当前会话里启用了哪些工具、技能、上下文、记忆、历史内容，你可以通过对话去逼近了解原因。

下面正式开始，假设你就发送了一句你好，但是输入token消耗了1.7万，这是很不对劲的，那我们就进入排查步骤。

第一步先问Agent刚才你带了什么，直接复制下面这段话去问你的小龙虾跟马：

我刚才只发了一句“你好”，但输入消耗了大约1.7万token，输出只有20token。

请你不要泛泛解释，请具体帮我分析：

1. 这 1.7万输入token里，可能包含了哪些部分？

2. 当前会话里你启用了哪些工具？

3. 当前会话里你加载了哪些skill/插件/MCP/记忆/项目上下文？

4. 哪些内容是回答“你好”必须的？

5. 哪些内容对“你好”来说是不必要的？

6. 我应该怎么跟你说，才能让下一次输入token更低？

请用表格回答。

你要看它回答里有没有下面这些关键词：

1、tools

2、tool schema

3、skills

4、memory

5、project context

6、system prompt

7、history

8、MCP

9、plugins

10、browser

11、terminal

12、file system

13、subagent

如果Agent说当前启用了很多工具、插件、技能等，哪些启用或者使用得最多的，那就基本就是你要找到的方向了。

第二步让Agent自己给自己设定一套瘦身的方案，提示词可以按下面这样去发，你要再修改一下也行：

请你基于当前会话，帮我设计一个最省token的聊天模式。

要求：

1. 只保留普通聊天必须的能力。

2. 不需要浏览器。

3. 不需要读写文件。

4. 不需要终端。

5. 不需要子Agent。

6. 不需要图片、语音、PPT、表格、飞书等工具。

7. 不需要加载项目上下文。

请告诉我：

– 我应该关闭哪些工具或功能？

– 如果你知道具体命令或配置，请给我。

– 如果你不知道具体命令，请告诉我应该在设置里找哪些关键词。

你不需要知道哪些复杂的配置名，说句实在话老马根本就不去记这些东西。都是让小龙虾或者马告诉我的，当然这里面也有一些小技巧。

你可以把小龙虾和马的官方文档发给它们去学习，而且要求是深入全面的学习。甚至是创建一个定时任务，比如每三天去学习一次，更新一下知识。

回到主题，你把以上提示词发送过去后，小龙虾跟马就可能会回复你，建议你执行下面的操作：

1、关闭browser

2、关闭terminal

3、关闭filesystem

4、关闭MCP

5、关闭skills

6、关闭delegation

7、使用chat-only profile

8、新开session

9、不加载workspace

而你拿到这些需要执行的操作清单后，也不用自己去执行，你就直接告诉小龙虾跟马，给我关闭browser，关闭MCP啥的即可。

第三步让Agent做一下必要性的审计工作，提示词如下：

请你审计当前会话里所有已启用的能力。

请按这个格式列出来：

能力名称 | 类型 | 回答“你好”是否需要 | 是否可能增加输入token | 建议保留/关闭 | 理

只讨论当前会话真实启用或你能感知到的能力，不要虚构。

你重点要看的是“回答你好是否需要”这一列的内容，如果一堆东西都是不需要的，那就说明基础上下文太多太重。

上下文太多太重最主要影响的就是输入，所以开头提到的小伙伴为啥输入token消耗1.7万，输出才20左右token，很明显是输入的上下文太多太重。

第四步让Agent模拟关掉后能省多少token，提示词如下：

请你不要编造精确数字

根据经验判断，如果我只保留普通聊天能力，关闭工具、skills、MCP、项目上下文、子Agent，输入token可能会下降在哪些部分？

请按：

– 很可能下降

– 可能下降

– 不一定下降

分类说明。

另外告诉我，我应该怎么做一个最简单的A/B测试来验证。

这时候Agent应该会说很可能下降有工具schema，skill描述，项目上下文，历史消息等。

可能下降的有memory记忆，MCP工具描述，插件提示词等。

不一定下降的有固定的system prompt，平台内置安全提示，模型服务商隐藏开销等。

第五步是用新会话测试去排除历史问题，你不用配置任何东西，分别在老会话发送一句你好，记录一下消耗的token。

在新会话也同样发送一句你好，记录一下消耗的token。然后接着给Agent发送以下的提示词去询问它：

我做了一个测试：

老会话：输入token约X，输出token约Y。

新会话：输入token约A，输出token约B。

请帮我判断：

1. 如果新会话明显更低，说明什么？

2. 如果新会话还是一样高，说明什么？

3. 下一步应该排查工具、skill、system prompt、缓存，还是历史上下文？

通过Agent的回答，我们就可以很容易地判断出来，新会话明显输入消耗token低的话，那说明老会话历史的上下文太多太重。新会话也很高，则是默认的基础上下文太多太重。

这就是一套固定的包袱，无论新老会话，你都背负着。开头提到小伙伴的情况，就属于固定的包袱，他需要优化的就是甩掉不必要的包袱负重。

第六步用连续两次你好测试缓存是否命中，但是这个测试对于两次输入消耗token都一样的情况来说，就没有必要做了。如果不是都一样的小伙伴，可以做一下。

我们假设缓存都没有命中，做完了之后，直接就问Agent：

当前会话里，有哪些内容可能导致prompt cache失效？

请重点检查：

1. system prompt是否会变化；

2. 当前时间是否放在上下文前面；

3. 工具列表是否每轮变化；

4. skill 列表是否每轮变化；

5. 项目文件列表是否每轮变化；

6. 是否每次生成随机session id；

7. 是否切换模型或provider。

你不知道的地方请明确说不知道，不要猜。

其实前面老马在介绍缓存命中率低的时候，已经是直接用一句话提示词，询问当前模型到底支不支持prompt cache。小龙虾给的答复是龙虾本身支持，而模型不支持。

但这也说明prompt cache是生效的，小龙虾自己会去缓存。如果你的小龙虾prompt cache都不能正常运行，那就得进一步询问如何开启：

如果当前模型不支持provider prompt cache，请说明小龙虾自己的prompt cache具体缓存了什么？是模型请求前缀、工具schema、工具调用结果、历史摘要，还是其他内容？它是否能降低实际 API input token计费？如果没有开启，我该如何开启？

第七步问Agent怎么以最省token的方式继续，这是最简单粗暴实用的一步，提示词如下：

从现在开始，请你进入省token模式。

规则：

1. 不主动调用工具，除非我明确要求。

2. 不主动读取文件，除非我给路径。

3. 不主动打开网页，除非我给链接并要求阅读。

4. 不使用子Agent。

5. 回答先给短版。

6. 需要展开时先问我。

7. 不重复解释已经说过的背景。

8. 如果你发现上下文太长，请提醒我开新会话。

请确认你能遵守哪些，不能遵守哪些。

这个提示词指令不一定能减少系统层面的固定token消耗，但是能减少后续的工具调用、长输出和历史上下文膨胀所导致的token消耗问题。

第八步让Agent帮你写好下次的启动配置，对于小龙虾和马这种工具型 Agent而言，最好的方式就是让它自己输出配置的建议，提示词如下：

请帮我生成两个使用模式：

模式 A：普通聊天，最低token消耗。

模式 B：联网研究，适中token消耗。

每个模式请说明：

– 应该开启哪些工具；

– 应该关闭哪些工具；

– 是否开启skills；

– 是否允许子Agent；

– 是否加载项目上下文；

– 适合什么任务；

– 不适合什么任务。

如果你知道Hermes / OpenClaw的具体配置方式，请分别写出来。

如果不知道，请只写原则，不要编造命令。

以上Hermes/OpenClaw你需要改动一下，发给小龙虾就只写OpenClaw，发给爱马仕就只写Hermes，别两个都混着发过去了。

还有就是模式A跟模式B，分别能干什么活，这也不是固定的，你可以修改。别到时候用了老马这个提示词，小龙虾跟马干活不利索了。

模式A跟模式B只是一种假设，等于你给小龙虾和马设置两个开关。每个开关对应不同的能力，普通聊天就能力开得少一点，联网研究就能力开得多一点。

这个小龙虾跟马会回复你，每个模式具体应该应该开启什么东西。你就审查一下，哪些东西是你需要的，哪些是不需要的，这也算是节省token的一种思路。

以上八个步骤走下来，基本上就能排查出问题的根源所在。当然，有些小伙伴会说，真按你写的八个步骤挨个弄下来，人都瓦特了，有没有统一一步到位的操作。

这就只能简化成两步了，但排查过程是完整的，第一步你可以这么去问小龙虾跟马：

我刚才只发了一句“你好”，但输入消耗了大约 XX token，输出只有 XX token。

请你站在节省token的角度，帮我做一次当前会话体检。

请按表格回答：

1. 当前可能进入输入上下文的内容有哪些？

2. 这些内容对回答“你好”是否必要？

3. 它们是否会增加 input tokens？

4. 我能不能通过设置、配置、换会话、关闭工具来减少？

5. 如果能，具体应该怎么做？

6. 哪些你无法确认，请明确写“无法确认”，不要猜。

重点检查：

– system prompt

– tools / tool schema

– skills

– plugins

– MCP

– memory

– project context

– conversation history

– subagent / delegation

– browser / terminal / file tools

– prompt cache

等小龙虾和马的检查报告清单出来以后，你接着继续追问：

请你给我一个最小化验证方案。

要求：

1. 我只能通过聊天操作，不会看源码跟日志。

2. 每一步只改一个变量。

3. 每一步告诉我应该发送什么测试句子。

4. 每一步告诉我应该记录哪些数字。

5. 每一步告诉我不同结果分别说明什么。

如此这般操作，你就能快速定位问题的根源，并且得到一套最终的解决方案。所以说养虾养马，玩各种AI Agent的本质思路都是一样的，那就是得用起来，让它们自己去解决自己的问题。

好了，以上就是今天的分享，欢迎关注、点赞、转发一键三连。有任何问题和需求，请在评论区留言，回见！

对了，老马最近刚创建了一个AI学习交流群，有兴趣进群的小伙伴可以添加老马微信号：immajiabin，添加好友时备注：进群（不备注不通过）。