「开源之道」 2026-11-05 搜集事件和材料

「开源之道」昨日阅读 · 2026-11-04

今天这份，落在同一条断层线的第五个剖面上：规则都写好了，为什么它管不住那些不在规则里的人。

① 先看一件本周最硬的事。 11 月 4 日，Michael Larabel 发现了一条被漏看的邮件列表事故：Synaptics 用律师函（cease and desist）逼停了一个开源 DisplayLink 内核驱动 Vino，仓库已从 GitHub 下线。这不是一次普通的下架——律师函的英文正文由 Synaptics 的 IP 主管亲自签署，逐条要求"停止一切开发、撤下所有已提交给内核维护者的补丁、交出所有提交与分发记录"；而收信人是一个没有任何法律代理的苏格兰业余开发者。

② 他一个人写了回信。 10 月 14 日那封 4 点抗辩里，他先顶住管辖权（“我住在苏格兰，按 1982 年《民事管辖与判决法》附表 4，要告我到苏格兰最高民事法院去告”），再打专利有效性——援引英国知识产权局自己的检索报告：那两件专利（GB2484736 / GB2485613）在 2011 年的审查检索里，分别有 7 篇和 6 篇文献以 X 类（单独破坏新颖性）命中，独立权利要求作为原始申请时全部被 X 类打穿，后来是加进"经通用数据网络传输"这一限定才获授权。最后他抬出 OIN：Synaptics 是 OIN 被许可方，他自己 2026-08-17 也成了 OIN 被许可方。

③ 这一条为什么重要。 它精确地展示了开源世界里**“防御性专利池"的边界在哪**：OIN 是一个只有几页纸的互不侵犯条款，它默认成员都是"Linux 生态里的公司”；当一家公司收购了一个不在 OIN 定义范围内的产品线（DisplayLink 2020 年 7 月并入 Synaptics），那些专利就悄悄掉出了池子——而池子的边界由谁解释、由谁举证，条款里没写。 律师函里那句最冷的话是："代码即便独立编写、逆向观察得出、免费分发或以开源许可发布，也不构成专利侵权的抗辩；开源许可证也无法授予 Synaptics 所持专利下的任何权利。"

④ 这跟今天的三篇论文其实是同一件事。 Foresight-SWE 说 agent 抓不住自己引入的缺陷（FRR 只有 6.13%–24.53%）；BOBA 说 agent 在链条上把"自己测试通过"当成了"正确"（链式完成率 51% vs 单发 95%），而它们被问到"这个实现对不对"时只对 53%；vLLM 的仓库则给出了组织层面的答案——39/40 个已合并 PR 上都有 Claude 机器人的评审记录，但那 39 条记录里一条 APPROVED 的效力都没有，最终把关的仍然是 35 个人类。三个独立研究加一次真实事故，指向同一句话：验证这件事，不能外包给被验证者的同类。

所以今天真正想说的是：开源这套制度，从来不是靠"规则写得好"运转的，是靠"有一个能承担后果的主体"运转的。 Synaptics 的律师函能奏效，不是因为它的法律论证更强，而是因为它有一个法务部、一封挂号信、和一个可以起诉的对象；而 Mike Lothian 之所以要自己写四点抗辩，是因为他这头什么都没有。同一周里，vLLM 用 163 行的 AGENTS.md 把 AI 贡献的边界写到了"纯 agent PR 不允许"，也把 pr-checklist 写成了 skill——那是把"能承担后果的主体"这个要求，明确地落在了提交者身上。GPQA 里的 53%、BOBA 里的 51%、Foresight 里的 24.53%，量的是同一件事：当某一环没有主体，这一环就只在统计上存在，不在制度上存在。 奥斯特罗姆的第八条原则讲监督，其实还有一句更少被引用的前置条件——监督者必须对受监督者有合法权威。机器没有这个权威；律师函有；一个署名的人有。

📄 最新开源研究论文

