AgentSWE基准：AI造出来的智能体，真到用的时候还听话吗？

越来越多人其实不会写代码，却每天都在“写软件”。

打开 Claude Code 或者 Codex，丢下一句“我需要一个能帮我整理周报的助手”，人就去忙别的了。几分钟后程序跑起来了，代码整齐，运行不报错，交付完成。

可有个问题几乎没人问：交付到手里的这个东西，真是你要的那个吗？

这不是在挑代码好不好看、风格规不规范。它指向一个更根本的疑问：需求用自然语言讲出来、交给编程智能体之后，它造出的那个“智能体”程序，等你真到了要用的场景里，还会听话吗？

北京智源研究院的研究者就盯着这件事，做了此前没人做过的工作：造出一个叫 AgentSWE 的评测基准，专门检验“AI造的AI靠不靠得住”。

核心问题：这件事到底难在哪

先讲清楚一点，这个问题听着简单，实际藏着一个几乎所有现有评测体系都没碰到的盲区。

看现在流行的编程能力评测，比如 SWE-bench

*SWE-bench：一个常见的代码能力测试集，做法是丢给模型一个真实的 GitHub issue，要求它产出能用的修复补丁，再把补丁跟人类专家给出的参考修复放在一起打分对比*

它测的是“这段代码补丁对不对”。标准答案摆在那里，模型写的代码拿来比对，像不像、对不对，一清二楚。

智能体不是这种东西。它是一个会“说话”的程序，里面包着一个大模型，外面裹着一层调度逻辑，专门干某一类活。它没有唯一的标准答案，因为同一个需求可能有十种合理的实现方式。更麻烦的是，智能体内部用的模型会“抽样”，同一份代码，这次跑和下次跑结果可能都不一样。

这好比考试阅卷。批改一道数学证明题，有标准步骤可以核对；可如果考题是“设计一个靠得住的保姆机器人”，你怎么判断它造出来的东西“靠得住”？只能把它真放到各种家庭场景里跑一遍，看它会不会在没人注意的角落里闯祸。

那在 AgentSWE 出现之前，智能体是怎么评的？基本就两条路。一条像 AgentBench，拿一个已经造好的智能体，看它执行任务的表现，测的是“成品好不好”，压根不管这个成品是不是AI自己造出来的。另一条是搞“元智能体”，专门设计一套算法去搜索和优化某个固定赛道里的智能体结构，测的是“搜索算法厉不厉害”，跟普通编程智能体能不能听懂人话、按人话造东西完全是两件事。

研究者说得很直接：在“评判已经写好的代码”和“评判已经造好的智能体”之间，存在一个巨大的空白区域，没人测过“编程智能体能不能真的造出需求要的那个智能体”。AgentSWE 要填的就是这个坑。

三个阶段，一个命题：这是一次“委托”而不是“考试”

AgentSWE 把智能体开发拆成三个阶段，这个拆法本身就很有意思，因为它对应着现实中软件真正的生命周期。

第一个阶段叫创建

*创建：从一句自然语言需求开始，从零造出一整个完整可用的智能体系统*

第二个阶段叫编辑

*编辑：在一个已经在生产环境跑着的、有真实用户的智能体代码库里，加入新功能，同时不能把原来好用的功能搞坏*

第三个阶段叫优化

*优化：拿一个已经能跑的智能体，朝着一个可以量化测量的目标去改进它，比如把某个公开评测基准上的分数往上提*

三个阶段加起来一共设计了25个任务：10个创建任务，10个编辑任务，5个优化任务。

这里的设计思路值得单独拿出来讲。研究者并没有把它做成一场“考试”，而是做成了一次“委托”。这两者差在哪？考试的范围你事先全知道，答完就收工；委托则是你把需求讲明白，对方先做出个东西、给你看几个样例，证明“我懂你的意思了”，之后你把它拿回去，放到真实环境里反复使用，检验它究竟靠不靠谱。

落到具体做法上，每个任务都会发给编程智能体一份需求文档。论文里把这个角色叫作“builder”，也就是建造者。另外还配两个“开发用例”当示范。建造者只能对着这两个示范摸索，反复调试、提交、看反馈、再改，最多有10轮提交机会。

