qwen-code 的 DSW SWE-bench Verified 发布流水线从 GitHub Release 触发到 500 实例基准评测的异步全链路设计【免费下载链接】qwen-codeAn open-source AI coding agent that lives in your terminal.项目地址: https://gitcode.com/GitHub_Trending/qw/qwen-code本篇技术指南以 docs/design/dsw-swe-verified-release-pipeline.md 设计文档为核心骨架结合仓库中的 GitHub Actions 工作流、一次性派发脚本与 Manifest 构建工具源码完整解析 qwen-code 如何把一次GitHub Release发布事件转化为一条「自托管 Runner 派发 → 持久化任务池调度 → Publisher 回写 Release」的 SWE-bench Verified 评测流水线。读完本文你将掌握这套流水线的触发过滤规则、隔离边界、组件职责划分、评分与隔离QUARANTINED判定逻辑以及如何通过workflow_dispatch手动执行单实例与全量验证。一、流水线定位一条与既有评测互不干扰的隔离实现该流水线是对如下端到端链路的独立实现GitHub Release - self-hosted DSW runner - short run submission - persistent Coordinator 10 Executors - Publisher - Release result设计文档开篇即强调两条硬性约束它不调用、不修改PR #7584 所引入的 workflow、service、state 或 result 标记DSW 侧的实现由内部独立仓库qwen-code-benchmark-dsw维护当前开源仓库中只包含GitHub 触发配置、Manifest 冻结脚本、派发适配器dispatch adapter与公开设计契约四部分。也就是说.github/workflows/dsw-swe-verified-release.yml 与 .github/scripts/dsw-swe-verified/ 目录是这条流水线在开源侧的全部可见面评测执行本体Coordinator、Executor、Publisher运行在自托管的 DSWData Science Workspace基础设施上。二、生产行为规则从发布事件到评分回写的完整链路设计文档对生产行为定义了严格的状态机与判定规则逐条梳理如下。2.1 触发过滤与不可变提交解析只有稳定的vX.Y.0Release才会从该 Release tag 指向的 commit 自动启动流水线patch 版本、prerelease 以及无关的 tag 家族一律跳过Release tag 会被解析为不可变的 Git commit保证后续评测针对的是确定代码版本在派发之前完整的 500 个 SWE-bench Verified 实例清单会被冻结frozen避免任务池运行期间数据集漂移。2.2 异步派发Actions 只负责下单自托管 runner 通过出站连接接收 Actions job一次性派发脚本负责冻结 Manifest并调用qwen-benchmark-pool submit创建 run 与初始任务Actions job 记录 pool 返回的run_id后立即结束不等待评测完成。这意味着即使 GitHub Actions 本身超时或被取消后台持久化任务池仍会继续执行完整评测。2.3 持久化执行Coordinator 10 Executors一个持久化的Coordinator与十个持久化的Executor共同处理 run每个 Executor原子性地认领claim一个任务同一时刻只运行一个 Harbor/Docker trialHarbor 的实时 trial 目录保留在本地 NVMe 上完成后的 attempt 产物再拷贝到 OSS不依赖 OSS 的 POSIX 权限操作规避对象存储无权限语义带来的兼容问题Executor 通过心跳续租heartbeat leases并以原子方式提交执行结果可重试的基础设施错误最多重试 4 次退避间隔分别为60、120、240 秒。2.4 Coordinator 的恢复与门控Coordinator 负责恢复过期租约、对账 run 计数器并应用 Manifest 完成门控与发布门控孤立的终端失败不会取消其余任务——单个实例失败不会拖垮整批评测。2.5 Publisher 与评分/隔离判定持久化的 DSW Publisher 监视进入终端态的 run并主动把公开结果 JSON 与逐用例轨迹归档回写writeback到触发该 run 的 Release只有满足以下全部条件才会写入正式分数全部 500 个实例均到达唯一终端态没有任何任务被取消EXECUTION_ERROR INFRA_FAILED 10分数公式为RESOLVED / (RESOLVED UNRESOLVED)分母只使用有效的 grader 结果无效的 grader 结果不计入分母一旦出现以下任一情况run 进入QUARANTINED状态只写状态与计数、不写分数终端错误达到 10 个或以上存在被取消的任务可计分用例缺失结果可计分用例缺失轨迹。这套规则保证了分数这个对外发布的数值具有严格的可审计前提任何不满足条件的情况都以 QUARANTINED 暴露而不是给出误导性的百分比。三、隔离边界六个维度的显式命名空间为避免与既有评测流水线互相污染设计文档为每个维度指定了独立标识维度标识Runner labelqwen-benchmark-dswWorkflow.github/workflows/dsw-swe-verified-release.ymlSuitedsw_release_swe_verified_v1PostgreSQL 数据库qwen_benchmark_dsw_release_v1Runtime 目录/mnt/workspace/qwen-benchmark-dsw-release-v1模型凭证/mnt/workspace/qwen-benchmark-dsw-release-v1/config/model.key属主root:github-runner权限0640OSS/mnt/data/qwen-benchmark/dsw-release-v1Release 标记qwen-code-dsw-swe-verified补充约束Docker 镜像层可以复用 DSW 宿主缓存但实验状态与产物不与其他基准流水线共享路径或数据表。值得注意的细节是设计文档声明的 runner label 为qwen-benchmark-dsw而仓库内工作流实际使用runs-on: [self-hosted, Linux, X64, qwen-benchmark-dsw-hk-eas]见 .github/workflows/dsw-swe-verified-release.yml。从源码结构看这是 EAS 部署形态下带区域后缀的 runner 标签部署细节由内部基础设施决定。四、GitHub Actions 工作流逐段拆解.github/workflows/dsw-swe-verified-release.yml 定义了整条流水线的开源侧入口共两个 jobrelease_gate触发门控与benchmark派发。4.1 触发事件与手动输入参数工作流同时监听release: published与workflow_dispatch两种事件。手动触发时支持以下输入输入名必填默认值可选值 / 说明release_tag是—接收结果的目标 test/prerelease tagqwen_release_tag否取release_tag指定要评测的已发布 Qwen npm 版本instance_limit是1SWE-bench Verified 实例数1/5/500instance_id否sympy__sympy-20590instance_limit1时的精确实例terminal_bench_limit是1Terminal-Bench 2.0 任务数1/89terminal_bench_instance_id否regex-logterminal_bench_limit1时的精确任务execution_backend是eas-smokeeas-smoke仅验证基础设施/eas-harbor完整执行工作流还声明了permissions: contents: read只读权限以及并发组dsw-swe-verified-release且cancel-in-progress: false防止并发发布互相取消。4.2 release_gateShell 实现的触发决策矩阵release_gatejob 仅在github.repository QwenLM/qwen-code时运行防止 fork 误触发在ubuntu-latest上用一段 bash 计算should_run及后续参数workflow_dispatch直接放行采用输入参数instance_limit1时透传instance_idprerelease 且 tag 匹配^dsw-eas-smoke-...以eas-harbor执行 500 实例用于演练生产级 EAS 链路prerelease 且 tag 匹配^dsw-eas-tb-smoke-...以 1 个 SWE 实例sympy__sympy-20590 1 个 TB 任务regex-log做冒烟prerelease 且 tag 匹配^dsw-eas-full-...以eas-harbor执行 500 实例全量非 prerelease 且 tag 匹配^v[0-9]\.[0-9]\.0$放行稳定版自动触发路径。默认后端为eas-harbor、默认全量 500 实例若判定不执行输出::notice::提示跳过原因。门控结果通过 job outputs 传给下游。4.3 benchmark15 分钟内完成派发即撤离benchmarkjob 依赖release_gate运行在自托管 runner 上timeout-minutes: 15。其环境变量覆盖了派发所需的全部上下文RELEASE_TAG、QWEN_REF、INSTANCE_LIMIT、BENCHMARK_INSTANCE_ID、BENCHMARK_IDEMPOTENCY_KEYdsw-release-v1-${{ github.run_id }}、GITHUB_RUN_URL、BENCHMARK_EXECUTION_BACKEND以及POOL_BIN、POOL_PYTHON、SWE_VERIFIED_DATASET_ROOT、BENCHMARK_POOL_DATABASE_URL等 DSW 侧路径与连接串。job 内三个步骤Checkout pipeline仅拉取 1 层深度的工作流源码Resolve release通过 GitHub API 拉取 Release 元数据校验非 draft若为 prerelease则从 Release body 中解析Benchmark-Qwen-Ref: version覆写行正则形如^Benchmark-Qwen-Ref:[[:space:]]*(v?[0-9]\.[0-9]\.[0-9](-[0-9A-Za-z.-])?)随后git fetch对应 tag 并用git rev-list -n 1解析出不可变 commit同时取回release_idDispatch to persistent DSW pool执行 .github/scripts/dsw-swe-verified/dispatch-release-benchmark.sh输出run_id与statusQUEUEDRecord dispatch receipt把 pool run、状态、SWE/TB 实例数写入 Actions step summary明确说明 TB 仅在 SWE Publisher 成功更新该 Release 后才派发。整个benchmarkjob 的哲学是**记录派发回执即完成**——评测本身由后台持久化任务池接管。五、一次性派发脚本参数校验、缓存预热与提交dispatch-release-benchmark.sh 是开源侧最核心的派发逻辑它完成四件事。5.1 输入合法性校验脚本先做强校验任何一项不满足立即以退出码 2 终止INSTANCE_LIMIT必须为 1500 的整数TERMINAL_BENCH_LIMIT必须为 1 或 89TERMINAL_BENCH_INSTANCE_ID仅在 limit 为 1 时允许BENCHMARK_MAX_ATTEMPTS必须为 18默认 4retry_backoff_seconds必须为非负整数默认 60execution_backend仅允许harbor、eas-harbor、eas-smoke。随后按后端检查必需路径pool_bin、python_bin、数据集根目录、TB 任务缓存等eas-harbor还会额外校验 ACR 镜像清单、EAS 模板、运行时上传器、Node/npm 二进制与 Docker 配置等。5.2 模型凭证与后端的隔离加载脚本对模型凭证做了显式分层eas-harbor模式下 source 的model.env只含OPENAI_BASE_URL与OPENAI_MODELAPI key 单独存放在 Executor 消费的 0600 权限文件中默认模型名为qwen3.7-max。5.3 Manifest 冻结与后端差异以make-manifest.py冻结 SWE-bench Verified 清单后按后端分支执行不同准备动作harbor调用prepare-agent-cache.py预热 qwen-code 版本与 Node/npm 运行时Nodev22.23.1、nvmv0.40.2为默认值eas-smoke仅运行validate-eas-templates校验模板与任务清单匹配不进入真实执行eas-harbor调用prepare-eas-agent-cache.py构建qwen-code-cache-version-nodegzip-v2镜像标签并上传 ACR 运行时产物。5.4 submit 参数与幂等设计${pool_bin} submit \ --idempotency-key ${BENCHMARK_IDEMPOTENCY_KEY} \ --suite dsw_release_swe_verified_v1 \ --dataset swe-bench/swe-bench-verified \ --dataset-revision 2 \ --task-prefix swe-bench/ \ --qwen-ref ${QWEN_REF} \ --qwen-commit ${QWEN_COMMIT} \ --model ${model_name} \ --manifest ${manifest_path} \ --max-attempts ${max_attempts} \ --retry-backoff-seconds ${retry_backoff_seconds} \ --infra-failure-threshold 0 \ --repository ${GITHUB_REPOSITORY} \ --release-id ${RELEASE_ID} \ --release-tag ${RELEASE_TAG} \ --github-run-url ${GITHUB_RUN_URL:-}要点--idempotency-key形如dsw-release-v1-run_id保证同一 Actions run 重复执行不会重复建 run--infra-failure-threshold 0与设计文档基础设施错误累计 10 才允许出分的门控相呼应返回的 JSON 会被严格校验必须包含非空run_id且匹配[A-Za-z0-9][A-Za-z0-9._-]{0,127}格式防止下游拿到脏数据。5.5 Terminal-Bench 2.0 的链式跟随脚本随后从版本化 ACR 缓存中的 tar.gz 构建 TB 2.0 任务清单并调用create-release-chain注册一条以-terminal-bench-2.0为后缀的幂等键的后续链路明确terminal_bench_statusPENDING_SWE_PUBLICATION——即 TB 只有在 SWE 结果成功写回 Release 之后才会被派发且 SWE 的 QUARANTINED 结果同样会触发 TB 跟随两者评分独立性互不影响。最终输出的dispatch-receipt.json记录了status: QUEUED、SWE 与 TB 的期望实例数、Qwen 版本与 commit 等审计字段。六、Manifest 冻结工具500 实例的确定性保证6.1 make-manifest.py.github/scripts/dsw-swe-verified/make-manifest.py 负责 SWE-bench Verified 清单的冻结扫描--dataset-root下所有目录名含__的实例目录严格校验必须恰好 500 个--instance-id仅允许配合--limit 1且实例必须存在于清单中输出 JSON 包含dataset、dataset_revision、expected_instances与排序后的instance_ids保证同一次提交的确定性。对应测试 make-manifest.test.mjs 覆盖了冻结 5 个排序实例、精确选择单个实例、全量 500 且 ID 去重、--instance-id与--limit冲突报错、未知实例报错、以及数据集不足 500 时提示Expected exactly 500.*found 499等路径。6.2 make-terminal-bench-manifest.py.github/scripts/dsw-swe-verified/make-terminal-bench-manifest.py 从 ACR 缓存的 tar.gz 归档中枚举tasks/name/instruction.md排除tasks/packages严格校验恰好 89 个任务输出schema_version: qwen-code-terminal-bench-2.0-manifest/v1的清单数据集记为terminal-bench/ revision2.0。七、组件边界六个角色各司其职设计文档用一张组件边界表明确了流水线的职责划分组件职责GitHub 自托管 Runner长驻的 GitHub job 接收器Dispatch / Pool submit一次性 run 与任务创建者PostgreSQL共享持久状态存储不是调度器Coordinator过期租约恢复、run 对账、完成门控Executors任务认领、Harbor/Qwen Code/grader 执行、心跳、结果提交Publisher终端 run 校验、公开结果与轨迹包生成、活跃 Release 写回其中 PostgreSQL 被明确标注为共享持久状态存储而非调度器说明调度决策逻辑集中在 Coordinator 与 Executor 的租约协议中数据库只承担可恢复的状态持久化。八、全量验证实录一次 QUARANTINED 的 500 实例运行设计文档记录了 2026-07-25 完成的隔离 prerelease 全量验证这是理解整套门控逻辑最直观的案例测试 Releasedsw-swe-full-async-poc-20260724-2c5ad4a5d0-r3GitHub Actions run30079405895Pool runpool-31a24bc8acca49d2数据集swe-bench/swe-bench-verified2500 个冻结实例执行10 个持久 Executor每实例至多 2 次尝试被测版本Qwen Codev0.20.0-nightly.20260722.b98306b7e模型qwen3.7-max墙钟耗时约12 小时 27 分钟结果分布332RESOLVED、107UNRESOLVED、56EXECUTION_ERROR、5INFRA_FAILED有效 grader 覆盖率439/50087.8%有效结果上的诊断解决率332/43975.6%运行状态QUARANTINED未发布官方分数公开 JSON500 条记录、500 个唯一实例 ID该次运行完整验证了异步派发、任务池执行、严格隔离与 Publisher 写回的全链路但它不是官方模型分数61 个实例缺少有效 grader 结果且运行中的 Executor 池在一次源码热更新后保留了旧的错误分类器。设计文档明确给出干净重跑的硬性前提——固定 worker commit/digest并重启做过版本校验的 Executor。九、分支验证与手动触发实践设计文档给出的本地验证路径是从目标分支使用workflow_dispatch手动触发并指向一个隔离的 prerelease自动的release.published触发则被刻意限制在稳定vX.Y.0。手动触发一个测试 prerelease 时可在 Release body 中写一行覆写指令Benchmark-Qwen-Ref: v0.20.0-nightly.20260722.b98306b7e该行会让评测使用已发布的 Qwen npm 版本而结果仍写回隔离的 POC Release。此覆写仅对 prerelease 生效正式 Release 永远评测自身 tag。实操注意事项手动验证默认只跑 1 个实例instance_limit1以控制时间与模型成本5 实例与 500 实例的运行不会透传单用例instance_id两种触发方式都是异步的Actions 记录派发回执即结束不会为评测全程保活workflow_dispatch保留用于显式诊断与重跑配合execution_backendeas-smoke可只校验 EAS 基础设施链路而不消耗真实评测额度。十、总结DSW SWE-bench Verified Release Pipeline 是一套以异步、隔离、可审计为设计原则的基准评测基础设施GitHub Actions 只负责门控与派发持久化任务池负责执行Publisher 负责把结果回写为 Release 资产严格的评分门控全部终端态、无取消、基础设施错误 10与 QUARANTINED 兜底机制保证了任何不完整的结果都不会被包装成分数发布。对关注 qwen-code 评测方法与质量体系的开发者而言仓库内的 设计文档、工作流、派发脚本 与 Manifest 工具 构成了从设计契约到可执行代码的完整闭环是理解该评测流水线的最佳起点。【免费下载链接】qwen-codeAn open-source AI coding agent that lives in your terminal.项目地址: https://gitcode.com/GitHub_Trending/qw/qwen-code创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考