Longtail-SWE开源多语言仓库级编程评测，覆盖13种长尾语言

摘要：Longtail-SWE 发布面向仓库级软件工程任务的基准，包含 Clojure、Dart、Elixir、Erlang、F#、Haskell、Julia、Kotlin、Lua、OCaml、R、Scala 与 Swift 等13种在主流评测中覆盖不足的语言，共收录202个问题修复任务。其核心是 solver–judge–repairer 构造流水线：利用模型解题轨迹和测试结果共同审查任务，修正误杀有效实现或放过错误补丁的测试。项目同时开放可执行环境、构建与评测工具、智能体轨迹，以及更适合小模型的简单任务集，补足主流 SWE 基准偏向 Python 的生态偏差。不过，样本总量仍然有限，LLM 裁判偏差与仓库测试完备性仍是独立复现的主要风险。

---

核心发布

Longtail-SWE 将软件工程智能体的评测范围从 Python 主导的 GitHub issue 修复，扩展到 13 种长尾编程语言。正式集包含 202 个仓库级问题修复任务，覆盖 Clojure、Dart、Elixir、Erlang、F#、Haskell、Julia、Kotlin、Lua、OCaml、R、Scala 和 Swift。

项目同时发布可执行环境、完整的数据构建与评测工具、智能体运行轨迹，以及额外提供的简单任务集。前者用于研究真实仓库中的多文件修改和工具协作，后者让计算预算有限的小模型也能获得具有区分度的评测信号。

为什么现有 SWE 基准不够用

仓库级 SWE 评测通常面对三个工程难题：

1. 候选任务稀缺：很多语言在 GitHub 上的活跃仓库、issue 数量和可复现测试规模都远少于 Python。简单按数量筛选，会把大量语言直接排除。
2. 测试不等于规格：测试通常只覆盖参考实现的行为。若测试把实现细节写死，就会错误拒绝行为等价的替代方案；测试覆盖不足时，错误补丁也可能通过。
3. 任务描述存在歧义：issue 原文可能缺少复现步骤、环境约束或预期行为，模型即使实现正确，也无法稳定对齐判定标准。

Longtail-SWE 的价值不是简单增加语言数量，而是把“候选任务是否可解、测试是否公平、描述是否明确”作为独立的数据质量问题处理。

Solver–Judge–Repairer 如何清洗任务

Longtail-SWE 使用三阶段流水线：

• Solver：让求解智能体在目标仓库环境中实际尝试修复问题，并记录执行轨迹、测试结果和资源消耗。
• Judge：同时检查 issue、求解轨迹与测试输出，判断任务描述是否含混、测试是否错误，以及补丁失败是否源于模型能力而非任务缺陷。
• Repairer：根据审查意见修改测试或任务描述，目标是消除“误杀有效实现”和“放过错误实现”，同时保留具有工程难度、没有被降级为机械题目的任务。

这一方法比单纯的失败率过滤更合理。求解器失败并不自动意味着任务质量差：可能只是模型缺少对应语言能力、仓库环境配置复杂，或问题本身确实需要跨文件推理。Judge 引入额外语义判断后，可以让失败轨迹成为修复测试和规格的依据，而不是直接删除任务。

不过，该流水线仍有双重偏差风险：Judge 可能偏好自己熟悉的语言或实现风格，也可能把某个模型的失败模式误判为任务缺陷。测试被修复后，如果缺少独立验证者确认“原行为确实应被保留”，修订可能继续扩大偏差。

评测维度与工程成本

项目评估了九种模型配置，覆盖前沿模型，并同时分析三个维度：

• 首次任务解决表现；
• 多次尝试之间的一致性；
• Token、调用次数及执行时间等资源使用。

只看单次解决率容易把随机采样优势误判为能力优势。对仓库级智能体而言，重复尝试的一致性非常重要：真实部署通常会配置采样、重试和测试驱动迭代，模型是否能稳定收敛比某一次幸运通过更接近可用性。

长尾语言还会引入明显的工程成本差异。Clojure、Haskell、OCaml 和 Elixir 等语言的工具链、构建系统及测试运行方式不同，评测容器需要为每类仓库固定依赖版本和系统库。容器可复现并不意味着完全稳定：上游包更新、CI 镜像变化或平台特定路径都可能让原本通过的测试失效。因此，正式比较时应记录镜像摘要、依赖锁文件及失败轨迹，而不能只公布最终解决率。

Benchmark 设计的可信度边界

Longtail-SWE 比传统 SWE 基准增加了测试与描述修订环节，但 LLM Judge 并不等价于形式化验证。仓库内可见测试通常只是规格的一个子集：一个补丁通过全部测试，只能说明它满足当前测试覆盖，不足以证明没有回归或完整实现了 issue 要求。

此外，202 个正式任务的统计规模仍偏小。若按13种语言计算，每种语言约15个任务，单语言成绩会被任务难度构成显著影响。更稳健的呈现方式应同时给出：

• 按语言拆分的结果与置信区间；
• 至少三次独立运行的解决率；
• issue 修复后的隐藏测试或人工复核比例；
• 模型是否接触仓库历史、测试修复信息或基准构造工具；
• 简单任务集与正式集之间的难度差距。

如果某模型在正式集上的提升主要来自更高推理预算、更多采样次数或针对特定语言的脚手架，不能直接归因于通用代码能力。

开发者如何落地使用

该基准适合用于三类工作：

1. 模型评测：比较不同模型或智能体框架在非主流语言上的仓库修复能力，避免结论只由 Python 生态主导。
2. 智能体开发：分析完整轨迹中的检索、编辑、测试与错误恢复行为，定位模型是在理解需求、编写补丁还是运行工具时失败。
3. 数据治理：将 solver–judge–repairer 思路迁移到企业内部代码库，用于清洗 issue、补充复现步骤和修正脆弱测试。

实际接入时，建议先固定容器与依赖，再为每种语言准备对应的构建命令和超时策略。评测脚本应保存完整补丁、终端输出、测试失败摘要以及每个工具调用的 Token 成本；否则，仅比较最终解决率很难判断收益来自模型、提示词还是脚手架。

对于希望展示长尾语言能力的团队，Longtail-SWE 比单一 Python 榜单更接近真实多语言软件维护场景。但它更像一个可扩展评测基础设施，而不是已经封闭的绝对排名体系；其长期价值取决于社区是否持续贡献任务、修复环境漂移，并保留人工验证和历史版本。

---

消息来源：Hugging Face Daily Papers (2026-11-06)

—— 完 ——

主题标签： #代码智能体 关注 #SWE-bench 关注 #多语言编程 关注 #仓库级评测 关注 #评测数据清洗 关注