arXiv 通道说明：今日 mcp__arxiv__search_papers 共五次查询，全部正常返回、未报错、未回退 OpenAlex 充当 arXiv：①(cs.SE OR cs.CY) AND abs:"open source"（date_from=2026-10-29，宽口径 23 条）；②治理向叠加（4 条）；③供应链向（8 条）；④econ.GN / econ.TH / cs.CY 公地与治理向（33 条，has_more）；⑤coding agent × review / maintainer 向（15 条）。合计去重后约 60 篇候选。 去重核对：已比对 10-21 → 11-04 全部简报的 arXiv 编号全集（2610.03969、2610.24161、2610.28027、2610.34435、2610.34933、2610.36229、2610.36603、2610.37332、2610.37734、2610.38049、2610.38054、2610.38167、2610.38617、2611.02527）。候选中的 2611.02527（MCP 破坏性工具审批）为 11-04 已报道，直接剔除。今日入选 3 篇此前未覆盖的论文，全部经 get_abstract 核对摘要原文。 补充通道：OpenAlex 检索（open source maintainer governance license）返回 20 条，其中 1 条（Dmitrenko《Why Memory Components Fail》）本报 2026-07-03 已以索引形式收录（仅有一行摘要与一句点评，作者字段当时标为"待确认"），不重复纳入；其余命中为 2025 年旧文或与治理无关（区块链治理报告、英联邦报告、Ofqual 年报等），全部剔除。今日无制度经济学方向的新刊论文。

1. 编码 Agent 看不见自己引入的缺陷：Foresight-SWE 与 6.13%–24.53%

  • 标题：Do Coding Agents Catch Their Own Bugs? (They Don’t.)
  • 作者：Shaswat Patel、Michel Liao、Peter Henderson、He He、Valerie Chen（Princeton / NYU 等）
  • 链接：arXiv:2611.01181（cs.SE，2026-10-31 提交）
  • 摘要：需求文档里不会写明的问题——一个改动会不会引入可被利用的漏洞、会不会破坏下游假设——正是软件工程师必须预见的那部分。既有基准大多只测"当前任务是否完成"，不测"未来后果"。作者提出 Foresight-SWE：212 个样本、4 种语言、35 个流行开源仓库，每个样本由两个真实的 Pull Request 组成——后一个 PR 修的正是前一个 PR 引入的缺陷。核心指标 **FRR（foresight resolve rate）**定义为：既完成原任务、又避开后续 PR 指出的那个缺陷的比例。评测 11 个大模型，FRR 区间仅 6.13% 到 24.53%。
  • 为什么与开源之道相关：这是本报 10-28（GSoC 学徒制信号失真）、10-30（Anthropic 漏洞扫描 29,432→6,123→513）、11-01（CyberDual 攻击者 vs 审核者）那条"AI 抬高供给、不动核验"主线上的第四个独立样本——而它第一次把核验的对象从"别人提交的代码"换成了"自己刚写下的代码"。这个换法很关键：前三篇问的是"谁能看出别人的错"，这篇问的是"人看不出自己的错，机器能吗"。
  • 开源之道视角点评：24.53% 这个上界比平均数更值得记——最好的模型，在最好的情形下，也只能预见四分之一的自伤。这不是能力不足的度量，是**“自我审查"这个动作本身的结构缺陷的度量：审查的价值来自独立性，而自审的前提就是"我不是同一方”。开源之所以把 review 设成制度而不是建议，正是因为作者与审核者的分离不是流程偏好，是认识论要求**。另一个细节是它的样本构造方式——用"后来真的被修掉的那个缺陷"当标准答案，这让指标从"主观好不好"变成"历史有没有记账"。制度分析里最可信的信号，永远是已经留下的痕迹，而不是当事人在当下的自评。这条方法论，比论文结论本身更值得抄走。

