DeepSeek vs Gemini：RAG 场景的工具调用风格调优

给博客 AI 助手选模型时，我同时试了 DeepSeek 和 Gemini 2.5 Flash。最有意思的发现是：同一套 System Prompt、同一组工具，两个模型的「性格」完全不同，调优方向几乎相反。

两种截然不同的「性格」

DeepSeek：推理欲望强，会主动突破软约束去穷尽意图。

• 在 RAG 场景下倾向于多轮调用工具——搜一次不够再搜一次、换个 query 再来；
• token 消耗偏高；
• 但中文语境下效果出色，且成本极低。

Gemini：极度克制，严格遵循指令约束，走最短路径完成任务。

• token 消耗低；
• 但回答有时过于简略，甚至在同样的提示词下显得「懒惰」——该多查一步的时候它就不查了。

一个像热情过头的实习生，恨不得把所有资料都翻一遍；一个像惜字如金的专家，问一句答一句。

针对 DeepSeek：在代码层踩刹车

DeepSeek 的「勤奋」是双刃剑：召回更全，但容易陷入「贪婪循环」，一轮轮调工具停不下来，token 飙升。所以对它的调优重点是在代码层硬限制工具调用次数：

// 每个请求最多几轮工具调用——给 DeepSeek 这种爱多调的模型踩刹车
export const CHAT_AGENT_TOOL_CALL_MAX_STEPS = 5

光靠提示词说「别调太多次」对它不太管用——它推理欲望强，会突破软约束。硬限制比软约束可靠：到了上限就强制收尾。这是用 DeepSeek 做 Agent 时最重要的一条工程护栏。

针对 Gemini：在提示词里加发散指令

Gemini 的问题相反——太省。如果换成它当主力，调优方向就要反过来：在 System Prompt 里显式加入发散性指令，鼓励它「拿不准就先检索」「多取一些上下文再综合」，避免回答过于保守、漏掉本该查到的信息。

也就是说：

	DeepSeek	Gemini
默认倾向	过度调用工具	调用不足
调优方向	代码层限制步数	提示词层鼓励发散
token 成本	偏高	低
中文表现	出色	也不错但偏简

我的最终选择

我把 DeepSeek 作为主力，Gemini 作为备选。原因：

• 博客是中文内容，DeepSeek 的中文表现更贴；
• 成本极低，对个人项目友好；
• 它的「过度勤奋」可以用一行 MAX_STEPS 配置稳稳摁住，而 Gemini 的「过度克制」要靠不断打磨提示词去哄，后者更费心。

换句话说：约束一个勤奋的模型，比激励一个懒惰的模型更可控。

更普适的经验

这事给我的启发超出选型本身：

1. 模型有「性格」，提示词不是万能的。同样的 prompt 在不同模型上会被「理解成不同的勤奋程度」。
2. 软约束（提示词）和硬约束（代码）要配合。能力边界（最多调几次、最长多少 token）用代码兜底，风格倾向用提示词引导。
3. 选型要结合你的护栏成本。不要只看「哪个模型更聪明」，要看「哪个模型的偏差更容易被你现有的工程手段纠正」。

小结

DeepSeek 勤奋、Gemini 克制，RAG 场景下一个要「踩刹车」（代码层限工具步数），一个要「加油门」（提示词促发散）。我选 DeepSeek 当主力，因为中文好、成本低，而它唯一的毛病——过度调用——恰好能被一行硬限制稳稳摁住。选模型，本质是选一个「偏差最好纠」的伙伴。