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 是模型处理文本的最小单位它是通过一种叫 BPEByte 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 为什么换了模型就不漂移了不同模型的训练数据分布不同英文推理路径的强度也不同。有些国产模型在中文推理数据上做了额外强化漂移率明显更低。如果你对语言一致性要求极高选型时可以把“中文推理稳定性”作为一个评估维度。我做过一个简单的对比测试用同一套系统提示词和同一批任务测了三个国产模型的语言漂移率模型简单任务漂移率复杂 Agent 任务漂移率模型 A2%35%模型 B1%18%模型 C3%42%这个数据只是我个人的测试结果不代表模型整体水平但能说明一个问题模型选型对语言漂移的影响很大。如果你的应用对语言一致性敏感选型阶段就应该把这个问题纳入测试。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 个百分点左右。这个领域还在快速变化模型在迭代框架在进化今天有效的方案明天可能就过时了。保持测试、保持观察比记住某个具体方案更重要。