首页 > 应用开发 > IT综合 > 当智能体编写代码时,开源为何依然重要
知名开源项目的维护者正在面对一种全新的收件箱。Pull request 依然源源不断地到来,数量往往比以往任何时候都多,而且许多都干净、格式规范,初看之下也颇为合理。变化在于,如今一个人可以在一个下午产出上百个这样的请求,而维护者仍然必须逐一阅读,才能从中找出那三个真正有价值的。
这种倒转是过去两年里开源领域发生的最具深远影响的事情,而它几乎与代码质量无关。三十年来,正是贡献的成本让贡献变得有意义。它就像工作量证明:持续的贡献代价高昂,因此它是承诺的可靠信号,而项目则以影响力来回报它。智能体已将这一成本压至接近于零。信号消失了,建立在其之上的一切如今都变得不稳定。
先澄清一点:这一切都不适用于开放权重模型。我认为“开源”并不是描述它们的恰当术语,因为它们是另一个物种。模型是基础智能,更接近一种生产工具,而非一个程序。
无论发布多少权重,没有人能在家里复现 DeepSeek V4 或 Kimi K3 这种规模的模型。开放权重并不会开放训练过程,而且随着模型规模增长,后训练的成本会越来越高。开放权重的真正作用是让智能民主化,而不是促成社区或治理。把模型当作一种强大的新型生产工具,传统的软件市场依然存在。改变的是供给侧,而后果正是在那里显现。
自 ChatGPT 以来,人们一直预测会出现没有界面、没有离散功能的软件。我认为这不会发生,至少不会以激进的方式发生。
我整个职业生涯都投入在数据库软件上,而在查询和检索方面,自然语言并不像 SQL 那样精确或完整。以仓库管理系统为例:当你需要展示和更新库存时,表格是信息所能采取的最直接形式。用散文来描述库存更新既痛苦又缓慢。
这不是智能问题,而是界面问题。数据库查询必须精确且无歧义,而自然语言本质上是有歧义的。再强的模型能力也无法修复媒介与意图之间的错配。
我们已经在编程中看到了极限。用自然语言描述一个原型很快。但复杂的部分,以及对现有行为的任何精确修改,很快就会变得笨拙。关于软件复杂性有一句老话:它从不消失,只会转移。用自然语言编程把它转移到了你看不见的地方,而那正是软件债务累积之处。
因此,我们仍然需要数据库、编译器、操作系统和业务系统。在歧义可以接受的地方,它们可以保持模糊。在必须精确的地方,交互设计仍然必须直观且正确。这就是为什么,即便生产软件的成本正在崩塌,最好的软件仍然由优秀的工程师和领域专家构建。
开源本质上一直是一种成本极低的发行模式。广泛的发行构建了生态系统,贡献者加速了工作,二者的结合成为了一道护城河。与此同时,治理则建立在以贡献作为承诺证明的基础之上。
如今任何人都能在一个下午生成大量贡献,这一衡量标准已不再具有原本的意义,而分配过去随之而来的收益就成了一个真正的问题。这就是为什么越来越多领先项目正在关闭外部贡献渠道。我认为这是一种自然的反应,而非对任何事物的背叛。
副作用是维护者的权力不断增长,而上游的迭代实际上可能放缓。当供给实际上是无限的,稀缺资源就变成了关于合并什么的决策,而面对大量嘈杂的 PR,维护者会变得更加保守,而非更不保守。
渐渐地,这些项目开始变得像策展。DHH 的 Omarchy 是一个很好的代表,这个名字并非偶然:它建立在 omakase(厨师精选)之上。策展将社区讨论从技术细节转向政治。过去,请求被上游拒绝是因为它们确实不可行。如今,下游贡献者可以在一个周末内于 fork 中实现其中大部分,因此上游是否合并某个东西,与其说取决于难度,不如说取决于持有合并权者的判断。
第二个趋势更安静,也更糟糕。传统企业用户正在完全脱离公开讨论和治理。如今维护一个私有 fork 通常比说服上游合并你的需求更便宜,而智能体对热门项目的理解已经足以支撑这些公司所需的大部分内容。
称之为静默分叉:严肃的生产用户在下游私下解决自己的问题,从不反馈回来。上游失去了真实的企业反馈,这对系统软件尤其危险,因为生产反馈是发现某些类别 bug 的唯一途径。随着时间推移,上游因缺乏信号和过度谨慎而放缓,而每个 fork 都在重复自己低质量的迭代。由于几乎所有人都在使用相似的模型和相似的 harness,这些 fork 往往会产生相似的幻觉,因此重复的工作甚至并不多样。
发行也在走同样的路。过去软件选择由工程师做出,这种判断常常有缺陷,但那是他们自己的判断。如今选择越来越多地由智能体做出。今天让一个智能体搭建一个小网站,它会选择一个默认技术栈,数据库通常是 Postgres,因为这是其训练数据中出现最频繁的。这是统计,而非评估,那些可能更合适的选项甚至不太可能作为候选出现。开源表面上看起来生机勃勃,而发行却在悄然集中化。
在商业上,简单的运维业务是最先消失的。开放核心是下一个,而我从来就不喜欢它。这种模式是:开源核心,闭源销售配套部分——可视化、运维工具、加密、权限管理,打包为企业版。
这不再成立。一个更漂亮的仪表盘对智能体来说微不足道。一个运维工具是一天的工作量。任何实现门槛较低的外围功能,客户都可以按需重建,因此过去用来制造锁定的锦上添花功能正在迅速失去粘性。
还有一个更微妙的版本:为开源软件提供托管云服务。其中很多是披着 SaaS 外衣的开放核心,把运维层从客户的硬件搬到了你的硬件上。问题在于你并不控制底层资源,而且无论哪种方式,客户的基础设施成本也不会有太大变化。除非你有认真的超售策略,或者从云和模型提供商那里拿到了异常优厚的折扣,否则你是一只手从客户那里收钱,另一只手把它交给上游平台。
所以目前最危险的位置是中间那些功能单薄的 SaaS:那些靠部署麻烦、数据连接器、表单和仪表盘来制造托管溢价的业务。更稳固的是广义上的存储系统、支付与结算网络、持有持久状态并支持多方协作的平台,以及任何愿意为业务结果承担责任的产品。
开放核心(open core)的真正问题从来不是仪表盘有多难构建。让大型企业选择某个供应商的关键归结为一个词:责任。出问题时谁来处理。有新需求时谁来响应。是否有一份合同约束某个人持续维护这个软件。
关键软件的长期 SLA 是企业真正愿意为之付费的东西。同样真实的是,大客户常常购买仪表盘,是为了让财务部门有具体的东西可以入账,因为许多财务部门不接受一项无形的保障可以很昂贵。
这些都不是新问题,而这正是重点。复杂软件仍然有复杂的生产端,领域专业知识仍然稀缺。交付合同仍然是价值交换发生的地方。消失的是作为价值主张的托管便利性。我应该在这里直接说明我自己的立场:TiDB 从第一次提交起就一直以 Apache 2.0 开源,PingCAP 在其之上销售托管服务。这些是我自己公司运营所受到的约束,而不是对别人业务的观察。
过去两年制造了一种幻觉,认为传统软件被系统性地高估了。我一开始也抱有同样的乐观态度,后来逐渐认为复杂系统仍然是复杂系统。构建工业级操作系统或分布式数据库,今天并不比十年前容易多少。敲代码的时间减少了,而任何构建过这类系统的人都知道,敲代码从来只占工作的一小部分。
这也是为什么一人公司和独立的前向部署工程师在企业市场目前还站不住脚。现在交付软件很容易。期望一个人在没有背后保障、平台级验证和保险支持的情况下,多年持续承担责任,无论从制度上还是人性上都不现实。
智能体正在让那些无需任何人负责的小软件变得免费。在此过程中,它们让那些需要有人负责的复杂软件变得更昂贵,同时切断了初级工程师过去用来成为那个负责方的路径。
那么我们还需要开源吗?需要。
先说简单的原因:如果你的软件不是开源的,它就不太可能进入未来模型的训练数据。更深层的原因是,行业的繁荣建立在技术的民主化之上,无论有没有 AI。当开发成本高昂时,闭源具有真正的正当性。读一读比尔·盖茨 1976 年写给爱好者的公开信,其逻辑在当时是合理的,因为生产端确实付出了巨大的劳动。
这个假设已经改变,而真正受到威胁的权利是所有权。编码智能体解决了修改的能力。它们没有解决修改的许可。开源与闭源的区别在于,用户能否在未经供应商同意的情况下接管眼前的系统。对于闭源软件,每一次变更都必须来自供应商,即使他们愿意和你谈,对话也受限于人的速度。
这意味着你购买的软件并非你拥有的软件。所有权仍归供应商所有,你持有的只是使用权。真正的所有权体现在修改权上,而开源正是赋予这一权利的途径。对大多数用户而言,这项权利过去只是理论上的,因为行使它需要稀缺的技能。如今,它第一次变得切实可行。
还有一个社会层面的论点。即便假设智能体最终能够重写任何东西,重写也不等于继承。重写不会继承多年积累的隐性知识,而在复杂系统中,这些知识主要存在于少数核心开发者的经验之中。设想一个智能体能力极强、所有软件均为闭源的世界。那里不会缺少软件,而是会充斥着大量低质量的私有软件,同时极度匮乏高质量的公共软件,每家公司的智能体都在重复造轮子,经验教训永远被困在私有的孤岛中。智能体会加速软件的生产,却会拖慢软件文明的累积进步。
在我看来,有四类软件必须开放,而且很可能也会保持开放:
预期将长期使用的软件。
多方共同依赖的软件,例如协议和数据格式。
失败后果严重的软件。
承载历史数据、大量状态以及大量隐性专家知识的软件。这并不意味着数据本身必须开放。
具体而言:编程语言、编译器、数据库、操作系统、网络协议。这些领域的迭代将会加速。重写它们仍将困难重重,而且不仅仅是技术原因。太多隐性知识嵌入在旧代码库和人们的头脑中,而围绕它们重建社会信任并非 vibe coding 所能做到的。
如果开源能力如今已属于社会,那么开源公司就不再通过把守能力来赚钱,而是通过良好运营和对结果负责来赚钱。对于任何旨在成为标准或智能体默认选择的东西,开源仍然是必须的。围绕它的策略则发生了转变。
开放你希望整个行业采用的东西。协议规范、数据格式,任何有机会成为共享基础设施的东西。以不附加自身利益的方式推广它。Anthropic 的 MCP 就是一个很好的例子,关键细节在于它位于 modelcontextprotocol.io,而不是 anthropic.com 的子域名下。
弄清楚价值在于软件本身还是构建软件的过程。对于某些软件而言,构建过程及其评估中蕴含的专有技术远比最终产物更有价值。测试环境、测试数据以及特殊的测试框架,可能比智能体最终输出的代码更重要。
对需要持续人工问责的环节收费。托管运维、持续更新、大规模托管、合规审计、灾难恢复、SLA 保障和事件响应、保险与理赔。
MCP 说明了这一点。协议及其 SDK 应完全开放。具有真正可靠性保障的企业级托管 MCP 服务应当收费。如果你的业务是构建定制 MCP 服务,交付本身价值不大,而需要你持续更新并为你所构建的东西提供保障的客户则价值巨大。同样的逻辑用我称之为有界委托授权的方式取代了按席位收费:你不是出售一个运维平台然后让客户自己去跑生产,而是直接交付运维 SLA 本身。定价确实很难,因为你必须知道保障值多少钱,以及你能否承受失败的代价。
还有一点:并非每个开源项目都应该变成一家公司。惯常的做法是利用开放分发来建立广泛的依赖,然后在依赖足够深时通过更改许可证来实现商业化。更极端的版本是早期打造公共利益形象,后期再将已经成为公共基础设施的东西重新圈起来。这是糟糕的做法,而近期的例子并不少见。
价值链可能会分化为五种角色:定义并构建产品的开发者、托管并运行产品的云平台、分发产品的智能体平台、验证生成软件的认证机构,以及为其结果承保的保险公司。前两种已经存在。智能体平台刚刚兴起。针对智能体生成软件的验证和保险则完全不存在。
至少有三处。第一是时机。我在这方面已经犯过一次错,一开始我确信智能体即将压缩复杂系统的工作。如果能力持续复合增长,重写与继承之间的差距可能会比我预期的更快缩小。
第二是价值链。验证和保险是我刚才描述的结构中的承重部分,而两者都不存在。它们可能永远不会出现,在这种情况下,责任仍然集中在少数大型供应商手中,市场看起来与2015年非常相似。
第三是我可能因为自己构建的是系统软件而对其过度加权。这一论点对数据库、编译器和操作系统最为有力。对应用软件的大片中间地带最为薄弱,在那里重写可能确实比继承更便宜。
我反复回到的原则是:资本应当能够从生产公共能力中获得回报,但不能从没收公共能力中获得回报。
智能体让生产软件几乎免费。它们并没有让对软件负责变得更便宜。
转载声明:本文为转载整理,原文版权归原作者及原站点所有。
原文来源:TiDB Blog
原创地址:https://www.pingcap.com/blog/open-source-agents-write-code/
原文作者:Ed Huang;如有侵权,请联系管理员删除。