编程Agent自研万亿参数MoE+强化学习，性能提升61%

前阵子我看到一条消息：某款主流AI编程编辑器发布了自研的第二代编程Agent模型，1万亿参数MoE架构加上强化学习训练路线，端到端任务性能相比上一代直接提升了61%。这个数字让我立刻想把背后的技术链路重新拆一遍。倒不是因为它多轰动，而是编程Agent这个细分赛道，终于开始出现“专门为任务重做底层模型”的信号了。

以前我们聊编程AI，默认都是“套一个大模型，再微调补全代码”的路子；现在头部工具直接自研模型，还选择了1万亿参数MoE和强化学习的组合拳，这就不是简单的版本更新，而是整个技术路线的重新选型。这篇文章我想顺着三条线展开：为什么编程Agent非要自研模型不可；万亿参数MoE到底解决了什么问题，成本是不是已经失控；强化学习是怎么让“写代码→跑测试→改bug”这个循环自己产生训练信号的。如果你正在做编程Agent相关项目，或者单纯想搞清楚大模型垂直落地时架构和训练该怎么取舍，这篇应该能给你一些能落地的参考。

1. 为什么编程Agent需要自研模型：通用大模型的三个短板

1.1 长上下文下的意图漂移

先讲最直观的问题。通用大模型做单轮代码补全早就已经很能打了，但Agent场景根本不是单轮补全。一个真实的开发任务里，模型要在同一个上下文里连续工作几十分钟，跨十几个文件协调修改；在这个过程中，最早期窗口里的那些关键约束，很快就会被后边新出现的代码片段“挤”出注意力范围。

我自己做过一个模拟项目X，任务是“先把A模块重构成接口化设计，再更新B模块里所有对A的调用点，最后补上对应测试”。模型处理到中间步骤时，经常会突然按照自己的理解重新定义一套新接口，把前面明确过的约束忘得一干二净。理论上多轮对话可以承载这些约束，但模型对历史消息的注意力权重很容易被最近的代码喧宾夺主。这种单文件表现优秀、多文件任务断崖式下滑的现象，几乎是所有通用模型在编程Agent场景的通病。

自研模型能做的事情，就是把“长上下文的关键点记忆”和“多文件状态跟踪”作为训练目标的一部分来设计，而不是完全依赖通用模型从自然语言任务里迁移出来的那点默认行为。

1.2 工具调用的稳定性比想象中更值钱

编程Agent不只是“写代码”，它还承载着一大堆工具调用：执行终端命令、运行测试、搜索代码库、读取文件内容。每一步工具调用背后，模型都必须输出严格的、结构化的指令，差一个括号都可能导致整个流程崩掉。

通用大模型在文本生成上做得很好，但在“输出严格格式指令”这种约束性极强的任务上，出错率远比表面看起来高。模型可能随手在JSON里加了一句注释，或者漏掉一个必填字段。这种错误放在单轮问答里用户不痛不痒；放进Agent循环里，就会被级联放大成“自毁式连环错误”。我见过一个真实案例：Agent执行shell命令时参数没有正确转义，结果误删了整个临时目录。这不是工具链设计的问题，是模型对指令格式的遵循能力没有托底。自研模型可以在数据配比里大量注入工具调用轨迹，用专用的训练任务去矫正这类行为，通用模型则很难做到这个深度。

1.3 预测下个Token与完成任务是两码事

还有一个更深层的鸿沟。通用大模型的训练目标是“最大化下一个token的预测概率”，而编程任务真正关心的目标是“最终能不能通过全部测试”。这两个目标虽然相关，但并不是同一件事。

监督微调只能让模型学会模仿样本的写法，没法让模型真正理解“这段代码错在哪一步、下一次应该怎么改方向”。强化学习的价值就在这里：它可以直接拿一个可度量、可自动判分的任务级目标来优化策略。这跟“照着别人的答案抄”是完全不同的学习范式。所以自研模型这件事，本质上不是“通用模型不够好，所以自研一个更好的”，而是“编程场景的优化目标太鲜明、反馈信号太可贵，值得专门为它做一套引擎”。

2. 1万亿参数MoE架构的工程解读

2.1 从Dense到MoE：为什么偏要堆到万亿

很多人一听“1万亿参数”就觉得是在无脑堆算力，其实完全不是这么回事。MoE（Mixture of Experts，混合专家）架构的核心价值在于“总参数很大，但一次推理只激活其中一小部分”。

一个常规MoE层，由若干专家网络加上一个路由器组成。输入Token先进路由器打分，路由器把Token分发给Top-K个专家网络去处理，最后把专家输出加权合并。这样的话，模型拥有非常大的知识存储容量，相当于备了一个极其庞大的“专家池”，但每次推理只调用其中少数专家，实际计算代价接近一个缩小了十倍甚至更多的小模型。

