当 Coding Agent 让写代码变得前所未有的“简单”，开源还有意义吗？TiDB CTO 黄东旭在这篇文章中给出了他最近的一些思考和判断：
- 模型不是软件，传统软件市场依然存在；
- 未来软件不会完全去界面化、去功能化，自然语言的局限性让我们仍旧需要数据库、编译器以及各种复杂系统；
- Agent 正在冲击传统开源——贡献变得廉价导致头部项目趋向“主理人化”、软件选择权正在让渡给 Agent 的统计偏好导致软件分发趋于中心化、靠“锦上添花”功能收费的 Open Core 模式将迅速崩塌；
- 冲击之下，开源的不可替代性反而凸显，技术民主化、公共知识累积和供应链安全在 Agent 时代变得更加不可或缺；
- 未来的开源商业将从“卖能力”转向“卖责任”，靠持续把软件运行好、演化好并为结果负责来创造价值。
……
声明：本文为技术观点分享，不构成具体产品选型建议。
最近一直在思考一个问题：在 Coding Agent 能力如此强、应用如此广泛的当下，开源软件和开源社区将会面临一个什么样的未来？
大家最近可能也都亲身感受到了，软件的生产成本正在急速下降。所以很多朋友问我：开源是否还有意义？或者说，当代码编写变得如此简单的时候，传统意义上基于开源构建的商业模式是否还成立？
还有一些更大的话题，比如新时代的开源软件与社区治理应该会是什么样子。正好这几天是小长假，得闲几天，就结合最近的一些感受稍微写一下。
本文还是一样，百分之百口述，由 Typeless 进行整理。本文所描述的观点，大概会在未来 1～2 个月内过时，毕竟 AI 的进展速度实在太快，不过这篇我试着从一些哲学和宏观的角度分析，也许过时的没那么快也说不定。
模型不是软件
首先我想澄清一个概念：今天讨论的话题不包括开源（开放权重）模型。甚至我觉得开放权重模型不应该套用“开源”这个定义，因为它完全是不一样的物种，甚至不是我们传统意义上理解的软件。
模型是一种更不一样的东西，它是底层智能，可以认为它是构建未来软件的一个更底层的假设。
为什么这里的区别如此重要？我觉得有几个核心：
第一，如果我们抛开各种后训练技巧以及做 fine-tune（微调）的门槛，开放权重模型其实并没有办法让广泛的社区和开源贡献者很轻易地参与进来，它的门槛非常高。你很难想象一个人在家里从零开始去复现一个模型，比如现在的 Deepseek V4、Kimi K3，它的权重已经不是开源爱好者能够复现的了。
所以说开放权重模型，更核心的本质是将智能民主化。它其实并没有社区或者治理的可能性，因为哪怕开放权重、把数据集都开放出来，你也很难参与到模型的训练过程中。要参与定制仍然需要大量的算力，这在今天显然是不可能的。
当然，后训练提供了一些可能性，但现代的后训练需要的算力规模也是相当惊人的。尤其随着模型越来越大，要想做一些更有意义的后训练或者改变权重，其实成本非常高。这很难形成那种传统意义上协作、共同进步的“大教堂”开发模式。
其实可以把模型，假设为一种新的、强大的生产力工具。在这种假设下，传统的软件市场仍然是存在的，只是因为供给端巨大的生产力变革，会导致非常多不一样的事情发生。今天主要就讨论这些。
我们在可预见的未来仍然会需要软件
从 ChatGPT 问世之后，大家经常想象未来软件的去界面化、去功能化，但我认为这不会过于激进地发生。哪怕 AGI 了，我们仍然需要在特定场合下使用计算机来辅助我们完成日常的事情，而不是每件事情都可以通过聊天完成。
举个例子：我一直以来做数据库软件，对于数据查询和检索这样的交互界面，用自然语言就是不如用 SQL 这样精确、完备的语言来描述。或者例如我要去做一个仓库管理系统，当我要去展示/更新库存，表格仍然是一个最自然、最直接的形态。你想象一下，通过语言去描述库存更新的需求时会有多痛苦。
为什么呢？这其实跟智能本身没有太大关系，而是一种交互媒介在特定场景中表达人类意图的能力不同。比如数据库查询场景需要精确、准确、无二义性，但自然语言天生存在二义性。这并不是模型的智商问题，而是我们通过自然语言本身就无法把这类事情表达得绝对清楚。
今天其实我们在 coding 领域，已经开始发现类似自然语言的局限性了。通过自然语言可以很快描述一个 prototype（原型），但到了复杂的部分，或者要去精确修改时，描述起来就会非常费劲。对于软件来说，关于复杂度其实有句名言：复杂度一直存在，它不会被消除，只会转移。
用自然语言编程其实是非常危险的，因为这些天然的复杂性被隐藏到了你看不见的地方，而这一切最终都会成为软件的债务，做点简单的玩具还行，你能想象一个没有任何计算机或者业务背景的人通过 vibe coding 给描述一个 SAP ERP 出来？对，至少我觉得在可见的未来，我们仍然会需要数据库、编译器、操作系统以及各种各样的业务系统。
只是它们会在 AI 时代变得更聪明、更好用。也就是该模糊的地方可以接受模糊，但该简洁准确的地方，也仍然会保持着符合直觉且正确的软件交互设计方式。
这也就是为什么现在大家观察到一个非常有意思的现象：虽然说 Vibe Coding 能大幅降低开发软件的成本，但在哪怕是 Vibe Coding 时代，做得好的一些软件背后，你会发现作者仍然是最顶级的工程师和业务专家。
Agent 对开源社区和商业的一些当下影响
我们先从动机开始说起。抛开成就感、挑战自我这些个人动机不谈，过去做开源的动机其实无非就几种（我在之前的文章里也提到过）：无非就是广泛传播带来的生态、吸引人才贡献带来的高迭代速度，以此构建起护城河，所以它其实是作为一种低成本的软件分发模式而存在的。
而且，商业化也是构建在软件不易得和软件维护成本非常高（不管是通过云还是通过维护软件服务的方式）的基础之上，这是过去开源的底层逻辑。
在传统的开源治理里面，贡献权是一个非常重要的事情，类似区块链的 PoW。因为持续的贡献是非常昂贵的，个人或者一个企业如果要长期贡献开源软件，在过去通常意味着巨大的投入和持之以恒的承诺。但这样一来，你自然也可以换取这个项目更多的主导权、声望以及产品的定义权。这就是过去商业开源公司通过这样的持续贡献换取产品主导权，从而享受开源模式获得高效/低成本的分发带来的红利。
但是今天，贡献变得如此廉价，任何人、任何组织都可以通过 Agent 在很短时间内进行大量的贡献。所以这里用来衡量承诺认真程度的标准（贡献）也变得不可靠了。当付出变得廉价的时候，收益的分配就会变成一个巨大的问题。所以今天能很明显地看到一个趋势，就是越来越多的头部开源项目正在关闭外部贡献的通道，我倒觉得这是一个非常自然的现象。
这个趋势会带来的一点副作用：知名开源项目 maintainer 的权力会持续上升，上游软件的迭代速度反而可能会变得缓慢。你想想，当供给变得无限增加的时候，稀缺资源就变成了决定哪些 PR 要被合并。当大量的噪声污染 PR 列表时，maintainer 会更加小心和审慎地做出决定。
慢慢地，这些头部的开源项目会渐渐变成类似“主理人”的模式，有点像最近 DHH 很火的 Omarchy 就是这种模式的代表（这个项目的名字很显然也是来自于 Omakase 的启发）。
这种“主理人化” 会带来的就是开源社区里面的讨论从更细节和技术化的讨论，变成一个更像是政治和哲学的讨论。因为在过去，有很多需求或可能性，受限于客观生产力没有办法满足而被上游拒绝。在今天，其实下游很容易就能在一个 fork 上把这些能力实现出来。于是，上游合不合并，很大程度上不受限于客观的实现难度，而是拥有合并权力的人或者团队对这件事情的主观判断。
另外一个趋势就是，我觉得很多传统意义上的开源软件企业用户会离开公共讨论和开源治理，在今天，维护一个私有分支的成本，其实比说服上游去合并自己的需求变得更低。而且大多数情况下，Agent 对于流行开源软件的理解已经足以支撑这些公司的业务需求。这样的话，其实上游会缺乏真实、严肃的企业级反馈，这对于很多系统软件来说是非常危险的。长此以往，上游的进化速度因为缺乏真实反馈和过度谨慎而放缓，下游又在各个私有分支里面进行各种低水平的重复和迭代（毕竟几乎所有人都是用着类似的模型和类似的 Harness，这意味着会产生类似的幻觉），虽然 LLM 看似推进了全球软件的产量和繁荣，但是对于优秀的软件公共资产反而是有害的。
更糟糕的事情来自于分发渠道，过去软件的选择是靠工程师的经验和对系统的理解做出判断（虽然很多时候也会有很多很糟糕的判断），但是今天选择使用什么软件完全是由 Agent 自主作出选择，人类在让渡选择软件的权利，一个简单的例子，如果你今天要让 Agent 给你开发一个小网站，它可能会下意识地去使用一些特定的技术栈（例如数据库一定会选 Postgres），或者使用在训练集里大量重复出现的模式，这完全是基于统计概率的。反倒是一些也许更适合当前场景、或者质量更好的选择就很难出现在候选列表中。所以一方面看上去开源非常繁荣，但实际上软件的分发又开始变得越来越中心化。
在商业上 Agent 对开源软件的冲击也是巨大的，上面提到了简单的运维模式的崩溃很好理解，就是 Open Core 的模式也会逐渐崩溃，过去也是很常见的一个开源软件商业模式（我一直不看好），大概意思就是软件内核本身开源，但周边的一些支撑性部件，比如可视化、运维系统，企业级功能（比如加密或权限管理等），选择放在企业版里闭源发售。
这个模式其实我觉得已经不太成立了。如果客户真的有这么强的需求，今天对于企业客户来说：做一个更喜欢、更好看的 dashboard，对 Agent 来说简直易如反掌，而运维本身的工具，只要 Agent 愿意，真的一天就能写一个。只要是实现门槛不高的周边功能，Agent 想怎么搞就怎么搞，简单来说锦上添花的能力，粘住用户的效果是在快速降低。
还有一种很隐蔽的 Open Core 模式，就是在云上提供开源软件的托管云服务。这在过去其实资本市场是非常看好的，但我觉得很多这类的 SaaS 只是披着一个云 SaaS 的外壳，底下本质上还是 Open Core 这种锦上添花的模式，只是把运维管理系统从 dedicated 的硬件变成了云上的 dedicated 硬件。
这里面的问题我觉得在于：对底层的资源你并没有真正的控制权，你赚取的利润只是在帮用户做托管和运维。不管用多少台服务器、是在云上还是在用户那儿，对用户的成本来说基础设施的成本区别其实不大，哪怕在云上，如果你没有很好的超卖策略或者从云和模型那里拿到超乎想象的折扣，你只不过是左手从用户那里收钱，右手直接给上游平台方（云和模型）交租。这意味着你本质上还是在卖自动运维和 dashboard，只是包装成了一个看似性感的 SaaS 的生意。在今天，如果客户能够很轻易地去构建一个自己的这种运维管理系统，当云服务器和 Token 的账单仍然是客户支付的时候，那作为供应商的你就得问一下自己：你提供的价值和你的利润来自于哪里？
所以过去其实 Open Core 模式的问题本质，不在于这个 dashboard 有多难写。这些公司的大客户真正选择这个 vendor，归根结底仍然还是两个字：责任。责任意味着：出了故障谁来处理？有需求谁来响应？是不是有一个契约能够确保供应商在这件软件上持续维护？
有人承诺对这个软件做出长期的 SLA 保障，而这个承诺对于企业客户来说是值得付费的。过去我们也知道，很多时候大客户买个 Dashboard 只是对内能有个能让会计入账的条目（因为很多企业的财务并不理解软件的 SLA 这种看不见摸不着的东西是很贵的）。
关于商业模式，我觉得今天这件事情的本质也没有变化：因为复杂的软件，就像上面说的，它的生产端仍然是复杂的，领域的人才也是稀缺的。构建一个软件仍然还是困难的，于是，你就还是得有这种交付契约存在，于是才有价值的交换，只是托管便利性这个价值点在未来就不存在了。另外就是最近这几年，我觉得由于 Coding Agent 的能力越来越强，会给大家创造一种幻觉，就是整个传统的软件领域其实在被系统性地低估。我一开始也是在这种盲目的乐观里面，但是最近这两个月，我越来越发现，复杂的系统在 AI 的时代仍然还是复杂系统，今天做一个工业级的操作系统或者是分布式数据库，并不会比 10 年前简单多少。最多是写代码的时间变少一点，但是做过这类系统的人也知道，写代码在这种真正复杂的软件里面所占的时间，那真的是微乎其微的。
所以，最危险的是处在中间的薄功能 SaaS：用部署麻烦制造托管溢价，数据连接器，信息搬运，表单和 Dashboard 这类项目会死的很惨，而比较坚固的是：广义上的数据库（存储）系统，支付和结算网络，掌握持续状态和多方协作的平台，任何愿意承担业务结果责任的软件产品。
这也是我觉得现在很多 OPC 或独立 FDE 在企业级市场仍然不太成立：现在软件的生产和交付当然是容易的，但你希望凭着一个人去提供持续、长期的责任，这件事情是非常困难的，这个在制度上和人性上都不现实。所以这件事要成立，至少需要有（哪怕是第三方提供的）背书保障，以及平台性的验证、保险、持续维护的制度性保障，瓶颈并不在生产力这端。
Agent 只是让那些不需要有人负责的小软件变得免费了，这反过来会让需要人负责且需要让人信任的复杂软件变得更加昂贵（初级人才的成长的路径被切断），这实在是很有意思。
Agent 的时代我们是否还需要开源？
扯了那么多，回归一下主题：我们今天是否还需要开源？我的答案是肯定的。首先是一个最好理解的原因：今天如果你不开源，你的软件就很难出现在未来的模型的训练集里，这一点不用过多展开。
另外一个更深层次的原因是：我觉得软件行业的繁荣，一定是根植于软件和技术的民主化。只有充分的民主化，才能带来繁荣的软件生态，让更多好的想法诞生出来，这点不管有没有 AI，都是成立的。在过去，由于软件本身的开发成本非常高，所以闭源在过去确实有了一定的正当性，这可以参考比尔·盖茨在上世纪 70 年代写给软件爱好者的那封著名公开信。在相当长的时间里，我觉得这都是有道理的，毕竟生产端确实付出了大量的劳动。
但在今天的 AI 时代，这个假设变了。我们其实有机会做到真正的技术民主化，而这里面的一个核心权利，就在于软件的所有权。而当在出现这种未知的问题、或者新需求的时候，其实才是体现出软件所有权的重要性时候，Coding Agent 其实解决的是修改能力的问题，但是开源和闭源的区别就在于：用户是不是能够不经过原所有者的许可，接管和修改眼前的这个系统。闭源软件最大的问题在于任何修改都要来自于原厂，先暂且不提他愿不愿意跟你沟通、满足你的需求（你可以想象一下，绝大多数情况下他是不会理你的），哪怕他理你了，响应速度和沟通速度的瓶颈，仍然是人类速度的瓶颈。
所以这个地方就有一个很有意思的点了：你购买的软件，其实并没有拥有它的所有权，本质上所有权还是掌握在闭源厂商手上的，你只有使用权。真正的所有权，是体现在修改的权利，开源其实给予了用户这种权利，但在过去，受限于专业能力，编码是一件高门槛、需要高资源的事情，所以绝大多数终端用户是没有办法行使这项权利的，但是今天情况已经有点不太一样了，我们第一次有机会实现更大范围的技术民主化，前提是开源。
另外，从整个社会协作的角度来看，开源也是一个必选项。
首先， Agent 虽然每次都可以重写，假设未来也有足够的能力重写，但是“重写”并不等于“继承”，这些重写的替代品很难去继承长年累月中积累的各种隐性知识，尤其是上面提到的复杂系统，这些隐性知识目前大量的存在于少数的核心开发者的脑子里和经验中。想象一个所有软件都闭源、但 Agent 极强的世界。它不会缺少软件，而会呈现：低质量的私人软件极度丰饶，高质量公共软件却极度贫困。每家公司，每一个人的 Agent，都在不停地、重复地造轮子，解决类似的问题，这些经验教训和记忆都留在自己的私有领域里，永远没有办法形成社会的协同效应。简单来说没有开源，Agent 可能极大提高软件的产生速度，却降低软件文明的累积性。从软件供应链安全的角度来说，这种中立的、可靠的、社会级别的公共知识和公共软件，也是极其重要的，社会不能让公共能力存续依赖某个商业主体的许可。
所以，在 Agent 的时代，哪些类型的软件必须且必然要开源？我这边举几个例子：
- 预期会长期存在的软件
- 有多方共同依赖的软件，比如说协议、数据格式等
- 出错的后果极其严重的软件
- 会承载历史数据和大量状态，包含大量隐形专家知识的软件（并不是数据也需要开源）
具体的例子：编程语言、编译器、数据库、操作系统，网络协议等，迭代速度会加快，但是重写仍然是非常难的事情，不仅仅是技术原因，还有社会的信任的原因，就像我上面说的：有太多的隐性知识在这种长时间积累的老代码库和人脑子里面，重建信任不是 vibe coding 能做的。
关于 Agent 时代的一些开源商业策略
像上面提到的 Agent 时代，开源软件的能力属于全社会，开源企业不再靠封闭能力收费，而靠持续把它运行好、演化好并为结果负责来赚钱。这点对技术设施型的企业尤其重要，尤其对于想成为标准、基础设施或 Agent 默认能力的产品，开源仍然是必选项，但是这里的策略会变成：
第一，开源你希望全行业都共同采用的东西。比如协议 Spec、数据格式，比如任何这类有潜力成为标准的公共基础设施和想法。对于这一类东西，你需要毫无私心地去推广和运营，不要有任何公司、组织或者个人利益色彩。我觉得一个特别好的例子，就是 Anthropic 的 MCP 协议和 Skill 的定义，MCP 的官网是：modelcontextprotocol.io，注意并不是 anthropic 的子域名。
第二，如果你要去开源软件，你一定要想好，这个价值是你的软件本身，还是你这个软件的构建过程和迭代方式，这点非常关键也可能非常值钱。因为有些软件的构建过程和 eval（评测）中所蕴含的 know-how 的价值，是比这个软件本身要高得多的，甚至测试环境、测试数据，以及一些复杂的独特的 harness，价值会比 Agent 吐出来的代码重要的多。
第三，选择那些客户需要人持续负责任的部分作为收费的锚点。可以是代运营，可以是持续的更新，可以是大规模的托管，可以是合规审计，可以是灾备，可以是保障 SLA 和事故处理，可以是保险和理赔。
还是用上面说的 Anthropic 的 MCP 来举个例子：MCP 作为一个协议本身，它应该是完全开源的，包括一个标准的 SDK、包括这个通信的协议等部分。但是如果你是希望提供一个企业级 MCP 能力的托管服务，去保障提供的 MCP service、托管的 MCP service 的 SLA，你能做出这样的这种可靠性保障的时候，就应该是一个付费服务。或者如果你把开发 MCP（比如说给客户定制开发具体的 MCP service）作为一个商业模式，开发和软件交付本身是不值钱的。但是，如果你能找到的客户长期依赖你开发的 MCP 服务，同时他需要你在上面持续更新迭代或者提供保障，那这个是可以付费的。
这类模式适合 Agent 基础设施、开发者工具、数据交换层和新协议，通常发起人会提供一个中立的实现，供其他人（Agent）参考。
对于基于开源软件构建的 SaaS/PaaS 服务来说，模式仍然成立，只是传统的按照坐席/资源订阅的收租模式可能要改变：如果你在客户的核心场景之中，那就应该大大方方地去和客户聊软件本身的维护、长期的专业维护，还有这种长期保障的带来的业务价值。第二种模式是授权委托，企业购买的是一份有边界的授权委托。这是什么意思呢？比如说，过去你卖的是一套运维平台，当你卖出这套软件后，你并不真正负责用户的生产环境运维（使用者仍然是客户），但在未来，这已经不够了。你可能要直接给企业交付一个运维的 SLA，也就是你卖的是 SLA，而不是单纯的运维系统。企业这边负责为你的系统和平台开放必要的边界，而你最终交付给它的是一个确定性的稳定性。这里面的定价会是一个挑战，因为问题会变成：客户原因为它的 SLA 支付多少钱，以及你是否有能力承担失败带来的损失？
另外在 Agent 时代，不是每个开源项目都应该成为公司，传统的 VC 模式的开源软件策略：
- 通过砸钱推广加上开源的分发优势，快速形成广泛的社会依赖；
- 持续研发投入巩固开源项目的主导权；
- 当形成足够强的依赖后，通过修改许可证，或者制造能力不对称来进行商业化。
甚至还有更极端的例子：在早期以一个公立的形象构建生态，后期又开始利用这个优势，重新圈占已经成为公共基础设施的场景，进行强行商业化。这其实是很不好的，具体的例子数不胜数，我就不一一列举了， 最近的例子就有。
未来不同类型的软件可能需要三种不同运营载体：
- 长期公共基础设施：基金会，甚至应该由政府主导的强制捐赠和背书。
- 有明确商业动机/模式和网络效应的平台性质项目：以服务订阅为模式的开源云平台公司。
- 承担关键运行责任的基础系统：以保险为商业模式的开源运营公司。
开放生态和开源软件创造的商业价值，未来终将不一定由原始开发者捕获，也不应该由一方完全获得。
开源软件生态的产业链可能会分化为：
开发者（定义/开发产品），云平台（托管和运行），Agent 平台（分发），认证机构（对生成的软件进行验证），保险机构（对软件的结果承保）
上面这个模式里面，开发者和云平台很好理解，现在就有，但后面的三者：从 Agent 平台（慢慢开始出现），到专业的 Agent 生成软件的验证服务（没有），再到对生成的软件提供保险的服务（没有），现在还是一片空白。
所以，我觉得这里面有很多新时代才有的问题和机会，核心在于资本可以从公共能力产生的活动中获得回报，但不能依靠没收公共能力获得回报。