2. BOBA：链式任务上从 95% 掉到 51%，还是 53% 的自我判断

  • 标题：Built on Broken Assumptions (BOBA): Why Coding Agents Cannot Be Left Alone
  • 作者：Alejandro Cuadron、Arpit Gupta（UC Santa Barbara）
  • 链接：arXiv:2611.02207（cs.SE / cs.LG，2026-11-01 提交）
  • 摘要：编码 agent 被当作"自主开发者"使用，会连续处理一串相互依赖的请求。现有基准却仍一次只测一个请求、只在人类写的代码上、只检查一次。作者构建 BOBA-Bench：140 个真实开源项目、280 条各含 20 个连续请求的链，评测 10 个编码 agent。结果：单独发请求时平均完成 95%，串成链后只剩 51%。原因不是代码写得更差——检查之后，agent 的代码作为后续请求的基础，几乎和人类代码一样好；根因是它们漏掉的错：agent 只要自己写的测试通过就宣告完成，而测试没覆盖到的错被下一个请求继承，后续请求失败率约为两倍；这个错很少被事后发现；让 agent 去"审阅代码是否正确"，判断正确率只有 53%，几乎等于抛硬币。反事实很干脆：在一次失败后给一句外部的"这不对"、再修一轮，链式完成率从 51% 升到 59%，且被修掉的错误不再污染后续请求。
  • 为什么与开源之道相关：53% 是今天最有分量的一位数——它给"用 AI 审 AI"这个正在全行业铺开的做法，标了一个接近随机猜测的上界。而这正是本报 11-01 在 CyberDual 里、11-04 在 MCP 破坏性工具审批里反复撞到的那堵墙：规则可以被写成两端都能解释为"不是我"的样子。BOBA 把这个结构讲到了最朴素的程度：agent 的"完成"定义，是"我的测试过了"，而不是"这件事成了"。
  • 开源之道视角点评：这篇的贡献与其说是"agent 不行"，不如说是把"验证"从"能力"里切了出来，单独定价。请注意那个 51%→59% 的增量：一句外部的否定，抵得上模型换代好几次。这就是威廉姆森讲治理结构时的核心权衡——当交易的资产专用性为零（模型随时可换）、不确定性极高（链条越长越不可控）、频率又极高时，理性的选择是把它内化进一个有责任能力的层级里，而不是继续在市场上买。开源的做法恰好相反：它把 review 这个环节外化成了一句"谁来都能说"的公共品，然后把成本摊给了极少数愿意说的人。这篇论文给出的数据说明，那句"这不对"值 8 个百分点——但没有人被付费去说它。另一点必须点破：BOBA 测的是 agent，读它的人却大多是维护者——同一份结论，在 agent 厂商那里是"再迭代一版"，在维护者那里是"又一批需要我当兜底的人"。评估结果的解读权，本身也是一种权力。

