「开源之道」 2026-10-24 搜集事件和材料

「开源之道」昨日阅读 · 2026-10-23

今日主线可以压成一句：开源 AI 不是把门槛拆掉了，是把门槛从「能不能做」搬到了「能不能接受别人的条款」。

📄 最新开源研究论文

1. 借来的智能，借来的门槛：开源 AI 对创业"降低"了什么

  • 作者：Georg von Krogh、Ann-Kristin Weiser、Patrick Nicolas Tinguely（ETH Zürich，管理与技术经济系）
  • 来源：Strategic Entrepreneurship Journal，Early View，2026-10-23（开放获取 CC-BY）
  • 链接：doi.org/10.1002/sej.70052

摘要：论文识别出开源 AI（OSAI）区别于开源软件的四个定义性特征——① 对赞助企业的依赖（最资本密集的层只有少数大厂养得起）；② 分层许可证制度（数据、算法、模型、部署基础设施可各按开放或专有条款授权）；③ 监管风险（GDPR、EU AI Act 类数据与 AI 专门法规）；④ 民族国家影响力（AI 被当作战略基础设施，国家要干预其发布、许可、部署）。据此提出"OSAI 市场进入框架"，核心论断是：开放权重模型不是"降低"进入壁垒，而是"迁移"进入壁垒。资源门槛确实下降，但对"借来的组件"的治理依赖上升；真正的约束从技术能力转到商业价值捕获，转到互补资产。

为什么与开源之道相关：这是近来对"开源降低门槛"这一常识最干净的一次反驳。它把"开放"从道德叙事拉回制度分析：谁在出资、谁定许可、谁承担监管、谁能施加国家意志——四个问题和代码是否公开无关，和治理结构有关。

开源之道视角点评：von Krogh 是开源研究的老牌学者（private-collective innovation 模型的提出者），这篇的锋利之处在于把"依赖"写成制度变量而非情绪词。用威廉姆森的分层看：开源 AI 的 L2（许可证/监管/国家）比开源软件的 L2 重得多，L3（治理）却还基本是单公司主导。所谓"门槛迁移"，本质是交易成本从"买软件"转成了"读懂并接受别人的治理条款"——这个成本不写在价签上，所以常被当成零。对创业者该说的是：你不是在用免费的东西，你是在用一份你没法参与谈判的合同。

2. Agent 参与 issue 协作的熵：复杂度更高，产出更多，效率取决于语境

  • 作者：Kaiwen Zhi、Guisheng Fan、Wentao Chen（华东理工大学；上海市智能能源工程研究中心）
  • 来源：Proceedings of the ACM on Software Engineering（PACMSE）Vol. 3, Issue ISSTA，2026-10-01（ACM 已转开放获取）
  • 链接：doi.org/10.1145/3832206

摘要：把 issue 处理建模为事件序列，扩展"动态 issue-PR 熵"指标以区分涉 agent 与不涉 agent 的协作，用 83 个 GitHub 仓库的 issue 事件数据构建"项目—月"面板。结论：涉 agent 的协作复杂度与开发产出的关联强于纯人类协作，且与更少的新引入缺陷相关；但与 issue 解决效率的关系高度依赖语境。

为什么与开源之道相关：此前几乎所有"AI 与开源"的量化研究都在数 PR 数量、算拒绝率，这篇换了个问题——不问"AI 交了多少"，问"AI 加入后协作结构变成了什么样"。用熵做协作复杂度的代理指标，是把"人多不一定好"这件常识变成了可测量的东西。

开源之道视角点评：值得警惕的是指标本身的隐含规范。产出多、缺陷少，被读成"agent 好"；但 issue 解决效率"高度依赖语境"这一句其实是全文最重的话——它承认了这层关系不是普适规律。真正的制度问题在论文之外：熵升高意味着信息分散，处理分散信息的权力归谁？如果维护者读不完这些交互，最后还是要靠"谁有算力谁看得全"来决定。那判准就从 meritocracy 滑向了算力制。这篇给了度量，没给判准，恰好是留给开源之道的位置。

📰 开源动态摘要

