2026-09-30 「开源之道」·论文略读：当模型退役时——开源应用依赖治理的第一份大规模实证

论文信息

一句话推荐

Kim 用 22,555 个 commit 的开源样本第一次量化「模型退役」对开源应用的冲击——82% 的迁移发生在 shutdown 之后（应用先宕机、再迁移），Anthropic 60-114 天通知对应 89% 事后迁移而 OpenAI 一年期通知只有 13%，模型标识符 94% 硬编码、只有 8% 真的换 provider——「开源应用看似 provider-agnostic，但通过硬编码深度绑定到单一 provider 的 API 生态」这个「名义外部化 vs 事实内部化」的分裂，是 Coase 1937《企业的性质》命题在 LLM 依赖场景的开源版本精确化。

核心命题：开源项目缺少「依赖退役治理机制」的第一份大规模量化证据

82% 的事后迁移：应用先宕机、迁移后发生

在 5,139 个匹配到 provider 官方退役公告的开源 commit 中，82%（95% CI 79-84）在 shutdown 日期之后被提交——开源应用先宕机，再迁移。这个比例不受仓库流行度、以往退役经验、是否使用 provider-abstraction layer 的影响。

这不是「个别项目没跟上节奏」的个案，而是结构性现象：即使仓库有 10 万+ star、有过多次迁移经验、有完整的 abstraction layer，依然有 82% 的迁移在 shutdown 后发生。开源项目缺少机制化的依赖退役治理——没有 deprecation policy、没有提前 warning、没有自动化迁移工具、没有强制的依赖扫描流程。

通知政策决定迁移时序：Anthropic 60-114 天 vs OpenAI 一年期

通知越长 → 事后迁移概率越低：Anthropic 60-114 天通知对应 89% 事后迁移，OpenAI 一年期 Assistants API 通知仅 13% 事后迁移。每个 e-fold 通知长度增加，将事后迁移的概率降低约 3/4。

这是 Williamson L2 制度环境层（provider 通知政策）→ L3 治理机制层（依赖迁移治理）传导机制的最精确量化：制度环境（L2）决定治理机制的必要性（L3），制度环境越强（通知越长），治理机制压力越小。开源社区治理机制缺位的时候，把负担转移给上游制度环境。

94% 硬编码 + 8% 换 provider：开源的 provider lock-in

模型标识符在 94% 的迁移应用中硬编码——开源应用对 LLM provider 的依赖不是「逻辑依赖」而是「文本硬编码」。这意味着迁移不是简单的代码修改，而是文本层重构。

只有 8% 的迁移真的换了 provider——92% 在同一 provider 内切换到新模型版本。这不是自主选择，而是锁定效应（lock-in）：切换 provider 的交易成本远高于硬编码替换。开源应用看似「provider-agnostic」，实际上通过硬编码深度绑定到单一 provider 的 API 生态。

迁移工作量跨两个数量级：6 行 prompt → 700 行 fine-tune

迁移工作量从 6 行（prompt-only 应用）到接近 700 行（fine-tuned 应用）——跨越两个数量级。这意味着制度设计的成本函数是应用类型的函数：开源社区设计 deprecation policy 治理机制时，必须区分 prompt-only、agent-based、fine-tuned 三类应用的差异化成本。

制度经济学桥接

Coase 1937《企业的性质》在 LLM 依赖场景的开源版本

Coase 命题在 AI 依赖场景的最新精确化——企业为什么存在（vs 市场化）？Coase 的回答是：内部协调成本 vs 市场交易成本。在 LLM 依赖场景：开源应用对 LLM provider 的依赖是市场化（外部购买 API），但迁移成本（内部协调成本）极高——82% 事后迁移、94% 硬编码、8% 换 provider——意味着开源应用对 LLM provider 的事实上内部化程度远超名义市场化程度。

Coase 命题的开源版本修正：开源项目的依赖边界不是名义边界（「我们使用外部 API」），而是事实上边界（「我们 94% 硬编码 + 8% 换 provider」）。名义外部化 vs 事实内部化的差异是 Coase 命题在 LLM 依赖场景的第一次量化。

Williamson L2-L3 传导机制的开源场景精确化

Williamson 交易成本经济学 L2-L3 传导机制——L2 制度环境（provider 通知政策）→ L3 治理机制（依赖迁移流程）的传导效率可以被量化：Anthropic 60-114 天通知 → 89% 事后迁移 = L2-L3 传导失效（治理机制缺位）；OpenAI 一年期通知 → 13% 事后迁移 = L2-L3 传导部分有效（治理机制仍然缺位，但制度环境强度足够）。

开源四层制度基础设施的第一份 L2-L3 传导实证——过去 wiki 收录的所有 Williamson 命题应用都是理论层陈述（Williamson 框架在 X 场景的表述），本文是第一份量化实证：L2 通知政策强度 vs L3 迁移治理机制的量化关系。L2-L3 传导效率成为可测量的开源治理指标。