3. vLLM 自己的"可核查性"讨论：标签、审计与"没人读的标签"

  • 标题：A Gated Spec-Driven Workflow: An Audit-Trail Study of Coding-Agent Work
  • 作者：Rodrigo Figueiredo Abdo、Pedro Carvalho Brom
  • 链接：arXiv:2611.05094（cs.SE，2026-11-03 提交）
  • 摘要：Spec-driven development（SDD）要求编码 agent 从规格、计划、任务清单出发，而不是从聊天记录出发。作者研究了一套用于 Claude Code 的这类工作流，其中几乎每一个控制项，都是由被它约束的那同一个模型来执行的指令。用户必须逐阶段批准；一个 reviewer 子 agent 按每一阶段固定的缺陷清单检查产物；一个 executor 子 agent 只允许改动任务里列出的文件；每组任务结束后，orchestrator 跑一次文件清单检查，找未申报的改动。作者用7 个项目里的 9 个功能（从 Fortran 求解器、Python 程序，到书稿和论文本身）的全部日志与对话记录做审计：5 个功能完成了全部计划任务，581 个计划任务里完成 288 个；executor 的遵守极好——交付目录里只留下 1 处未申报改动，并且被检查抓到了；弱点在 orchestrator——它自己执行、自己评判自己的检查：247 次分块检查里记录到 11 次未申报改动（多来自作者当轮追加的请求与环境），但只中断了 4 次。
  • 为什么与开源之道相关：这篇论文本身就是一份**“制度自我审计"的样本**——作者审计的是自己写的论文的生产过程。而它给出的结论，恰好是本报 11-04 在 vLLM 里实测到的同一个结构的另一面：规则文本可以非常精良，而执行规则的那一环可能没有任何外部约束。今天 Project Pulse 的实测（见下）显示，vLLM 的 docs/contributing/labels.md 里写着一条极为清醒的自陈：“三个自动打标签的系统覆盖不到的标签，得靠人手动加，而实践中这意味着大多数时候根本没人加。”
  • 开源之道视角点评：我最想留下的是那个 11 比 4——检查发现了 11 次偏航，只中断了 4 次。“发现"与"处置"之间那道缝，是所有治理体系里最难堵的地方，也几乎从未被度量过。开源项目里同构的现象是：CI 红了没人管、标签打了没人读、issue 开着没人分诊——它看起来像是参与度问题，其实是**“发现"这一环已经有了自动化，“处置"这一环还靠人力，而两环之间没有强制连接**。另一句值得写进方法论笔记的是”几乎每一个控制项，都是被它约束的同一个模型执行的指令"：这句话本身就是对当下大量"AI 治理框架"的判决书——它们不是治理，是自我承诺的自动化。奥斯特罗姆的边界规则之所以有效，不是因为写在纸上，是因为越界会被别人抓住。这一点，与今天开头的 Vino 律师函是同一件事的两端：一端是外部主体有能力强制执行，另一端是内部规则完全没有外部执行者。

📰 开源动态摘要

  • 来源：Phoronix《Synaptics Appears To Use Legal Threats To Block Open-Source DisplayLink Driver》（2026-11-04）、Phoronix《Experimental, Reverse-Engineered & AI Assisted Rust Driver Targets Modern DisplayLink Hardware》、LKML 归档：Mike Lothian 2026-10-14 回函（含 Synaptics 2026-08-17 律师函及附件原文）
  • 摘要：Vino 是 Mike Lothian 开发的净室逆向、以 Rust 编写、部分由 Claude Code（Opus 4.8）辅助的内核 DRM 驱动，目标是把 Dell D6000 一类 USB 扩展坞里的 DisplayLink DL3 显示输出接进 Linux 主干——此前 Linux 侧只有 evdi 模块开放，真正与硬件对话的那部分是闭源二进制。Synaptics 自 2026-07-20 起多次联络未获实质回应后，由 IP 主管 Andrew Bateman 署名发出停止侵权函，援引其 全球 270 余件已授权专利、50 余件在审申请（其中英国境内 125 余件），要求：停止一切开发测试与发布、撤下所有已提交给内核维护者与邮件列表的补丁、公开列出所有发布/镜像/分叉位置、书面交代所有接收过材料的人与组织、保留全部开发记录（含与维护者的通信）不得删除、并在 8 月 28 日前出具遵守承诺书；函中明言”代码即使独立编写、逆向观察、免费分发或以开源许可发布，也不构成专利侵权抗辩；开源许可也不能授予 Synaptics 所持专利下的权利"。作者回函四点：①管辖权在苏格兰；②专利有效性存疑——英国知识产权局 2011 年的检索报告里，GB2484736 有 7 篇文献以 X 类命中原始权利要求 1–4、6–9，GB2485613 有 6 篇以 X 类命中全部原始权利要求 1–10，两件专利都是加入"经通用数据网络传输"这一限定后才获授权，而该特征在 1998 年 1 月的 RFB/VNC 规范里已有披露；③Synaptics 与本人均为 OIN 被许可方，要求对方指明排除 DisplayLink 专利所依据的具体条款或限制性选择（Limitation Election）及其日期；④函件本身未提出任何具体请求。现状：Vino 的 GitHub 仓库已不可公开访问，短期内不会有既开源又能进主线的 DisplayLink 驱动。
  • 开源之道点评：这件事的分量不在"又一个大厂压制开源驱动”（那是旧故事），而在它把"防御性专利池"的适用边界摆到了台面上。OIN 是开源世界里规模最大的专利互不侵犯安排，它的全部效力建立在两条默认上：成员是同一个生态里的公司、专利在加入时就已经落进池子。DisplayLink 2020 年 7 月才并入 Synaptics，其专利是否属于"Synaptics 的专利”、还是属于"Synaptics 的某个后来加入的关联实体"，取决于协议里那几个词的解释权和举证责任归谁——而作者在信里问的正是这个：请指出依据的条款，或你们做过的限制性选择及其日期。这是一个只有法律团队才能回答的问题，而他是一个人。 两层结构性事实需要分开说： 第一层是不对称——律师函的成本对一家上市公司几乎为零，对个人开发者是一次生存事件；函件要求的"保留全部证据、交代所有接收者、出具承诺书"这三项，本身就把对手拖入了一个只有专业法务才能安全穿过的流程。第二层更值得记：这个驱动是 AI 辅助写成的，而 Synaptics 的函件完全不讨论 AI——因为侵权判断与"谁写的"无关。这恰好和本周的论文互为注脚：当 AI 把产出成本压到极低，它在生产端带来的效率，会在合规端被原封不动地收回，而收回的方式与产出方式无关。效率的红利是局部的，责任是全局的。 最后一点是制度层面的：这不是"开源失败"，而是开源在硬件描述符不可得时的结构性极限——逆向是合法权利，但行使这项权利的成本不由权利本身决定，而由对方的法务预算决定。这跟我们此前记录的 CRA"开源管家"是同一个问题的两面：法律需要一个能被追责的主体，而开源的生产方式恰好没有这样的主体。

