一套客服 Agent 服务多国用户：按地区自动切换知识库实战

我们产品在东南亚和日本都有用户，客服这块一直头疼：同一个问题，新加坡用户问的是英文、政策按 SG 区算，日本用户问的是日文、政策完全是另一套。早期我们维护了三个独立的客服机器人，三套配置各改各的，改一处漏两处是常事。

后来我把它们合成了一套 Agent，进来的请求按地区自动挂对应知识库。这篇记一下怎么做的，以及踩的坑。

思路：一个 Agent，多个知识库，路由切换

核心不是建三个 Agent，是建一个 Agent + 三个知识库（SG / JP / 通用），在工作流前面加一个"识别地区 → 选库"的路由节点。这样话术框架、兜底逻辑、发布通道全共用，只有检索源按地区切。改通用逻辑改一处就够，这是当初最想解决的痛点。

怎么搭的

用的是一个零代码就能配智能体的平台，工作流大概长这样：

region 这个字段我是从调用方传的——我们 App 在请求里带了用户的注册地区，比从 IP 猜靠谱。如果你拿不到这种字段，退一步可以让模型先从用户语言粗判（日文→JP），但不准，混着用英文问 SG 政策的日本用户就会被分错。

路由节点我用的是条件分支，按 region 的值走不同检索节点，每个检索节点绑死一个知识库。配的时候要注意，三个知识库得分开建、分开维护文档，别图省事全塞一个库里再靠 metadata 过滤——我试过那条路，召回经常串台，日本用户能检索到新加坡的条款，很尴尬。物理隔离最省心。

语言这块比想象中麻烦

有个细节坑了我半天：知识库文档是中文写的，但用户用日文/英文提问，检索时跨语言召回质量明显掉。后来我把每个区的知识库文档直接做成对应语言的版本——JP 库里就是日文文档，SG 库里就是英文文档，同语言检索召回稳多了。多维护几份文档，换来召回质量，值。

还有回复语言，我在 prompt 里加了"用与用户提问相同的语言回答"，大部分时候对，但偶尔用户中英夹杂它就纠结。这种边缘 case 我没完美解决，占比很低先放着了。

效果

合并后维护成本降得明显，以前改一条通用话术要去三个机器人改三遍，现在改一次全区生效。客服同学最满意的是兜底转人工——按地区转到对应时区的客服群，不会再出现日本用户半夜的问题转给新加坡白班的人。

一句话交代底层

三个地区跑的都是同一套大模型，我没为多语言去折腾不同的模型部署——讯飞 Agent 是 MaaS 模式，多语言能力现成大模型 API 就覆盖了，省了我自建多套推理服务的事。

你们做多区域客服是合成一套还是拆开维护的？跨语言召回掉点你们怎么治的，评论区交流。