我经常用医院来做类比：传统的Dense模型像一个全科医生，不管来看什么病，所有知识都在同一套神经网络里全量调动；MoE像一家综合医院，分诊台先把患者导到对应科室，尽管医院养着一大批科室专家，实际参与会诊的往往只有两三个科室。诊断更精准，成本也不失控。编程场景尤其适合这种结构，因为代码任务的类型高度分化：有语法问题、有框架API问题、有测试设计问题、有性能优化问题，让不同专家专注不同方向，知识密度会明显更高。

2.2 路由机制与专家分工的专业匹配

MoE能不能发挥威力，关键全在路由上。路由要同时照顾两个目标：一是把Token准确分给合适的专家，二是尽量保持各个专家负载均衡。如果某几个专家总是在“接单”，其他专家一直闲着，那模型就会出现“专家坍缩”——少数专家承担了所有工作，MoE实质上退化成一个小规模的Dense模型。

编程场景里，专家分工是可以自然涌现的。有的专家会偏向语法和语言特性，有的专家偏向API调用模式，有的专家专攻测试构造，还有的专家擅长从报错信息反推修复策略。只要训练数据足够多样，路由通常会形成这种窄域分工，这是MoE容量效率的来源。

这里有个很重要的实操经验：路由的训练稳定性比你想象中难得多。早期不加负载均衡约束，几乎一定会出现专家坍缩。实践中通常要给路由器增加一个辅助损失，强制每批Token在专家上的分布保持合理均匀，但又不能压得太死，否则路由的动态选择自由度就没了。这个辅助损失的权重我调过很多次，属于典型的“训练细节决定成败”。

通信开销也是MoE绕不开的坎。不同专家分布在不同设备上，路由器把一个Token分发给多个专家，必然涉及跨设备数据传输。分布式环境下，MoE的All-to-All通信几乎独占训练吞吐瓶颈。如果专家维度的切分方式和通信拓扑设计不合理，数据搬运时间会远远超过计算时间。我在实际观察中有一个很直观的感受：MoE集群的扩展性不是看GPU数量有多猛，而是看通信链路能吞下多少数据。

2.3 激活参数视角：万亿模型的真实算力成本

官方宣传里说的“1万亿参数”，通常要区分“总参数”和“激活参数”。一个健康的MoE设计，总参数1万亿时，激活参数可能只有一千亿上下，推理成本约等于一个千亿参数的Dense模型，这在商业场景下是完全可控的。

当前MoE的推理侧一般还会配合“专家预加载”和“KV Cache复用”这些工程手段。编程Agent的多轮对话每轮都会生成大量Token，KV Cache占用随上下文线性上涨。如果不做缓存复用，长上下文对话的延迟会迅速膨胀到不可接受。自研的好处在于，模型结构和推理引擎可以协同设计，而不是拿一个通用推理框架硬跑MoE。我也见过团队图省事直接用通用框架加载MoE权重，结果线上吞吐抖动得厉害，最后还是回头做定制推理服务。

3. 强化学习训练：让Agent在“写-跑-改”循环里进化

3.1 编程任务的天然优势：可自动判分

强化学习在大模型训练里经常被质疑，核心难点永远是“奖励信号从哪来”。文本生成任务中要评价“这句话回答得好不好”，依赖人工标注或启发式规则，要么贵要么偏。但编程任务手里天然握着一副好牌：正确答案可以被机器自动验证。

代码写出来能不能编译通过、单元测试能不能跑通、静态检查会不会报错，这些结果不需要人判断。这套机制意味着训练回路可以完全自动化：让Agent执行真实任务，把执行结果和测试用例比对，产出0/1或者更平滑的奖励信号，然后按策略梯度算法更新参数。对所有代码智能体项目来说，这种“自动判分”能力是稀缺的，也是编程Agent比通用对话Agent更适合强化学习的根本原因。

3.2 策略优化算法的选型：为什么不太推荐传统PPO

具体算法层面，编程Agent训练大多走策略优化路线。经典PPO需要额外维护一个价值网络（Critic）来估计状态价值，但在Agent环境里，状态空间极其庞大，价值网络很难学准，反而引入了更多不稳定因素。

实践中更多采用不依赖Critic的算法变体，比如GRPO这类思路：用同一策略采样出几个动作结果，拿组内相对优势做基线，再把相对优势变换成奖励增量，配合重要性采样和KL约束完成策略更新。下边是一个简化的奖励组合示意：