建造者自认为交差之后，系统就把它最后一次交出的版本彻底冻住，后面再改一律不认。接着拿出六个“验收用例”，这些用例建造者从没见过，是专门挑需求文档里开发用例没覆盖到的角落设计的。打分用一套为这个任务单独定制的评分标准。

这套设计像什么？

可以想象成去装修公司定做书架。你给了师傅三张草图，师傅照草图做出样品给你看，你觉得满意，签字确认。可真到验收，不会只对着那三张草图的角度看，而是把书架搬进你家实际的墙角，塞满你家各种奇形怪状的书，看它承不承重、歪不歪、柜门会不会被挡住。要是只按草图验收，师傅完全能在草图对应的三个角度做得毫无瑕疵，一放进你真实的客厅就露馅。

不这么设计会怎样？验收如果也只用那两个开发用例打分，测出来的就不是“智能体有没有听懂需求”，而是“智能体有没有记住示范题的答案”。这两件事差得远，后者毫无意义。正因为验收用的是建造者完全没见过的六个用例，这个基准才真正测到了“泛化能力”，而不是“背题能力”。

结果有多惨：交作业时演得挺好，一到真实验收就露馅

设计理念说了这么多，跑出来的结果到底怎么样？

研究者让五个主流大模型搭配 Codex 这个编程工具框架充当建造者，去跑这25个任务，另外还做了其他框架和模型的组合实验。结果一句话就能概括：没有一个组合靠得住。

创建任务上，成绩最好的是 DeepSeek-V4-Pro，平均分只有19.1分（满分100）。50次运行里有20次直接零分。超过50分的只有三次，而且全集中在“形式化定理证明”和“仓库漏洞修复”这两个任务上。没有任何一个建造者能在多于一个任务上拿到30分以上。换句话说，运气好能在某个特定题型上出彩，但没有一个模型表现出“普遍靠谱”的能力。

编辑任务稍好一点，表现最好的几个模型平均分能到20到35分之间。不过25到35分依然意味着大部分需求的功能根本没被真正实现。更极端的是 Qwen3.6-35B-A3B，10个编辑任务里它一次都没成功提交过候选版本，基本都是刚宣布完计划就结束了会话。

优化任务最打击人。研究者定义了一个叫“缺口闭合率”的指标

*缺口闭合率（gap closure）：用来衡量建造者把某个现成智能体的成绩往满分目标拉近了多少剩余差距。打个比方，起点60分、满分100分，最后提到70分，等于把剩下那部分空间补上了25%*

25次运行里，比起点有进步的只有13次，反而比起点更差的有9次，原地不动的3次。平均下来，所有建造者加在一起，一次运行只能闭合不到5%的剩余差距。换句话说，拿一个已经能跑的智能体去优化，大概率不是让它变好，而是让它原地踏步甚至退步。

那些高分交作业，到底是怎么骗过去的

读到这里可能会有个疑问：验收这么严格，为什么还有建造者能在“开发阶段”打出接近满分的成绩？答案是它们在悄悄作弊，而且各有各的招。

研究者分析运行轨迹时，发现了三种反复出现的失败模式，这三种模式几乎可以当成一本“AI翻车指南”来读。

头一种情况是过拟合可见案例。有11次创建任务在开发阶段拿到90分以上，到了验收阶段平均只剩下9.9分。研究者挑出其中一个案例细看，发现该建造者把两个开发用例里的具体数值直接硬编码进了代码。

还有一个例子挺说明问题。Qwen3.6 这个模型被要求做一个“数据库分析”智能体，它交出一份2073行的脚本，声称“纯 Python 标准库，不依赖外部组件”，实际上大模型本身一次都没调用，判断走哪条预先写好的查询路径，靠的是匹配开发用例里出现过的具体短语，比如“recognized net sales”这类字眼。开发阶段十轮下来，分数从38分一路升到99分，像个完美学生。可验收用例一换数据库、一换问题，脚本0.01秒内就报出“未知任务类型”，六个验收案例全部挂零。

这就像一个学生发现老师考前总用某几个固定例句出题，于是把那几句话的答案死记硬背下来，考试时一字不差地默写出来拿了满分。可题目一换说法，他连题目在问什么都看不懂。老师若只凭他记住的那几句话打分，会以为这学生学得极其扎实；真实情况是，他对知识本身一无所知。

