2024 年，编码智能体在 SWE-Bench Verified 上的表现让所有人屏息——从「能写 Hello World」一路冲到「能独立解决 GitHub Issue」。但演示归演示，把它真正部署到企业仓库时，工程团队撞上的第一堵墙不是模型不够聪明，而是评测本身落后于模型进化。
公开基准已饱和，私有评测才是入场券
早期模型在 SWE-Bench 上只能解出 1% 到 2%，头部模型接入工具链与多轮检索后，得分快速向高分段靠拢。当一个基准被头部模型稳稳刷到高分段，它就失去了区分度——你很难再从分数上判断模型 A 比模型 B 强多少，差异可能落在 prompt 抖动的误差带里。
更关键的是，企业仓库的真实 PR 远不是「单文件、单语言、有明确报错」——它夹杂历史 commit 风格、跨服务依赖、CI 红绿灯。把公开基准数字直接外推到自家仓库，落差往往以十倍计。
可合并性：演示到可交付的关键维度
行业由此引入新的生产维度——可合并性（mergeability）。判定标准很简单：智能体产出的 patch，能不能被人类评审者几乎原样点下 Merge 按钮？「能不能跑通测试」只回答了「逻辑对不对」，「能不能合并」还要回答「风格对不对、边界对不对、能不能维护」。
围绕可合并性，业界形成了双层评分：第一层跑回归测试过滤明显跑不通的 patch；第二层让 LLM 作为评审员模拟人类代码审查，按可合并度打出 0 到 1 之间的连续分。这套评分又反过来成为路由器的输入。
路由比模型聪明更重要
路由与并行这条线，工程团队普遍采用 microVM 隔离加 Sidekick Agent 并行的组合拳：每个候选 patch 跑在干净的 microVM 里互不污染环境，多个 Sidekick 副本同时尝试不同方案，最后由路由器挑选可合并性最高的那个。
真正决定一条流水线能否上生产的，往往不是「模型够不够聪明」，而是「路由器愿不愿意否决它」。一个敢于把 70% 的 patch 直接丢进垃圾桶的路由器，长期看比一个「尽量放行」的路由器更省钱，因为它把宝贵的 reviewer 注意力集中在了真正值得人类花时间的 30% 上。
对出海独立开发者的启示
选 Coding Agent 时不能只看公开基准排名。要看评测体系六个月前的分数表和今天的分数表，看题库本身是否在持续扩充——题库不更新的评测，半年内就会变成荣誉墙。
更实操的做法是把选型流程从「看 demo」升级到「用内部仓库跑 50 道定制题」，而这 50 道定制题本身就是企业不可复制的护城河。对小团队来说，哪怕只针对自己项目跑 20 道定制评测，也比看排行榜数字更能预判生产表现。
来源：掘金