[代码评测现状] SWE-bench之后，Code Clash与SOTA编程基准回顾——John Yang
[代码评测现状] SWE-bench之后，Code Clash与SOTA编程基准回顾——John Yang
摘要
- SWE-bench的商业重要性，始于Devin将一项沉寂的2023年10月基准测试变成代理竞赛。 Yang说，在Cognition发布“令人震撼”的Devin之前，市场几乎没有采用，发布前Walden曾发邮件称其“有个不错的数字”。如今这一生态已扩展至Pro、Live、多模态和多语言版本，后者覆盖9种语言、约40个仓库。Yang说，随着基于筛选的多样化和难度宣称不断增加，未来如何划分评测仍是开放问题。
- CodeClash衡量的是代理能否反复改进具有实际后果的代码库，而不只是一次性通过补丁测试。 2个或更多模型分别维护代码库，每轮进行修改，并在竞技场中竞争，通过反复对局评估持续开发能力。Yang的前提很明确：“我不喜欢把单元测试当作验证方式。”
- 编程评测正从单一排行榜变成按成本分层、按垂直领域展开的组合。 SWE-fficiency关注运行时间，同时保持单元测试通过；主持人将SciCode称为“更好的HumanEval”；完成式基准可以先于昂贵的多轮评测。METR使用VBench和“人类工作小时”框架，主持人则指出SWE-bench Verified可作为代理指标。Terminal-Bench、物理、网络安全、τ-bench和Vending-Bench扩大了评测范围，但主持人质疑用户模拟器可能只是在“采样一条路径”。
- 不可能任务可能成为评测系统的绊线，用来识别那些只会宣称完成、却无法判断失败的系统。 主持人提议在τ-bench中刻意设置不可能案例作为作弊标记，理论上任何Retail得分超过75分的模型都可能因此暴露；他还提到可能来自Anthropic的ImpossibleBench，该基准将SWE-bench Verified中的问题改造成不可能完成的任务。主持人说所有模型都尝试了这些任务并宣称完成；Yang认为这是一项重要基准。
- 更长时间的自主运行在技术上可以测量，但在商业上含义模糊，因为用户往往通过快速交互解决需求不明确的问题。 Yang设想让代理运行5小时，回来时得到一个“扎实的代码库”。主持人说，需求不明确使快速来回沟通更符合现实；Yang则警告，将自主运行推到24小时，可能只是噱头或存在性证明，而不是会改变行业的工作流。主持人更认可按任务匹配人机协作：想亲自操作时就保持介入，但例行的JSON解析可以交给代理后离开。
- 战略瓶颈可能是专有的人机交互数据和对代码库的理解，而不是又一套静态任务集。 Yang羡慕Cognition和Cursor拥有的使用轨迹，并说模拟器不能只是“ChatGPT，假装自己是人类”。他强调CodeClash可以作为测试平台，比较纯AI、多代理和人机团队；同时提到Cognition的“codebase retrieval plus”和自动化上下文工程。冻结代码库上的知识问答很容易饱和。
精读
1. Devin将SWE-bench从沉寂发布推向代理竞赛
- Yang将SWE-bench真正可用的版本追溯到2023年10月，当时几乎没有引起关注。Cognition后来发邮件告诉他有“一个不错的数字”；Devin的发布“令人震撼”，并“拉开了军备竞赛”。
- 如今这一系列已包括Live、多模态和多语言版本——覆盖9种语言、约40个仓库——以及一个完全独立的Pro项目。Yang说，虽然自己没有参与Pro，但不介意它沿用SWE-bench这一名称。多模态和多语言版本有意将仓库范围扩展到以Django为主的原有重点之外。
- Yang认为，各个独立split还能凭越来越复杂的筛选宣称难度更高多久，以及最终评测应由什么方向引导，仍是开放问题。
2. CodeClash让昨天的代码约束明天的代理
- CodeClash源于2点质疑：一是“我不喜欢把单元测试当作验证方式”，二是SWE-bench的实例在提交时彼此独立结束。Yang希望转向长周期开发，让每个模型的代码库在反复对局中持续产生实际影响。
- 2个或更多模型各自维护代码库，自由进行改进，然后进入竞争阶段，由竞技场判断哪一个更好。LLM裁判只是可能的机制之一，并非设计的全部。
- 初始竞技场使用Halite等现有编程游戏——“像是在玩StarCraft，但你可以写代码”（like playing StarCraft, but you can code）——包含舰队、资源、攻击和防守。目前的工作是搭建具有经济价值的竞技场，让CodeClash更接近现实世界的实用性，正如SWE-bench和Terminal-Bench所追求的那样。
3. 评测栈正按成本、领域和时间跨度分化
- Jeffrey Ma的SWE-fficiency修改代码库以提升运行速度，包括并行化等技术。Yang明确要求保持单元测试通过；主持人将目标概括为除运行时间改善外不改变行为。AlgoTune沿着相近的优化路线推进。
- 主持人将SciCode称为“更好的HumanEval”。更广泛地看，完成式基准可以作为低成本的第一步，再让模型进入昂贵的多轮评测。
- METR使用VBench，并以人类工作小时为框架，一条轴是运行时间，另一条轴是完成度。主持人也认可METR使用SWE-bench Verified作为其中一些测量的代理指标。
- Critical Point引入物理、SecBench网络安全以及覆盖更广环境的Terminal-Bench。τ-bench、τ²-bench和Vending-Bench则将讨论延伸到用户模拟，但主持人质疑单次采样路径究竟有多现实。
4. 不可能任务揭示模型是否知道何时停止
- 关于τ-bench包含需求不明确或不可能任务的说法，引发了Karthik的反驳。Yang理解这一担忧，但将其视为一个研究拆解：“问题出在歧义吗？还是……用户模拟器？”
- 主持人提出了更尖锐的方案：刻意加入不可能任务，作为作弊标记——“所有人在τ-bench Retail上都报告超过75分”，反而可以暴露他们自己。Yang认为这会“很酷”。
- 主持人提到可能来自Anthropic的ImpossibleBench，该基准将SWE-bench Verified的问题改造成不可能完成的任务。主持人说，所有模型都尝试了这些任务，并宣称“我做到了”（I did it）；Yang称其为一项关于拒答和识别不可能性的关键基准。
5. 真正的前沿是让自主性匹配人的意图
- 主持人预计SWE-bench还会出现更多变体。他称赞Terminal-Bench 2.0，并希望看到3.0和4.0，因为由人编写的环境比SWE-bench现有问题和拉取请求所代表的场景更能激发创造力。Yang讨论了增加更多人、非编程任务和非编程环境后可能带来的变化。
- Yang理想中的自主运行，是给代理一个宽泛目标和一个还算靠谱的验证器——哪怕目标是“打造一套最赚钱的代码库”——然后离开5小时，回来得到扎实的结果。主持人指出，需求不明确意味着必须快速来回沟通；Yang则警告，将自主运行延长到24小时，可能只是噱头或存在性证明，而非真正改变行业。
- 主持人更认可人机协作，而不是消灭人的参与。合适的抽象取决于任务：需要亲自操作时使用Windsurf，但例行的JSON解析则可以交给代理后离开。Yang基本认同。
- Yang呼吁获得更好的交互证据：学术界需要一个像LMArena一样能够持续产生一致使用数据的有吸引力的产品，或者需要比“ChatGPT，假装自己是人类”认真得多的模拟器。CodeClash可以在不同竞技场中比较纯AI、多代理和人机团队。
- Yang还强调Cognition的“codebase retrieval plus”，目标是帮助人类理解自己的代码库，并结合人和模型的能力；同时也包括面向LM的自动化上下文工程。他不确定，除了很容易饱和的冻结代码库知识问答之外，还能如何评测理解能力。