副标题三款模型实测 八条 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 6GBQwen3-8B指令模型8.2B本地 llama.cpp, GTX 1660 Ti 6GBDeepSeek V4 Pro指令推理(云端)~671B MoEAPI 调用三个测试任务任务描述预期行为① 简单问答对照组“什么是 KV Cache用一句话回答”不需要工具单轮推理② 搜索总结“搜索 KV Cache 相关内容总结优化方法”调 search_kb → 总结③ 搜索计算“查 Qwen3-8B 的 KV Cache 公式算 ctx16384 时的大小”调 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.6sV4 的 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 公式算 ctx16384 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_model512, d_head64 → 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_head8, d_model512, d_head64 → 这些参数从哪来的从模型自己的训练知识里翻出来的 → 而不是从 search_kb 返回的结果里取的 问题就出在这里——它搜到了 36 layers, 8 kv_heads, 128 d_head 但推理过程中认为我记忆中的 d_model512 才是正确的 → 推理模型的自我推理覆盖了工具输出五、三组模型的 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 公式然后算 ctx16384 的大小 → search_kb → 搜到参数 → 再计算 → 2-3 轮 ✅ Qwen3-8B36 层、8 个 KV 头、d_head128。公式是 2×L×H×d×ctx×2。 算 ctx16384 时 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] — 本文