arXiv cs.CL 新论文 When the API Speaks the Wrong Language: Revisiting Post-Training for Multilingual Tool Use 把一个长期被低估的问题放到了台前：LLM agent 的工具调用能力，在多语言场景下并不等同于“会翻译”。一个模型可以流畅回答中文问题，却在工具选择、参数映射、日期格式或单位转换上出错。
这对全球化产品很关键。很多团队的工具描述、函数名、schema、错误消息都是英文，但用户输入可能是中文、日文、德文、阿拉伯语或混合语言。模型需要跨语言理解意图，再把意图落到英文工具接口。这中间有多个断点。
工具调用不是翻译题
假设用户说：
帮我查一下上周五上海到北京最早一班高铁，预算别超过 600 元。一个普通翻译系统只需要翻译句子。工具调用 agent 需要做更多事：
- 识别任务是查询交通，而不是天气或日历。
- 选择
searchTrainTickets工具。 - 把“上周五”解析成具体日期。
- 把“上海到北京”映射成出发地和目的地。
- 把“最早一班”映射成排序条件。
- 把“别超过 600 元”映射成价格上限。
- 确认货币单位。
- 返回结果时不要编造工具没有给出的班次。
每一步都可能错。模型即使能把原句翻译成英文，也不代表能正确填工具参数。尤其是相对日期、地名、货币、否定约束和排序条件，都是多语言 agent 的高风险点。
多语言断层在哪里
多语言工具调用常见断层有五类。
第一，工具选择断层。用户语言和工具描述语言不同，模型可能选错工具。比如“开票”在中文业务语境里可能是 invoice，不是 open ticket。
第二，参数槽位断层。模型知道要查车票，却把目的地和出发地写反，或者把预算写到 minPrice。
第三，格式断层。日期、时间、电话号码、地址、货币、小数分隔符在不同语言和地区里格式不同。
第四，领域术语断层。企业内部术语、医疗术语、金融产品名不一定能被通用翻译正确处理。
第五，错误恢复断层。工具返回英文错误，用户继续用中文追问，模型需要跨语言解释并修正参数。
这些断层说明，评估多语言 agent 不能只看最终回答是否通顺。最终回答可能很通顺，但工具根本没被正确调用。
为什么英文 benchmark 不够
很多工具调用 benchmark 默认英文。模型在这些 benchmark 上表现好，不代表能处理真实国际化流量。原因有三个。
第一，英文工具名和英文用户请求有词面重合。用户说 “book a flight”，工具叫 bookFlight，模型很容易对齐。中文用户说“订机票”，模型要跨语言映射。
第二，英文日期和数字格式较统一。多语言场景里，“05/06/2026”可能有不同解释，中文“下下周一”也需要本地时间语境。
第三，英文 benchmark 往往忽略混合语言。真实用户会写“帮我 book 下周去 Tokyo 的酒店”，企业员工会混用产品名、英文缩写和中文动词。
因此，多语言工具调用必须单独评估。
开发者的评测设计
一个合格的多语言工具调用评测集，至少要覆盖四层指标。
第一层是 intent accuracy：模型是否理解用户要做什么。
第二层是 tool accuracy：模型是否选对工具。
第三层是 argument accuracy：每个参数是否正确，包括日期、单位、枚举和布尔值。
第四层是 answer faithfulness：最终回答是否忠实于工具结果。
可以用这样的样本格式：
{
"locale": "zh-CN",
"input": "把明天下午三点和王丽的会议改到下周二上午十点",
"expectedTool": "rescheduleCalendarEvent",
"expectedArgs": {
"attendee": "王丽",
"fromTime": "2026-08-15T15:00:00+08:00",
"toTime": "2026-08-18T10:00:00+08:00"
},
"risk": ["relative_time", "person_name", "timezone"]
}注意，日期需要固定测试时区和当前日期。否则“明天”“下周二”会随运行时间变化，回归测试不可重复。
工具 schema 要本地化吗
函数名不一定要本地化，但 schema 描述应该考虑多语言用户。
不建议把同一个工具复制成 searchTrainTicketsZh、searchTrainTicketsEn、searchTrainTicketsJa。这样会让工具数量膨胀，增加维护成本。更好的做法是保留稳定工具名，在描述和枚举值上提供本地化解释。
例如：
{
"name": "searchTrainTickets",
"description": "Search train tickets. Supports multilingual user requests including Chinese city names and relative dates.",
"parameters": {
"origin": "Departure city, e.g. Shanghai or 上海",
"destination": "Arrival city, e.g. Beijing or 北京",
"date": "ISO date after resolving relative local expressions",
"maxPriceCny": "Maximum price in CNY"
}
}关键是让模型知道字段语义，而不是只看到英文变量名。
翻译前置的利弊
一种常见策略是先把所有输入翻译成英文，再做工具调用。这有优点：可以复用英文 benchmark 和工具描述，系统复杂度低。
但它也有问题。
第一，翻译可能丢失本地格式。地址、姓名、机构名和产品名被错误翻译后，工具参数会错。
第二，翻译可能改变约束强度。比如“尽量不要超过”与“不得超过”不是同一约束。
第三，多轮对话会更复杂。用户原文、英文中间表示、工具结果和中文最终回答之间要保持一致。
更稳妥的策略是：翻译作为可观测中间层，但不要让它成为唯一依据。保存用户原文、翻译文本和最终参数，评测时分别检查。
生产系统加固
第一，对高风险字段做确定性解析。日期、货币、单位、地区代码不要完全依赖模型。模型可以提出候选，最终由解析器和校验器确认。
第二，工具返回错误要本地化。用户用中文发起请求，工具错误如果只返回英文机器码，模型可能解释不清楚。
第三，保留原文。日志里必须保存用户原始输入，不能只保存英文翻译。
第四，按语言统计成功率。不要只看全站工具调用成功率。某些语言可能失败率显著更高。
第五，构建混合语言测试。企业用户很常用“中文动词 + 英文产品名 + 缩写”，这比纯中文更真实。
结论
When the API Speaks the Wrong Language 这类研究提醒我们：多语言 agent 的难点不在于把一句话翻译得漂亮，而在于把跨语言意图稳定落到工具接口。工具调用是语言理解、格式解析、业务规则和执行安全的交叉点。
如果你的 agent 面向全球用户或多语言企业团队，不能只跑英文工具 benchmark。至少要建立按语言、地区和字段风险分类的回归集。工具选择正确、参数正确、结果忠实，三者同时成立，多语言 agent 才算真的可用。