一年前，大家还在为1T参数的开源模型兴奋，如今2T+级模型不断涌现，模型越做越大，似乎成了业内共识。

与此同时，Agent成为最受关注的方向之一。但复杂的Agent任务，如优化代码仓库、完成办公工作流等，往往只有大尺寸模型才做得好。这也带来了一个现实问题：大模型单次推理本就昂贵，而Agent完成一项任务通常需要调用模型数十次甚至上百次，进一步放大了成本。随着任务复杂度和使用频率持续提升，推理成本将成为影响Agent大规模使用的关键因素。

降低成本最直接的办法，是让小模型来承担Agent任务。但这件事并不容易。代码与办公场景的工作流，都要求模型同时具备知识、推理、规划、工具理解和错误恢复能力，并在很长的交互轨迹里保持稳定。对参数容量有限的小模型来说，把这些能力同时装进去，是个不小的挑战。

Nanbeige4.2-3B是对这个问题的回答：在3B参数的约束下，用一个模型同时掌握代码智能体、办公智能体、复杂工具调用，以及通用推理。围绕这个目标，BOSS 直聘南北阁大模型实验室在模型架构、Agent数据构造、训练pipeline三个层面做了系统的工作。

整体效果

在四类能力上评测模型：General Agent、Code Agent、Reasoning和Alignment，对比对象包括Qwen3.5-4B/9B与Gemma4-E4B/12B。

在General Agent与Code Agent的各项评测上，Nanbeige4.2-3B的表现稳定超过参数量更大的Qwen3.5-9B和Gemma4-12B，覆盖复杂工具调用、办公工作流、代码仓库修改和终端操作，而非集中在单一环境。在推理方面，它在多数数学、代码和科学推理评测上取得同规模最佳，同时在Alignment上保持整体竞争力。

 

 

 

预训练：在固定参数下提升模型容量

3B模型首先受限于参数容量。研究团队的思路不是加参数，而是在参数固定的前提下，尽可能压榨出更多的有效容量。

2.1 Looped Transformer

Nanbeige4.2-3B采用Looped Transformer：模型从底到顶经过一遍所有Transformer层后，输出的隐藏状态会再次送入同一组Transformer层，完成第二遍计算。这种权重复用在不增加参数量的前提下，提高了有效计算深度和模型容量。

围绕Loop结构，重点验证了三个问题：

• 从头训练而非Upcycling：先训标准Transformer再转成Loop，效果明显弱于从预训练一开始就用Loop。模型需要在整个训练过程中，去适应对同一组层的重复复用。
• 循环两遍最合适：两遍在效果、训练速度和稳定性之间取得了最好的平衡——相比同规模的标准Transformer，它具有约75%的token efficiency（训练相同token数的loss水平）收益。继续增加循环次数，额外收益有限，但训练明显变慢、也更不稳定。
• 不共享KV Cache：跨Loop共享KV虽然可以把Inference阶段的Cache减半，但收益上低于满血Loop。研究团队最终选择不共享，以效果为先。

预训练语料从上一代Nanbeige4的23T tokens扩展到28T tokens。配比上，研究团队对数学、代码和合成QA等类型数据采取了更激进的上采样，对小模型的收益尤其明显。

架构与数据的共同收益，使得Nanbeige4.2-3B-Base在推理与知识相关的多个评测集上，全面超过上一代Nanbeige4-3B-Base、并显著领先开源模型Qwen3.5-4B-Base与Gemma4-E4B-Base。

 

Agent数据：环境与任务的联合Scaling

普通指令数据，无论单轮还是多轮对话，本质上都是问答形式，只涉及模型和用户。Agent数据要复杂得多：一条完整的轨迹背后，需要一个可执行的环境、供任务展开的物料与资产、以及控制模型如何与环境交互的Scaffold。因此扩展Agent数据不能只堆任务数量，而要同时把可执行环境、任务素材、具体任务和Agent Scaffold一起扩展起来。具体而言，研究团队分别面向代码智能体、复杂工具调用和办公智能体，构建了相应的轨迹合成与质量筛选数据管线。

3.1 代码智能体

研究团队从真实代码仓库中构造软件工程任务，并在独立沙箱里重建依赖和测试环境。模型只能看到待修改的仓库和任务描述，补丁与测试都不暴露；它需要自己浏览代码、定位问题、完成修改并运行验证。对同一任务，会通过Claude Code、OpenHands、SWE-agent等多种Scaffold生成轨迹，从而提高泛化性。最终训练时，除了约束轨迹的最终结果能通过目标测试与回归测试之外，也在Turn级别做无效工具调用、重复动作和错误步骤的过滤。训练过程中，研究团队引入模型的失败轨迹的周期性分析，将反复出现的错误模式归纳为能力缺口，据此调整后续合成轨迹的仓库选择、补充相应训练数据，形成“训练—失败分析—数据补充”的飞轮。

 

3.2 复杂工具调用