2. Anthropic 的 OSS Scanner：扫描免费，处理账单不免费

  • 来源：TechTarget《Anthropic’s open source vuln scans shift bottleneck to maintainers》（2026-10-30）、VentureBeat《6,157 findings reported, 516 patched》（2026-10-09）
  • 摘要：Anthropic 自 10 月 8 日起开放 OSS Scanner 报名，为符合条件的开源项目提供由其最强模型（含 Claude Mythos）执行的免费、周期性代码审计，每份报告带自包含复现器、漏洞说明，以及（若有）候选补丁。但报告完全由模型生成，不经人工复核或分诊，官方明确说明"报告可能不正确或无效"。规模侧：截至 10 月 2 日，模型共在开源软件中找到 29,432 个候选漏洞，Anthropic 人工复核分诊了 6,123 个，最终 513 个在上游被修补。受访专家的共识是负担转移：一位律所 AI 工程师的说法被广泛引用——"扫描是免费的，处理它发现的问题所需的时间不是。总得有人去复现、判断在自己的项目里是否真可利用、决定多紧急、再评审那个建议的补丁。即便是一个真漏洞，安全地修掉也要花相当功夫。“分析师的判据则更直接：“成功的衡量标准不该是发现了多少漏洞，而是有多少在攻击者利用之前被验证、排序并修复。”
  • 开源之道点评：29,432 → 6,123 → 513，这条漏斗是本报 11-04 已经记过的数字，今天需要补上的是它被行业内化之后长什么样：一个免费服务的定价权在提供方，而成本在接收方；当供给价格被压到零，接收方那边清理队列的时间就成了新的稀缺资源——稀缺没有消失，只是换了科目。值得注意的是 Anthropic 的口径已经诚实：问题不在"模型报错了多少”，而在"没有人有义务去分诊"。这与今天论文里的 53%、51%、24.53% 是同一条线索：验证这件事没有规模效应，它不能像代码生成那样靠加机器解决。 还要说一句不那么讨喜的话：这份服务对头部项目是净收益，对长尾项目是净负担。有专职维护者的仓库，多一条线索是好事；一个人维护的仓库，收到 20 条"可能有问题"的报告且每条都需要复现，等于又收到 20 个 issue——而本报 11-04 在 CPython 的记录里已经看到，一个项目积压 1,070 个超 6 个月未关闭的 PR 时，"没人管“不是态度问题，是没有哪个角色的 KPI 是把它们一条条看过去。免费扫描没有创造这个角色，它只是把队列变长了。