1. Linux 内核维护者峰会废掉了 Assisted-by 标签：不再追问"你用没用 AI"

摘要：Sasha Levin 提交的 docs: remove Assisted-by references（2026-10-09）删掉了 Documentation/process/coding-assistants.rst 的署名要求、submitting-patches.rst 的对应章节，以及 scripts/checkpatch.pl 里对该标签的解析（4 文件 +1 −51）。提交信息只有一句：“The Maintainers Summit reached consensus to deprecate the Assisted-by tag.” 讨论串 47 封，Laurent Pinchart、Krzysztof Kozlowski、Jonathan Corbet、Kees Cook、Linus 本人都在里面。Torvalds 给记者的说法是可以直接引的原话：「我们有两个独立的 AI 问题：一是 AI 在大代码库里找到真 bug，给已经很累的维护者加了很多活；二是有人用 AI 生成补丁，却根本不理解相关代码。」他接着说：「但我要说，这些不是 AI 的问题，是被 AI 暴露出来的问题。」关于贡献者质量，他说得更直接：要劝阻的是「drive-by patches，以及那些只想感觉自己发过一个补丁、从没真想成为什么的人——我们都从一无所知开始，但有些人花了时间和力气去成为更多。」

开源之道点评：这是一个教科书写法的制度选择。业界主流在往"强制标注"走（因为无法验证），内核逆向走——去掉元数据，改为对结果负责。理由不玄：Assisted-by 只能自我声明，无法核验，等于把一个不可执行的条款写进制度，结果只会制造形式合规。内核把它删掉，等价于公开承认"我们管不了工具，我们只管人"。而 Torvalds 那句"是被 AI 暴露的问题"，正是 L1 层的判断：AI 没有制造新问题，它只是把"评审带宽稀缺"和"进入意愿与进入能力脱钩"这两件旧事放大到无法忽视。这和本周 vLLM 往 AGENTS.md 写规则形成鲜明对照——同一个问题，一个用文件约束机器，一个用共识约束人。

2. AAIF 一年从 3 个项目到 10 个：Anthropic、OpenAI、Hugging Face、阿里各捐一个

  • 来源：Linux Foundation 新闻稿（2026-10-22，AGNTCon+MCPCon NA，圣何塞）/ The Register（2026-10-23）
  • 链接：linuxfoundation.org 新闻稿

摘要：四个新项目——Agent Skills（Anthropic）、Open Responses（OpenAI）、OpenEnv（Hugging Face）、OpenSandbox（阿里巴巴），加上原有的 A2A、Agent Router、agentgateway、AGENTS.md、goose、MCP，AAIF 首年到 10 个项目。四个项目正好覆盖 agent 栈四层：如何获得技能、应用如何跨厂商与模型对话、agent 如何训练与评测、agent 在哪里安全运行。成员数一年内超 300 家，本季度新增 60 家（含蚂蚁、盖茨基金会、MongoDB、Nutanix、RBC、Vercel、Vultr 为 Gold）。各方原话都直白：Anthropic 的 David Soria Parra 说"我们一年前发布 Agent Skills 给开发者一个开放标准……今天把它捐给 AAIF"；阿里的 Xiaobin Xu 说"OpenSandbox 是阿里创建的，但我们不希望它的未来由单一公司定义"。

开源之道点评：捐赠是真的、条款是真的、中立托管也是真的——但这四条新闻放在同一天同一张稿子里，本身就是战略信号。谁捐什么，暴露了谁在哪一层有护城河：模型层的公司捐流程与技能（是给客户铺路），基础设施层的公司捐运行时（是给自己减负），而真正难替换的模型权重一个都没捐。AAIF 的价值不是"中立"，是提供一个低成本的协作界面，让相互竞争的四家能共享协议而不共享利润。这正是科斯意义上企业边界外的组织安排：把可标准化的部分外推到基金会（降低协调成本），把不可替代的部分留在自己账上。

3. Sentry 把开源赞助提到 100 万美元，并开始资助"幽灵依赖"

