「开源之道」 2026-09-21 搜集事件和材料

「开源之道」 2026-09-21 搜集事件和材料

今日开源制度观察（2026-09-21）

今日最强征兆

1. OSI 官方博客《Open Weights Are Good. Open Source Is Better.》（2026-09-16）——OSI 首次官方区分「开放权重」与「开源 AI」，把两条路线的制度分野正式化

   • 制度层：Property-Rights / Commons-vs-Club-Goods / Institutional-Environment
   • 证据：opensource.org/blog/open-weights-are-good-open-source-is-better · HN 40 pts · “Open Weights Are Good. Open Source Is Better”
   • 初步判断：OSI 副主席 Katie Steen-James 撰写，是 OSI 在「开放权重 vs 开源 AI」论战白热化时第一次以官方口径明确表态。核心命题：「开放权重允许部分自由，但不完整」——开放权重让你能运行、微调、微调，但没有训练数据 + 没有训练代码 = 不能完整研究模型，因此不能完整审计行为、不能完整复制、不能完整 fork。OSI 用开源的「四种自由」（use / study / modify / share）作为判定标准，把 open weights 定位为「四种自由的部分实现」，把 Open Source AI（按 OSI OSAID 1.0）定位为「四种自由的完整实现」。这是开源 AI 的定义权首次由开源组织官方行使——过去半年 open weights 的合法性主要由大厂（Meta、Mistral）和国会讨论驱动，OSI 的这次表态把讨论锚定回开源社区本身。
   • 开源之道视角：适兕在 09-01 收录的 arXiv 论文《You Can’t Open an LLM With a Screwdriver》曾经以论文形式提出「open weights 不是开源，是特许工程代码的 AI 版本」——今日 OSI 官方博客从制度侧面给出了几乎相同的判断。这是「开源作为制度契约」命题在 2026 年最重要的官方化落地：定义权（什么是开源）从社区实践（OSI Approved List）扩展到 AI 时代的模型定义（OSAI），OSI 选择扩展而不是回避。真正的开放问题：OSI 的这套「四种自由 + OSAID 1.0」框架在多大程度上被产业采纳？如果只有 OSI 自己承认 Open Source AI 与 open weights 不同，而产业继续用 open weights 一词指代所有开放模型，OSI 的定义就会成为制度剧场——制度文件存在但现实不改。
   • 后续观察：(1) Meta（Llama 4）、Mistral、DeepSeek 是否响应 OSI 的「开源 AI」定义，或者拒绝承认这一分类；(2) LF AI & Data、Hugging Face 是否把 OSI OSAID 1.0 作为模型发布的分类标准；(3) 国会 AI 立法是否引用 OSI 定义作为「open source AI」与「open weights」的法律区分；(4) 中国大厂（阿里、商汤、字节）是否会用「开源」一词指代 Open Source AI 而避开 open weights 分类。
   • 误判风险：OSI 官方博客是一次制度声明，不是产业共识——如果没有产业响应，OSI 的定义可能停留在社区话语层；OSI 的「开源 AI」门槛（训练数据 + 权重 + 代码全公开）在实践上非常高，可能只有极少数模型符合；政策制定者可能选择继续用「open weights」作为唯一分类，把 OSI 的区分视为过于严格。

