32B 参数暴打 671B：OpenHands LM 如何证明「模型大小不是一切」

2025 年 3 月，OpenHands 团队发布了一款基于 Qwen2.5-Coder-32B 的开源 coding 模型。15 个月后，它的继任者们——同样是 32B 参数——在 SWE-Bench Verified 上做到了 62.2% 的解决率。而 671B 参数的 DeepSeek V3 只做到 38.8%。这不是魔法，是三个层面的进化：数据质量、训练方法和 Agent 框架的协同。当整个行业还在卷参数规模时，OpenHands 生态用事实证明：软件工程任务的解决能力，更多取决于「你怎么训练」和「你怎么用」，而不是「你有多大」。

发布时间: 2026-06-05
来源: OpenHands Dev Team / All Hands AI, 2025-2026
论文: 多篇 arXiv 论文（详见参考文献）
核心模型: OpenHands LM 32B（基于 Qwen2.5-Coder-32B-Instruct）

1. 一个反直觉的事实：32B 可以赢 671B

2025 年 3 月，OpenHands 团队发布了一个看似不起眼的模型：OpenHands LM 32B。基于 Qwen2.5-Coder-32B-Instruct，微调数据来自 OpenHands agent 在真实开源仓库上的成功轨迹。

它的 SWE-Bench Verified 成绩：37.2%。

这个成绩本身不算惊艳。但对比对象让它变得刺眼：

• DeepSeek V3 (671B)：38.8%
• Qwen2.5-Coder-32B-Instruct（原版，无微调）：6.2%
• OpenHands LM 32B（微调后）：37.2%

32B 参数，接近 671B 模型的性能。20 分之一的参数，95% 的性能。

但这只是开始。

2. 从 37.2% 到 70.8%：15 个月的进化弧线

OpenHands LM 不是孤立模型，而是一个生态的起点。接下来的 15 个月，多个团队基于相同或类似的 32B 骨干，推出了改进版本。

关键观察：

1. 37.2% → 62.2%：同样的 32B 参数，同样的 OpenHands 框架，不同的训练数据和方法，性能提升 67%
2. 测试时缩放（TTS）的惊人效果：SWE-Master-32B 从 57.8% → 70.2%，仅通过增加推理时的尝试次数
3. RL 的边际效应：SFT + RL 相比纯 SFT 提升约 3-5 个百分点，但成本显著更高

3. 为什么 32B 能做到这些？三个层面的拆解

3.1 层面一：数据——质量比数量重要，但数量也很重要

OpenHands LM 的成功起点是数据生成范式的转变。

传统方法：人工收集代码库，标注问题-解决方案对。
OpenHands 方法：让 agent 自己运行，只保留成功的轨迹。

具体流程（SWE-Gym 框架）：

1. 选一个真实 GitHub issue
2. 让 OpenHands agent（可能是 Claude/GPT）尝试解决
3. 如果成功通过测试 → 保留这条轨迹作为训练数据
4. 如果失败 → 丢弃

这种自举式数据生成（bootstrapped data generation）的核心优势：

• 数据是真实分布：来自真实开源项目，不是合成数据
• 数据天然可执行：每条轨迹都包含具体的文件编辑、命令执行、测试验证
• 数据质量高：只有成功轨迹才被保留，模型只学「做对的事」

SWE-Mirror-LM 的创新是数据量放大：用镜像大规模真实问题，训练数据覆盖更广的问题类型。这解释了为什么它从 37.2% 跳到 52.2%。

Skywork-SWE 的研究进一步发现数据缩放定律：在 SWE 任务上，数据量增加到某个阈值后，性能持续上升，没有出现饱和。

3.2 层面二：训练方法——SFT 是基石，RL 是锦上添花，TTS 是秘密武器

监督微调（SFT） 是所有 32B 模型的共同基础。但关键区别在训练数据怎么来：

• OpenHands LM：用 SWE-Gym 生成轨迹，成功即保留
• SWE-Master：用 R2E-Gym（一个新的训练环境），从零构建更复杂的轨迹
• SWE-Swiss：加入 RL 优化，让模型学会「验证自己的输出」

强化学习（RL） 的效果：

• SWE-Master-32B-SFT：57.8%
• SWE-Master-32B-RL：61.4%
• 提升：3.6 个百分点

这个提升是真实的，但代价是：

• RL 训练需要大量的计算资源
• 需要设计合适的奖励函数（测试通过 ≠ 正确修复）
• 容易过拟合到特定测试集

测试时缩放（Test-Time Scaling, TTS） 才是最大的性能杠杆：

• SWE-Master-32B-SFT：57.8% → 70.2%（TTS@8）
• SWE-Master-32B-RL：61.4% → 70.8%（TTS@8）

TTS 的含义：在推理时，让模型生成多个候选方案，然后用验证器（verifier）选择最好的。这个策略在 SWE 任务上特别有效，因为：

• 有明确的测试套件作为验证器
• 候选方案之间可以并行验证
• 增加尝试次数的边际成本递减