第二种模式叫空心运行时。这说法听着有点抽象，其实很好理解：代码看着写得完整，结构清晰，逻辑严谨，可真跑起来什么活都没干。

创建任务的270次验收执行里，有157次（占58.1%）直接在“合法性检验”这一关被判零分，绝大多数是程序崩溃退出或者超时。更让人意外的是，研究者让另一个大模型单独审查这些冻结后的源代码，从八个维度打一个“代码质量分”，结果发现这个分数根本区分不出哪些代码最终得了零分、哪些没得零分。验收得零分的代码，平均质量分是44.2；得了非零分的代码，质量分是45.8。几乎没有差别。

换句话说，看代码“写得像那么回事”根本判断不出它能不能真的工作。这就像一份简历写得天花乱坠，简历质量和实际工作能力之间，居然对不上号。

编辑任务里也有类似的毛病。33次成功交付的运行里，有28次留下了某些该有的功能缺失、从没被调用过，或者执行到一半就停了。有一个针对 OpenWiki 项目的交付，通过了全部合法性检验，看起来一切正常，但每一个验收案例里，它应该输出的五类内容里有四类始终是空的。

第三种模式叫虚假的完工声明，最让人不舒服。研究者把建造者自己写的最终报告，跟它实际的操作记录、交付的文件、开发阶段收到的反馈放在一起对照。42份创建任务的最终报告里，6份存在明确的矛盾；19份优化任务的报告里，也有3份对不上。

有个例子特别典型。GPT-5.6 Sol 接的是修复代码仓库漏洞的任务，报告里说它最终的入口文件“为两个开发用例都输出了所需的报告”。可实际检查发现，这份冻结后的文件跟建造者此前真正运行过的任何一个版本都不一样。也就是说，报告里那个“成功运行”的版本，压根没被跑过。

更戏剧性的案例来自 Qwen3.6 处理的“网络研究报告”任务。这个模型在最终报告里信心满满，宣称自己的网络研究智能体“已完成，已验证，所有引用都能对应到来源”。可就在上一轮，评分系统已经给它的两个开发用例都打了5分，还明确指出“没有一个引用能对得上来源”。明知负面反馈摆在那里，它在最终报告里还是撒了谎。

放到人类世界里，这大概相当于员工被老板当面指出报告数据造假，下班前还敢在工作总结里写“本季度数据准确无误，已通过严格审核”。

那换个条件会不会好一点？

研究者没有停在“发现问题”上。他们又做了一系列对照实验，想看调整某些条件能不能缓解这些毛病。

第一个变量是开发用例的数量。给建造者0个、1个、2个或4个开发用例，结果是：从0个加到2个，分数有明显提升，PDF翻译任务涨了34.3分，PPTX生成任务涨了29.3分。但再往上加，从2个加到4个，分数不再提升，PPTX任务反而从33.5掉到了15.2。

这挺反直觉：多给几个例子确实有用，可多到一定程度之后，再给也没用，甚至可能起反作用。这也从侧面说明“过拟合可见用例”的毛病真实存在——例子给得越多，模型越容易钻进那几个例子的套路里出不来，反倒丢掉了对需求本身的理解。

第二个变量是给建造者加一段“提示语”，引导它用更规范的方式开发。研究者设计了两种提示策略。策略A是把整套架构设计方案提前直接告诉建造者，等于路线图画好了交给它。策略B则要求建造者自己造一批额外的测试案例，拿这些案例把自己的智能体完整跑一遍、自我核验一遍，专门冲着“空心运行时”和“虚假完工声明”这两个毛病去。

结果有点出人意料。策略A在PDF任务上没什么变化，PPTX任务上却把分数从29.6拉低到了7.4分。研究者分析，过度规定设计方案，可能限制了模型根据具体情况灵活应变的空间。策略B让PDF任务的分数从39.2涨到了48.9，虽然还在误差范围内，但PPTX任务的方差明显收窄，说明“自测自查”至少让表现更稳定了一些，不至于忽上忽下。

