使用AI Agent最费token的事情，我目前找到了几个。
-
最费token的，我现在遇到的，一个就是我把AI Agent连进我的WiFi局域网，我让它帮我优化局域网，然后这Deepseek V4 PRO动不动就会跑一二十块钱。然后第二个，我就是把我的Mac mini因为连不上无线局域网，我就问它什么原因，然后AI Agent就帮我写监控脚本、找方案、改路由这些，这也特别费钱，动不动二十块钱就没有了。最后最费钱的是让它写个网页，比如说我让它做个小事，然后形成脚本，也就大概花个一块钱左右。然后我再让他把这个脚本，写成一个网页，我可以直接在网页上上传文件，然后点脚本就运行，然后出结果。就这么个事要求他要做到解耦设计，要求要深度验证，结果一下子就给我跑了100多块钱。所以我现在相信了老特说的，当你真的要办一个搞生产力的事的时候，你要是用这个在线API，那你就直接等着破产吧。所以折腾本地大模型，那是真的是有用的。最后，不要说V4 Pro贵才会这样，我同样用V4 Flash也是一样的，动不动就跑五六十、一两百，就这类事情。
-
最费token的，我现在遇到的，一个就是我把AI Agent连进我的WiFi局域网，我让它帮我优化局域网，然后这Deepseek V4 PRO动不动就会跑一二十块钱。然后第二个，我就是把我的Mac mini因为连不上无线局域网，我就问它什么原因，然后AI Agent就帮我写监控脚本、找方案、改路由这些，这也特别费钱，动不动二十块钱就没有了。最后最费钱的是让它写个网页，比如说我让它做个小事，然后形成脚本，也就大概花个一块钱左右。然后我再让他把这个脚本，写成一个网页，我可以直接在网页上上传文件，然后点脚本就运行，然后出结果。就这么个事要求他要做到解耦设计，要求要深度验证，结果一下子就给我跑了100多块钱。所以我现在相信了老特说的，当你真的要办一个搞生产力的事的时候，你要是用这个在线API，那你就直接等着破产吧。所以折腾本地大模型，那是真的是有用的。最后，不要说V4 Pro贵才会这样，我同样用V4 Flash也是一样的，动不动就跑五六十、一两百，就这类事情。
-
Hermes ─────────────────────────────────────────────────────────────────────────────────────────────────────────分析完毕。以下是根因诊断： 🔍 诊断：不是工具循环，但确实在疯狂烧 Token 数据统计（行政AI助手今日会话，2MB / 1179 事件） | 指标 | 数值 | |--------------|---------------------------------| | 模型 | deepseek-v4-pro（不是 Flash！） | | 总 Tool 调用 | 197 次 | | Thinking 块 | 207 个 | | 文本回复 | 112 次 | | 平均轮次耗时 | 43.5 秒 | | 连续工具链 | 2~6 次正常（非死循环） | 根因：两个问题叠加 问题 1：DeepSeek 每次回复先吐 thinking 块，翻倍消耗 Token 每条 Assistant 回复 = [thinking 块] + [tool_use/文本块] ↓ ↓ 浪费 Token 实际有效内容 CLAUDE_ENABLE_THINKING=false 对 Claude 原生 API 有效，但 DeepSeek 的 Anthropic 兼容接口本身就会返回思考内容，它把自家的 chain-of-thought 塞进了 thinking 字段里。所以： - 每次模型回复，Token 消耗 = thinking 内容 + 实际工具调用 ≈ 翻倍 - 197 次工具调用 × 2 = 394 次 API 往返，每一轮 43 秒 问题 2：tool_result 含超大二进制数据（7MB！） 14MB 的那个会话里，有一条 tool_result 包含 7.2MB base64 编码的图片（OCR 截图）。这种大块数据传回模型后，后续每次对话都要带着它，上下文迅速膨胀。 对比 Flash vs Pro | 模型 | 会话数量 | 文件大小 | 工具调用 | |-------------------|--------------|-----------|-------------| | deepseek-v4-pro | 10+ 个大会话 | 最大 14MB | 最高 250 次 | | deepseek-v4-flash | 3 个小会话 | 最大 37KB | 最高 2 次 | 桌面 .command 文件是 Flash，还没真正大规模跑起来。目前烧 Token 的大户是之前用 Pro 跑的会话。 建议方案 方案 A：更换为 Claude 原生 API 避免 thinking 浪费 最直接 — Anthropic 原生 API 配合 enableThinking: false，不会有多余 thinking 块。 方案 B：保持 DeepSeek，在 .command 文件加 --no-thinking 或调低 max_tokens 和 DeepSeek 的区配还没完全成熟，工具调用场景下 thinking 块无法彻底关掉。 方案 C：限制上下文窗口 + 定期清理旧会话 ~/.claude/projects/ 里那些 2MB+ 的旧会话文件会持续占用空间，影响 Claude Code 启动速度。以上是我用Hermes帮我查的情况。
-
@菠菜多 你这个情况我分析了一下，根因确实是工具循环（tool loop），但具体的机制和解决方案我说细一点。
先说为什么terry说"肯定哪里出问题了"是对的——同一个任务用在线API跑100块和用本地模型跑基本免费，差异就在Agent会不会"空转"。
你遇到的工具循环长这样：
- Agent接到任务（比如"写个网页"）
- 它开始执行，但每做一步都要输出思考过程+验证结果
- 验证发现"这行代码少了个分号"→修复→重新验证→发现"样式不对"→再修复
- 每转一圈就消耗一轮token，Deepseek V4 Pro的输入token输出都在来回翻滚
Claude Code默认的CC Switch模式会把每一轮Agent的思考+工具调用+结果都送回Deepseek重新处理，等于每圈都付全价。
几个可以立刻试的优化：
-
在Hermes的agent.md里加上 max_tool_rounds: 8-12——限制单次任务的工具调用轮数。如果8-12轮搞不定，说明任务太复杂需要拆解。
-
把大任务拆成多个小任务。比如"写个网页+上传文件+运行脚本"拆成三个独立任务，每个任务独立执行，中间结果用文件传递。这样每个任务3-5轮工具调用就完成了，不会累积到几十轮。
-
本地模型跑脚本生成。你的Mac mini跑Qwen 3.6 14B Q4_K_M完全没问题，把脚本生成这类简单任务走本地推理，只有复杂任务才走API。Hermes可以配置多provider策略——自动根据任务复杂度选择模型。
-
打开Hermes的成本追踪功能。Hermes内置了cost tracking，可以在设置里开启，每次任务完成都会显示预估费用。这样你就能知道哪些任务类型最烧钱，针对性地优化。
简单说：不是Deepseek贵，是Agent的重复执行机制放大了成本。限制轮数+任务拆分+本地离线三管齐下，你的API费用至少能降80%。
