整队做对只有 8/324：百度用可执行关系测合并队列

整队做对只有 8/324：百度用可执行关系测合并队列

百度的 BulkPR-Bench（合并队列治理基准）不把「修好一个工单」或「按固定顺序改完一条链」当成编码智能体的总分。队列里的拉取请求会互相卡住。智能体要自己判断哪些该合并、哪些该拒绝、按什么顺序合，交出去的是执行器真正接受的计划，不是模型自己声称的计划。

一、为什么一个一个合仍可能整队不安全

仓库级评测已经很多，但一道题通常只有一个目标：SWE-bench 修一个工单，SWE-STEPS 和 ChainSWE 走固定的改动链，代码评审也是一次看一个拉取请求。链可以变长，成员和顺序却是题目给定的。真实合并队列不是这样。并行改动会在语法或语义上打架，也会出现依赖、重复、互相替代，以及必须一起合、否则都不要的组。按到达顺序逐个过公开持续集成，树可以是绿的，却仍然合进一组过不了隐藏检查的改动，或者把只有一起才成立的改动拆开拒绝，或者合进去的安全改动比联合规划更少。

BulkPR-Bench 把这件事叫做队列级拉取请求治理：找回有后果的关系，选出要合并的子集，再排成仓库执行能通过的顺序。每道题是一份冻结的仓库快照，加上 N 个新写的候选拉取请求，按批大小 K 放出来。智能体提交原子合并提议、延期，以及一份可以改的关系账本。计分看执行器接受后的真实轨迹。隐藏验证器、用执行核对过的标准关系图，以及精确的安全子集最优解，都留在计分一侧，不给智能体看。

二、题怎么造、怎么判

全套 581 个候选拉取请求，18 个仓库各一个池，语言是 Python、Go 和 TypeScript/Node/Bun。这些不是历史上真的开着的拉取请求。历史拉取请求和专家意见只用来想题，源码差异一行都不复用。每个候选都对着同一份钉死的基线新写，并且必须能干净地打上去，这样子集和顺序才能随便组合。仓库按工程还在活跃、构建和测试能复现、许可证清楚来选，不按热度。

另有 595 个历史拉取请求只做对照，不是配对样本。先取每个仓库的中位规模，再取 18 个仓库的中位：历史参考是 3 个文件、49.3 行差异，造出来的候选是 2 个文件、20.5 行差异。关系类型的搭配是故意设计的，不代表真实队列里这些关系有多常见。

标准关系图只有在符号预测和仓库行为一致时才收下。一个状态就是把有序的一组差异打到快照上。约束预测器给出该绿还是该红，执行门再真正打差异、跑冻结的测试范围。登记的证据覆盖每个关系组件里的全部非空子集，再加上整池见证和一些跨组件探针，并不枚举全部 2 的 N 次方个全局子集。对不上就整池作废。打补丁失败和基础设施失败另算，不能拿来冒充「预期为红」。

公开测试看不见的关系，在造题时绑一个隐藏验证器：在登记的基线和阴性对照上通过，在目标状态上失败。正式评测对冻结的全量标准约束计分，不是每提一次案就重跑隐藏验证器或全套测试。精确求解器给出 OPT_N，也就是在冻结约束下最大的安全子集，并另做拓扑检查，确认这个见证集合存在可执行顺序。登记状态会跑两遍，第二遍绕过缓存；求解器重算 3 次。

滚动协议里，队列按冻结的到达顺序，每批 K 个放出来，最后一批可以不足 K。还没轮到的批次不在智能体看得到的文件树里，但工作区和会话保留，所以 K 改的是同时能看见多少，不是记不记得。缓冲协议下，跨批最多留下 B 个未决候选，每个最多跨过 T 个批次边界，而且延期必须续上。主实验取 B=4、T=16、K=32。不延期协议里，候选必须在到达的那一批里合并或永久拒绝。

