3B参数Nanbeige4.2-3B：本地个人助手的Agent能力新标杆
当前大模型领域的发展呈现出明显的参数扩容趋势，万亿级参数模型层出不穷，但这类模型的单次推理成本高昂，而智能体（Agent）任务往往需要多次调用模型，进一步放大了使用成本。如何让小模型也能胜任复杂的Agent任务，成为了行业内亟待解决的问题。
Nanbeige4.2-3B正是针对这一痛点推出的解决方案：在仅30亿参数的约束下，这款模型同时具备代码智能体、办公智能体、复杂工具调用以及通用推理能力。研发团队从模型架构、Agent数据构造、训练流程三个核心维度出发，完成了系统性的优化工作。
模型整体评测表现
研发团队从通用智能体、代码智能体、通用推理以及对齐能力四个维度对Nanbeige4.2-3B进行了全面评测，对比模型包括Qwen3.5-4B/9B与Gemma4-E4B/12B。
在通用智能体与代码智能体的各项测试中，Nanbeige4.2-3B的表现稳定超越参数量更大的Qwen3.5-9B和Gemma4-12B，测试覆盖了复杂工具调用、办公工作流、代码仓库修改和终端操作等多个场景，而非局限于单一环境。在通用推理方面，这款模型在多数数学、代码和科学推理评测中取得了同规模模型的最佳成绩，同时在对齐能力上也保持了整体竞争力。
预训练：挖掘固定参数的最大潜力
30亿参数的模型首先面临的核心限制是参数容量有限，研发团队没有选择增加参数量，而是在固定参数的前提下，尽可能挖掘更多的有效计算容量。
Nanbeige4.2-3B采用了Looped Transformer架构：模型从底层到顶层完成一次所有Transformer层的计算后，会将输出的隐藏状态再次送入同一组Transformer层进行第二轮计算。这种权重复用的方式在不增加参数量的前提下，有效提升了模型的计算深度和容量。
围绕Loop结构，研发团队重点验证了三个核心问题：
- 从头训练而非参数升级：先训练标准Transformer再转换为Loop结构的效果，明显弱于从预训练阶段就采用Loop架构的模型。这是因为模型需要在整个训练过程中适应同一组层的重复复用。
- 循环两次为最优选择：两次循环在模型效果、训练速度和稳定性之间取得了最佳平衡。相较于同规模的标准Transformer，这种架构能带来约75%的token效率提升，也就是训练相同数量的token时，loss水平更优。如果继续增加循环次数，额外的性能收益有限，但训练速度会明显变慢，稳定性也会下降。
- 不共享KV Cache：虽然跨Loop共享KV Cache可以将推理阶段的缓存占用减半，但最终的效果不如完整的Loop架构。因此研发团队选择不共享KV Cache，以模型效果为优先考量。
预训练语料的规模也从上代产品的23T tokens扩展到了28T tokens。在数据配比上，研发团队对数学、代码和合成QA等类型的数据采取了更激进的上采样策略，这对小模型的性能提升尤为明显。
架构优化和数据增强的共同作用，让Nanbeige4.2-3B-Base在推理和知识相关的多个评测集上，全面超越了上代产品Nanbeige4-3B-Base，同时显著领先开源模型Qwen3.5-4B-Base与Gemma4-E4B-Base。
Agent专属数据体系：环境与任务协同扩展
普通的指令数据无论是单轮还是多轮对话，本质上都是问答形式，仅涉及模型和用户两方。但Agent数据要复杂得多：一条完整的智能体交互轨迹背后，需要可执行的运行环境、供任务展开的物料资产，以及控制模型与环境交互的交互框架。因此，扩展Agent数据不能仅靠堆砌任务数量，而是需要同时扩大可执行环境、任务素材、具体任务和交互框架的规模。
研发团队分别针对代码智能体、复杂工具调用和办公智能体三个方向，构建了完整的轨迹合成与质量筛选数据管线。
代码智能体数据构建
研发团队从真实的代码仓库中提取软件工程任务，并在独立的沙箱环境中重建依赖和测试环境。模型只能看到待修改的仓库和任务描述，补丁和测试用例不会直接暴露给模型，它需要自行浏览代码、定位问题、完成修改并运行验证。针对同一任务，研发团队会通过Claude Code、OpenHands、SWE-agent等多种交互框架生成轨迹，以此提升模型的泛化能力。在训练过程中，除了要求最终轨迹能通过目标测试和回归测试外，还会在每一轮交互中过滤无效的工具调用、重复动作和错误步骤。同时，研发团队会定期分析模型的失败轨迹，将反复出现的错误模式归纳为能力缺口，据此调整后续合成轨迹的仓库选择，并补充对应的训练数据，形成“训练—失败分析—数据补充”的闭环。
复杂工具调用数据构建
真实的工具环境很难直接大规模复制：部分工具依赖实时网络，部分需要复杂的运行环境，还有一些缺少稳定的接口。因此研发团队组合了三类环境：真实的在线MCP服务、用Python重建的本地可执行工具，以及由模型模拟的虚拟工具。任务会按照工具链长度、信息检索难度、参数推断难度等多个维度生成，并配套可执行的验证函数。对于模型已经能够稳定完成的任务，数据合成器会适当提升任务难度，让训练数据跟随模型的能力一起进化，避免模型长期停留在已经掌握的任务上。
办公智能体数据构建
办公任务通常围绕具体的文件展开，包括文档、表格、幻灯片、PDF、代码等，不同文件之间往往还存在依赖关系。研发团队首先构建了跨行业、跨格式的素材库，然后按照语义和领域对素材进行聚类和组合。任务生成Agent基于素材库设计任务和评估标准，执行模型负责产出文件，Judge Agent则会检查任务的完成度、评估标准一致性和执行过程。通过验证的产出文件会被回收到素材库中，作为后续任务合成的新素材。通过这种方式，随着素材库的持续积累，研发团队可以进一步构建跨文件依赖更强、流程更长的办公任务。
后训练：兼顾通用推理与Agent能力
研发团队在后训练阶段，首先建立稳定的通用推理基础，再逐步让模型学习更长的工具交互和环境反馈流程。整个训练过程采用了64K、128K、256K三阶段课程学习：早期训练以数学、代码、科学推理为主，随着训练进程推进，逐步提高Agent数据的占比。
即便是最终成功的长程交互轨迹，中间也可能包含错误的工具调用、重复动作或者没有推进任务的步骤。研发团队结合执行反馈和评估标准，为每一轮输出设置了Loss Mask：错误的轮次不会参与损失计算，但该轮的动作和环境反馈会保留在后续的上下文当中。这样模型不会被训练复现错误，但能够学会在真实的错误历史之上继续修正任务。
多阶段强化学习配方
经过多领域混合数据的监督微调后，小模型仍然容易出现一些不稳定的生成问题，比如无法及时停止、格式错误、异常续写和幻觉等。如果直接在这样的模型上进行强化学习，错误会在多轮交互中不断累积。因此研发团队先处理模型的生成稳定性，再分别优化通用推理和Agent能力。
- Think/Non-Think两阶段RLHF：首先训练一个Point-wise Reward Model，用于评估通用问答场景下模型回复的整体质量。先在Think模式下进行RLHF训练，再继续进行Non-Think模式的RLHF。研发团队发现，这种行为层面的规范能力可以跨任务、跨模式泛化：不仅能够改善模型的指令遵循能力，还能提升数学、代码和Agent表现；而且在Non-Think模式上训练得到的收益，也可以直接迁移到Think模式。
- 带长度控制的Reasoning RL：在优化推理能力的RL阶段，研发团队不仅关注模型效果的提升，还关注思维链长度的控制。对于已经能够稳定解决的问题，会根据历史正确轨迹设定长度预算，并结合当前的通过率调整超长惩罚；对于困难问题则保留自由探索的空间。研发团队的目标不是一味缩短思考过程，而是减少简单问题上的无效Token消耗。
- 结合结果与过程奖励的Agentic RL：对于参数容量有限的小模型来说，长程Agent任务中的有效探索能力相对有限。如果仅依赖最终结果的奖励，监督信号既稀疏又滞后，很难将任务的成败归因到具体的步骤。因此研发团队使用Outcome Reward来判断任务是否最终完成，同时通过Action-Centric Rubric评估每一轮工具调用是否正确、是否带来有效信息并推动任务进展。也就是说，不仅要看任务最后是否完成，还要检查中间每一步是否有效。
研发团队还发现，小模型的RL训练数据不宜一味追求难度。相较于那些模型成功率低、轨迹较长的任务，选择轨迹较短且模型已有一定成功率的任务进行训练，会更加稳定，带来的收益也更高。
完整的RL流程带来了全面的性能提升：模型在数学推理、竞赛编程、软件工程、智能体等多个评测类别中，同时实现了准确率提升和平均输出长度下降。例如PinchBench-V2的准确率从55.9%提升到了74.7%，同时平均输出的Token数量也明显减少，这意味着模型变得更加准确，推理效率也得到了提升。
落地场景：本地个人助手实测
本地个人助手是小模型Agent的天然应用场景，但要真正解决实际问题，模型需要具备多轮规划、工具调用、文件处理和错误恢复能力。Nanbeige4.2-3B仅有30亿非Embedding参数，部署门槛较低，同时保留了完成多步工作流所需的Agent能力。
为了评估模型在这一场景中的实际表现，研发团队选择了能够覆盖日常协助、办公工作流和深度研究的OpenClaw作为统一评测框架。在相同的交互框架、外部工具和打分设置下，Nanbeige4.2-3B在多项评测中均超过了Qwen3.5-4B和参数量更大的Qwen3.5-9B，尤其是在办公工作流场景中优势尤为明显。
不过，尽管Nanbeige4.2-3B在同规模模型中取得了不错的评测结果，但距离在开放环境中成为稳定可用的Agent仍有较大差距。面对更长的任务链和更多不可预期的环境反馈，研发团队还会继续提升模型能力，并迭代数据与训练方法。
部署方案与后续研发方向
Nanbeige4.2-3B已经适配了Transformers、SGLang、vLLM、llama.cpp和Ollama等多种推理引擎，同时支持思考模式与非思考模式。
随模型开源的Modeling代码中，还包含了针对Loop结构的进一步改进、跨层信息传递方式的优化，以及基于N-Gram模块补充小模型的记忆容量等内容。这些特性已经被应用于正在训练的Nanbeige4.5，预计会在后续发布。研发团队还会继续探索Linear/Sparse Attention技术，训练更大规模的Nanbeige系列模型，并探索如何通过大模型蒸馏得到更强的小模型。
小模型不会取代大模型，但也不应仅被视为大模型的压缩版本。在高频调用、本地部署和成本敏感的Agent场景中，小模型拥有独立的研究和应用价值。研发团队会沿着这条路线继续探索，也欢迎社区围绕模型架构、Agent数据合成与训练方法展开讨论。
