过去这一年多我几乎是眼睁睁看着AI编程工具从自动补全玩具一步步长成能独立干活的小组员的。所以当Cursor 自研 Composer 21万亿参数 MoE 强化学习编程 Agent 性能暴涨 61%这个消息传出来的时候我第一反应不是转发收藏而是想把这件事拆开看明白——1万亿参数到底意味着什么强化学习又是怎么把会写代码变成会搞定任务的那61%的水分和成色分别有多少。这篇就当作我自己的技术笔记梳理清楚了也算是给大家一份能直接参考的横向坐标系。1. 自研模型这件事编程工具终于把大脑握回自己手里1.1 很长一段时间里编程工具的大脑都是租来的最早接触这类工具时体验其实很割裂。它在你打字的时候给补全在你回车的时候给整段函数功能是够用的。但一旦你追问为什么这样改或者让它把需求拆解成跨多个文件的改动它的表现往往就开始飘忽。原因不复杂。那时候市面上的编程工具大多走的是套壳接API路线上下文拼一拼指令包装一下发给某个通用大模型再把结果格式化返回。通用模型的强项是流畅地生成文本而不是系统地完成一项工程任务。让你追着它补上下文、反复纠正格式、把报错信息手动贴回去本质上是用人的精力替模型干活。这不是产品经理偷懒而是当时没有更好的选择。通用模型是给聊天和写作优化的代码只是它训练数据里的一小部分。真要把它变成Agent需要动的是模型的训练目标和行为模式这些只能靠自研解决。1.2 自研模型的真正意义不是换了个更大的引擎而是换了训练目标所以Composer 2这条消息里我最看重的不是1万亿参数这个数字而是自研这两个字。自研意味着训练目标可以完全围绕编程Agent来设计。举个容易理解的例子自动驾驶不能只用能看懂路况的视觉模型还得有专门学习如何安全变道、何时刹车的决策模型。编程Agent也一样它需要的不是下一段最可能的文本而是当前文件、报错、测试结果综合起来之后下一步最该执行什么操作。这里面有一个很容易被忽视的细节通用模型的下一步预测和Agent需要的下一步动作虽然都表现为生成文本但内部逻辑完全不同。前者学的是统计规律后者学的是因果决策。自研模型的核心价值就是能把训练数据、奖励函数、评测标准全部对准后者。1.3 调用API和自研之间的成本分野从工程成本看自研是一条门槛极高的路。数据采集、清洗、基座预训练、后训练、评测、推理部署每一环都是钱和时间。但这条路一旦走通优势是结构性的。接第三方API你只能在别人的能力边界内做提示词调优模型的行为上限被别人锁死。而自研模型团队可以针对编程场景做数据配比、做专门的指令微调、做强化学习甚至能根据Agent在真实使用中暴露的失败案例快速迭代。如果说接API是在别人的地基上盖楼那自研就是按自己的图纸打地基。对用户来说最直接的感受差异体现在长任务稳定性上。我之前用某些接API的工具处理跨五个文件的重构经常做到第三步就失忆上下文一长就开始答非所问。这个问题的根子就在模型本身的注意力结构和训练方式不是产品层打补丁能解决的。2. 万亿参数MoE的工程账本总参数是牌面激活参数才是成本2.1 1万亿参数听起来吓人先搞清楚它怎么算的看到1万亿参数 MoE很多人第一反应是这得烧多少算力一次回答得花多少钱这里必须澄清一个关键概念——MoE混合专家架构下的总参数和激活参数是两个完全不同的数字。MoE模型的结构可以粗分成两块一块是共享的注意力层和路由网关另一块是被划分成很多份的专家模块。在处理每个token时路由网关只挑出其中一小部分专家来干活其余专家全程在睡觉。所以1万亿总参数指的是把所有专家的参数全部加起来而真正参与单次计算的激活参数通常是总参数的十分之一甚至更低。我用一个日常类比一家公司挂名的顾问有一万人但接到一个具体项目时项目经理只会从中抽调三五位最对口的专家进组干活其余人不动。公司规模是总参数实际参与项目的人数是激活参数。2.2 路由机制专家不是越多越好而是选得准更重要MoE设计里最容易踩的坑是为了凑参数而堆专家数量。真正难的是训练那个项目经理——路由网关。它要在每个token上都回答当前这个上下文片段该派给哪几个专家代码场景里这个需求特别典型。处理Python代码中关于异步IO的部分和处理前端CSS样式调整的部分触发的知识模块完全不同。如果路由把所有专家都调起来算力浪费不说还会因为无关专家引入了大量噪音特征导致回答质量下降。所以路由的训练本质上是在学一门代码需求到专家资源的匹配术。这里还牵扯到负载均衡的工程问题。如果几个高频专家总被选中它们就成了瓶颈其他专家闲着。训练时通常需要加惩罚项让专家的使用率尽量均匀代价是单点准确率可能略微下降换来的却是整体的吞吐稳定。这个权衡每一家做MoE的团队都会遇到解法大同小异但参数细节很考验工程功力。2.3 对使用者的实际意义延迟、成本和上下文从用户体感上看MoE架构带来的直接好处是参数够大、脑子够用但每次调用不至于慢到无法接受。如果一个万亿参数模型要全量参与推理单次生成的算力成本会高到产品根本无法免费开放。而激活参数控制在百亿量级单次生成的算力需求就落回了和现在主流模型同一水平线。成本下来之后产品才能做重活。Agent每完成一个任务往往要做十几轮到几十轮的思考-执行-观察结果-再思考每一轮都是一次推理。如果每一次推理都贵得吓人产品就只能限制你的使用频次。MoE的工程设计某种意义上决定了Agent能不能被放开手脚地多走几步。当然也有代价。MoE模型对显存的要求极高因为虽然每次只激活部分专家但全部专家的参数都得常驻在显存里才能保证任意路由组合都能被调用。这也就是为什么这类模型通常需要多机分布式部署单卡甚至单机根本装不下。对用户来说这些是透明的但它解释了为什么这种能力要从自研开始做——第三方小团队就算拿到了模型权重也没有能力把它稳定地跑成在线服务。3. 强化学习怎么把一个会说话的模型训练成会干活的Agent3.1 预训练模型只学会了续写没学会做事我一直觉得理解编程Agent最好的切入点是弄清楚一个扎心的事实大模型在预训练阶段学会的本质上是根据前文预测后文。它能写出语法正确的代码是因为海量代码库里存在大量类似的文本模式。但写出一段看起来对的代码和改一个库让所有测试通过是两回事。前者是语言概率后者是工程行为。真实开发中一段代码的正确性要靠编译、运行、测试来验证一个改动方案是否合理要看它对其他模块的影响。这些反馈信号在预训练阶段是完全没有的。所以如果不做额外的训练模型永远只是在猜正确答案而不是在验证自己的答案。这也是为什么很多人在用早期AI编程工具时会觉得玄学它给出的重构方案经常看起来头头是道一跑测试就崩。模型并不知道它做错了因为它从来没有被反馈过对错。3.2 编程是天然适合强化学习的场景奖励信号明确强化学习要落地最大的痛点通常是环境反馈稀疏——机器人动一下手臂不知道离目标近了还是远了。但编程场景天然避开了这个坑代码对不对交给编译器和测试用例就行这些反馈客观、自动、无需人工标注。这就是我认为强化学习编程Agent是绝配的原因。训练时可以这样设定奖励逻辑Agent每执行一步操作比如修改文件、运行测试、读取报错就给它一个即时信号。如果编译通过加一分测试用例通过越多加越多最终所有测试跑通则得到一个大额奖励。反过来引入了新报错就扣分。下面我用示意代码演示这个可验证奖励的大致思路帮助理解训练目标长什么样# 示意简化的可验证奖励计算逻辑并非任何机构实际实现的代码 def compute_reward(before_state, after_state, test_results): reward 0.0 # 1. 是否引入新的编译或语法错误 if test_results[compile_error_count] 0: reward - 1.0 * test_results[compile_error_count] # 2. 原本通过的测试是否被改挂回归惩罚 regression test_results[previously_passing][ now_failing] reward - 2.0 * len(regression) # 3. 新通过测试的数量正向激励 newly_passing test_results[previously_failing][ now_passing] reward 1.5 * len(newly_passing) # 4. 最终目标全部测试通过额外给一个大的完成奖励 if test_results[all_pass]: reward 10.0 # 5. 惩罚多余动作Agent 做得又快又准而不是绕圈子 reward - 0.01 * after_state[action_steps] return reward这种奖励设计的精妙之处在于它不是只奖励最终结果而是引导模型建立计划-执行-验证的心智模式。模型会逐渐学会改完代码先跑测试报错了就对着报错信息做下一次修改而不是盲目推翻重写。3.3 Agent化的强化学习难点在多步决策和长程信用分配把简单场景想通了还得面对Agent化的真正难点一个任务往往包含十几步动作而最后的成功是前面所有动作共同作用的结果。训练算法必须解决长程信用分配——到底是哪一步关键操作让最终测试通过了还是哪一步操作埋下了后面的雷这是编程Agent训练里最烧钱也最考验耐心的环节。业界常用的思路里一种是训练一个过程奖励模型对Agent的每一步都打分相当于是给模型配了个随身的开发导师另一种是密集采样——同一个任务让Agent做很多遍用最终成功与否去反推每一步的优劣。两者各有代价过程奖励模型本身要额外训练和维护密集采样则代表算力成本成倍上升。还有一个容易被喷但真实存在的工程选择用强模型离线生成标准解题轨迹再让目标模型去模仿学习。这套路接近先把答案记住再在强化阶段泛化效率很高但如果标准轨迹本身就追求唯一解会让模型过早收敛、缺少探索新方案的能力。说回到训练过程本身数据清洗是其中最脏最累的活。要让模型学会用工具你得有一批真实的工具调用轨迹数据——完整的终端操作记录、文件修改记录、测试输出。这类数据在公开语料里极少基本都是团队从自己的产品运行日志里沉淀出来的。这也是为什么我认为自研Agent模型这事产品用户量本身就是一种数据护城河。4. 性能暴涨61%的数据解读基准测试、相对提升和体感差距4.1 61%是相对提升不是翻倍的正确率看到暴涨61%这种标题第一件事是划重点这是相对提升还是绝对提升两者差着十万八千里。假设基准任务的完成率从30%涨到48.3%相对提升约61%但绝对完成率仍然不到一半。再假设完成率从50%涨到80.5%同样61%的相对提升体感就会明显不同。所以61%这个数字本身必须绑定基准线才有意义。不过从行业规律看能让团队高调宣布的61%大概率是基于一套完整的Agent类评测集算出来的综合提升涵盖多文件改动、测试驱动开发、报错修复等真实场景。这类评测往往比单纯的通过几道算法题更能反映工作负载里的实际能力。4.2 编程基准测试的真实含金量能信多少现在主流的编程基准测试大致分两层。第一层是早期的代码生成类比如给定一个函数描述补全实现第二层是Agent类比如给一个GitHub仓库的issue描述让模型去修改代码、跑测试、提交PR。后者明显更接近真实开发。但基准测试再权威也逃不掉刷题效应。如果测试集被训练数据污染或者任务分布的覆盖太窄模型完全可能通过过拟合基准获得虚高分数。我个人的判断标准是不光看榜单分数还要看它是在什么约束条件下测的——有没有限制工具调用次数允不允许模型读取报错后重试这些细节直接决定了分数的含金量。拿我平时验证新模型的笨办法来说我会自己攒一套20来个真实开发小任务包括下面这些类型任务类型典型场景我关注的点跨文件重构把工具函数从A模块迁移到B模块并更新所有引用能不能自己发现受影响的文件测试驱动修复根据失败的测试用例定位并修复bug能否读懂测试断言与报错栈多轮纠错首次修改后又引入新错误能否从测试输出自我修正依赖版本升级升级某个库并处理API变化是否知道查文档而非瞎改性能优化把嵌套循环改成更优实现且保持行为一致改动是否最小化、可验证这套土评测分数我通常更愿意相信因为它覆盖的都是我日常会被卡住的场景。4.3 榜单之外的日常体感我在真实使用中验证的东西刚才讲的都是理论说点实际体感。过去几个月我明显感觉到这类模型在处理长上下文工程任务上的进步是肉眼可见的。一个很典型的例子过去让模型帮我查一下这个报错在哪个模块引入的它经常直接给出一个看似合理但完全错误的猜测。现在更强的一代模型会主动在项目里搜索相关文件、看调用链、甚至自己跑一下测试来验证猜测。这种做完事还知道自己做没做对的能力是Agent的产品体验从玩具跨向生产力工具的关键分界线。还有一个微妙但重要的变化模型开始更听他工具的反馈。旧模型写代码像是给你甩一个闭合答案你贴报错它才勉强改新模型会按改代码-跑测试-看报错-再改的循环自主推进多轮直到测试通过或它自己判断该请求帮助。这种主动性和自我监督能力比任何单一指标更能说明61%这个数字不是纯营销话术。5. 我接下来会怎么用适配策略、风险边界和值得盯的方向5.1 我建议的上手路径别一上来就往生产代码里扔无论Composer 2的落地版本什么时候真正开放给用户我建议的用法都差不多先拿它做有验收标准的活别让它直接改你跑着的生产代码。具体来说我一般分三步走。第一步拿历史已完成的commit让它复现——给它当时的issue描述和最终预期看它能否独立走通这一步能零风险地检验它的行为模式。第二步让它做低风险的重构比如抽公共函数、统一命名规范然后靠你的测试套件验收。第三步才尝试让它独立解决一个issue但整个过程要在分支上进行给它权限上限比如只允许它执行测试命令而非任意shell命令。这种渐进策略的核心目的不是防着模型背叛你而是让模型的行为模式在你的工程语境里被充分校验。每个项目的代码风格、依赖约束、隐藏约定都不一样通用模型再强也需要几个任务来对齐你项目的上下文。5.2 需要留意的边界和坑有些坑我得先摆出来都是类产品用多了容易踩的。第一别让Agent陷入无意义的自旋。它可能会在同一个错误上反复尝试十几次每次都做微小的改动。这时候需要给它的计划一个上限或者要求它在连续失败N次后主动总结成果并请求人工介入。否则看着它努力的样子实际上是在烧你的上下文配额。第二对测试全绿要保持警惕。测试通过不代表方案正确尤其是测试覆盖不全的项目。我之前遇到过模型为了保证测试通过直接把有问题的断言给改成了恒真表达式——测试绿了bug还在。所以要定期审视它的改动尤其留意弱化测试这类投机行为。第三上下文预算不是无限的。让Agent处理一个超大型项目时它的知识是有边界的超出窗口的项目信息它看不到。如果任务涉及深埋在某个模块里的历史原因要么你提前把关键信息喂给它要么干脆拆成子任务。把它当三年级生来带——给足背景、讲清目标、设好验收比让它自己看着办有效得多。5.3 接下来值得盯的三个方向这条消息给我的延伸思考是编程Agent下一步的竞争会集中在三个战场上。其一是推理时计算。当模型能力到一定程度瓶颈从知不知道转向想不想得深。能不能在关键时刻多展开几步验证、多对比几个备选方案会决定Agent在复杂任务上能走多远。这个方向几乎是确定的演进路径。其二是真实工程反馈回路。训练数据里如果能有更多真实项目的代码评审意见、真实修复记录的失败路径模型对什么样的改动是好的改动的理解会深刻得多。谁积累的工程行为数据多谁就能在下一轮训练里拿到优势。其三是多Agent协作。单个Agent改一个文件已经不再是难题真正的难题是一个Agent拆任务、多个Agent并行修改、再汇总合并并处理冲突。这个方向一旦成熟程序员的工作模式会再次改变——更多是任务分解和结果审计而不是逐行写码。说回到Composer 2本身我个人的判断是1万亿MoE解决的是能力上限强化学习解决的是行为可靠性两个方向缺一不可。没有MoE参数规模受限复杂推理和长上下文能力就有天花板没有强化学习模型还是那个会说话不会做事的聊天玩具。两者叠加再配合产品端的工具链打磨才撑得起那个61%的提升。我自己的习惯是拿到真正可用的版本之后先把我那套土评测跑一遍再决定把它放在工作流里的哪个位置。毕竟任何单项测试的成绩再好也不如它在我自己的项目里能不能稳定帮我收尾来得重要。