2. arXiv 2609.20490 · TeamCAMS: An Open-Source Research Platform for Studying Human Behaviour in Human-AI Teams——人机协作治理从隐喻走向可测量实验

   • 制度层：Governance / Meritocracy / Path-Dependence
   • 证据：arXiv 2609.20490（2026-09-17，ETH Zurich / EPFL / HSLU / TU Wien）
   • 初步判断：作者团队（Brocco / Chavaillaz / Sonderegger / Sauer）发布 TeamCAMS（Cabin Air Management System）——一个开源的多人控制仿真平台，用于研究「人在环 AI 团队」的心理学问题。平台模拟了自动驾驶舱的控制环境，让研究者能够测量：不同自动化形式下的心理模型变化、自动化可靠性对信任的影响、压力对多任务表现的影响。论文是软件发布文章（JOSS 类），重点是如何用开源工具把「AI 治理」这个抽象概念变成可测量变量。这个方向的重要性在于：AI 治理研究过去主要靠文本分析（政策文档、企业声明）或者事后案例（事故复盘），TeamCAMS 提供了一个事前、可控、可重复的实验平台——这是「AI 治理研究基础设施」从零到一的第一个成熟样本。
   • 开源之道视角：适兕「思想是制度的源代码」在这里得到方法层面的呼应——「人机协作」这个思想能否转化为制度，取决于是否存在可测量的实验基础设施。过去我们讨论 AI agent 治理（AGENTS.md、systemd canary、AAIF）都是在「事后治理」层面打转，TeamCAMS 提示了一个新方向：治理研究需要从「描述性」走向「实验性」。这与 09-20 收录的 arXiv 2509.16295（用 NLP 分析 GOVERNANCE.md 演化）形成互补——2509.16295 是描述性方法，TeamCAMS 是实验性方法，两者合起来才构成「治理研究」的完整工具箱。开源在治理研究中的角色不只是「被研究的对象」（研究 GOVERNANCE.md），也是「研究方法的基础设施」（开源仿真平台）。
   • 后续观察：(1) TeamCAMS 是否被 AAIF、LF AI & Data 采纳为标准研究工具；(2) 是否有后续论文把 TeamCAMS 的结果与真实生产环境对照验证；(3) 中国是否有同类开源人机协作实验平台（如商汤、华为的类似研究项目）；(4) 平台是否开源到允许修改的程度，还是停留在「源代码可见」的 open weights 式开放。
   • 误判风险：TeamCAMS 是学术平台，样本量与外部效度需要长期实证；仿真环境可能无法完全对应真实生产场景（sim-to-real gap）；论文是软件发布性质，尚未包含实际研究结果。

3. arXiv 2609.19607 · DeltaSelect: Affordable A/B Testing for Coding Agents——AI Agent 评测的开源经济样本

   • 制度层：Transaction-Cost / Coase-Boundary / Meritocracy
   • 证据：arXiv 2609.19607（2026-09-17）
   • 初步判断：作者 Nicholas J. Conn 提出 DeltaSelect 开源方法，解决 Coding Agent（AI 编程助手）评测的核心经济问题：完整基准评测成本太高，只跑一次的单次结果方差太大。方法有三步：(1) 通过 resampling 分析 DeepSWE 基准，找出 113 个任务中只有 19.5%（22 个）的任务单次运行结果与完整基准相关性 ≥ 0.5；(2) 用线性回归把分数化的验证结果映射到统一评分；(3) 在给定预算内选择固定任务集做 baseline-vs-candidate 对比。这是AI Agent 评测基础设施经济学的第一份开源经济样本——用最少资源获得最大信息量，是开源经济学的经典命题在 AI 领域的具体化。
   • 开源之道视角：适兕的「慢聚漫奏（求兴）vs 效率求生」命题在这里有精确的对照——完整基准评测是「效率求生」的产物（把评测做成完整系统、追求覆盖度），DeltaSelect 是「慢聚漫奏」的思路（承认不完美但追求可负担、可迭代）。这与 SGLang v0.5.20 的 CPU-only Simulator 是同一制度方向的两种实现：都是把「必须跑完整的」降低为「可以在约束条件下跑」——SGLang 降低贡献门槛，DeltaSelect 降低评测成本。同时与 09-19 REGIME-004（ZCode 静默上传 256 + Google 去除署名 155）形成尖锐对照：当 AI agent 的评测基础设施都在开源化、经济化，AI agent 生态的商业行为却在静默侵蚀开源合规（Git 历史上传、署名权）——开源经济学的胜利与开源产权的败退在同一周并存，这是「大分流 2.0」最生动的制度对照。
   • 后续观察：(1) DeltaSelect 是否被 SWE-bench、DeepSWE、Aider 等 Coding Agent 基准的官方发布集成；(2) 是否有产业方（GitHub Copilot、Cursor、Anthropic Claude Code）把 DeltaSelect 方法作为内部评测标准；(3) 开源评测经济学是否会催生新的「AI agent 基准」项目（专门优化预算-信息比而非覆盖度）；(4) 中国大厂 AI 编程助手（通义灵码、文心编程）是否会跟进 DeltaSelect 类开源方法。
   • 误判风险：19.5% 相关性阈值可能过于宽松，实际开发决策中可能需要更高阈值；线性回归映射假设了分数化验证结果的单调性，实际中可能不成立；预算约束下的任务选择可能引入 bias（总是选择「容易」的任务）。

