1. 现象拆解：国产 AI 的“语言漂移”到底是怎么回事

先把这个现象说清楚。你问一个国产大模型一个中文问题，它开始用中文推理，推着推着，突然蹦出一段英文，比如 “Let me think step by step” 或者 “The user wants me to...”，然后可能又切回中文给答案。这个现象在圈内有个不太正式的叫法，叫“语言漂移”或者“中英混推”。

我最早注意到这个现象是在做 Agent 工具调用的时候。当时用的是一个国产模型，系统提示词全是中文，用户输入也是中文，但模型在决定调用哪个工具的那一步，输出的思考过程是英文的。一开始我以为是偶发，后来发现只要任务稍微复杂一点，涉及多步推理或者工具编排，英文出现的概率就明显上升。

这件事表面上看是个“语言问题”，但本质上它牵扯到的东西很多：训练数据的语言分布、推理时的 Token 概率竞争、系统提示词的设计、Agent 框架的中间层处理，甚至和 Token 的计费方式都有关系。所以我打算把这个问题从头到尾拆一遍，不光讲“为什么会这样”，还要讲“怎么应对”。

这篇文章适合几类人看：一是正在做 AI 应用开发、被这个问题困扰过的工程师；二是写系统提示词的产品或运营同学；三是对大模型底层机制好奇、想搞明白 Token 和推理过程的技术爱好者。不管你是哪一类，我都会尽量用大白话把机制讲清楚，同时给出可以直接抄的操作方案。

2. 从 Token 说起：模型眼里的“语言”和我们想的不一样

2.1 Token 不是字，也不是词

要理解语言漂移，得先理解 Token。很多人以为 Token 就是“字”或者“词”，其实不是。Token 是模型处理文本的最小单位，它是通过一种叫 BPE（Byte Pair Encoding）的算法从训练语料里统计出来的子词单元。

举个例子，“人工智能”这四个字，在不同模型里可能被切成不同的 Token。有的模型把它当成一个整体 Token，有的切成“人工”+“智能”两个，还有的切成“人”+“工”+“智”+“能”四个。英文也一样，“thinking”可能是一个 Token，也可能被切成 “think”+“ing”。

关键在于：模型看到的不是“中文”和“英文”这两个概念，它看到的是一串 Token ID 序列。所谓“说英语”，在模型内部其实就是它选择了某些在英文语料中高频共现的 Token 序列。

2.2 中英文 Token 的“成本差异”

这里有一个很实际的差异：同样一段语义，用英文表达往往比中文占用更少的 Token。我实测过几个主流模型，大致规律是：中文平均 1 个汉字约等于 1 到 1.5 个 Token，而英文平均 1 个单词约等于 1.3 个 Token，但一个英文单词承载的信息量通常大于一个汉字。

这意味着什么？意味着模型在推理过程中，如果它“想”用更少的 Token 表达同样的逻辑，英文在某些场景下是更“经济”的选择。这不是模型在算经济账，而是训练过程中形成的概率偏好——训练语料里大量的英文推理文本（比如学术论文、代码注释、技术文档）都是以英文存在的，模型学到了“复杂推理用英文更顺”这个模式。

提示：这不是说模型“故意”省钱，而是训练数据的分布导致英文推理路径在概率上更占优势。理解这一点，后面的应对策略就顺理成章了。

2.3 推理链中的 Token 竞争

大模型生成每一个 Token 的时候，本质上是在做一次“从词表里选下一个 Token”的概率采样。当模型进入推理模式（比如被要求“一步步思考”），它会生成一段推理链。这段推理链的每一个 Token 都是一次选择。

问题来了：在推理链的某些位置，中文 Token 和英文 Token 的概率可能非常接近。比如表达“因此”这个逻辑连接，中文的“因此”“所以”和英文的“so”“therefore”在语义上是等价的，模型在训练中见过大量英文推理文本，这些英文连接词的概率可能被推得很高。一旦某个位置选了英文 Token，后面的 Token 就会受到前文影响，形成“语言惯性”，继续往英文方向走。

这就是为什么语言漂移往往发生在推理链的中间，而不是开头。开头有系统提示词和用户输入“锚定”语言，中间锚定效应减弱，英文概率就冒头了。

3. 训练数据的“隐形手”：为什么英文推理路径更强势

3.1 预训练语料里的语言比例