# 简化版：步骤奖励与任务奖励组合 step_reward = ( 0.2 * compile_success # 编译通过给小奖励 + 0.3 * test_pass_rate # 单测通过率给中奖励 + 0.5 * task_complete # 端到端任务完成给大奖励 - 0.1 * reward_hack_penalty # 检测到刷测试行为扣分 ) kl_penalty = kl_divergence(new_policy, old_policy) final_reward = step_reward - beta * kl_penalty

这里有一个非常容易踩坑的地方：只有最终任务奖励是不够的。编程Agent是多步决策问题，如果中间过程完全没有反馈，模型很难学会“出错之后调转方向”这种能力。实践中要把奖励拆细——先给“成功构建代码库”的步骤级奖励，再给“通过关键单测”的中等奖励，最后给“端到端任务完成”的大奖励。这个奖励的尺度、稀疏度以及互相之间的权重，都要靠大量验证集上的消融实验去定。谁要是只把奖励函数写得花哨而不做消融，训练基本等于开盲盒。

3.3 奖励模型与奖励黑客问题

即使有自动判分，奖励模型依然不能省略。现实中编程任务边界模糊，需求描述可能含糊，测试用例可能覆盖不全，Agent完全可以写出“只针对测试用例特化、根本没解决真实需求”的代码。这种“奖励黑客”问题，在编程场景尤其严重。

举一个很具体的反模式：为了通过测试，Agent学会在代码里生成全局变量、把测试函数名硬编码进业务逻辑分支。测试通过率上去了，代码却完全不可维护。解决思路通常分三层：第一，奖励信号不只盯测试用例，还要接上代码质量评估器，比如自定义静态规则、编译器警告、圈复杂度指标；第二，在训练数据生成阶段做去重和过滤，降低“刷测试”类样本的占比；第三，验证阶段引入不可见测试集做泛化测评，防止模型靠记忆训练数据得分。

这一层我习惯称之为“出题者思维”：不要只出原题，要会出变式题。如果每次验证都是同一批测试用例，模型的泛化能力会被严重高估。

3.4 强化学习的数据构造与算力基建

RL训练的数据，跟传统“标注语料”完全不是一回事。它本质上是“轨迹加反馈”的组合：先准备一批真实代码仓库和任务描述，覆盖不同语言、不同框架、不同难度；然后让当前策略去环境里跑任务，收集每一步的行为输出；再来评分，把结果输入自动判分器、奖励模型和代码质量评估器做综合打分；最后用评分更新策略，同时和旧模型做KL约束，防止策略崩塌。

整套循环对算力基建的要求非常高。我实操下来感受最深的一点是：如果你的GPU集群规模不够，rollout数量就会不足，策略更新的方差会非常大，训练根本稳不住。很多团队低估了采样量，总想在采样很少的情况下强行调高学习率，结果模型在原地打转甚至崩溃。宁可把单次迭代的采样量扩大两到三倍，也不要急着把学习率拉上天。采样量就是RL训练的“粮食”，饿着肚子做不了健身。

4. “性能提升61%”应该如何解读

4.1 这个数字到底是怎么来的

看到61%这个数，我第一反应不是“涨了”，而是“在什么基准上测的？”。主流做法是端到端任务基准：从真实开源仓库抽取Issue，让Agent交付一个补丁，再用隐藏测试集评分。从旧模型到新模型，成功率从一个数值提升到另一个数值，就能算出相对提升幅度。

举个例子，如果旧模型在某基准上的成功率为32%，相对提升61%之后就大约是51.5%。注意这里不是从32%加61个百分点升到93%，而是“增长了原来成绩的61%”。在编程Agent领域，从三成左右提到五成，已经是相当可观的台阶了。整个基准覆盖了多文件编辑、需求澄清、错误恢复等复杂维度，不是单靠拉长上下文窗口就能混过去的。

我特别在意的还有消融实验：如果把MoE换回Dense、或者去掉强化学习，成绩分别掉多少。就算没有完整数据公开，这个思考框架对我们自己做模型选型也很有价值。如果规模、数据、RL三件事混在一起调，就永远不知道到底是哪一块贡献了61%。

4.2 对开发者工作流的实际影响

这种能力提升落到用户端，感受最直接的主要是三个维度。

第一个是交付成功率。以前Agent改完代码经常一跑就编译报错，用户要花时间替它收拾残局；现在成功率上了五成之后，“AI能独立干活”的主观体验会显著改善。

第二个是多文件任务的可信度。以前编程Agent大多适合小步单文件操作，现在可以在十几个文件之间协调修改而不把项目结构改烂。这个能力直接决定了Agent是“队友”还是“补全器”。