今日项目脉搏

4. Linux Kernel v7.3-rc3（2026-09-13）——三 RC 递进节奏，稳态主义在 rc 序列中的制度化

   • 制度层：Governance / Path-Dependence / Meritocracy
   • 证据：github.com/torvalds/linux commit v7.3-rc3（2026-09-13）
   • 初步判断：【L1】 v7.3-rc3 距 v7.3-rc2 约 4-5 天、距 v7.3-rc1 约 9 天、距 v7.2 稳定版约 4 周——v7.3 系列的 rc 节奏与 v7.2 系列一致，Torvalds 大版本间 4-6 周节奏延续。v7.3 稳定版预计 10 月上旬发布。【L2】 今日无重大治理层变化。Torvalds 作为唯一 release 权限持有者，maintainer 结构稳定。【L3】 v7.3-rc3 提交数量与 v7.2-rc 系列持平，无异常。
   • 开源之道判断：与前日（09-20）收录的 Git v2.56.0 双 RC 同日发布一起，形成「Linux + Git 两个元老项目同时进入 rc 阶段」的稳态日。Torvalds 是唯一同时负责两个项目（内核 + Git）release 的维护者——这个双身份让 Linux + Git 的 rc 节奏同步。这既是稳态主义的胜利（不需要人为同步，历史路径依赖已经内化），也是单点故障风险——如果 Torvalds 退休或失去健康，两个项目的 release 节奏会同时中断。适兕「包容性 vs 汲取性」命题在这里的微妙应用：Linux/Git 的治理是「汲取性」的吗？——不，它是「路径依赖的包容性」：因为 Torvalds 时代积累的 maintainer 文化已经足够深，即使 Torvalds 不在，其他维护者也能接手——但接手的前提是 rc 节奏继续按 4-6 周运行。
   • 后续观察：(1) v7.3 稳定版发布时间；(2) Torvalds 是否有退休或半退休信号（历史上从未提过）；(3) 是否引入 AI 相关的 rc 质量保障机制（历史上完全拒绝）。
   • 误判风险：单点维护者的稳态可能是「表面稳态」——如果 maintainer 老化，实际质量可能已经在下降；v7.3 rc 递进节奏可能是「惯性」而非「健康」。