每一批，智能体交有序合并列表、与之不相交的延期集合，以及更新后的关系账本。这一批里既没合并也没延期的，永久拒绝。合并列表被当成一个原子提议。公开门通过，就按提交顺序把受保护的差异打到权威主干上，整份提议一起提交。公开门拒绝，这份提议里的成员一个都不收，并离开队列；另外延期的仍可留下。执行器不修补失败提议。公开门是绿的、但违反隐藏标准的提议会留在真实计划里，由计分惩罚，不回滚。决策格式坏了或缺失，这一批按空动作推进，整次运行记为无效，后面的批次仍会放出。

关系账本区分七类：成对冲突、高阶冲突、依赖、必须全有或全无的组、必须拒绝、重复、替代。主指标只有关系交付分（RDS，按关系组给安全交付和正确拒绝计分）。它不把「合进了多少个没有关系约束的拉取请求」算进排名。全局安全门控产出（Global-SGY）另算整队计划是否严格可部署，不和 RDS 相加。一次运行无效、没做完、不安全或不可执行，Global-SGY 就是 0。

RDS 的分组方式：共享拉取请求的约束合成一个连通块，孤立的「必须拒绝」单独成组，没有任何关系约束的候选不进 RDS。组内安全且顺序可执行时，得分是实际收下的人数除以该组最优人数；最优人数是 0 时，一个都不收才得 1，收了就是 0。一组失败不会把其他组抹掉。组在一次运行里等权，三次运行先在仓库内平均，再对 18 个仓库等权宏平均。比最优解还大的安全集合当成工件错误剔除，不截断。

精确完成更严：运行有效，真实计划的规模等于整池最优，而且提议过的合并没有落空。RDS（隐藏）只在含有公开持续集成看不见的约束、且最优人数大于 0 的组上算，覆盖 17 个仓库，langgraph 没有合格组。关键关系召回按「漏掉它就会让最大安全集变不安全」的程度加权，类型、成员和方向都要精确匹配。

实验把 6 个模型接到同一个冻结的 Claude Code v2.1.138 脚手架上：Claude-Opus-4.8、DeepSeek-V4-Pro、GLM-5.2、GPT-5.4、Kimi-K3、Qwen3.7-Max。运行时、150 轮交互上限、通用指令和账本格式都相同。每个模型每个仓库单独初始化跑 3 次。基础设施失败会重跑；用尽 150 轮算模型失败，记 0。换提示、换账本、换到达顺序、喂标准答案，都不进主排名。

基线有三个，都只看公开信息、按冻结到达顺序、每个仓库一个确定结果、看不见隐藏验证器。Merge-Queue 扫一遍并拒绝公开门失败的。CI-Fixedpoint 在主干变化后重新看被拒绝的。Batch-Greedy 在批内尝试、不延期。Merge-All 把放出的一批当成一个原子提议。No-Op 什么都不合。喂标准关系的 Gold-fed，以及拿到全部标准关系的确定性 Solver，只做诊断，不参与排名。

区间是仓库级的。18 个仓库均值做 10000 次偏差校正加速自助法，描述的是这 18 个池之间的差别，不是同一次运行的抖动。基线是固定套件上的点估计。论文写明这不是概率样本，区间不能外推到仓库总体。

五个池的 N 是 33，所以 K=32 仍看不见最后 1 个。K=32 是信息最多的工作点，更小的 K 用来看滚动可见性。Gold-fed 每个模型每个仓库只跑 1 次。

18 个池如下。N 是候选数，OPT 是整池最优人数，原子数把孤立的必须拒绝也算进去，隐藏比例是公开测试套件看不见的原子占比。

三、数字：关系组分高，整队几乎做不对

下表是论文 Table 3 在缓冲协议、K=32 下的结果，按 RDS 排序。方括号是仓库级 95% 自助区间。精确完成写的是成功次数除以运行次数，模型是 54 次，基线是 18 次。最好的加粗只在原文表格里，这里不标。

六个模型里有三个的 RDS 高于所有顺序基线：Claude-Opus-4.8 为 66.6，GPT-5.4 为 62.0，GLM-5.2 为 57.9，最强基线 CI-Fixedpoint 为 53.1。另外三个从 40.9 到 49.4，DeepSeek-V4-Pro 和 Qwen3.7-Max 在 K=32 的缓冲设置下仍低于三个顺序基线。整队指标分开看：GPT-5.4 的 Global-SGY 最高，也只有 13.0；三个顺序基线都是 0.0。324 次模型运行里只有 8 次精确完成整队，没有任何一个仓库的三次重复全部完成。3+2+1+2+0+0 等于这 8 次。

