AREX Feed Article
阿里 Qwen 开源多语言智能体基准 BabelArena：同一购物任务英文 25 次工具调用、泰卢固语 201 次均判通过
北京时间 10 月 26 日 20 时 32 分（UTC 12 时 32 分），阿里巴巴 Qwen 官方开发者账号 ，一个覆盖 23 种语言的 LLM（大语言模型）智能体（agent）基准。帖子举出的例子是：Qwen-3.8-Max 用英文和泰卢固语完成同一个购物任务，两次都拿到同样的四件商品、都被判通过，但英文只用了 25 次工具调用（tool calls），泰卢固语用了 201 次。截至发稿，这条帖子获得 1,547 个赞、82,176 次浏览。
开源内容是成套的：跟帖给出了。仓库采用 Apache-2.0 许可证，页面显示 10 月 23 日更新；配套论文已于 9 月 20 日挂在 ，署名来自 Alibaba Token Hub（阿里巴巴集团）与 Ant International。按仓库口径，基准把 699 项规范任务改写成 23 种语言，共 16,077 个实例。
都判通过，但泰卢固语多出了 176 次工具调用
Qwen Developers 在帖子里解释了名字的来历：取自巴别塔的故事——语言障碍会让朝着同一目标协作的人互相误解；而在智能体场景里，可能断掉的地方更多，比如工具参数、数据库条目和搜索查询。
那个购物任务里，泰卢固语一轮反复对本地化后的商品目录发起搜索，一再得到空结果。发布方写道：「即便两条都通过了，上线之前我们也想先看到这个差距。」（中译）201 次调用约为英文 25 次的 8 倍。
这组对比出自发布方自己：模型是 Qwen 自家的 Qwen-3.8-Max，基准也是 Qwen 自家发布。泰卢固语在 BabelArena 里属于低资源语言组，这个例子要说明的是，通过与否的单一判定看不见执行成本，而后者直接影响用户等待的时间和账单。
699 项任务、23 种语言，来自四个基准家族
显示，BabelArena 的任务来自四个现成的智能体基准家族：VitaBench 出 200 项带模拟用户的交互式服务任务（外卖、到店、在线旅行），DeepPlanning 出 120 项长程规划任务（旅行、购物），τ³-Bench 出 212 项工具调用与政策合规任务（航空、零售、电信、银行），ClawEval 出 167 项异构自主任务（含多模态），合计 13 个领域、699 项。论文口径是 702 项任务、16,146 个实例；开源发布冻结的 standard 子集为 699 项、16,077 个实例，比论文少 3 项任务。每种语言变体保留源任务的身份和评测标准，因此同一项任务可以跨语言直接对比。
23 种语言分高、中、低三档资源，覆盖 15 种文字系统：高资源 7 种（英语、中文、日语、法语、俄语、阿拉伯语、西班牙语），中资源 8 种（韩语、印尼语、印地语、泰语、希伯来语、土耳其语、越南语、马来语），低资源 8 种（白俄罗斯语、东旁遮普语、哈萨克语、高棉语、缅甸语、老挝语、泰米尔语、泰卢固语）。
本地化覆盖智能体接触的每一个组件：系统提示词、模拟用户与评测提示词、任务输入、工具描述，以及数据库、政策文档、检索语料这些环境内容，共享实体在各组件间保持一致。仓库 README 把它与 MAPS、SEATauBench 等六个现有多语言智能体基准对比：SEATauBench 同样四类组件全适配，但 BabelArena 的 13 个领域、23 种语言覆盖最广（发布方口径）。有一类内容被刻意留在英文：人名、账户等级、account_type 这类枚举值——评测要把标准工具调用在本地化环境里重放并做哈希比对，翻译这些标识符只会让任务无法打分。
任务数据约 14 GB：仓库本身只带代码和冻结的任务清单，数据需从 或 单独拉取，HF 数据集页显示 10 月 22 日创建、23 日更新。数据集卡片写明这是评测数据不是训练数据：拿它训练，之后再用它测量就失去意义。
BabelFlow：能跑的环境，不能逐段各翻各的
与自包含的输入输出对不同，智能体基准是任务、工具、数据库、模拟用户和评分器互相咬合的可执行环境。论文指出，如果各组件独立翻译，跨组件一致性会断掉——商品名在请求、数据库行和评分标准里对不上，执行就会失败，或者正确的智能体行为被判错。
BabelFlow 的做法是先追数据流再翻译。论文描述：一个编码智能体（Claude-Opus-4.8）读并运行源基准，盘点运行时会访问的每一个文本字段，标记哪些字段必须跨文件一致，并给每个字段定翻译类型——Preserve（保持字节不变：工具名、schema 键、ID、日期、评分控制词）、Translate-Free（就地翻译的说明文字）或 Translate-Canonical（翻一次、处处复用：城市、商品、星期、评分器匹配词）。翻译智能体（Qwen-3.7-Plus）用占位符保护 JSON 键、代码和模板，只翻提取出的字段，翻完原位写回。三个验证智能体（GPT-5.6-Sol、Qwen-3.7-Max、Claude-Opus-4.8）互相看不到彼此的报告，各自把源版本和译版并排运行，从结构完整性、跨文件一致性、语义保真、行为等价四层检查；人工复核者裁决发现、指导修订，所有层通过并签字后，译版才被接受。
效果有一个小规模对照：把 40 项任务翻成中文，独立逐字段翻译有 20.0% 的任务出现引用断裂、5.0% 行为不一致；BabelFlow 分别降到 2.5% 和 0.0%，代价是 3.35 倍的构建 token（词元）。翻译质量上，每种语言抽 200 条、共 4,600 条打分，高、中、低资源语言平均得 4.28、4.02、3.91（5 分制），标注者间 Cohen's κ=0.71。德语被刻意排除：源代码树里有不完整的德语文件、背后没有本地化环境，跑起来无从打分。
五款前沿模型，没有一个赢下全部四个家族
评测跑了五款前沿模型：Claude-Opus-4.8、GPT-5.6-Terra、Gemini-3.1-Pro、Qwen-3.7-Max、Qwen-3.8-Max，统一中等推理档、temperature 0；模拟用户由 Gemini-3.5-Flash 扮演，LLM 裁判用 GPT-5.6-Sol（DeepPlanning 用确定性规则打分，不用裁判）。每项任务跑 3 次独立试验，报 Pass^1（单次成功率）和 Pass^3（三次全部成功的比例），另报 LC（语言一致性，用户可见文本保持在目标语言的轨迹占比）。数据集卡片点破了这个指标的意义：一个智能体可以拿满任务分，同时在用英文回答一个泰语用户。
结果是发布方自己总结的那句话：没有一个模型在全部四个家族领先。Qwen-3.8-Max 在 VitaBench（Pass^1 42.3%）和 DeepPlanning（46.0%）领先，Gemini-3.1-Pro 在 τ³-Bench 的 Pass^1 领先（71.4%），Claude-Opus-4.8 在 ClawEval 领先（Pass^1 55.8%）。Qwen 自家的 Qwen-3.8-Max 在其中两个家族的任务指标领先，语言一致性却掉队：VitaBench 上 LC 为 94.7%，低于 Gemini-3.1-Pro 的 99.9%。按语言资源分组看，GPT-5.6-Terra 的 LC 三组全部最高——论文把这读作：任务表现强，不等于语言用得稳。
低资源语言的账单：报错更多、token 最多翻倍、切回英文
五款模型在低资源语言组里的 Pass^1、Pass^3 和 LC 全部低于高资源组。差距不止在分数：论文摘要写明，低资源语言出现的是更大比例的工具使用和控制流错误，而不只是答案质量错误。
开销同样放大：同样一批任务，低资源语言的输入 token 至多约为英文的 2 倍（论文区间：同一批 VitaBench 任务上为英文的 1.69～2.06 倍），而交互轮数并没有相应变长。语言切换也在发生：抽样标注的 DeepPlanning 与 ClawEval 不一致轨迹里，91.2% 的切换方向是英文，DeepPlanning 的不一致集中在助手回复，ClawEval 集中在工具调用前的文本前缀。论文还指出 DeepPlanning 的语言一致性明显差于其他家族，五款模型里最低只有 57.5%（Qwen-3.7-Max）。
回复区在追问：8 倍是常态还是长尾
这条帖子在回复区引出了两类声音。一类追问指标本身：用户 @ilmAI_ ，如果评测只看最终答案，25 次能干完的活跑 201 次照样算通过，评测应该把工具调用次数也数进去； 则按论文摘要对账：典型差距是低资源语言输入 token 至多约 2 倍，25 对 201 读起来像长尾个案——该问的是这种尾巴多久出现一次； 的版本更直接：同一个购物篮，顾客拿到同样的四件商品，等待和账单却是另一回事。
另一类更关心模型本身：，也有人对名字开起玩笑—— 写道：「别这么干，巴别塔的故事结局可不好。」（中译）
这类个案在 23 种语言里出现得多频繁，原帖没有给出频率数字；算清它要跑全套评测——按仓库说明，复现论文协议是标准任务子集、全部 23 种语言、每项任务 3 次试验，任务数据和评测代码均已开源。