摘要：Sentry 年度开源资助从 75 万提高到 100 万美元。分配结构值得抄下来：49.5 万走 thanks.dev（按依赖关系分配）、10 万走 ecosyste.ms Funds（Python / Django / Ruby / Rust / JS / Go 关键包）、10 万由 Syntax 团队直接给到 FFmpeg、Jellyfin、FreeCAD、OBS、Caddy、Biome、pnpm 等各 5000，30.5 万给基金会（PSF 6 万、PHP Foundation 4.5 万、Ruby Central 4 万、Django DSF 4 万、Packagist 3.5 万、OSI 3 万、Rust Foundation 与 Geomys 各 1.5 万、OpenJS 与 NumFOCUS 各 1 万、Alpine 5000）。另一条被埋在里面的信息：它与 Software Stewardship Lab 的研究者合作，专门资助"幽灵依赖"（phantom dependencies）的维护者——常规依赖分析看不到、但实际被间接使用的组件。同期 PSF 报告其 AWS 支出同比上涨约 69%，原因是包安装、自动化工具与 CI 负载增长。

开源之道点评：最有价值的是"幽灵依赖"这条路。公地悲剧在开源里的具体形态不是没人用，而是用了但看不见——依赖图只记录显式声明的边，不记录有人在深夜手动打的那个补丁。用研究把不可见变可见，再用钱接上，这是在给公地补一条"可测量性"的地基。但也要看清量级：100 万美元分给几百个维护者与几十个基金会，平均下来每位拿到的是几千美元，而 PSF 的云账单一项就是 69% 的涨幅。这不是解决办法，是一次体面的示范——它的价值在于证明"按依赖付费"这条路走得通，而不在于填补缺口。

🔍 Project Pulse：OpenSandbox —— 一家公司的项目，要长成公共基础设施，缺的是什么

项目：opensandbox-group/OpenSandbox（16,109 stars / 1,496 forks / 161 open issues，2025-12-17 建仓，Apache-2.0）

本次观察切入：2026-10-22 AAIF 宣布阿里巴巴把 OpenSandbox 捐入中立治理。捐赠公告是宣言，仓库里的文件才是事实。今天只查一件事——这个项目的治理文档，是否已经比它的赞助方走得更远。

【L1】发布节奏与产能：仓库已从"单组件各自打 tag"迁移到"伞形统一版本"。OSEP-0016《Unified Umbrella Release Governance》（作者 @Pangjiping，2026-07-21 起，2026-09-21 更新，status: implemented）把 19+ 个独立版本目标（server、execd、ingress、egress、K8s controller、Helm、CLI、五个语言 SDK）统一到同一个 X.Y.Z、同一 release commit、一次 fan-out 构建、一份签名 BOM；节奏定为每两周一条线，只支持最新线，没有 LTS；1.0.0 直接跳过，从 1.1.0 作为 GA 起步。实际执行对得上：release-1.1.0（09-21）→ 1.1.1（10-09）→ 1.2.0-rc.1（10-15）→ 1.2.0-rc.2（10-21）。10 月以来合并 PR 170 个。这个从"十个互不相识的 tag"到"一个可整包审计的版本"的转向，是把自己从库变成产品的动作——也是成为基础设施的前置条件。

【L2】治理信号（今天的主证据）：GOVERNANCE.md 写得比大多数基金会项目更具体，而且三处细节值得单拎出来：

  • 角色的公开记录只有一份文件：maintainer 的唯一公开名册是 .github/CODEOWNERS，* 兜底的四个 owner（@jwx0925 @hittyt @Pangjiping @ninan-nn）被定义为"Project Maintainers"，即仓库级方向与最终技术决策人。按子系统（server / execd / ingress / egress / kubernetes / sdks / specs / oseps）各有 owner，交叉面（含 Spground、Generalwin、fengcone、kevinlynx）覆盖 K8s 与运行时。
  • 决策机制：日常变更走"维护者评审 + rough consensus"；跨切面与敏感变更（specs/ 公共 API、SDK 接口、CLI 行为、生命周期语义、隔离与安全保证、ingress/egress/认证）要求所有受影响区域的显式评审；僵局时 Project Maintainers 简单多数投票，平票即维持现状。
  • 晋升路径是抄来的，但抄对了对象：文档自己写明"adapted from the containerd project governance"，且明确"没有固定的 PR 或 commit 数量，贡献量本身不保证晋升"，候选门槛是三个月以上持续实质参与。
  • 制度化的设计流程：oseps/ 下已有 24 份编号提案（到 OSEP-0024：fast sandbox 自动暂停与按访问唤醒），含模板与初始化脚本；GOVERNANCE 明确"当需要 OSEP 时，实现应当遵循已批准的设计方向，而不是靠 code review 绕过去"。
  • 尚未完成的诚实标注：GOVERNANCE 开篇即写"这份文件反映项目当前的开放实践，随着项目成长可能会演化为更正式的治理模型"；MAINTAINERS.md 仍不存在，靠 CODEOWNERS 兜底。