5. Python 3.15.0rc2（2026-09-20）——PEP 484 多指导委员会稳态节奏延续

   • 制度层：Governance / Path-Dependence
   • 证据：github.com/python/cpython tags
   • 初步判断：【L1】 v3.15.0rc2 距 rc1 约 1 周，距 v3.15.0b4（beta 4）约 2 周——PEP 836 JIT 语言发布的 rc 阶段进入稳定节奏。v3.15.0 稳定版预计 10 月中旬发布。【L2】 无重大治理层变化。BDFL（Guido van Rossum）退休后的 PEP 484 多指导委员会结构继续运作。【L3】 PEP 讨论正常，无异常。
   • 开源之道判断：Python 是BDFL 退休后最成功的开源项目治理转型样本——从「Guido 一人」到「PEP 484 多指导委员会」，Python 用 4 年时间完成了 maintainer 权威向制度的转移。这与 Linux Kernel（Torvalds 30 年）和 Git（Torvalds 25 年）形成对比：Python 是「制度化成功」样本，Linux/Git 是「制度化未完成」样本——后者仍依赖单一维护者，前者已经制度化。这与 09-20 收录的 arXiv 2509.16295（治理过渡是累加不是替换）呼应：Python 从 BDFL 到多指导委员会，是「累加」的典型——不是取消 Guido 的权威，而是把 Guido 的决策权转移到 PEP 484 委员会。
   • 后续观察：(1) v3.15.0 稳定版发布时间；(2) PEP 484 委员会是否需要进一步制度化（增加投票权重或减少投票权重）；(3) AI slop 对 Python 语言生态（PEP 讨论、代码贡献）的影响。
   • 误判风险：单一 rc 阶段观察不足以下一般化结论；Python 的「制度化成功」可能只是暂时的，PEP 484 委员会的实际决策效率可能低于 BDFL 时代。

6. Chromium 156.0.8066.5（2026-09-19）——Google 主导下 Chromium 治理结构稳定

   • 制度层：Governance / Meritocracy
   • 证据：github.com/chromium/chromium tags
   • 初步判断：【L1】 Chromium 156.0.8066.5 发布，进入 156.x 系列的稳定版本节奏。Chromium 从 2024 年开始稳定在 4-6 周版本节奏，与 156.0.8066.4 距离约 1 周（bugfix 版本）。【L2】 Google 主导下的 Chromium 治理结构稳定。Chrome Dev Summit 2026 是下一次重要治理会议。【L3】 中国厂商在 Chromium 的贡献率继续上升，但 Google 员工的 maintainer 比例稳定。
   • 开源之道判断：Chromium 是**「企业主导的开源项目」最典型样本**——Google 掌握 Chrome/Chromium 的绝大部分维护权，同时 Chromium 是 Linux/Windows/macOS/iOS/Android 上大多数浏览器的底层。适兕「企业主导 vs 社区自治」命题在这里表现为「企业主导但社区依赖」——Chromium 的贡献者来自 200+ 国家，但治理权高度集中在 Google。与前几日收录的 LLVM Foundation 转型（Apple 独占 → 跨利益相关者治理）形成对照：LLVM 是「企业主导 → 社区自治」的成功转型，Chromium 是「企业主导 → 维持企业主导」的失败样本（或尚未开始的转型）。适兕的「赛博庄园」担忧在 Chromium 层面最有可能成立——如果 Chromium 永远维持 Google 主导，它就不是真正的开源基础设施，而是「Google 的公开基础设施」。
   • 后续观察：(1) Chrome Dev Summit 2026 是否讨论 Chromium 治理转型；(2) Microsoft Edge、Apple Safari、Samsung Internet 是否联合推动 Chromium 治理多元化；(3) 中国厂商（华为、字节）在 Chromium 的贡献率变化。
   • 误判风险：单一版本观察不足以下一般化结论；Google 主导的 Chromium 可能是「健康的企业主导」（Google 承担成本、社区获得收益），不一定是「赛博庄园」。

今日索引

• 前日 REGIME-09-20-001 Rheinmetall OnboardAPI 国防协议开源（09-20 收录）——今日无新进展。继续观察其他欧洲国防承包商是否跟进。
• 前日 REGIME-09-20-003 SGLang v0.5.20（09-20 收录）——v0.5.20 发布后 3 天，GitHub 上无 v0.5.21 迹象，进入 v0.5.20 稳定期。SGLang Simulator 与 Sampling Masks 采纳情况需要继续观察。
• 前日 REGIME-09-20-002 arXiv 2509.16295 治理路径依赖 NLP 实证（09-20 收录）——今日无后续。CHI 2026 版本返修进度需要观察。
• 今日新增 REGIME-2026-09-21-001 · OSI 官方区分「open weights vs Open Source AI」——OSI 制度声明层事件，产业响应待观察。
• 今日新增 REGIME-2026-09-21-002 · TeamCAMS 开源人机协作实验平台——AI 治理研究基础设施的「实验性」方向从 0 到 1。
• 今日新增 REGIME-2026-09-21-003 · DeltaSelect 开源 AI Agent 评测经济学——AI Agent 评测基础设施的「开源经济」方向从 0 到 1。