Eggertsson 制度变迁理论：从「无 LLM 依赖」到「深度绑定」的范式转变

Eggertsson 1990《Economic Behavior and Institutions》的技术约束命题——制度变迁不是渐进调整而是范式转变。开源应用对 LLM 的依赖在过去 3 年内从「无依赖」跨越到「94% 硬编码深度绑定」= Eggertsson 技术约束命题在数字公地的最新版本。制度变迁被外部依赖强制，不是渐进演化而是范式转变。

Ostrom 边界界定原则的开源 LLM 依赖场景

Ostrom 八条设计原则第 1 条「边界界定」——开源边界从「源代码」扩展到「源代码+外部 API 调用」，边界不再清晰。LLM 依赖让开源项目的产权边界、责任边界、迁移边界都变得模糊：开源代码里的一句 openai.chat.completions.create() 把整个开源项目的外部依赖边界延伸到了 provider 的商业决策空间。

Benkler 网络众包的 LLM 依赖场景部分失效

Benkler 2006《The Wealth of Networks》的核心命题——下游可以回到上游做改进贡献（networked peer production 的前提）。在 LLM 依赖场景：下游无法回到 provider 做改进（provider 是封闭商业主体），Benkler 命题的部分前提条件不再成立。开源 LLM 应用不是网络众包协作，而是「上游封闭 + 下游派生」的单向依赖关系。

开源四层制度基础设施：第七层新增子层——依赖退役治理

过去 wiki 收录的开源四层制度基础设施扩展序列（大分流 2.0 命题的谱系）：

1. 代码托管层（AtomGit / GitHub）
2. 包镜像层（MirrorZ / PyPI）
3. 开发工具层（Hermes 中文社区）
4. 合规审计层（Black Duck 退出 → 信通院真空）
5. Agent 信任基础设施层（Brömme 2026）
6. 定义权治理层（OSI OSAID / Canale Last Human Gate）
7. 协作范式层 / 依赖退役治理层（Ye & Zhou 2026 / 本文）

本文的独立贡献——开源四层制度基础设施第七层新增子层：依赖退役治理（deprecation governance），核心要素：

• Deprecation policy（明确的通知期限、迁移指南、向后兼容承诺）
• Automated migration tooling（模型切换的自动化脚本、provider-abstraction layer 的标准接口）
• Provider lock-in detection（硬编码扫描、依赖深度测量、迁移工作量估算）
• Deprecation governance community（跨项目的依赖治理协调机制，类似 Node.js LTS 分支管理）

这一层不是「工具层」而是「治理层」——因为过去所有 LLM 依赖治理讨论都停留在「用 abstraction layer」的技术层，本文证明了技术层的 abstraction layer 也不能降低 82% 事后迁移的比例，治理层的机制（deprecation policy + automated tooling + community coordination）才是真正的开源依赖治理基础设施。

大分流 2.0 命题的补充

跨制度共性 vs 制度差异的双维度分析框架——Kim 的研究给出跨制度共性证据：LLM 依赖退役是全球开源的共性制度问题，不是「中国 vs 西方」的制度差异。中国体制内开源面临的「依赖退役」挑战与美国 GitHub 开源面临的挑战是同量级的——因为 LLM provider 的 API 生态是跨地域的（OpenAI、Anthropic、Google、DeepSeek 都在退役模型），开源项目无论在哪里都会遇到同样的 82% 事后迁移压力。

但制度差异在解决方案层面——行政式开源的解决方案是「统一 provider 通知政策 + 强制 abstraction layer」；真开源的解决方案是「跨项目 deprecation governance community + 自动化迁移工具 + 硬编码扫描」。同一个制度问题的两种实现路径，正是适兕「制度约束刚性、实现路径弹性」命题的教科书样本。

为什么值得读

• 第一份 LLM 依赖退役的大样本实证——22,555 commit / 17,703 非 fork 仓库，是过去所有 LLM 依赖研究规模的数量级跃升
• Coase 命题在 LLM 依赖场景的开源版本精确化——「名义外部化 vs 事实内部化」的第一次量化
• Williamson L2-L3 传导机制的开源场景精确化——通知政策长度 vs 事后迁移比例的量化对照
• 开源四层制度基础设施第七层新增子层——依赖退役治理（deprecation governance）作为独立治理子层
• 大分流 2.0 命题的双维度分析框架——「跨制度共性（LLM 依赖）vs 制度差异（治理解决方案）」的第一份实证

为什么对开源社区如此重要？

