Senior SWE Bench：一个专注于现实未充分指定功能任务的新基准测试

# 高级 SWE-Bench 来源：https://senior-swe-bench.snorkel.ai/blog/2026-06-16-how-it-works 我们很高兴发布 Senior SWE-Bench，这是一个用于评估智能体扮演高级工程师能力的基准测试。Senior SWE-Bench 是开源的，并且兼容 Harbor。初始版本包含 100 个任务，其中 50 个保持私有以减轻污染。 ## 为什么构建 Senior SWE-Bench 随着更强大的智能体以及它们与 Slack、GitHub 等自然工作面的集成日益流行，我们大多数人已经像对待高级工程师一样对待智能体。我们期望它们能从消息或命令行提示中独立、得体地完成工作，而无需完整的规格说明。与高级工程师一样，它们需要具备对齐人类意图、开放式技术设计、复杂运行时调试以及良好品味的技能。 然而，现有的大多数基准测试把智能体当作初级工程师，提供过度具体的需求（尤其是功能任务），并且主要根据它们编写正确代码的能力（而非展示广泛技能）进行评估。Senior SWE-Bench 的目标是创建最可靠、最真实的评估，来衡量智能体履行高级工程师关键行为的能力： - 高级工程师在需求没有过度指定的情况下构建功能 - 高级工程师从行为报告中通过运行时调查解决 bug - 高级工程师在无需明确指示的情况下交付正确的代码 现有的大部分基准测试都有不切实际的过度指定指令，完全不像工程师可能在 Slack 上发送给后台智能体的信息。这主要是为了在行为和接口可能发生变化的环境中，便于预先编写的验证器。即使是最近使用更多行为验证器的基准测试，也受困于这种权衡，其任务指令可能看起来像完整的规格说明。我们通过引入一个验证智能体来打破这种权衡，该验证智能体能适应广泛的解决方案设计空间，同时仍然在运行时测试代码。 过去的基准测试也主要关注行为正确性而非质量，导致了 METR 的“许多 SWE-bench-Passing PRs Would Not Be Merged into Main”（https://metr.org/notes/2026-03-10-many-swe-bench-passing-prs-would-not-be-merged-into-main/）。Cognition 最近发布了 FrontierCode（https://cognition.com/blog/frontier-code），它通过仓库维护者自己设计的详细任务评分标准来评估智能体的代码质量。我们采取了一种更具可扩展性的方法，通过一个全局品味判断器，使用观察性和比较性信号来评估代码质量，在任务级评估保真度和可应用于任何任务的奖励机制之间进行权衡。 所有这些都与广泛、多阶段的质量控制流程相结合，该流程结合了专门的自动化评估和人类专家评审。一个基准测试的好坏取决于其任务的可靠性，我们希望确保 Senior SWE-Bench 衡量的是真实的信号。 现在我们来深入了解 Senior SWE-Bench 的设计！ ## 任务设计 我们的目标是构建真实且多样的任务，代表我们委托代码智能体完成的软件开发的广度。 ### 任务来源 任务基于真实仓库中的真实 PR，根据完成工程工作所需的技能进行选择。 - **近期真实世界的 PR**：Senior SWE-Bench 的任务来源于 2026 年 2 月之后在开源仓库中合并的真实 PR。我们聚焦于真实世界的 PR，以确保任务代表可证明的真实工作，并拥有来自仓库维护者的权威参考补丁。 - **多样化的仓库**：仓库涵盖广泛的类型、领域和年龄（参见“源仓库”部分（https://senior-swe-bench.snorkel.ai/blog/2026-06-16-how-it-works#source-repositories））。其中 50% 的仓库是在过去 5 年内创建的；这是为了捕捉更大功能、更现代技术栈的高节奏而做出的有意选择。 - **多 PR 范围**：任务（尤其是功能任务）可以通过将多个相关的 PR 分组在一起来创建，以形成真实的范围。 - **高级作者**：大多数 Senior SWE-Bench 任务基于由在相应仓库中有超过 100 次提交的工程师编写的 PR，我们优先考虑由仓库维护者编写的 PR 的任务。 - **复杂任务**：PR 会进行复杂度过滤，包括跨越服务边界的更改以及需要进行大量运行时调查的修复。请参见下面的任务类型部分。 ### 任务类型 Senior SWE-Bench 任务分为两个主要部分：设计并构建与调查并修复。设计并构建任务侧重于在没有完整规格的情况下设计功能和迁移的复杂性。调查并修复任务侧重于从行为报告中对棘手的 bug 和性能问题进行运行时诊断。 | 方面 | 设计并构建 | 调查并修复 | |------|------------|------------| | 任务类型 | 功能、迁移 | Bug、性能 | | 来源 PR 特性 | 复杂、多组件的功能和迁移 | 有运行时调查证据的 bug 和性能修复 | | 指令风格 | 描述所需更改，附带 PM 级别的用户故事 | 行为性的用户问题报告 | | 奖励机制 | 验证器、验证、评分标准、品味 | 验证器、评分标准、品味 | | 接口变更 | 可能涉及新的或更改的系统级接口 | 系统级接口不变 | | 所需技能示例 | 接口/API 设计、数据模型设计、架构重构、跨服务推理、框架熟练度 | 故障定位、日志/错误解释、本地部署、并发推理、查询优化 | ### 任务范围 我们将 Senior SWE-Bench 任务的范围与其他近期基准测试进行了比较，包括指令长度和参考解决方案大小。Senior SWE-Bench 的任务指令更自然地欠指定，并且覆盖了广泛的任务范围，从精确的 bug 修复到涉及多个服务层的功能。 ### 任务环境 任务环境通过克隆目标仓库、回滚到第一个任务提交之前，然后过期 reflog 并清理仓库来创建。主要的系统依赖（如 Python 或 Postgres）已预装，较重的个别库（如 PyTorch）也已预装。为了最好地反映一个后台智能体被放入开发沙箱中的性能，环境完整设置（如安装所需包和启动服务）留给智能体处理。因此，所有任务都设置 `allow_internet=true`。我们会进行轨迹分析以识别基于互联网的作弊行为，并计划在未来的版本中将互联网使用限制在特定的必需域名。 ## 奖励设计 Senior SWE-Bench 结合使用多种奖励机制来评估智能体在正确性和品味方面的表现。验证智能体和品味判断器将在接下来的部分深入讨论。 | 奖励机制 | 描述 | 用于设计并构建？ | 用于调查并修复？ | 执行代码？ | 基于 LLM？ | 用于正确性？ | 任务特定？ | |----------|------|-----------------|-----------------|-----------|-----------|-------------|-----------| | 验证器（预写） | 预写的行为测试（如 pytest、go test） | 是，必需 | 是，可选 | 是 | 否 | 是 | 是 | | 验证（自适应） | 由智能体编写的行为测试（使用专家设计的配方），适应提交的解决方案 | 是，必需 | 否 | 是 | 是 | 是 | 是 | | 评分标准判断器 | 由 LLM 评估的任务特定评分标准 | 是，可选 | 是，可选 | 否 | 是 | 否 | 是 | | 品味判断器 | 由智能体评估的全局代码质量评分标准 | 是 | 是 | 否 | 是 | 否 | 否 | ### 测试行为而非实现细节 验证器和验证测试是为了测试行为而非实现细节而编写的。这使得奖励分配对于不同的有效设计和微小的实现差异具有鲁棒性。只要可能，它们使用系统级接口，如 HTTP 端点、CLI 命令或渲染的 UI 组件。 那些主要使用完整规格指令测试编码技能的基准测试，能够从 PR 中直接收集单元测试作为验证器，因为这些测试针对精确指定的实现形状运行。而在进行行为测试时，验证器和验证测试必须从头设计，以在正确的系统接口级别编码正确的区分信号。当可用时，我们使用集成测试或系统测试作为灵感。 ### 测试明确和隐含的需求 高级工程师被期望以同时符合明确陈述需求（如来自 PM 的产品需求）和隐含需求（如在系统级框架内实现功能）的方式交付代码。Senior SWE-Bench 使用运行时奖励机制（验证器和验证）来测试明确和隐含的需求，这些需求通常分为三类。 | 需求类型 | 描述 | 示例 | 在指令中陈述？ | |----------|------|------|---------------| | 行为契约 | 任务指令中陈述的行为需求 | 对 API 添加新功能 | 是 | | 关键代码库实践 | 影响功能的强大且一致的代码库模式 | 新 API 端点需向现有认证框架注册 | 否 | | 一般最佳实践 | 对高级工程师显而易见且没有合理替代方案的做法 | 列出无界集合的 API 端点必须分页或限制 | 否 | 由于所有验证器和验证测试必须通过才算成功解决，因此需要特别注意确保尤其是隐含的需求确实是代码库强制要求或没有合理替代方案。智能体的轨迹会作为质量控制流程（https://senior-swe-bench.snorkel.ai/blog/2026-06-16-how-it-works#quality-control）的一部分，分析是否有不公平评分的迹象，并相应修改任务。 任何可能被认为是代码库明显或一般实践偏好（但不是关键要求）的内容，都被交由评分标准处理，其中单个标准失败不会阻碍成功解决。此外，无法在运行时测试的需求（如与外部服务的集成）被交由任务特定评分标准处理。我们希望对这些需求同样采取非阻断式处理，因为 LLM 判断器的可靠性低于运行时执行代码的方法。 ### 通过测试和失败测试 验证器、验证和评分标准都可以编码通过测试（pass-to-pass）和失败测试（fail-to-pass）。通过测试在预补丁代码库上成功，充当回归保护，确保现有行为继续工作。失败测试仅在成功应用补丁后成功，用于区分有效和无效的解决方案。 ## 使用验证智能体实现真实功能任务 对于涉及更改接口的任务（如功能任务），大多数现有基准测试被迫在真实指令（没有过度指定的需求）和可靠评估之间做出权衡。这主要是由于主要的奖励机制：预写验证器和 LLM 判断器。为了解决这个问题，我们引入了一个验证智能体，它使用专家设计的配方来编写适应被评估智能体解决方案的系统级行为测试脚本。 ### 验证智能体的工作原理 验证智能体的工作是编写适应求解智能体提交解决方案具体形状的行为验证器测试。验证智能体被提供了专家设计的验证规范，求解智能体无法访问该规范。验证规范包括要编写的测试集合、每个测试的编写配方，以及每个测试将运行的多个测试用例。在工作流开始时，验证智能体会审查提交的解决方案的实现细节，例如 HTTP 端点的响应结构，并据此编写验证器脚本。 Senior SWE-Bench 验证过程从头开始合成测试脚本（而不是编辑现有脚本），以便能够适应广泛的有效解决方案形状。这包括适应结构方面（如调用提交解决方案中实现的多步流程），而不仅仅是较小的重命名和参数化。 一旦验证智能体完成测试脚本的编写，它们将由相应的测试驱动程序（如 pytest、cargo test）以编程方式执行。然后，一个 LLM 判断器审查测试执行和测试脚本，并决定是接受脚本、写反馈进行修订，还是因验证智能体对齐问题而丢弃该试次（请参阅“确保验证智能体可靠性”部分）。在最终接受或丢弃的决定之前，允许一轮修订。最终分数由所有参数化测试用例的最终测试脚本执行决定。 ### 验证智能体允许更真实的指令 由于验证智能体被设计为适应广泛的有效解决方案形状，因此任务指令不需要像使用预写验证器时那样详细说明完整的接口和行为契约。因此，Senior SWE-Bench 的功能任务可以使用自然语言指令编写，描述所需功能，而无需达到真实世界智能体使用中不现实的规格级别。Senior SWE-Bench 功能任务指令由整体需求和一组行为需求（或用户故事）组成，类似于产品经理可能提供的内容。这些行为需求与验证测试相对应，并从验证规范注入到任务指令中。 举例来说，比较一下 Senior SWE-Bench 和 SWE-Bench Pro 中功能任务的指令。 示例说明：Senior SWE-Bench 的指令读起来像队友的消息；而依赖验证器的基准测试侧重于僵化、过度指定的需求。注意：Senior SWE-Bench 示例使用了与 SWE-Bench Pro 相同的任务源以进行比较；该任务不包含在 Senior SWE-Bench 中。 ### 确保验证智能体可靠性 我们采取了多重步骤来确保验证智能体的可靠性；如果实现得过于简单，可能会引入随机性、行为失配或假阳性/假阴性。 - **明确的角色定义**：验证智能体被赋予明确的测试工程师角色，其职责是忠实地实现测试程序，而不是修复解决方案中的问题。 - **专家编写的程序**：验证过程的骨干是验证规范，其中包含大量的程序和指南供验证智能体使用。它包含如何可靠使用测试夹具和工具的细节、在提交补丁中要寻找的模式，以及明确的测试步骤。 - **在 oracle 和 no-op 上测试**：为了确保验证智能体在任务上可靠运行，对于给定的任务，验证智能体在 oracle 补丁上运行 3 次，在 no-op 补丁上运行 3 次，然后该任务才被接受进入基准测试。如果 oracle 补丁上 `pass^3 < 1` 或 no-op 补丁上 `pass^3 > 0`，则任务被拒绝。也就是说，如果验证智能体不能始终接受已知正确的解决方案或始终拒绝已知错误的解决方案，我们拒绝该任务。 - **多个测试用例**：验证智能体编写的每个测试都是参数化的，并针对多个输入和期望输出对运行。这使得求解智能体或验证智能体更难硬编码正确答案。 - **判断器审查**：一个 LLM 判断器审查验证智能体的输出，并根据包含行为保真度和相对于验证规范的完整性的评分标准进行评分。还会运行机械的共谋检查。如果验证智能体表现不足，该试次将被丢弃。在实践中，少于 5% 的试次...