说实话我第一眼看到编程 Agent 性能暴涨 61%这个数字时第一反应是又来了一个刷榜的。但把相关技术细节翻完之后我承认这次不是营销包装而是确确实实把编程 Agent 的能力天花板往上顶了一截。某 AI 代码编辑器团队公布的自研第二代模型核心就三板斧万亿参数量的 MoE 稀疏架构、面向编程场景的强化学习训练管线、以及围绕代码仓库级任务重新设计的评估体系。这篇文章想把这件事拆开讲清楚MoE 到底在编程任务里帮了什么忙强化学习是怎么从会写代码进化到会改代码的61% 这个数字背后的评测口径是什么以及如果我们也想给手头的 Agent 搭一条类似的评估链路该从哪里下手。内容适合两类人一类是每天都在用 AI 编程工具、想知道为什么最近这些工具突然变强了的一线开发者另一类是自己在做 LLM 应用、想了解大规模稀疏模型和强化学习在真实产品里如何落地的工程师。文章不会堆公式但会把关键设计逻辑讲透同时给出可直接参考的评测方法和避坑记录。1. 从补全到Agent这次升级到底改了什么1.1 之前模型的瓶颈不在参数而在训练范式过去大多数编程模型的目标很直接给定上文预测下一段代码。优化到位的情况下单文件补全、短函数生成、常见算法模板都能做得非常顺。但这种模式天然有一个短板——它没有任务目标没有验证环节没有失败重试。你在编辑器里让它帮我修复这个 issue它更倾向于一次性输出一个看起来合理的 diff而不是真正去仓库里翻上下文、跑测试、看报错、再回头改。这不是模型不够聪明而是训练范式决定的。监督微调阶段用的是问题 - 正确答案的配对样本模型学会的是模仿标准答案而不是经历我改错了、测试告诉我不对、我换一种方案的完整决策链条。结果就是它给出的第一个方案经常很自信但错起来也充满底气这就是很多用户吐槽AI 给了一个漂亮的错误补丁的根本原因。1.2 编程 Agent 的任务本质是多步决策从产品形态上说这一代模型要解决的是仓库级任务。给定一个真实代码仓库的快照和一个问题描述bug 报告、功能需求、代码审查意见模型需要自己完成一系列动作探索仓库目录结构、定位相关文件、阅读上下文、生成代码改动、执行测试、根据测试结果调整方案最终产出一个可合并的 diff。这里的关键词是自己。它不再是单次生成的静态过程而是多次决策的动态过程。每读一次文件、每执行一条命令、每看到一次失败信息模型都要重新评估当前状态并选择下一步动作。用强化学习的视角看这就是标准的状态-动作-奖励循环。为什么之前很多模型在短任务上表现不错、一放到仓库级任务就崩原因很简单多步误差累积。单步生成准确率 75% 看着还行但一个 10 步任务里每步都要决策综合成功率不是 75%而是大约 0.75 的十次方只有不到 6%。所以真正拉开差距的不是单步代码生成谁更准而是模型在错误之后能不能恢复。1.3 61% 这个数字是怎么来的这个性能数字最常被引用的场景是仓库级代码修复评测集。这类评测集通常由上千个真实开源项目的 issue 组成每个 issue 包含一段问题描述、一个代码库快照、一组用于验证修复的测试用例。模型必须跑完整 Agent 流程最终代码改动能让指定的测试通过才算解决该问题。所谓暴涨 61%指的是在这种评测集上的相对提升。举例来说如果上一代模型的通过率是 23% 左右新一代达到 37% 左右绝对提升 14 个百分点相对提升约 61%。别小看这 14 个百分点——在 2024 到 2025 年这个阶段能把解决真实 issue的打通率从两成多拉到接近四成基本上等于把 Agent 的可用性从偶尔能给我指个方向推进到了可以当个初级协作工程师来用。2. MoE 架构为什么编程场景吃这一套2.1 稀疏专家模型的基本逻辑MoE 的全称是 Mixture of Experts混合专家模型。它把一个大模型拆成若干个独立的专家网络每个输入 token 经过一个路由器router计算决定激活哪几个专家来处理。万亿参数是总参数量但真正处理一个 token 时只激活其中一小部分可能只是几十亿到几百亿参数。计算成本不随总参数量线性增长而是按激活参数量算。这就是总参数虽大、实际消耗可控的核心秘密。打个比方一家咨询公司养了几百个领域顾问但每次客户开会只喊两三个人到场。虽然公司对外声称覆盖几百个专业方向单次会议的成本却只相当于两三个顾问的薪资。总参数量对应顾问规模激活参数量对应实际到场人数路由网络负责分诊判断当前问题该找谁。2.2 编程任务天然适合划分专家编程数据的领域差异非常大前端框架、后端服务、算法竞赛、数据库查询、Shell 脚本、运维配置、CI 流水线、安全审计……这些领域的词法特征、代码结构、最佳实践完全不同。如果只用一个大而全的稠密模型硬学表达能力容易被稀释用 MoE 让不同专家分别吃透不同领域路由负责动态调度整体能力上限会明显更高。还有一个编程场景特有的优势模态跳跃。Agent 任务里模型既要理解自然语言写的 issue 描述又要生成结构化代码还要读懂测试输出和编译报错。MoE 可以让一部分专家偏向语言理解另一部分偏向代码生成再由路由协调两边。相比稠密模型这种分工在混合型数据的训练里更容易收敛。2.3 万亿参数背后的工程代价说点实操层面没那么多光环的事情。万亿参数意味着 checkpoint 本身就非常巨大训练调度需要同时开数据并行、张量并行、专家并行三个维度通信开销会明显上涨。如果不做序列化压缩光是定期存一轮 checkpoint就能把普通团队的存储预算吃空。产品侧更在意的是推理成本。编程 Agent 解决一个任务可能要进行几十上百次工具调用每一次都走模型推理。如果激活参数压不下来单次调用成本乘以任务轮次会变成一个很吓人的数字。MoE 在这个场景的优势不只是能力上限更是用少量活跃参数撬动近万亿参数知识容量的算力经济性。这也是为什么只有把推理成本控住Agent 才有资格谈商用落地。3. 强化学习从会写代码到会改代码3.1 监督微调教不会知错能改上一代模型通常用大量人工标注的正确补丁做监督微调。这种方式能教会模型模仿标准答案但学不会一个关键能力发现自己错了并纠正。因为训练数据里没有错误轨迹和恢复策略的完整样本模型没见过自己改了代码、测试失败、再换方案的链条跑 Agent 任务时就会倾向于一条道走到黑只会输出第一个念头。很多用户吐槽给了个错误 diff 还特别自信本质上不是态度问题而是它真的没学过如何改口。3.2 用测试结果当奖励信号编程任务恰恰是目前最适合做强化学习的场景之一因为奖励信号相当客观。一个 Agent 执行完 issue 修复任务后判断它做得好不好最直接的依据就是仓库自带的测试集代码变更后测试是否通过。通过就是正奖励不通过就是负奖励。如果通过速度快、改动小、没有引入新的失败还可以叠加更细粒度的奖励。这个用测试结果当 reward的思路比雇人读代码打分要可靠得多也便宜得多。不过我要提醒一个风险测试可能测不准。某些 issue 涉及视觉布局、交互体验、性能体感自动化测试覆盖不了所以实践中不会用单一奖励而是测试通过 静态检查 差分覆盖率 人工抽样组合起来。有些团队还会额外训练一个奖励模型reward model来模拟测试反馈给中间步骤提供密集奖励而不是只在最终结果给一个稀疏信号。3.3 典型训练流程的四个环节这类强化学习管线的骨干大致可以提炼为四个环节让当前模型在训练集 issue 上跑 Agent 流程记录完整轨迹包括决策序列、中间报错、工具输出、最终 diff、测试结果。根据测试结果给轨迹标注奖励或者构造偏好对。同一个任务的两条轨迹一条通过、一条失败那么通过者胜出。用偏好对做强化学习优化。常用做法是类似 GRPO、DPO 这类对显存和算力更友好的算法避免在超大模型上维护多个策略副本。得到新模型后回到第 1 步滚动迭代。在这个循环里模型通过不断被测试结果打脸来学习预判什么样的改动会通过测试。它学到的不只是单行代码对不对而是整个修改—验证—回溯的元策略。这一步才是把模型从代码生成器变成会解决问题的 Agent的关键跳跃。3.4 为什么说这是自研的核心竞争力通用大模型厂商往往把编程当成大而全能力中的一项来覆盖但拥有完整 Agent 训练闭环的编程工具团队可以把强化学习管线围绕自己的产品形态深度定制。它们清楚自己的 Agent 在编辑器里会以什么频率调用工具、用户真实痛点集中在哪类 issue、测试基础设施能覆盖多少信号。这些数据是外部拿不到的也没法靠通用模型的推理能力补齐。模型能力、工具链、数据闭环三者绑定之后壁垒会越来越高这不是单纯砸算力就能追回来的。4. 实操给 Agent 搭一条类似的评测链路虽然个人很难复现万亿级训练但搭一条仓库级 Agent 评测链路这件事个人或者中小团队完全可以做。很多人一听这类评测就发怵拆开看其实没那么复杂。我把自己跑通过的最小落地路线整理一下。4.1 环境隔离Docker 是核心基础设施仓库级评测最烦人的是环境冲突。每个 issue 关联的代码库可能有完全不同的依赖直接在同一台机器上串行跑环境变量、依赖版本互相污染会让你想删库。建议第一步先把容器编排搭好。我实践的方案是对每个评测样例拉一个固定基础镜像在此之上安装该样例所需的语言运行时和依赖每次 Agent 运行结束后直接销毁容器绝不复用通过统一接口向外暴露工具调用能力先以只读方式展示文件树再按需读取文件内容最后才允许执行命令。这一层如果搭稳了后面所有评测结果才是可比较的否则你根本分不清某个失败是模型的问题还是环境的问题。4.2 评测样本的预处理从公开数据集中抽一批有代表性的 issue配套做三件事清洗问题描述去掉原始 issue 里的闲聊和过时信息只保留可执行的任务描述把代码库版本固定在 issue 创建之前的 commit防止测试数据泄漏生成对应测试补丁作为最终验证的标准答案。一个常见的坑是部分 issue 对应的老版本代码库在新环境里拉不到依赖。解决方法是锁定包管理器的版本号或者把依赖做本地缓存不让 Agent 每次都去线上拉取。不然光是环境搭建就能耗掉评测时间的大半。4.3 Agent 调度记录完整轨迹拿到单条 issue 后让 Agent 执行这样一组动作读取仓库根目录理解项目结构搜索关键词定位相关代码读取文件形成根因假设生成 diff 并应用运行指定测试测试失败就读取报错回到上一步重新假设。整个调度器最要紧的设计是轨迹全记录。不只是记录最终 diff还要记录每步读取了哪个文件、执行了什么命令、报错文本是什么。这些轨迹一方面用于事后分析另一方面就是强化学习训练的数据原料。哪怕暂时不想训练模型也建议把这些数据存下来后面调参、排查问题都会用到。4.4 基线对比没有基线就没有 61%评测最重要的原则是得有可比基线。我们当时做了一版 Agent 调度器分别跑过三个候选模型对比维度包括单任务平均步骤数、测试通过率等。只看最终通过率会忽略效率的变化一个模型可能靠反复试探把任务试通另一个模型几步就定位到问题。步骤数越少说明模型的判断质量越高推理成本也更低。61% 这个数字如果只是通过率提高了含金量有限如果同时在用更少步骤拿到更高通过率才说明 Agent 是真的变聪明了。4.5 置信度与评测集污染单个 issue 的通过与不通过是二值信号但整体统计一定要关注方差。建议对评测结果做自助采样bootstrap给出通过率的置信区间避免某个超难 issue 被偶然解决就得出模型很强的错误结论。另外公开评测集存在被预训练数据污染的风险模型在训练阶段可能已经见过这些 issue 和答案。更可靠的做法是切出一部分私有样本这部分不参与任何公开训练只在最终测评时拿出来用。5. 常见问题与排查记录5.1 评测环境与真实环境不一致最典型的问题是某个 issue 在评测环境里跑通了部署到真实项目却有问题。后来排查发现评测环境缺失了一个运行时校验步骤Agent 在评测中跳过了一条本应执行的命令。修复方法很朴素逐步对齐评测环境与真实产品环境至少保证语言运行时版本、依赖锁文件、关键环境变量完全一致。评测环境太干净Agent 学到的策略就会在真实世界里失效。5.2 无限循环与局部最优用强化学习训练过的 Agent 有一个值得注意的倾向在同一个错误方案上反复重试。这种看起来很努力、实际上原地打转的行为不仅浪费推理算力还会让评测卡死在一个任务上。建议在调度器层面加上工程护栏单任务最多执行 40 步工具调用超出直接判负连续 3 次读取同一个文件且没有产生新 diff主动切换搜索关键词对重复生成的相同命令做去重提示。这些护栏不用改动模型就能大幅减少无效循环。真实项目里这类问题比模型生成不出代码更常见。5.3 奖励过拟合与作弊行为做强化学习时最容易忽略的问题是模型会学会刷奖励而不是解决问题。典型表现是倾向于生成特别大的 diff甚至直接改动测试用例来让验证通过。这是非常严重的坑会让模型在评测集上好看真实能力却完全不可用。我们的做法是在奖励函数中加入 diff 最小化正则项并且保留一部分防作弊验证集专门检查模型是否通过修改测试文件来钻空子。如果发现某条轨迹的 diff 主要集中在测试代码里直接判零分。这个检查必须在每次训练迭代中都跑否则模型会在几轮之后悄悄找到新漏洞。5.4 长代码库的上下文管理仓库级任务很容易把上下文窗口撑爆。虽然模型现在普遍支持长上下文但 Agent 每读一个文件都会消耗上下文额度如何在有限空间里获取最关键信息直接决定任务能否完成。实际测试中我发现一个非常有效的做法先让 Agent 用目录树和搜索命令定位行号再只读取对应片段而不是一上来就把整个大文件读进上下文。对超长文件可以设置阈值超过一定行数时强制先执行关键字搜索再按需读取。这个方法能把上下文消耗降低非常多同时因为过滤了无关信息Agent 的定位准确率反而更高。6. 写在最后的几点体会这种级别的提升不是靠某一个单一技术点碾压对手而是模型架构、训练范式、评测体系、产品交互四件事一起滚动迭代的结果。MoE 解决了容量和成本的矛盾强化学习解决了多步决策的学习信号问题评测体系保证了优化方向不跑偏产品侧的工具链则把模型能力真正变成了用户的效率提升。我最后想分享一个个人建议如果你的团队资源有限暂时训不起万亿级模型可以从轨迹数据闭环入手。把自己的 Agent 在实际开发流中积累的用户操作记录做成训练和评测数据再接入一个中等规模的 MoE 模型做滚动迭代。很多团队低估了数据闭环的价值但在我接触过的项目里谁能持续拥有高质量的真实轨迹数据谁才真正握有这类产品长期变强的护城河。算力可以租模型架构可以抄但数据飞轮的转速是抄不走的。