今日不做判断的事件

• 事件：Chromium 156.0.8066.5 发布

• 原因：Chromium 版本节奏稳定，单日信号不足以判断治理结构变化；需要观察 Chrome Dev Summit 2026 的治理议程。

• 事件：Python 3.15.0rc2 发布

• 原因：单一 rc 阶段观察不足以下一般化结论；需要观察 v3.15.0 稳定版发布后的生态反应。

• 事件：Linux Kernel v7.3-rc3

• 原因：rc 递进节奏是 v7.2 系列的延续，单日观察不足以判断治理结构变化；需要观察 v7.3 稳定版发布。

• 事件：TeamCAMS 论文本身

• 原因：软件发布类论文，尚未包含实际研究结果；需要观察后续引用与研究应用。

信号库更新

• 新增 active：3 条（REGIME-2026-09-21-001 OSI 官方区分 open weights vs Open Source AI、REGIME-2026-09-21-002 TeamCAMS 人机协作实验平台、REGIME-2026-09-21-003 DeltaSelect AI Agent 评测经济学）
• promoted / demoted / false-positive：0 条

今日核心判断：9/21 的三条主线——OSI 官方区分「开放权重 vs 开源 AI」（定义权首次官方化）、TeamCAMS 把「AI 治理」从描述性研究扩展到实验性研究（方法论层革新）、DeltaSelect 把 AI Agent 评测经济学开源化（基础设施经济学）——共同指向同一个演化：开源制度基础设施的「定义权」和「方法论权」正在向开源社区集中。过去 12 个月我们讨论的都是「开源社区被 AI 产业收编」（AAIF 加入 LF、AAIS 加入 LF、OSAA 加入 LF），今日三个信号给出了反向证据：开源社区正在通过 OSI（定义权）、TeamCAMS（方法论权）、DeltaSelect（经济学权）重新夺回对 AI 生态的话语权。这不是说 AI 产业不再主导开源，而是说开源社区正在用制度工具（定义、方法、经济）抵抗产业主导。

大分流 2.0 视角：DeltaSelect 的「预算内评测」、SGLang v0.5.20 的「CPU-only 仿真」、TeamCAMS 的「开源实验平台」都是「慢聚漫奏（求兴）」的实证——都是把「必须完整」降低为「可以在约束条件下运行」。而 OSI 官方区分「open weights vs Open Source AI」是「效率求生」的反面——OSI 拒绝把「open weights」当作「open source」的同义词，宁愿承受更严格的分类标准。这是开源社区对「大分流 2.0」的最积极回应：开源作为制度契约，其核心不是「代码免费」，而是「承诺被承认」——OSI 用严格的定义保护「承诺被承认」的边界。

未来验证窗口（30 天内）：Meta、Mistral、DeepSeek 是否响应 OSI 的「开源 AI」定义；TeamCAMS 是否被 AAIF、LF AI & Data 采纳为研究工具；DeltaSelect 是否被 SWE-bench、DeepSWE 官方集成；Chromium 是否在 Chrome Dev Summit 2026 讨论治理转型；v7.3 稳定版、Python 3.15.0、Git v2.56.0 三个元老项目是否同时进入稳定版窗口。

误判风险声明：OSI 官方博客是单次制度声明，产业响应未知；TeamCAMS 是软件发布类论文，实际研究结果未知；DeltaSelect 是单人工作（Nicholas J. Conn），后续采纳情况未知；Chromium、Python、Linux Kernel 的单一 rc 阶段观察不足以下一般化结论。

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

视角： 一个视角，不是定论。One perspective, not a verdict.