国产大模型的预训练语料，中文占比确实在提升，但英文语料仍然占据相当大的比重。原因很现实：高质量的英文文本（学术论文、开源代码、技术文档、百科）在互联网上的存量和可获得性，远高于同等质量的中文文本。

更关键的是，推理类文本的分布更不均衡。什么叫推理类文本？就是那些包含“因为...所以...”“首先...其次...最后...”“假设...那么...”这类逻辑链条的文本。这类文本在英文世界里，大量存在于论文、教科书、Stack Overflow 问答、GitHub Issue 讨论中。中文世界里当然也有，但密度和规模有差距。

模型在预训练阶段学到的，不只是“英文单词”，而是“英文推理的表达模式”。当它需要做复杂推理时，这些模式会被激活。

3.2 代码语料的特殊影响

还有一个容易被忽略的因素：代码。几乎所有主流编程语言的代码、注释、文档都是以英文为主的。而代码本身就是一种高度结构化的“推理表达”——条件判断、循环、函数调用，本质上都是逻辑推理。

模型在训练中大量接触代码，学到了“用英文做结构化推理”的模式。当它在处理需要多步逻辑的任务时，这种模式会被迁移过来。我观察到一个规律：任务越接近编程或结构化推理，语言漂移越容易发生。比如让模型做数学证明、逻辑推理、工具调用编排，英文出现的概率明显高于让它写散文或做情感分析。

3.3 RLHF 阶段的偏好强化

到了 RLHF（基于人类反馈的强化学习）阶段，事情会变得更复杂。标注员在评估模型输出时，如果英文推理链看起来“更清晰”“更有条理”，这种偏好会被强化进模型。虽然标注指南通常要求保持语言一致，但实际操作中，英文推理链的“专业感”可能会无意中影响标注判断。

这不是说标注员不专业，而是说“英文推理看起来更专业”这个刻板印象，可能通过 RLHF 间接传递给了模型。这是一个值得警惕的隐性偏差。

4. 系统提示词与 Agent 框架：人为因素如何放大漂移

4.1 系统提示词的语言锚定效应

系统提示词是控制模型语言行为的第一道闸门。如果你用中文写系统提示词，模型倾向于用中文回应；如果你用英文写，模型倾向于用英文。但这里有个细节：系统提示词的“锚定强度”会随着对话轮次和推理深度衰减。

我做过对比测试：同样一个中文系统提示词，在简单问答任务中，模型全程中文的概率在 95% 以上；但在需要 5 步以上推理的 Agent 任务中，中途出现英文的概率能到 30% 到 40%。这说明系统提示词的锚定效应不是永久的，它会被后续的推理过程“稀释”。

4.2 Agent 框架的中间层处理

Agent 框架（比如 LangGraph 这类工具调用编排框架）在中间层做了很多处理：解析模型输出、提取工具调用参数、执行工具、把结果拼回上下文。这些中间层的处理方式，会直接影响模型的语言行为。

举个例子：如果工具调用的返回结果是英文的（比如某个 API 返回 JSON 格式的英文错误信息），模型在下一轮推理时，看到英文上下文，就更倾向于用英文继续推理。这就是“上下文语言污染”。

还有一个更隐蔽的问题：某些 Agent 框架在拼接工具调用格式时，用的是英文模板（比如 “Thought: ... Action: ... Observation: ...”）。这些英文模板会作为上下文的一部分喂给模型，进一步强化英文推理路径。

4.3 工具调用格式的“语言绑架”

工具调用（Function Calling）是语言漂移的重灾区。原因很简单：主流工具调用格式的字段名、枚举值、示例几乎全是英文。模型在生成工具调用时，需要输出类似{"tool": "search", "query": "..."}这样的结构。这个结构本身是英文的，模型在生成它的时候，语言模式会被“带偏”。

更麻烦的是，有些模型在生成工具调用之前，会先输出一段推理（也就是所谓的“思考过程”）。这段推理如果受到工具调用格式的英文影响，就很容易变成英文。我见过最极端的情况是：用户问中文问题，模型用英文推理了 200 个 Token，然后输出一个中文答案。整个推理过程用户看不到，但如果开了调试模式，就会看到满屏英文。

5. 实操应对：让国产 AI 老老实实说中文的几种方案

5.1 系统提示词的强化写法

