为何编码智能体在处理私有公司的代码时仍面临困难

公开的编程基准测试能够检验实用技能，但很难反映企业内部私有生产代码的实际运行情况。一种名为Real-SWE的基准测试试图进行第二种类型的检验。其开发者是一家由Y Combinator资助的小型初创公司Specific Labs，他们从真实企业获取了私有代码，从中挑选出工程师们已完成的十项任务，然后交给八名编程助手处理。表现最好的一名助手完成了38.8%的任务。

其中一项任务是处理账单紧急状况：该服务发出的发票完全没有税项，而计费工作将在周一恢复。所有助手总共尝试了64次才解决这个问题，最终有两次成功。这项任务被称为“税务管辖范围”，是那十项任务之一。

为何这些代码仍被保密

创始人们最近发布了这项基准测试，它凭借数百点分数和上百条评论登上了Hacker News首页。Real-SWE在十项任务中评估了八种模型与智能体组合，每项任务进行八次尝试，共计640次测试，最终得分即为通过测试的尝试次数所占比例。

这些底层项目看起来就像普通的商业软件：一款拥有20多万用户并跻身App Store前100名的消费者活动应用，一款已处理超过10万份银行对账单的金融科技产品，以及一个企业销售平台。智能体可使用Docker和Kubernetes、三种数据库（Postgres、MySQL、MongoDB）、Redis、GitHub以及模拟的亚马逊云环境，不过每项任务仅会暴露其工作流程所需的服务。

某些工作环境还会引入 Slack、Intercom、Google Drive、ClickUp 以及 Linear MCP 服务器，这样客服人员可以直接从 Linear 中读取工单内容。如果工单中未包含某些细节，客服人员就不得不像该团队的工程师一样，从相关讨论串或文档中查找这些信息。

税务处理工作需要依托 TypeScript 编写的 NestJS 服务、两个相同的外部税务机构实例（一个用于测试的沙箱环境，另一个用于实际提交申报的正式系统），以及用于记录已完成销售的 InfluxDB 日志表。

任务采用 Harbor 格式，验证内容会在评分时才会公开。这样做的目的是降低客服人员为迎合已公开的测试而忽视实际要求的可能性。验证内容取自这些公司原本就运行的测试套件，有时甚至是原封不动地使用那些测试内容。

作者们用一个惊人的论点来解释他们的动机：现实企业中99%的代码片段对Frontier模型来说是不可见的。由于这些任务来自私有软件而非公开的GitHub项目，模型在训练过程中无法接触到相关代码或其隐藏信息。

该基准测试的统计数据表明，指令的平均长度为1,742个字符，这一数值低于FrontierCode（2,056）和DeepSWE（1,975）。但在平均情况下，参考解决方案需要修改11个文件，而另外两个方案仅需修改6个文件。

不同任务的结果差异极大

单一的总体得分掩盖了两种截然不同的任务类型：一类是智能体能够反复解决的任务，另一类则是每次都会失败的任务。多区域扫描在67.2%的情况下能解决问题，API密钥与环境配置问题在65.6%的情况下可解决，权限超额问题有50%的解决率，而客户身份迁移问题的解决率为40.6%。

榜单末尾的情况相当糟糕。税务处理部分的准确率为3.1%，线性扫描的准确率为4.7%，而S3数据存储的测量值为10.9，API令牌计量的准确率为12.5，账单调度迁移的准确率为14.1，这些数值也仅略高一点。在分析流简化器方面，所有模型均毫无进展：64次测试中均未通过。

在税务处理任务中，仅有两个模型取得了成功，且这两个模型在其他七次尝试中都失败了。在多区域扫描任务中——这是难度最低的任务——有三个模型8次全中，另外两个模型各成功2次。将这些数据平均后得出的67.2%的准确率掩盖了其中一组从未出错的模型以及另一组几乎从未成功的模型。

其中一位作者在Hacker News上表示，如此低的准确率反映了“那些真正的工程师花费数周时间才能完成的任务”。

完整排名如下：

分数无法解释失败原因

每一次失败的部署都会被贴上五个标签之一，这些标签源自 DeepSWE 的分类体系：

• 未经验证的假设。 代理没有检查工作环境，而是自行猜测系统的运行方式。

遗漏要求。说明中要求的某些内容在修改后完全未出现。

集成错误。方法本身是正确的，但与周边系统的连接方式有误。

回归问题。该修改破坏了之前正常运行的功能。

文件选错。修改被应用到了运行中的应用程序根本不会访问的代码中，比如某个废弃脚本。

每个百分比值都以模型自身的失败运行次数作为分母。

Grok 4.6出现了61次故障，其中三分之二（67.2%）属于未满足需求。Gemini 3.8 Flash则有55次故障，其中49.1%为集成错误。GPT-5.6 Sol的故障中最多的是未经验证的假设，67次故障中有43.3%属于此类，而Fable 5.1的49次故障分布更为均匀：约37%为未满足需求，约35%为集成错误。

