过去这一年多，我几乎是眼睁睁看着AI编程工具从"自动补全玩具"一步步长成"能独立干活的小组员"的。所以当"Cursor 自研 Composer 2：1万亿参数 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. 强化学习怎么把一个"会说话的模型"训练成"会干活的Agent"3.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%的提升。我自己的习惯是，拿到真正可用的版本之后，先把我那套土评测跑一遍，再决定把它放在工作流里的哪个位置。毕竟任何单项测试的成绩再好，也不如"它在我自己的项目里能不能稳定帮我收尾"来得重要。
过去这一年多，我几乎是眼睁睁看着AI编程工具从"自动补全玩具"一步步长成"能独立干活的小组员"的。所以当"Cursor 自研 Composer 2：1万亿参数 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. 强化学习怎么把一个"会说话的模型"训练成"会干活的Agent"3.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%的提升。我自己的习惯是，拿到真正可用的版本之后，先把我那套土评测跑一遍，再决定把它放在工作流里的哪个位置。毕竟任何单项测试的成绩再好，也不如"它在我自己的项目里能不能稳定帮我收尾"来得重要。