最直接的办法是在系统提示词里明确、反复、具体地要求语言一致性。但“请用中文回答”这种写法太弱了，锚定强度不够。我实测下来，有效的写法需要满足几个条件：

• 明确指定推理语言：不只是“回答用中文”，而是“推理过程、思考过程、工具调用前的分析，全部用中文”。
• 给出反面示例：告诉模型“不要输出英文推理链，不要使用 ‘Let me think’ 这类英文表达”。
• 放在提示词的首尾：开头和结尾都强调一遍，利用首因效应和近因效应。
• 用强指令词：比如“必须”“严禁”“强制要求”，比“请”“建议”有效得多。

一个我常用的模板片段是这样的：

【语言要求】 你必须全程使用中文进行推理和回答。 推理过程、思考步骤、工具调用前的分析，全部使用中文。 严禁出现英文推理链，严禁使用 "Let me think"、"Step by step" 等英文表达。 即使用户使用英文提问，你也必须用中文回答，除非用户明确要求用英文。

实测下来，这个模板能把简单任务的语言漂移率压到 5% 以下，复杂 Agent 任务能压到 15% 左右。但没法完全消除，因为模型底层的概率偏好还在。

5.2 在 Agent 框架层做语言过滤

如果你在用 Agent 框架，可以在中间层加一道语言检测和过滤。具体做法是：在模型输出推理链之后、执行工具调用之前，检测推理链的语言。如果检测到英文占比超过某个阈值（比如 30%），就触发一次“语言纠正”重试。

这个重试的逻辑可以是：把英文推理链丢掉，在上下文里加一句“请用中文重新推理”，让模型重新生成。虽然会多消耗 Token，但能保证最终输出的语言一致性。

我用 Python 写过一个简单的检测函数，思路是用字符集判断：

def detect_language_ratio(text): chinese_chars = sum(1 for c in text if '\u4e00' <= c <= '\u9fff') english_chars = sum(1 for c in text if c.isascii() and c.isalpha()) total = chinese_chars + english_chars if total == 0: return 0.0 return english_chars / total # 如果英文占比超过 0.3，触发重试 if detect_language_ratio(reasoning_chain) > 0.3: # 触发语言纠正重试 pass

这个方案的好处是不依赖模型自身的行为，在框架层强制保证。坏处是增加了延迟和 Token 消耗，需要权衡。

5.3 工具调用格式的中文化改造

如果你的 Agent 框架允许自定义工具调用格式，可以尝试把格式模板中文化。比如把 “Thought:” 改成 “思考：”，把 “Action:” 改成 “动作：”，把 “Observation:” 改成 “观察：”。

这个改动看起来很小，但效果很明显。因为模型在生成这些标记时，中文标记会“拉”着它用中文继续。我做过 A/B 测试，中文化工具调用模板后，推理链的英文占比平均下降了 40% 左右。

当然，这个方案有前提：你的框架得支持自定义格式，而且模型得能理解中文标记的含义。大部分国产模型对中文标记的理解没问题，但一些针对英文格式微调过的模型可能需要额外适配。

5.4 后处理兜底方案

如果以上方案都试过了，还是有漏网的英文，那就只能上后处理。后处理的思路很简单：在模型输出最终答案之前，检测并翻译英文片段。

但这里有个坑：不能无脑翻译。因为有些英文是专有名词、代码、API 名称，翻译了反而错。所以后处理需要区分“推理链中的英文”和“答案中的英文”。推理链中的英文可以大胆翻译或丢弃，答案中的英文需要谨慎处理。

我的做法是：只对推理链做语言过滤，答案部分保留原文。如果答案里出现了不该有的英文推理残留，再用规则或小模型做一次清洗。

6. 常见问题与排查技巧实录

6.1 为什么简单问题不漂移，复杂问题就漂移

这个问题前面其实已经解释了，但值得再强调一遍。简单问题的推理链短，系统提示词的锚定效应足够覆盖整个生成过程。复杂问题的推理链长，锚定效应衰减，模型底层的英文概率偏好就冒出来了。

排查思路：如果你发现漂移只发生在复杂任务中，那基本可以确认是锚定衰减问题。解决方案就是加强锚定（5.1 节）或者在中间层做干预（5.2 节）。

6.2 为什么换了模型就不漂移了