🔍 Project Pulse

vLLM（vllm-project/vllm，96,312 ★、24,402 fork、9,852 open issues，LF 托管，Project Leads 5 人）

选定理由：(a) 它是本报监控池里唯一一个把"AI 贡献政策"直接写进仓库根目录 AGENTS.md、并把检查流程做成 agent skill 的项目——治理文本与执行机制的耦合度是当前所有大项目里最高的；(b) 11-04 的 CPython 分析给出了"人力监督以’某人还有力气’为供给曲线"的样本，vLLM 则提供了另一个极端：监督已经部分自动化，两者可直接对照；(c) 今日论文（BOBA 的 53%、Gated Spec-Driven 的 11:4）正好为它的实测提供读数框架。

【L1 · 大版本发布】 发布节律稳定得近乎机械：v0.31.0（10-05）→ v0.32.0（10-18）→ v0.33.0（11-02），间隔 13 天、15 天，与 docs/contributing/release_process.md 明文写的”aim to have a regular release every 2 weeks“完全吻合；从 0.12.0 起 minor 版本号即代表常规发布，patch 只留给新模型与紧急修复。版本分支在发布前 1–2 天切出，cherry-pick 标准写成了白名单四条（回归修复、严重缺陷、上一版新功能的修复、文档），并明文”No feature work allowed for cherry picks"。这套写法值得记：它不是"从严审批"，而是把"什么算例外"提前定义好——本报 11-01 在 PyTorch 的 [no-ci] 前缀上看到的正是同一思路的另一半（例外必须留名）。

【L2 · 治理结构变化】 治理文本在四层上同时存在，且互不重叠：docs/governance/process.md 定义价值与层级（Project Leads = 事实上的 TSC，与 Linux Foundation 项目治理定义对接，每周例会分配工程资源）；docs/governance/committers.md 是名册即代码——75 名在任 committer（每人一行职责，如 @BugenZhao: Rust frontend、@hmellor: Hugging Face 集成与文档），18 名 emeritus，35:18 的卸任比例说明有通道；docs/governance/collaboration.md 规定重大特性先提 RFC、由 committer 提名 assignee、争议时指定 DRI；.github/CODEOWNERS 277 行按目录切分审核权。三处细节最像制度设计而不像文档：①labels.md 明文自陈"三个自动系统覆盖不到的标签，实践中基本没人手动加"，并给出加标签的三项硬条件（有受众、有 owner、有同 PR 内的规则），甚至提醒"模板里 labels: 必须写已存在的标签，GitHub 会静默跳过不存在的，任何地方都不报错"；②process.md 里那句"No one buys their way into governance. Committer status belongs to individuals, not companies"——这是对"公司赞助 = 席位"的显式否认；③collaboration.md 把与模型厂商的合作写成了流程：建私频道、建 org 内私有分叉、预发布权重不公开、按请求删除——开源公地与厂商保密之间的接口，被明确写成了合同而不是默契。