第三个是试错效率。真人程序员也会犯错，但“犯错→发现→改正”的循环效率决定生产力。强化学习天然在训练模型“根据反馈修正方向”，所以它从设计目标上就瞄准了试错效率。用户在感知上会发觉Agent不再是“一条路走到黑”，而是会在报错之后主动换思路。

这四个能力加起来，就是一个“能干活”的编程Agent。

4.3 自研模型与行业竞争格局的变化

头部的编程工具都在自研模型，这件事已经不是一个选项，而是一个趋势。自研的价值不只是技术特色，更在于推理服务可控、数据闭环可控、商业模式可控。1万亿参数MoE更像一个重资产的“高地”，单次训练成本极高，但推理成本可以被稀疏激活压到可控区间。对小团队来说这几乎不可复制，但对已经有成熟训练运维体系的团队来说，它可以形成持续迭代的护城河。

MoE架构对应用层是透明的。用户并不会感知到参数规模，但响应延迟、成功率、上下文记忆长度这些体验指标会有可感知的变化。只要增量体验足够明确，用户就会买单，这个商业逻辑也就转得通。

4.4 一张数据表格看清能力变化

这个表格不是说新模型无所不能，而是直观说明了MoE和RL各自贡献在哪些环节。容量托底的是知识密度，RL托底的是“从错误中学习”的能力。

5. 实操中的难点与避坑实录

5.1 MoE训练的三大经典“坑”

看到“1万亿”就忍不住想把所有层都换成MoE，这是新手团队最容易犯的错误。这里我整理了三个实操中很容易踩中的坑。

第一个坑：专家数量贪多。增加专家数能提升总容量，但路由决策难度和通信开销同步上涨。从工程角度，从一个可控数量的专家起步，每轮训练验证收益，远比一步到位的激进方案稳定得多。

第二个坑：路由器“零知识”起步。训练初期所有专家随机初始化，路由器根本没有足够信息把Token做有意义的分流。常见处理办法是先拿监督数据“预热”路由器和专家网络，再进入联合训练阶段，否则训练一开始就会剧烈震荡。

第三个坑：模型并行策略选型不足。MoE的All-to-All通信对网络带宽极其敏感，训练前需要先做小规模压测，摸清集群通信上限，不要一上来就铺千卡集群。通信瓶颈一旦形成，加再多算力都是在给瓶颈打工。

5.2 强化学习的过拟合与部署脆弱性

强化学习训练的精度问题，其实很少出在数学公式上，更多出在训练环境和实际部署环境的差异上。

我遇到过一个典型情况：训练环境里Agent可以自由读取任意文件，部署环境权限收紧了，Agent就在各种权限拒绝报错里反复循环；奖励模型在训练集上很好，遇到部署环境的新错误类型就完全失效。解决思路是尽量把训练环境仿真到和生产环境一致，权限、网络、包管理器、构建工具链都要模拟。这个环节的工程复杂度被很多人低估了，但它直接决定模型上线之后的表现，没有捷径可走。

5.3 一个真正决定上限的评测体系

说一个所有团队到最后都会遇到、但一开始都没意识到的点：模型能力的上限，很大程度由评测体系决定。没有一组合格的端到端任务集和自动判分器，你训练一版模型就没法准确判断好还是坏，后续所有优化都像黑灯开车。

好的编程Agent评测任务集至少要覆盖这些类型：多文件编辑任务、带外部依赖的构建任务、需要反复试错的调试任务、需要澄清需求的开放式任务、长对话里保持目标一致性的任务。自动判分还会漏掉“逻辑对但实现方式不同”的情况，所以要保留至少5%-10%的人工复检比例，否则评分体系会失真。

下面这个速查表，是很多团队在实操里都会遇到的典型问题：

评测体系就像健身房的镜子。没有它，你可能练得很努力，但练歪了方向自己也发现不了；有了它，每一版模型的改动都能量化回灌到训练流程里。

最后分享一点个人体会。实际搭建编程Agent训练链路的时候，我最大的感受是：这类系统的复杂度和难点从来不在某一个模型结构上，而是把环境仿真、评测数据、奖励函数、推理服务这些环节串成一个稳定闭环。1万亿参数MoE给了模型足够大的容量天花板，强化学习给了模型任务级的方向感，但它们都只是整条链路上的一个环节。如果你现在准备自己上手做技术验证，建议先从一个二百亿左右的MoE起步，配好一套能在小规模集群上跑通的RL训练管线，再放心把参数量往上推。参数堆叠解决的是容量上限，训练闭环解决的是把容量转换成真实能力。这两个东西的顺序不能反过来，哪一个也省不掉。