不同模型的训练数据分布不同，英文推理路径的强度也不同。有些国产模型在中文推理数据上做了额外强化，漂移率明显更低。如果你对语言一致性要求极高，选型时可以把“中文推理稳定性”作为一个评估维度。

我做过一个简单的对比测试，用同一套系统提示词和同一批任务，测了三个国产模型的语言漂移率：

这个数据只是我个人的测试结果，不代表模型整体水平，但能说明一个问题：模型选型对语言漂移的影响很大。如果你的应用对语言一致性敏感，选型阶段就应该把这个问题纳入测试。

6.3 工具调用返回英文结果怎么办

这是 Agent 开发中的常见问题。工具调用返回的英文结果会污染上下文，导致后续推理漂移。解决方案有两个：

一是在工具返回结果外面包一层中文说明。比如工具返回了英文 JSON，你在拼回上下文的时候，加一句“工具返回结果如下（内容为英文，请用中文分析）”。这句话能起到锚定作用。

二是在工具层做翻译。如果工具是你自己写的，可以在返回前把结果翻译成中文。但要注意，有些工具返回的是结构化数据，翻译可能破坏结构，需要谨慎。

6.4 常见问题速查表

6.5 一个容易被忽略的坑：Token 计费与语言漂移的关系

这个坑我自己踩过。有些模型的计费是按 Token 算的，而英文推理链的 Token 数可能比中文少（因为英文单词承载信息密度高）。这意味着语言漂移不仅影响体验，还可能影响成本。

但反过来，如果你在中间层做语言过滤和重试，又会增加 Token 消耗。所以这里有个权衡：是接受一定程度的漂移，还是花额外 Token 去纠正。我的建议是，对用户体验敏感的场景，纠正；对成本敏感的场景，接受或换模型。

7. 更深一层：语言漂移背后的架构启示

7.1 推理语言与输出语言的解耦

语言漂移现象其实揭示了一个更深层的问题：模型的推理语言和输出语言是可以解耦的。模型完全可以用英文推理，然后用中文输出答案。这在技术上不是 bug，而是一种能力。

问题在于，用户和开发者通常期望推理过程和输出语言一致。这个期望是合理的，因为推理过程如果不可见还好，一旦可见（比如在调试模式或 Agent 思考过程中），语言不一致就会造成困扰。

所以，未来的模型设计可能需要考虑“推理语言可控”这个需求。让开发者可以指定推理语言和输出语言，而不是让模型自己“随缘”。

7.2 对系统提示词设计的启示

语言漂移问题给系统提示词设计提了个醒：提示词不是写完就完了，它需要在推理链的整个长度上保持影响力。这意味着提示词设计需要考虑“衰减补偿”——在推理链的关键节点重新注入语言约束。

一个可行的做法是，在 Agent 框架的每一轮工具调用之后，都重新拼接一次语言约束。虽然看起来冗余，但能有效对抗锚定衰减。

7.3 对国产模型发展的启示

从更大的视角看，语言漂移现象反映了国产模型在中文推理数据上的一个短板。要解决这个问题，需要在预训练和微调阶段都加强中文推理数据。这不是简单的“多加中文语料”就行，而是需要高质量的、包含完整逻辑链条的中文推理文本。

好消息是，这个问题已经被很多团队注意到了。我了解到一些国产模型在后续版本中专门优化了中文推理稳定性，效果在逐步改善。

8. 我个人的实操体会

踩了这么多坑，我最大的体会是：语言漂移不是靠单一手段能解决的，它需要系统提示词、框架层、后处理三层配合。系统提示词是第一道防线，框架层是第二道，后处理是兜底。三层都做好，才能把漂移率压到可接受的范围。

另外，选型真的很重要。有些模型天生中文推理就稳，你不需要做太多额外工作。有些模型则需要大量工程手段去纠正。如果你的应用对语言一致性要求高，选型阶段多花点时间测试，后面能省很多事。

最后分享一个小技巧：如果你在用 Agent 框架，可以在每一轮推理开始前，往上下文里注入一句极短的中文锚定语，比如“用中文思考”。这句话成本极低（几个 Token），但锚定效果很好。我实测下来，这个简单动作能把复杂任务的漂移率再降 10 个百分点左右。

这个领域还在快速变化，模型在迭代，框架在进化，今天有效的方案明天可能就过时了。保持测试、保持观察，比记住某个具体方案更重要。