【L3 · 新人加入与社区活力】 过去 7 天新增 PR 1,129 个、合并 552 个、关闭未合并 79 个（合并/新增 ≈ 49%，关闭未合并仅占 12.5%——积压而不是拒绝，是这里的主要出口）；合并作者 276 人，头部一人仅占人类合并的 4.5%（对比 11-04 CPython：单一维护者占 33.7%）。这是一个真正去中心化的合并分布，与它 9,852 个 open issue、7,078 个 open PR 的规模放在一起看，含义很清楚：吞吐很高，队列更长。另需注意一处计量陷阱：GitHub 搜索把 vLLM 的合并 PR 全部计为非 bot 作者（552/552 无 bot），而实际评审端已经高度自动化——（今日实测，非估计） 在 11-01 以来合并的 315 个 PR 中抽取 40 个，逐个拉 /pulls/{n}/reviews：39/40 有 claude[bot] 的评审记录，3/40 另有 chatgpt-codex-connector[bot]，36/40 有人类评审，35/40 同时具备机器与人类评审，0 个完全没有评审。再抽查 11-03/11-04 合并的 10 个 PR：机器评审的时间戳普遍早于人类评审 6 分钟到 3 小时——机器先看，人后看，人决定。但关键的一步没有被让渡：机器人的评审状态全部是 COMMENTED，没有一条 APPROVED。合并按钮始终在人类手里（抽查到的合并者包括 WoosukKwon、DarkLight1337、ywang96、jeejeelee、zyongye、AndreasKaratzas 等 11 位不同 committer；自身 PR 自合并的情况存在但需要另一个 committer 的 APPROVED 在前，如 #65684、#65619 均由他人批准后本人合并）。

【开源之道判断】 这个项目的制度健康在变好，但变好的方式很值得警惕——它把"检查"自动化了，同时刻意没有把"裁决"自动化。 AGENTS.md（163 行，明写"breaching these guidelines can result in automatic banning"）的第一条硬规则就是"Pure code-agent PRs are not allowed. A human submitter must understand and defend the change end-to-end"，并要求 AI 辅助的 PR 必须自证"为何不与已有 PR 重复、跑了什么测试、模型评测结果、以及明确声明使用了 AI"。请注意这条规则和我们今天读的三篇论文的关系：BOBA 说 agent 的自测通过不等于正确（自判 53%），Foresight 说 agent 看不见自己引入的缺陷（≤24.53%），而 vLLM 的答案不是"让 agent 更努力地自审"，而是把责任明确挂回了一个能被追责的自然人，同时用机器去做它唯一做得好、且不需要承担责任的那件事——提出意见。 用威廉姆森的语言：它把 L3（治理机制）里最贵的那笔交易——判断——留在了层级内部（人类 committer），而把最便宜的那部分——初筛——外包给了市场（模型）。这与 11-04 CPython 的病灶正好构成对照：CPython 的问题是监督职能以"某人今天还有力气"为供给曲线；vLLM 的问题则是"机器给出的 39 条意见里，人类的采纳率无人统计"。 前者是供给不足，后者是反馈回路缺失。如果这 39 条机器评审从来没被评估过准确率，那它在制度上就还只是一个"看起来很忙"的角色——和 labels.md 里那句"实践中根本没人加"是同一类现象。真正该被量化的下一步不是"多少 PR 有机器评审"，而是"机器评审提出的问题里，有多少后来被人类确认、有多少被人类驳回"。没有这个数字，自动化就只是把一件没人度量的事，交给了另一个没人度量的角色。

📡 今日新来源发现

  • lkml.rescloud.iu.edu（Linux-Kernel Archive / Indiana University） · 邮件列表归档 · 发现方式：今日 Vino 律师函原文的唯一可公开访问载体 · 推荐理由：比 lore.kernel.org 更全——lore 对含 PDF 附件的邮件只保留元数据而不索引正文，本次法律函件全套（含 Synaptics 8-17 正函、10-05 跟进函、7–10 月往来、两件英国专利全文）均只在此归档可读；内核治理冲突的一手证据源 · 建议：加入（中置信，待人工确认）

说明：其余今日检索结果均为已在册来源（Phoronix、TechTarget、HKML、GitHub、arXiv、OpenAlex），无新增。未自动追加——上一条属"个体归档站"而非知名基金会，按规则留待人工确认。

署名： 「开源之道」·窄廊