一个越来越明显的落差
过去一年，编码智能体在公开基准上的分数一直在涨。各大榜单的头名换得很快，得分也从三成出头一路推到接近六成。这些数字被广泛引用，用来证明智能体已经能独立完成软件工程任务。
与此同时，真正把智能体放进企业代码库的团队，反馈往往没那么乐观。常见的情况是：在演示仓库里表现流畅，换到自己那套跑了七八年、依赖十几个内部服务、文档还停留在三年前的系统上，成功率明显下降。
这个落差有一部分来自评测方法本身。主流的编码评测多使用开源仓库与公开议题，而这些内容很可能已经出现在模型的训练语料里。模型不是没见过类似问题，而是可能见过同一个问题。Specific Labs 在 9 月发布 Real-SWE，试图把评测拉回到企业真实环境。
它测的是什么
Real-SWE 的做法是向企业取得授权，直接使用对方的生产代码库与真实工程任务，而不是用公开仓库或人工合成的题目。按发布说明，这样做的理由是：合成任务可以设计得很精巧，但它不等于真实公司里工程师真正要做的那件事。
具体来说，评测任务来自已在实际运行的系统，涉及跨应用的业务规则、内部约定与相互依赖的服务。发布方举的一个例子是账单场景：修一个发票问题，可能要同时处理税务逻辑、客户豁免、发票生成与一个第三方税务服务商。另一个例子是迁移任务，会同时碰到客户记录、后台作业与运维工具。
评测在「模型加工具链」这一层进行，而不是孤立地测模型。工具链决定智能体能调用的工具、文件访问范围、命令执行方式以及它与环境的交互。发布方认为，这更接近企业工程的实际形态——模型是通过终端、版本控制、数据库与业务应用来工作的。
运行环境包含 PostgreSQL、MySQL、MongoDB、Redis、AWS 模拟器、Kubernetes、GitHub、Linear、Slack 与 Google Drive 等服务，每个任务只暴露它真正需要的那几个。评测使用 Harbor 框架，每个智能体进入独立沙箱，验证器在评测时注入。每个任务跑八次，取平均的 pass@1 作为成绩。
那张榜单
按公开的首轮榜单，八个模型与工具链组合的成绩如下。最高的是 Fable 5.1 搭配 Claude Code，解决率 38.8%；GPT-6 Astra 搭配 Codex CLI 为 33.8%；Gemini 3.8 Flash 搭配 Gemini CLI 为 31.2%；GLM 5.3 搭配 Claude Code 为 28.8%；Grok 4.6 搭配 Grok Build 与 Muse Spark 1.3 搭配 Muse Code 同为 23.8%；Kimi K3 搭配 Kimi Code 为 18.8%；GPT-5.6 Sol 搭配 Codex CLI 为 16.2%。
把这组数字与公开基准对照，落差很明显。同一批模型在公开编码基准上常能拿到五成上下，到了私有生产代码库，最高的组合也只解出不到四成。
任务难度还体现在改动的广度上。指令的中位长度约 1742 个字符，而参考解平均改动 11 个文件，发布方对比的公开基准是 6 个。也就是说，一句话的需求背后，往往藏着一条横跨多处的依赖链。智能体必须先弄清现有行为、找到公司自己的写法、把改动接到正确的服务上，还要保住任务根本没提的那些行为。
六个任务几乎解不出来
公开样本包含十个任务，其中六个在所有被测系统上的综合解决率低于 15%。最低的几个是：分析流 reducer 为 0%，税务辖区为 3.1%，可线性化扫描为 4.7%，S3 数据存储测量为 10.9%，API 令牌计量为 12.5%，账单周期迁移为 14.1%。相对好一些的是多区域扫描 67.2%、API 密钥与环境 65.6%、超额行项 50.0%。
税务辖区这个任务很能说明问题。它要求正确处理企业与豁免客户的税务，而相关逻辑散落在 NestJS 与 TypeScript 服务、税务服务商沙箱与一个账本数据库之间。有一个模型在八次尝试中完成了一次，有两个模型一次都没完成。分析流 reducer 则是零成功——需要说明的是，零成功并不证明任务在生产中不可解，它只说明在这些指令与工具条件下，被测系统无法让验证器通过。
发布方把失败归成五类：未验证的假设、遗漏需求、集成错误、回归，以及改错了文件。不同模型的失败画像并不一样，例如 GPT-5.6 Sol 有 43.3% 的失败运行是在一个没核实的假设上继续往下做。
样本来自什么样的系统
按公开说明，被选中的代码库来自使用量较大、负载要求较高的公司。样本里包括一个用户超过 20 万的事件平台、一个处理过十万份以上银行对账单的消费金融产品，以及若干工作流复杂的企业销售系统。
私有仓库给智能体提供了完成任务所需的代码，但公开检索无法提供现成的补丁或讨论帖。智能体必须自己翻工作区，推断各个部件是怎么拼起来的。这正是这类评测想暴露的能力缺口——不是「能不能写出代码」，而是「能不能在一套陌生而复杂的系统里定位并安全地改动」。
中立思辨
需要辩证看待几件事。其一，成绩低不等于智能体没用。在改动范围小、依赖清晰的任务上，榜单里的组合仍能拿到六成以上。这些评测真正说明的是能力边界在哪里，而不是能力不存在。把它读成「智能体完全不行」同样不准确。
其二，这份基准由厂商发布，任务来自合作企业的授权代码库。任务选择、验证器设计与难度分布都掌握在发布方手里。在独立复现之前，这组数字应被看作一个方向性信号，而不是终局结论。
其三，八次运行取平均、验证器在评测时注入，这些方法降低了偶然性，也意味着结果高度依赖验证器写得好不好。验证器覆盖不到的合理实现，可能被算作失败。
其四，私有代码库的评测很难被第三方复现，这限制了它作为行业标准的可能。它的价值更偏向一份诊断报告——告诉你哪一类任务最容易崩，而不是一个可长期追踪的排行榜。
其五，十个公开任务只是样本的一部分，完整任务集与各任务的具体设定，公开材料未充分展开。目前官方及行业暂未披露更多细节，后续将持续跟进迭代动态。
给技术团队的四条做法
把这份评测的结论拆出来，有四条可以直接用。
用自己仓库做一次小规模实测。挑十个有代表性的历史任务，让智能体在隔离环境里跑，人工判分。外部榜单只能做参考，你自己系统上的成绩才决定要不要扩大使用。
优先投向改动范围小的场景。榜单显示，涉及文件少、依赖清楚的任务成功率高得多。把智能体先用在补测试、修小缺陷、加日志这类任务上，比直接交给它做跨服务迁移更现实。
把「未验证假设」当成重点防范对象。失败分类里这一类占比最高。在流程里加一道要求——智能体在动手之前，先列出它做了哪些假设、依据是什么。这一步能拦下相当比例的跑偏。
为回归准备护栏。任务要求智能体改动没被提及的行为时，回归是最难发现的失败。测试覆盖越完整，这类风险越低。上智能体之前，先把关键路径的测试补齐，收益往往比换模型更大。