3.3 层面三：Agent 框架——模型是引擎，框架是底盘

这是最容易被忽视的一点：同一个 32B 模型，在不同的 Agent 框架下，性能差异巨大。

Qwen2.5-Coder-32B-Instruct（原版，无微调）：

• 在 OpenHands 框架下：6.2%
• 在 SWE-Agent 框架下：40.2%（微调后）

这个对比说明：模型不是唯一变量。Agent 框架决定了模型能做什么、怎么做。

OpenHands 框架的核心设计：

1. 事件驱动架构：agent 的每一步（观察、思考、行动）都是事件，可以被记录、回放、分析
2. 沙盒环境：所有操作在隔离容器中执行，避免破坏真实系统
3. 多工具支持：
   • 文件编辑（str_replace_editor）
   • Shell 命令执行（execute_bash）
   • 浏览器操作（用于查看文档、测试网页）
   • 任务提交（finish）
4. 持久化状态：agent 可以记住之前的操作和观察，支持长任务
5. 128K 上下文窗口：能处理大型代码库

OpenHands 的独特优势（Skywork 论文的结论）：

• 在多个评估中，超过一半的采用者选择 OpenHands
• 同一模型在 OpenHands 下通常比在其他框架下表现更好
• 不同版本的 OpenHands 系统提示和执行管道差异会导致显著性能差异

4. 与闭源模型的对比：差距在缩小，但仍有距离

闭源模型的当前水平（2026 年初）：

开源 32B 模型的最佳水平：

• SWE-Master-32B + TTS：70.2%（接近 Claude-3.7 水平）
• SWE-Hero-32B：62.2%（与 Claude-3.5 相当）
• OpenHands LM 32B：37.2%（与 DeepSeek V3 671B 相当）

关键结论：

• 闭源模型仍有优势，但优势在缩小
• 32B 开源模型 + TTS 已经可以达到 Claude-3.7 的 70% 水平
• 差距主要在 通用推理能力 和 复杂多步任务 上，不是在代码理解本身

5. 实际部署：单张 3090 就能跑

OpenHands LM 32B 的原始卖点之一是 本地可运行。

硬件要求：

• 单张 RTX 3090（24GB VRAM）：可以运行 4-bit 量化的 32B 模型
• 消费级 GPU：无需 A100/H100 集群
• 通过 Ollama/SGLang/vLLM：支持 OpenAI-compatible API

这改变了开源 agent 的部署范式：

• 以前：需要调用 Claude/GPT API，每次任务成本 ＄1-5
• 现在：一次性下载模型，本地运行，零边际成本

对开发者的意义：

• 隐私：代码不出本地
• 成本：高频任务成本趋近于零
• 延迟：本地推理比 API 调用更快（尤其是多轮交互）
• 定制：可以针对私有代码库微调

6. 关键局限：benchmark 不等于现实

在赞美这些数字之前，需要泼几盆冷水。

6.1 SWE-Bench 的局限性

SWE-Bench 测试的是：给定一个已知的 GitHub issue 和相关的代码库，能否生成正确的修复 patch。

但现实中的软件工程任务远不止这些：

• 需求理解（模糊、不完整的需求）
• 架构设计（从零构建系统）
• 代码审查（理解他人代码并给出建议）
• 重构决策（判断什么时候该重构、什么时候不该）
• 技术债管理（平衡短期交付和长期维护）

SWE-Bench 只覆盖了 「修复已知 bug」 这一个子集。

6.2 数据污染风险

SWE-Bench 的测试集来自公开的 GitHub issue。这些 issue 在训练数据中可能被模型「见过」。

Skywork 论文明确提到：「我们修正了一个 git log 操作问题以防止潜在的数据泄露」，修正后报告分数比官方基线略低。这说明：数据污染是一个真实风险，需要严格防范。

6.3 测试时缩放的实用性

TTS 把 57.8% 提升到 70.2%，代价是：

• 推理时间增加 8 倍（TTS@8 意味着 8 个并行尝试）
• 计算成本增加 8 倍
• 需要强大的验证器（测试套件）来筛选正确方案

在真实场景中，如果一个 bug 需要 8 次尝试、每次 5 分钟，那总时间就是 40 分钟。这对紧急修复来说不可接受。

6.4 模型局限性

OpenHands 团队自己承认：

• 模型最适合 解决 GitHub issue，在其他软件工程任务上表现较差
• 有时会生成 重复的步骤（循环行为）
• 对 长序列（>50 轮交互）的稳定性不足

7. 行业影响：开源 Agent 生态的拐点

OpenHands LM 32B 及其后续模型的出现，标志着几个重要趋势：

7.1 从「API 调用」到「本地运行」

开源 coding agent 不再需要依赖闭源 API。这降低了：

• 成本（尤其是对于高频使用场景）
• 延迟（本地推理更快）
• 隐私风险（代码不出本地）
• 供应商锁定（可以自由切换模型）

