Agent 推理的“显微镜“：一次工具调用，到底花了多少 Token？
副标题： 三款模型实测 + 八条 Prompt 技巧——同样的任务，怎么让 Agent 少花一半 Token
一、引子：Agent 不是一次推理，而是一个循环
上篇文章（《Agent 不是工具调用器——理解 Agent 的工作机制》）我们拆开了 Agent 循环的每一环，从 System Prompt 到工具调用再到循环判断。现在，我们给这个循环算一笔账——每一轮推理要花多少 token？多少时间？
但真正把一个 Agent 任务跑起来时，你会发现：
用户提问
↓
模型"想"了一下 ← 消耗 completion token（含推理过程）
↓
调 search_kb 查资料 ← 工具调用
↓
工具返回结果
↓
模型又"想"了一下 ← 再次消耗 completion token
↓
再调一个工具...
↓
最终给出回答
整个过程可能循环 3-5 轮
一次 Agent 任务不是一个推理请求，而是 N 个推理请求组成的一个循环。 每一轮都有成本——Prompt token 在增长（历史在累积），Completion token 在消耗（模型在"思考"），工具调用在花时间。
在这篇文章之前，我对这个开销只有模糊的感觉。这篇文章之后，我们用真实数据说话。
二、先搞懂两个概念
Token 是什么？
Token 是模型理解文本的最小单位。它不是"字"也不是"词"：
"你好，今天天气不错" → 分词器 → ["你好", "，", "今天", "天气", "不错"]
6 个 token
模型按 token 计费（云 API）或按 token 消耗显存和时间（本地部署）。一个 Agent 任务消耗的 token 量 = 每一轮推理的 prompt token + completion token 的总和。
推理模型 vs 指令模型
这是理解实验数据的关键。
| 类型 | 代表 | 训练方式 | 行为特点 |
|---|---|---|---|
| 指令模型 | Qwen3、GPT-4o、Claude | 指令微调（SFT + RLHF） | 直接回答问题，服从用户指令 |
| 推理模型 | DeepSeek-R1、o1 | 强化学习 + 思维链（CoT） | 先内部"思考"再回答，擅长复杂推理 |
一个形象的类比：
- 指令模型像一位经验丰富的同事——你问问题，他直接给你答案。快，但遇到不熟悉的问题可能出错。
- 推理模型像一位严谨的学者——你问问题，他先在草稿纸上写满推导，然后才给你最终答案。慢，但复杂问题更准确。
但这里面有一个关键问题：当推理模型做 Agent 时，它的"严谨思考"会不会和"相信工具输出"产生冲突？ 这正是我们实验的核心发现。
三、实验设计
Agent 系统
我们搭建了一个极简的 Agent 循环（约 150 行 Python），包含三个真实工具：
| 工具 | 功能 |
|---|---|
search_kb(query) |
在本地 Chroma 知识库（5 篇技术博客，355 个片段）中检索信息 |
run_python(code) |
执行 Python 代码并返回结果 |
read_file(path) |
读取本地文件内容 |
工作流程：
用户任务 → LLM 思考 → 如果输出 JSON 工具调用 → 执行工具 → 结果反馈 → 继续循环
↓
如果输出自然语言 → 最终答案
三款模型
| 模型 | 类型 | 参数量 | 部署方式 |
|---|---|---|---|
| DeepSeek-R1-Distill-Qwen-7B | 推理模型 | 7.6B | 本地 llama.cpp, GTX 1660 Ti 6GB |
| Qwen3-8B | 指令模型 | 8.2B | 本地 llama.cpp, GTX 1660 Ti 6GB |
| DeepSeek V4 Pro | 指令+推理(云端) | ~671B MoE | API 调用 |
三个测试任务
| 任务 | 描述 | 预期行为 |
|---|---|---|
| ① 简单问答（对照组） | “什么是 KV Cache？用一句话回答” | 不需要工具，单轮推理 |
| ② 搜索+总结 | “搜索 KV Cache 相关内容，总结优化方法” | 调 search_kb → 总结 |
| ③ 搜索+计算 | “查 Qwen3-8B 的 KV Cache 公式，算 ctx=16384 时的大小” | 调 search_kb → 计算并输出 |
四、实验数据
全局对比
R1-7B(推理) Qwen3-8B(指令) V4 Pro(云端)
────────── ───────────── ────────────
任务① 简单问答 ✅ 正确 ✅ 正确 ✅ 正确
耗时 5.5s 5.9s 1.6s
总 token 540 540 418
任务② 搜索+总结 ❌ 幻觉 ✅ 正确 ✅ 正确
调 search_kb 1 次 1 次 3 次
耗时 36.5s 120s 35s
总 token 1,827 2,035 5,101
任务③ 搜索+计算 ❌ 算错 ✅ 2304 MB ✅ 2304 MB
调 search_kb 2 次 1 次 1 次
耗时 69s 121s 13s
总 token 2,976 2,708 1,854
深入看几个关键数据点
任务①：简单问答——所有模型都正确，但 token 差异巨大
"什么是 KV Cache？用一句话回答。"
R1-7B: 419 prompt + 121 completion = 540 tok, 5.5s
Qwen3-8B: 419 prompt + 121 completion = 540 tok, 5.9s
V4: 416 prompt + 48 completion = 418 tok, 1.6s
V4 的 completion 只有 48 tok——它几乎不需要"想"。而两个本地模型各用了 121 tok 才输出同样的答案，多出来的部分是内部推理/思考链。
任务②：搜索+总结——关键的分水岭
"搜一下 KV Cache 的优化方法"
R1-7B:
Round 1: search_kb("KV Cache 大小") → 得到正确内容
Round 2: 编造了 LRU 替换策略、缓存一致性等通用缓存知识 ❌
结论：搜到了博客数据，但模型用自己的知识覆盖了工具结果
Qwen3-8B:
Round 1: search_kb("KV Cache") → 得到正确内容
Round 2: 正确总结了量化、动态上下文等博客中的真实方法 ✅
V4 Pro:
Round 1: search_kb("KV Cache")
Round 2: search_kb("KV Cache 是什么") → 深入一步
Round 3: search_kb("KV Cache 优化方法") → 再深入
Round 4: 综合三次搜索结果，给出完整总结 ✅
R1-7B 失败的原因：作为推理模型，它在 Round 2 的推理过程中"觉得"自己对 KV Cache 优化已经足够了解了（虽然实际上并不知道），于是选择了用自己的知识而非工具结果。
Qwen3-8B 成功的原因：作为指令模型，它更"听话"——搜到什么就用什么。
V4 的独特模式：它连续调用了 3 次 search_kb，每次都用不同的搜索关键词深入——这不是"不知道该搜什么"，而是"有策略地多角度检索"。
任务③：搜索+计算——最清晰的对比
"查 Qwen3-8B 的 KV Cache 公式，算 ctx=16384"
R1-7B:
Round 1: search_kb("KV Cache Qwen3-8B") → 搜到: 36 layers, 8 kv_heads, 128 d_head
Round 2: search_kb("Qwen3-8B KV Cache 公式") → 搜到: 公式 = 2×layers×kv_heads×d_head×ctx×2
Round 3: 用自己的参数计算 → d_model=512, d_head=64 → 2 MB ❌
最终值跟博客里的正确值差了 1000 倍。
Qwen3-8B:
Round 1: search_kb("Qwen3-8B KV Cache 公式") → 搜到所有参数
Round 2: 用搜到的数据代入计算 → 2304 MB ✅
V4 Pro:
Round 1: search_kb("Qwen3 KV Cache 大小计算") → 搜到公式
Round 2: 直接计算 → 2304 MB ✅
R1-7B 的完整推理过程（截取）：
"我来计算...已知 Qwen3-8B 的参数设置：n_head=8, d_model=512, d_head=64"
→ 这些参数从哪来的？从模型自己的训练知识里翻出来的
→ 而不是从 search_kb 返回的结果里取的
问题就出在这里——它搜到了 36 layers, 8 kv_heads, 128 d_head
但推理过程中认为"我记忆中的 d_model=512 才是正确的"
→ 推理模型的"自我推理"覆盖了工具输出
五、三组模型的 Token 消耗画像
任务③的 Token 构成
R1-7B: Prompt: 1,410 tok | Completion: 1,566 tok | 总: 2,976 tok
工具: search_kb × 2 耗时: 69s
Qwen3-8B: Prompt: 1,281 tok | Completion: 1,427 tok | 总: 2,708 tok
工具: search_kb × 1 耗时: 121s
V4 Pro: Prompt: 1,164 tok | Completion: 690 tok | 总: 1,854 tok
工具: search_kb × 1 耗时: 13s
几个关键观察：
① Completion token 占总消耗的一半以上。 对于 Agent 任务，completion（模型"思考" + 输出）的成本往往超过 prompt（输入）。这与纯推理任务相反。
② V4 的 completion 只有 690 tok，远低于本地模型。 它不需要"想"那么久——能力强，直接给出正确计算。
③ R1-7B 多调了一次 search_kb，但问了几乎一样的问题。 这不是有效利用工具，而是"没记住上次搜了什么"——对话历史长了之后，小模型的注意力开始衰减。
速度 vs 能力的象限
能力强
↑
Qwen3-8B ● ● V4 Pro
(算得对但慢) (算得对又快)
│
慢 ──────────┼──────────→ 快
│
R1-7B ●
(算错了)
│
能力弱
六、核心发现与讨论
发现一：推理模型做 Agent 存在内在矛盾
这是本次实验最重要的发现。推理模型（R1）被训练成"自己解决问题"——它在输出前会进行深度的内部推理。但当它作为 Agent 需要"相信工具返回的结果"时，这两个目标打架了：
推理模型的内部动机：
"让我思考一下...我知道了，KV Cache 的公式是..."
→ 用自己的知识回答 （但知识可能是错的）
Agent 系统的要求：
"不要想，用 search_kb 返回的数据"
→ 但推理模型被训练成"想清楚再回答"
指令模型（Qwen3）没有这个矛盾——它不是被训练来"深度思考"的，所以它更倾向于直接使用工具返回的数据。
结论：在做 Agent 系统时，指令模型可能比同规模的推理模型更可靠。
发现二：Token 消耗随轮次线性增长
一个 Agent 任务的总 token 消耗 ≈ 单轮 token × 轮次数 × 1.3（历史累积系数）。
简单问答（1轮）： ~500 tok
搜索+总结（2轮）： ~2,000 tok (4x)
搜索+计算（3轮）： ~3,000 tok (6x)
如果 Agent 出错需要重试，成本直接翻倍。
发现三：模型能力对 Agent 效率的放大效应
V4 比 Qwen3 快 10 倍、比 R1-7B 快 5 倍——不仅仅是因为它"跑得快"，更是因为它一轮就做对了。小模型需要更多轮次来纠错、搜索、确认，大模型往往一轮到位。
七、总结
实验结论
-
推理模型做 Agent 要谨慎。 DeepSeek-R1-7B（推理）在任务③中失败了，而 Qwen3-8B（指令）成功了——尽管两个模型都是 7B 级别。原因不在于"谁更聪明"，而在于"推理模型的自我推理会覆盖工具输出"。
-
Token 是 Agent 的隐形开销。 一个简单问答 ~500 tok，但一个 2-3 轮的 Agent 任务可能消耗 3,000+ tok——6 倍。Completion token（模型思考）占比过半。
-
强模型不仅快，还更省 token。 V4 完成任务③只用 1,854 tok 和 13s，而本地模型用了 ~2,800 tok 和 69-121s。好的模型不是"做同样的事更贵"，而是"做得更快更准，反而更省"。
实操建议
| 场景 | 建议 |
|---|---|
| 简单问答 | 指令模型即可，不需要工具调用 |
| 单工具 Agent | 指令模型（如 Qwen3-8B）性价比最高 |
| 多轮工具调用 | 考虑云端大模型（V4/GPT-4o），节省时间和调试时间 |
| 6GB 显卡用户 | 优先选层数少的模型（DeepSeek-R1-7B 比 Qwen3-8B 少 8 层，同显存下更快） |
最后的思考： Agent 系统的设计不只是"给模型加工具"，而是要理解模型的行为模式——推理模型倾向于"自己想"，指令模型倾向于"听你的"。选对模型类型，比选对模型大小更重要。
八、使用技巧：怎么写 Prompt 让 Agent"省着花"
看完上面的数据，你会发现一个规律：Agent 花的每一分 token，背后都是我们用户的一次交互习惯决定的。 不是只有改模型才能省钱——你写 Prompt 的方式，直接影响 Agent 要跑几轮、花多少 token。
以下几条技巧，核心原则就一个：减少 Agent 需要"猜测"和"搜索"的环节。 每省一轮工具调用，就省几百 token 和几秒到几十秒时间。
① 直接给文件路径
最常见也最值得养成的好习惯。不给路径，Agent 的内心活动是这样的：
用户: "帮我看看实验数据"
Agent: "实验数据在哪？先 ls 看看" → Round 1
"没有？那 find 找一下" → Round 2
"找到了，开始读" → Round 3
而给路径，Agent 直接一步到位：
用户: "帮我看看 experiments/results/task3.json"
Agent: read_file("experiments/results/task3.json") → 读完回答
省了 2 轮，~400+ token，外加几十秒。任何你知道的路径、URL、文件名，直接在 Prompt 里说清楚。
② 搜索指令越精确越好
模糊的搜索词会让 Agent 先猜一轮、搜完发现不对、再调整关键词重搜。
❌ "查一下 KV Cache 的信息"
→ 搜 "KV Cache" → 结果太宽泛 → 再搜 "KV Cache 优化" → Round 2
✅ "搜索 'KV Cache 量化方法和动态上下文'"
→ 一次精准命中 → 直接总结
一个好的搜索词，相当于你帮 Agent 省掉了"试错的那一轮"。
③ 你知道的东西，直接告诉它
如果这个信息是你已知的，不要让它再去查一遍——它查到的结果也不会比你给的更准确。
❌ "搜一下 Qwen3-8B 的 KV Cache 公式，然后算 ctx=16384 的大小"
→ search_kb → 搜到参数 → 再计算 → 2-3 轮
✅ "Qwen3-8B：36 层、8 个 KV 头、d_head=128。公式是 2×L×H×d×ctx×2。
算 ctx=16384 时 KV Cache 多大？"
→ run_python 直接算 → 1 轮
你喂给 Agent 的信息越完整，它需要调的工具就越少。
④ 明确"不需要"什么
Agent 默认会倾向于"多用工具"——你把工具给它了，它总觉得该用一用。明确告知限制，能显著减少无效调用。
❌ "分析这个代码的性能瓶颈"
→ 可能先搜资料、再分析、再验证......
✅ "直接分析这个代码，不需要搜索。用你已有的知识回答。"
→ 单轮完成
✅ "只做计算，读文件和搜索我已经做完了。"
→ 锁定在 run_python，不走弯路
⑤ 复杂任务先拆再问
一个复杂大问题丢给 Agent，它可能需要 5-6 轮才能全部完成。拆成 2-3 个小问题分别问，每轮的 prompt 更短、历史累积更少、总 token 反而更省。
❌ 一次性问完:
"搜 KV Cache 公式 → 算大小 → 对比量化前后的差异 → 画个表"
→ 可能 4-5 轮，历史累积到几千 token
✅ 拆成 3 步:
① "搜 KV Cache 公式和参数" → 拿到数据
② "用刚才的数据算大小和量化后大小" → 得到结果
③ "把结果整理成对比表" → 最终输出
→ 每一步的对话都短，累积少
这不是让你多跑几轮，而是让每一轮的上下文更干净——Agent 不需要带着前 4 轮的历史去处理最后一步的格式化任务。
⑥ 直接把上下文贴进去
如果问题涉及某段代码、某份日志、某段文档——直接贴进去，不要让 Agent 去读文件或搜索。读文件本身是一轮工具调用，而且贴进去的内容 token 消耗远比 Agent 自己去"找"要低（因为省了一轮 completion）。
❌ "看看这段代码有什么问题"（不贴代码）
→ Agent: "代码在哪里？让我搜索一下" → 浪费一轮
✅ "看看这段代码有什么问题：<直接粘贴代码>"
→ 单轮开始分析
⑦ 指定用哪个工具
如果你已经知道该用什么工具，直接告诉 Agent，避免它"选错→重来"。
❌ "帮我算一下 384 × 1024 × 2 × 2 / 1024 / 1024"
→ 可能先搜怎么算 → 再用 Python → 2 轮
✅ "用 run_python 算：384 × 1024 × 2 × 2 / 1024 / 1024"
→ 直接计算 → 1 轮
⑧ 设定期望轮次
在 Prompt 末尾加一句期望，能让 Agent 更"收敛"——它不再无限搜下去，而是尽快给出答案。
"请在 2 轮工具调用内给出答案，如果 2 轮内信息不够，基于已有内容给出最佳回答。"
对应我们实验中发现的问题：Agent 死循环的根源是它不知道"信息够了"。你帮它划一条线，它就知道了。
总结一下
| 技巧 | 省什么 | 效果 |
|---|---|---|
| ① 直接给路径 | 省搜索轮次 | 省 1-2 轮，~400+ tok |
| ② 精确搜索词 | 省试错轮次 | 省 1 轮，~200+ tok |
| ③ 已知信息直接喂 | 省工具调用 | 省 1-2 轮，~500+ tok |
| ④ 明确"不需要" | 省无用工具调用 | 省 1-3 轮，视场景 |
| ⑤ 分步提问 | 省历史累积 | 每轮 prompt 更短 |
| ⑥ 直接贴上下文 | 省读文件轮次 | 省 1 轮，~200+ tok |
| ⑦ 指定工具 | 省选错重试 | 省 1-2 轮，~500+ tok |
| ⑧ 设定轮次上限 | 防死循环 | 避免无限浪费 |
这些技巧不需要你换模型、不需要改代码，只需要改变你和 Agent 对话的习惯。你在 Prompt 里多花 10 秒钟把话说清楚，Agent 就能少跑几十秒甚至几分钟。
系列全篇（CSDN）：
- 从零到一：用 AI Agent 辅助在 6GB 显卡上本地部署大模型实战 — 部署全流程
- 只有 B 级能力的大模型，怎么干出 A 级的活？ — 任务拆解方法论
- Agent 不是更聪明的模型，而是长了手脚的模型 — Agent 能力框架
- 从 Ollama 到 llama.cpp：一次"降一层"的本地推理探索 — 推理引擎对比
- KV Cache 优化实战：6GB 显存上的每一 MB 都算数 — 上下文优化
- 从零搭建本地 RAG 系统：200 行 Python 让你的模型"带着资料回答问题" — RAG 搭建
- RAG 配置怎么调最好？6GB 显存上的 4 组对比实验 — RAG 实验
- Agent 不是工具调用器——理解 Agent 的工作机制 — Agent 机制科普
- [Agent 推理的"显微镜"：一次工具调用，到底花了多少 Token？] — 本文
欢迎加入DeepSeek 技术社区。在这里，你可以找到志同道合的朋友，共同探索AI技术的奥秘。
更多推荐
13
0- 0
已为社区贡献2条内容
所有评论(0)