Grok 4.6和Muse Spark 1.3这两种模型的完成率均为23.8%，但故障类型不同。Grok的故障主要集中于未满足需求，而Muse Spark的故障则主要集中于集成错误，占比为41%。性能退化幅度从未超过10.9%，在8种配置中有3种的退化幅度为零。错误文件类别仅出现两次：GLM 5.3（7%）和Kimi K3（3.1%）。

需注意一点：虽然这些标签已经公布，但其背后的处理流程描述得不够详细，因此不能将这些百分比视为最终依据。相关公开资料并未明确说明是人工工程师、自动模型还是两者结合进行了分类。

运行时间更长并不代表更可靠

这些测试还按实际时长进行了划分：在十分钟以内，98次尝试中有70次失败，失败率为71.4%；而在十分钟或以上时，542次尝试中有398次失败，失败率为73.4%。

令牌使用量也能反映相关情况。在十项任务中的八项上，Grok 4.6的输出令牌数平均在3,000到20,000之间，但在得分最低的两项任务——线性化扫描和分析流简化器中，其输出令牌数分别达到了261,000和315,000。过高的令牌使用量可能是一个警示信号，尤其是当其远高于系统正常的基准值时。如果某次运行的输出量是预期值的数倍，应检查其运行轨迹或及时介入，而非让失败的尝试消耗资源。

价格最高的智能体并不总是最好的

每次运行的预估成本从2.50美元（Gemini 3.8 Flash）到6.96美元（Fable 5.1）不等，其价格排序与排行榜并不一致。GPT-5.6 Sol的价格为2.65美元，位居最后，而最便宜的选项Gemini 3.8 Flash则排在第三位。这些均为基准预估值，并非统一的定价排名，因为实际花费还取决于价格、设置、任务长度、重试次数以及工具使用情况。

Fable 5.1的成本是Gemini 3.8 Flash的2.78倍，且性能高出7.6个百分点。这是否值得则取决于任务失败会带来多大的损失。在此类场景中，任务失败可能表现为计费错误、本应免费的客户被收费，或是季度末对账出现差异。而对于界面微调而言，相关费用则完全不同。

这种差距主要源于输出token的数量。GLM 5.3每次运行平均输出117,000个token，而GPT-6 Astra仅为24,000个，在相同的十项任务中差距接近五倍。该基准测试的制定者对两个数值提出了警示：Grok 4.6的价格为3.44美元，Kimi K3的价格为3.90美元，但它们缺少部分使用数据，因此实际成本可能更高。这些数值应视为最低成本。

同一套工具，差距却达十七点

每个测试项都会将模型与其所在厂商提供的工具搭配在一起，这也是该基准测试将评分结果描述为“模型与工具的组合而非单独的模型”的原因。不过有两套工具出现了两次，以便进行大致比较。使用Codex CLI时，GPT-6 Astra的得分率为33.8%，而GPT-5.6 Sol仅为16.2%，两者差距达17.6个百分点。使用Claude Code时，Fable 5.1的得分为38.8%，GLM 5.3的得分为28.8%，相差十个百分点。

尽管如此，10项任务和8种配置仅构成一个小型测试板，且每个得分都附有公开的置信区间。每个模型均进行了80次测试，因此Fable 5.1的38.8%对应31次通过，而GPT-5.6 Sol的16.2%则对应13次通过。若某个模型在某项任务上结果反转，其得分就会变动数点。在这种规模的测试板上，没人应该选择特定供应商，作者也并未要求任何人这么做。这项测试表明，公开得分可能无法完全反映私有代码库中的性能表现，同时它还指出了导致这种差异的五类实际问题。

在您自己的代码上应用这五个分类标签

该分类体系是可以直接使用的。您随时可以将其应用到自己的代码库中。

取代理最近打开的二十个拉取请求，对于每个失败或被大量修改的请求，从五个类别中为其分配一个类别。统计这些分类的数量。其分布情况即为研究结果，而且不会与你本周读到的任何模型预测结果一致，因为它既取决于模型，也取决于你的代码库以及编写工单的习惯。无论哪个类别的数量最多，就在该类别上设置一道审核关卡。

如果未经验证的假设占据主导地位，就需要记录操作日志。要求代理在修改任何内容之前先记录它打开的文件列表，如果该列表遗漏了包含相关功能的文件，则应拒绝此次修改。未能满足的要求通常可以追溯到对应的工单。应将指令转化为一系列验收标准，并逐一核对，因为那些包含在冗长段落中的五项要求的指令正是导致Grok错误率高达67.2%的原因。集成错误表现为单元测试通过，但在调用链测试中失败，因此应从应用程序的入口点开始，沿着其实际运行的路径进行测试。错误地修改了非目标文件的情况相当罕见，一旦出现就应深入调查：确认每个被修改的文件都能通过应用程序实际调用的代码访问到。

从那时起，只需关注一个数字：按失败类型划分的、首次通过审核的代理拉取请求的比例。当审查标准变严时这一比例会发生变化，而底层模型改变时也会再次出现变化。