真实工具环境很难直接大规模复制：有的依赖实时网络，有的需要复杂运行时，有的缺少稳定接口。研究团队因此组合了三类环境：真实在线MCP服务、用Python重建的本地可执行工具、以及由模型模拟的虚拟工具。任务按工具链长度、信息检索难度、参数推断难度等维度生成，并配套可执行的验证函数。对于模型已经能稳定完成的任务，合成器会继续加难度，让训练数据跟着模型能力一起演化，而不是长期停在已经学会的任务上。

 

3.3 办公智能体

办公任务围绕具体文件展开——文档、表格、幻灯片、PDF、代码等等，文件之间往往还存在依赖。研究团队先构建跨行业、跨格式的素材库，再按语义与领域对素材聚类、组合。任务生成Agent基于素材设计任务与Rubric，执行模型产出文件，Judge Agent检查完成度、Rubric一致性和执行过程。通过验证的产出文件会被回收到素材库中，作为后续任务合成的新素材。以这种方式，随着素材持续积累，研究团队进一步构造跨文件依赖更强、流程更长的办公任务。

 

后训练方法：推理与Agent能力的兼顾

4.1 SFT：保留错误上下文，但不学习错误动作

研究团队在SFT中，先建立稳定的推理基础，再学习更长的工具交互和环境反馈。具体地，整个过程采用64K、128K、256K三阶段课程。早期以数学、代码、科学推理为主，随着训练进行，逐步提高Agent数据占比。

长程轨迹即使最终成功，中间也可能有错误调用、重复动作或没推进任务的步骤。研究团队结合执行反馈和Rubric，为每一轮输出设置Loss Mask：错误轮次不参与Loss，但该轮动作及其环境反馈仍保留在后续上下文里。这样模型不会被训练去复现错误，却能学会在真实的错误历史之上继续修正任务。

 

 

4.2 RL：多阶段训练配方

经多领域混合数据的SFT后，小模型还容易出现一些不稳定生成，比如无法及时停止、格式错误、异常续写、以及幻觉等问题。如果直接在这样的模型上做RL，错误会在多轮交互中不断累积。所以研究团队先处理生成稳定性，再分别优化推理和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数据不宜一味求难。相比policy model成功率低、轨迹较长的任务，选择轨迹较短且policy model已有一定成功率的任务来训练会更加稳定，带来的收益也更高。

完整RL流程下来，收益是全面的。模型在数学推理、竞赛编程、软件工程、智能体等多类评测上，同时做到了准确率提升和平均输出长度下降——例如PinchBench-V2从55.9%提升到74.7%，平均输出Token数也明显减少。换句话说，模型在变得更加准确，推理效率也在变高。

 

 

本地个人助手

本地个人助手是小模型Agent的一个天然应用场景。但要真正解决问题，模型还必须具备多轮规划、工具调用、文件处理和错误恢复能力。Nanbeige4.2-3B仅有3B非Embedding参数，部署门槛较低，同时保留了完成多步工作流所需的Agent能力。为评估模型在这一场景中的实际表现，选择能够覆盖日常协助、办公工作流和深度研究的OpenClaw作为统一评测框架。在相同的Scaffold、外部工具以及打分设置下，Nanbeige4.2-3B 在多项评测上均超过Qwen3.5-4B和更大的Qwen3.5-9B，其中在办公工作流上的优势尤其明显。

不过，尽管Nanbeige4.2-3B在同规模模型中取得了较好的评测结果，但距离在开放环境中成为稳定可用的Agent仍有较大差距。面对更长的任务链和更多不可预期的环境反馈，研究团队还会继续提升模型能力，并迭代数据与训练方法。

 

部署与下一步

Nanbeige4.2-3B已适配Transformers、SGLang、vLLM、llama.cpp和Ollama等多种推理引擎，并同时支持思考模式与非思考模式。

随模型开源的Modeling Code里，也包含了针对Loop结构的进一步改进、针对跨层信息传递方式的优化，以及基于N-Gram模块来对小模型记忆容量的补充等内容。这些特性已用于正在训练的Nanbeige4.5，预期会在后续发布。研究团队还会继续Linear/Sparse Attention，训练更大一些规模的Nanbeige模型，并探索如何用大模型蒸馏更强的小模型。

小模型不会取代大模型，但也不应只被当作大模型的压缩版。在高频调用、本地部署和成本敏感的Agent场景里，它有独立的研究和应用价值。研究团队会沿着这条路线继续走下去，也欢迎社区围绕模型架构、Agent数据合成与训练方法一起讨论。

资源下载

• Agent模型:https://modelscope.cn/models/nanbeige/Nanbeige4.2-3B
• Base模型:https://modelscope.cn/models/nanbeige/Nanbeige4.2-3B-Base
• 技术报告:https://modelscope.cn/models/nanbeige/Nanbeige4.2-3B/file/view/master/Nanbeige42_report.pdf