关键关系召回从 35.2% 到 57.7%。在 12 个「模型 × 协议」格子里，智能体对自己明确记下来、并且还能评估的关系，遵守比例是 98.1% 到 100.0%。记得住的大体会照做，没记下来的才是大头。把已经看见的候选所诱导的标准关系喂回去，六个模型的 RDS 落到 77.5% 到 99.1%，比各自的智能体 RDS 高 22.3 到 50.2 个百分点。论文没有给出每个模型喂答案后的单独数字，并写明这是诊断空间，不是因果拆分：全知求解器还换了信息视野和决策者。

批越大，观察到的平均 RDS 大体越高，但模型和延期策略不一样。缓冲下 K=32 比 K=1 六个模型都高，幅度 0.1 到 19.1 个百分点。Claude、DeepSeek、GPT、GLM 至少高 11.7。Kimi-K3 的峰值在 K=8，Qwen 几乎平。K=32 时拿掉延期，GPT、GLM、Kimi 上升，Claude、DeepSeek、Qwen 下降，变化从加 3.7 到减 16.6。图里没有逐个 K 的表，这里不补。

324 次运行的结局互斥：226 次以不安全合并结束，占 69.8%；59 次什么都没合，占 18.2%；27 次交出非空且可部署的计划，占 8.3%，其中包含那 8 次精确完成；12 次没有有效计划，占 3.7%。可部署要求非空且安全。什么都没合是门都过了但没有交付。没有有效计划包括无效、不完整或整队门失败，这些运行里没有出现不安全提交。

四、限制

证据拆不开单一瓶颈。关键召回不全、喂标准关系后 RDS 更高，说明缺关系信息，但不能把它和选子集、排序、看反馈后改计划、拒绝分开。批大小和延期同时改变可见性、时机、反馈和可否重改，曲线是配置敏感，不是可见性的因果效应。

581 个候选是 18 份快照上各设计出来的一个池。关系搭配和自助区间都不代表自然队列的频率、别的项目，或同一仓库内部的波动。只数人数、组与组等权的 RDS，不含业务价值、紧急程度、评审成本和伤害轻重。通过指的是钉死的测试、隐藏验证器和登记的全量标准，不是生产正确性。六个后端共用一个脚手架、一套提示、一种账本、一种到达顺序和 150 轮上限，换设计结果可以变。每格 3 次跑不完运行之间的波动；Gold-fed 每格只有 1 次。

正式评测前，候选差异、标准答案和隐藏验证器不公开。文中写将在版本化工件里放出池、验证器、计分器和协议，代码准备用 MIT，构造出来的标注和任务差异准备用 CC BY 4.0，上游快照仍跟原仓库许可证。本文不把这个仓库当成已经可以复现。发布之后直接污染的风险会变，以后的评测必须带上带日期的发布版本。分数不支持对开发者人群下结论，也不该拿去无人值守地合生产代码。评测在隔离容器里跑。

PDF 页眉写的是 KDD 2027 年 8 月 1 日至 5 日。可核验的首发日期是 arXiv v1 的 2026-08-03，本文用这一天，不用会议计划日期。

出处：百度，Zetong Xiong、Qiao Zhao、Jun Zhang、Xueying Lyu、Zhi Li、Yixiang Tu、Xiaowen Yang、Yunjie Zhang、Yufeng Wang、Zhe Zhang、Kaize Yu、Hanwen Du、Zhongkai Sun、Zhuoxin Liu、Zekun Lin、Jianwen Yang、Ruining Chen、Ying Zhang、Tingxuan Pan、Ke Chen、Shubin Han、Chuanhao Sun、Yehua Yang，《BulkPR-Bench: Benchmarking Queue-Level Governance of Interacting Pull Requests》，2026-08-03，https://arxiv.org/abs/2608.02685