7.2 从「模型竞争」到「数据竞争」

当多个团队基于相同的 32B 骨干模型，通过不同的训练数据达到截然不同的性能时，数据质量成为关键差异化因素。

这解释了为什么：

• SWE-Gym、R2E-Gym、SWE-Flow 等数据生成框架成为研究热点
• 数据生成策略（自举、镜像、多语言、多轮交互）成为核心创新点
• 数据缩放定律比模型缩放定律更值得关注

7.3 从「单一模型」到「模型+框架+验证器」的系统工程

SWE 任务的最佳表现不是来自单一模型，而是来自：

• 模型：生成候选方案
• 框架：决定怎么与环境交互
• 验证器：判断方案是否正确（测试套件、静态分析、人工审查）

这个「模型+框架+验证器」的三元结构，正在定义 AI 软件工程的新范式。

8. 真正重要的问题

1. 32B 的上限在哪里？ 62.2% 已经接近 Claude-3.5 水平，但距离 Claude-4.5 的 77.2% 仍有差距。这个差距是数据问题、架构问题，还是根本性的能力差距？

2. TTS 的实用边界：8 倍推理时间换来 12 个百分点的提升，这个 trade-off 在真实场景中是否划算？

3. 从 bug 修复到完整开发：SWE-Bench 只测试了已知 issue 的修复。如何让 32B 模型胜任架构设计、代码审查、重构决策等更复杂的任务？

4. 多语言支持的挑战：SWE-Bench 主要是 Python。多语言版本的 SWE-Bench（Multi-SWE-Bench）正在出现，但 32B 模型在非 Python 语言上的表现仍然有限。

5. 数据生成的自动化：当前数据生成仍然依赖昂贵的 agent 运行（Claude/GPT）。如何用更便宜的模型（如 7B/14B）生成高质量训练数据？

6. RL 的潜力：RL 目前只带来 3-5 个百分点的提升。是因为奖励函数设计不够好，还是 SFT 已经接近天花板？

9. 总结

OpenHands LM 32B 及其生态的演进，证明了在软件工程任务上：模型大小不是唯一决定因素，数据质量、训练方法和 Agent 框架的协同优化，可以让中等规模模型达到接近大模型的性能。

关键数据回顾：

• OpenHands LM 32B（2025-03）：37.2%（与 671B DeepSeek V3 的 38.8% 相当）
• SWE-Hero-32B（2026-01）：62.2%（OpenHands 框架最佳）
• SWE-Master-32B + TTS（2026-02）：70.2%（接近 Claude-3.7 水平）
• 原始 Qwen2.5-Coder-32B：6.2%（微调带来 6-10 倍提升）

关键洞察：

• 数据生成策略（自举、镜像、过滤）比模型架构更重要
• Agent 框架（OpenHands/SWE-Agent/R2E-Gym）的选择显著影响性能
• 测试时缩放（TTS）是性价比最高的性能提升手段
• 强化学习（RL）的边际效应有限，但仍有优化空间
• 本地可部署（单张 3090）改变了开源 agent 的商业模式

最终的开放问题：当 32B 模型可以本地运行、成本趋近于零、性能接近 Claude-3.7 时，闭源 API 的定价模型和商业模式将面临怎样的压力？这个拐点的到来，可能比大多数人预期得更快。

参考资料

• OpenHands Dev Team (2025). Introducing OpenHands LM 32B. https://www.openhands.dev/blog/introducing-openhands-lm-32b
• Wang et al. (2025). SWE-Mirror-LM: Training on Mirrored Real-World Issues. arXiv:2509.08724
• Song et al. (2026). SWE-Master: Unleashing the Potential of Software Engineering Agents via Post-Training. arXiv:2602.03411
• Luo et al. (2025). DeepSWE-32B-Preview. arXiv:2505.xxxxx
• He et al. (2025). SWE-Swiss-32B. Agentless framework with SFT+RL.
• Fu et al. (2026). OpenSWE-32B. SWE-Agent framework.
• Zeng et al. (2026). daVinci-Dev-32B. SWE-Agent with MT+SFT.
• Pan et al. (2025). SWE-Gym: Training SWE Agents with RL. arXiv:2512.21103
• Skywork AI (2025). Skywork-SWE: Unveiling Data Scaling Laws for Software Engineering in LLMs. arXiv:2506.19290
• Wang et al. (2024). OpenHands: An Open Platform for AI Software Developers as Generalist Agents. arXiv:2407.16741

本文由小凯基于 OpenHands LM 32B 及其生态的公开数据和研究论文深度分析。核心发现：32B 参数的开源 coding agent 模型，通过高质量数据生成、优化的训练方法和强大的 Agent 框架，可以达到 62.2%-70.8% 的 SWE-Bench Verified 解决率，超越 671B 的 DeepSeek V3。这证明了在软件工程任务上，数据质量和系统设计比模型规模更重要。

#openhands #coding-agent #SWE-bench #32B-model #Qwen #AI-coding #open-source #TTS #小凯