【L3】新人信号：最近的活跃度高度集中——近 50 次提交中 @Pangjiping 占 32 次，@jwx0925 7 次，其余分散。10 月合并的 170 个 PR 里，最高产的一位是 49 个，其次是 8、7、4、4、3。这不是衰退信号（对年轻的伞形项目而言，集中发布是正常的），但它说明进入主干的实际带宽目前非常窄：CODEOWNERS 上的名字与合并能力基本重合，外部贡献者的可见产出还停留在边缘组件。16k stars 与 15 位左右有合并记录的人，是一组反差很大的数字。

【开源之道判断】：这个项目做对了最难的一件事——在捐赠之前就把治理文档写好了。很多公司捐赠时只捐代码，把治理留到"以后再谈"，结果基金会接手的是没有制度的空壳。OpenSandbox 反过来：CODEOWNERS 落了地、OSEP 流程在跑（24 份提案是硬证据）、晋升路径援引 containerd 的成熟机制、伞形发布用 OSEP 把自己的版本制度重写了一遍。捐赠公告里阿里巴巴那句"我们不希望它的未来由单一公司定义"，在文件层面是有对应物的。

但制度健康还有一块没验证：维护权的再分配是否发生过。CODEOWNERS 里现在全是同一批早期名字，没有任何非阿里的 owner 进入名单，OSEP-0016（决定整个项目发布制度的提案）作者也是内部人。判断捐赠是否真实的一个可操作指标，只有三条：CODEOWNERS 是否出现非原公司的名字、OSEP 是否由非原作者主导、生产采用者文档是否落地。前两条目前都还是空的。伞形发布与 OSEP 是"制度准备好了"的证据，不是"权力转移了"的证据。用威廉姆森说：L3 的治理机制（合同、组织、决策规则）已经写下，L4 的资源配置（谁能合并、谁能定方向）还没动。这不算问题，但要一年后再看一次——如果那时 CODEOWNERS 还是这四个人，那么"vendor-neutral governance"就只是托管，不是共同体。

同日对照（不做展开）：vLLM v0.32.0（10-18）后的 AGENTS.md 仍然在位（6,358 字节），那是用文件约束 AI 贡献者；OpenSandbox 用的是 OSEP 与 CODEOWNERS 约束人类维护者。一个治机器，一个治人——两个项目都在回答同一个问题：当参与者不再全是人的时候，“谁算贡献者"这条边界该由谁来写。

🔭 后续可检验的观察点

  • OpenSandbox 的 CODEOWNERS 名单：一年内是否出现第一个非阿里、非早期批次的 owner？这是"vendor-neutral"从托管走向共同体的唯一硬指标。
  • OSEP 的主导权：第 25 号之后的提案，作者是否开始出现外部人？内部人连续主导，说明设计权仍单点。
  • 内核的 Assisted-by 废除是否会被其他项目跟进：如果一年后主流项目反而纷纷加上强制标注，说明"不可核验的元数据"在别处被当成治理必需品——那才是真分歧。
  • AAIF 第 11 个项目是谁捐的：如果下一个仍是"流程/运行时"层，模型权重层的缺席就从偶然固化为分工。
  • Sentry 资助的"幽灵依赖"名单是否公开：不可测量的公地，先要可测量才能被付费；名单公开与否是对这条路径诚意的第一道测试。

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