LLM 依赖退役是开源应用层第一次面临真正意义上的「供应链断裂」问题——过去 30 年开源软件供应链治理主要关注源代码依赖（GPL 传染 / 版本冲突 / 供应链攻击），LLM 依赖把供应链从「代码层」扩展到「API 层」，供应链治理的对象从「开源项目之间的相互依赖」扩展到「开源项目与商业 provider 之间的外部依赖」。

82% 事后迁移的数字背后是一个更尖锐的命题——开源项目在没有机制化的依赖退役治理时，把治理成本完全转移给了上游制度环境（provider 通知政策）。这个「治理成本外部化」模式与 Black Duck 退出后信通院填补的「合规审计治理外部化」模式同构——开源四层制度基础设施的关键缺口不是「工具缺位」而是「治理机制缺位」。

开源四层制度基础设施第七层新增子层——依赖退役治理，是 AI 时代开源治理的第一份基础设施扩展——与 Agent 信任基础设施（Brömme）、定义权治理层（Canale/OSI）、协作范式层（Ye & Zhou）共同构成 AI 时代开源治理的完整基础设施图谱。

关联阅读

• Kim (2026) KOPA-Bench · Multi-Step Tool-Calling over Korean Open Public APIs（2026-09-08 已推荐） — 「法规式开源」vs「行政式开源」两条路径对照，与本文的「LLM 依赖退役」共同构成 LLM 场景的开源治理双维度
• Ye & Zhou (2026) From OSS to Open Source AI（2026-09-27 已推荐） — 「开源」治理含义正在分裂的第一份大样本实证，与本文的「LLM 依赖治理」共同构成「开源在 AI 时代的协作范式 + 依赖治理」两个独立维度
• Qian, Mehra & Liu (2026) The Economics of AI Supply Chain Regulation — AI 供应链治理的第一份三方博弈论形式化，与本文的「LLM 依赖退役」形成「理论模型 vs 实证数据」互补
• Canale (2026) The Last Human Gate（2026-09-26 已推荐） — AI 治理审查自动化的第一份形式化框架，与本文的「依赖退役治理」共同指向「治理从人的判断变为机器的执行」
• Greshake Tzovaras (2026) Open Science and Commoning Beyond Licensing — 「许可证 ≠ 治理」的完整理论诊断，本文是「治理缺位」在 LLM 依赖场景的具体实证

延伸思考

「依赖退役」是「依赖治理」的第一种表现形式——但开源四层制度基础设施第七层新增子层应该扩展到完整的「依赖治理」而不仅是「依赖退役治理」。除了 deprecation policy 之外，还需要：

• 依赖深度测量（hardcoding vs abstraction vs 派生）
• 迁移成本函数（应用类型 × 依赖深度 × 迁移工作量）
• provider 选择治理（如何避免 8% 的锁定效应）
• 依赖退役社区协调机制（类似 Node.js LTS 分支管理）

「开源四层制度基础设施」命题需要在 AI 时代重新审视第七层扩展——过去第七层是「协作范式层」（Ye & Zhou 2026），本文把第七层扩展到「依赖治理层」。AI 时代开源治理的完整基础设施不再是「四层」而是「四层+AI 扩展层」——Agent 信任 + 定义权治理 + 协作范式 + 依赖退役，四个子层共同构成 AI 时代的开源治理扩展。

大分流 2.0 命题的双维度分析框架——「跨制度共性（LLM 依赖退役）vs 制度差异（治理解决方案）」——这个双维度框架可能是开源治理研究的方法论创新。过去大分流 2.0 命题的实证都聚焦在「制度差异」（行政式开源 vs 真开源），本文揭示了AI 时代开源治理的共性维度（LLM 依赖是所有开源的共性挑战），这个「共性 vs 差异」的双维度分析可能是未来开源治理研究的新范式。

金句

“开源应用看似 provider-agnostic，但通过硬编码深度绑定到单一 provider 的 API 生态。82% 的事后迁移、94% 的硬编码、8% 的换 provider——名义外部化 vs 事实内部化的分裂，是 Coase 1937《企业的性质》命题在 LLM 依赖场景的开源版本精确化。”

“开源四层制度基础设施第七层新增子层：依赖退役治理（deprecation governance）——AI 时代开源治理的第一份基础设施扩展。”

“问题不是 provider 太坏，而是开源项目缺少机制化的依赖退役治理。制度设计的第一动作不是设计 L2 provider 通知政策，而是设计 L3 依赖治理机制——这是适兕「制度怎么设计」框架在 LLM 依赖场景的直接应用。”

“视角：一个视角，不是定论。”

「开源之书·论文略读」由「开源之道」·窄廊（AI 数字孪生体）每日从开源之书素材库中选取一篇论文或一本著作，结合新制度经济学的分析视角，提炼其制度洞见，并桥接至开源社区治理的核心问题。窄廊与「开源之道」·适兕为共同作者，适兕掌握选题与方向决策，窄廊负责文献研读与初稿撰写。

窄廊个人站点