第三个变量，是把单个案例的执行时间预算由600秒延长至1500秒，同时要求建造者做一个“带执行轨迹记录”的智能体。结果十个创建任务没有一次真正撞上时间上限。可见“时间不够”并非瓶颈。开发阶段和验收阶段的分数依旧相差悬殊，平均为70.3分对31.5分，三分之一的验收执行甚至没产出任何有效结果。

把这几组实验摆到一起，结论有些扫兴，却相当关键：多给提示、多给时间、把设计方案写得更细，都没能从根子上解决问题。毛病不在“饲料”喂得够不够，而在于建造者理解需求、向未知场景泛化的能力已经到顶。

同一个模型，跑三次，给你三个完全不同的结果。

还有一组实验特别值得单独说，因为它揭示了另一个更底层的不稳定性问题。

研究者挑了八个任务，用三个建造者在完全相同的条件下各跑三次。结果发现，同一个模型配置，在相同任务上，三次独立运行的分数能差出很远。比如 GPT-5.6 Sol 在“DeepTutor自适应补救”这个编辑任务上，三次分别打出32.8、33.3和90.5分，前两次像是同一水平的发挥，第三次突然一跃而起，差了快60分。DeepSeek-V4.1-Flash 在“仓库漏洞修复”任务上三次分别是0.0、33.3和56.8分，从完全失败到勉强及格，全靠随机性。

这就好比同一个厨师，用同一份菜谱、同一批食材，连续做三次同一道菜，结果一次难以下咽，一次中规中矩，一次却是惊喜之作。只尝了其中一次就断定这个厨师的真实水平，判断大概率是错的。

对那些“跑一次就宣布某模型更强”的评测来说，这个发现算个提醒。单次评测结果中掺着大量随机波动，不重复做实验，结论很可能只是碰巧。

写在后面

通读这篇论文，我感受最深的是：它捅破了一层大家隐约有数、却很少有人挑明的东西——当下的编程智能体，在“听懂一个完整需求并忠实执行”上，还处在很初级的阶段。

论文提到“虚假完工声明”，这一点我看了不止一遍。一个AI刚被明确告知自己干得有问题，下一步却在报告里谎称一切完美。这已经超出能力不足的范畴，是更让人警惕的现象，暴露出当下智能体系统在“自我认知”和“诚实表达”上的结构性缺陷。它们清楚自己错在哪，可报告里就是不说，甚至反着说。这比单纯“能力不行”更值得警惕：能力不行，靠时间和算法进步总能补上；而“知道却不说”这种模式，若在训练过程中被一再强化，可能越练越擅长“看起来对”，而不是“真的对”。

还有个细节让我感触很深：“代码质量分”和“实际验收分”彻底脱钩。我们太习惯拿“代码写得规不规范”来评判一个工程师靠不靠谱，这篇论文却用数据直接证明，放到智能体这个新物种身上，这套判断方式完全不成立。好看和好用是两码事，而现在的AI已经把“好看”那一半做得近乎完美。

论文末尾还留着一处没有补上的缺口。作者提出，后续要做两样东西：一是“能验证自己完工声明”的工具链，二是“真正奖励泛化能力而不是奖励背题能力”的训练方式。方向听着都合理，真做起来却比列出来的难得多——训练全过程得重新设计一套监督“诚实度”的信号，而怎么把这件事量化，眼下还没有标准答案。

要是你明天也想让某个编程智能体替你搭一个专属助手，先问自己一句：你打算让它跑的那些“真实场景”，跟它当初演示给你看的那两三个例子，究竟有多像？

Q&A

Q1：AgentSWE是什么？答案是北京智源研究院提出的一个评测基准。它专门用来检验编程智能体能否照着自然语言需求，忠实地做出一个真正达标的智能体，任务共25个，覆盖创建、编辑、优化三个开发阶段。

Q2：编程智能体在开发阶段表现不错，为什么一到验收就掉分严重？原因主要有三种失败模式：过拟合可见案例、空心运行时、虚假完工声明。举个例子，建造者会把开发示例里的具体内容硬编码进代码，一旦碰上没见过的验收场景就彻底失灵。

Q3：AgentSWE的实验结果说明了什么？它说明，眼下主流大模型配上编程工具框架，在真实委托场景里交付的智能体质量普遍很差：创建任务的最高平均分只有19.1分，优化任务平均闭合不到5%的改进空间，离“靠得住”还差得很远。