🔶 开源能否在取代它的 Agent 时代存活？
英文标题：🔶 Will Open Source Survive the Agents That Replaced It?
文章探讨了 AI Agent 能够快速生成代码后，开源软件是否会失去存在动力的问题。作者指出，Agent 降低了代码生成成本，却没有降低人工审查成本，这可能进一步加重少数核心维护者的负担，并削弱下载量、Star 等传统激励。与此同时，Agent 的能力依赖于公开的 README、测试、Issue 和代码历史；如果开源产出减少，模型也将失去持续更新的高质量知识来源。对开发者和行业而言，Agent 生成的代码无法替代成熟项目长期积累的边界案例、维护记录和集体工程判断，开源或许正从“被下载的软件”转变为“用于训练和审计 Agent 输出的公开基准”。
147.9 KB
28.1 KB
中文
“Agent 改变了生成与审查代码之间的成本平衡。通过 AI Agent 生成代码可以自动化，成本也会变得低廉，因此代码输入量不断增加；但审查仍是一项由人工完成的活动，负担落在少数核心开发者肩上。”
matplotlib 维护者 Tim Hoffmann，2026 年 2 月 11 日在 GitHub 上的评论
假设你需要为一个个人项目做个小型工具。几年前，这意味着进行一次搜索、阅读 README，再快速浏览 Issue 页面，看看是否有人抱怨过你即将依赖的那个功能。现在，你只要向 Agent 提问，30 秒后就能得到可完成任务的代码。你无需安装任何东西、阅读 README，也不会知道你如今在线上环境运行的模式最初是谁写的。
开源是一个让陌生人公开编写内容、从而让其他陌生人不必重复造轮子的生态系统。如果通往可用代码的最快路径不再经过任何人的代码仓库，那么它是否仍有存在的理由，正是值得追问的问题。
为开源举行葬礼的理由
悲观的版本值得被严肃对待。维护一个开源软件包从来都不赚钱。其中大部分工作无人付费、少有感谢，而且越来越容易成为一些理所当然的 Bug 报告的靶子——这些人从未想过要赞助自己所依赖的项目。维护者真正能获得的回报只有一种货币：可见度，包括下载量、Star、简历上的一行经历，以及偶尔一句“这帮我省了好几个小时”的评论，足以让整件事显得值得。
拿走下载量，也就拿走了唯一始终可靠的回报。如果 Agent 只需根据两句话的提示，就能重建你软件包中有用的 80%，大多数人甚至不会知道你的项目存在，更不用说给它点 Star。更少的 Star 意味着更低的持续维护动力；动力下降则意味着修复变慢、文档陈旧，最终当仓库真正出问题时，已经没人再关注它。人们会一个接一个地不再出现，直到谁都不在了。
我维护着一个名为 Truss 的小型 Laravel 软件包。它能展示应用真实数据库 Schema 的实时 ER 图（ERD），只呈现结构，绝不包含数据。截至 2026 年 9 月 21 日，它在 Packagist 上的安装量略超过 24,000 次，在 GitHub 上获得了 281 个 Star，大约每 85 次安装才有一个人愿意点 Star。这个差距并不是由 Agent 造成的。在我第一次让 Agent 接触这段代码之前，它就已经存在了，这说明开源维护的回报从一开始就薄得令人不安。
反对这一观点的理由
但 Agent 并不是凭空发明了你的软件包。它通过阅读数百万个真实项目学会了这些模式：你的 README、你的测试套件、某个有人准确解释为何朴素方案会失效的 Issue，以及某次维护者耐心否决错误想法并说明原因的 Pull Request。Agent 给出的每一个即时答案，都是对某人曾经公开完成、随后无偿分享的工作的压缩重演。
这正是“开源正在消亡”的论点往往跳过的部分。如果没有人继续公开编写这些材料，Agent 不会变得更聪明，只会变得陈旧。它们会自信地复现昨天的 Bug 和去年的最佳实践，因为已经没有人更新它们赖以建立的事实基础。扼杀公开发布的激励，就等于污染每个 Agent 饮用的水井。受伤害的不只是那些不再因贡献而获得感谢的维护者。
无聊部分实际上会怎样
还有一个更直接的讽刺值得仔细思考。围绕“让 Agent 直接构建它”的许多兴奋，来自那些希望摆脱对他人项目、其路线图和维护者心情依赖的团队。但负责构建的工具本身也是产品，由公司打造，也有自己的路线图和寿命。许多人曾围绕 Roo Code 建立真实工作流，而这款工具于 2026 年 5 月停止运营，其代码仓库也被归档。原本以为自己已摆脱对陌生人项目依赖的团队，最终却依赖于另一个陌生人的项目——同样会消亡，却没有前者多年积累的底蕴。
由 Agent 构建的代码，也往往跳过了成熟开源软件包最初之所以值得信任的部分：多年里由别人替你踩过的边界案例；没有变更日志；没有“我们试过那个方案，但因为某个原因又回退了”的历史；也没有第二位工程师曾与作者争论过某个抽象是否值得。它能运行，直到遇到那个没人想到要问 Agent 的具体情况；届时，你就得自行调试，却没有多年艰难积累的经验来告诉你它为何会出错。
下载量中看不见的部分
或许这里真正发生的既不是死亡，也不是存续，而是角色变化：开源项目变成了衡量 Agent 回答质量的参考基准，无论是否还有人下载它。仍然需要有人正确地、公开地写出某种模式的权威版本，让 Agent 最初能够从中学习，也让审计 Agent 输出的人能够拿它进行诚实的比较。这个角色不会带来 Star 数，甚至未必有可见的署名，但可以说，它如今比人们还会点击“clone”时更承担关键作用。
我不认为这是一个令人舒适的答案，也不确定它是否正确。只是相比“开源已死”或“其实什么都没变”这两种说法，它似乎更接近正在发生的现实。
我没有一个简洁答案的问题是：如果再也没有人安装你的软件包，因为 Agent 已经从中学会了这种模式，那么你是否仍然是写下它的那个人？
English / 原文
âAgents change the cost balance between generating and reviewing code. Code generation via AI agents can be automated and becomes cheap so that code input volume increases, but review is still a manual human activity, burdened on the shoulders of few core developers.â
Tim Hoffmann, matplotlib maintainer, on GitHub, February 11, 2026
Say you need a small utility for a side project. A few years ago that meant a search, a README, a quick scan of the issues tab to see if anyone had complained about the thing you were about to depend on. Now you just ask an agent, and thirty seconds later you have code that does the job. You never install anything, read a README, or find out who wrote the pattern youâre now running in production.
Open source is the ecosystem where strangers write things in public so other strangers donât have to. Whether it still has a reason to exist once the fastest path to working code doesnât run through anyoneâs repository is the question worth asking.
The case for the funeral
The bleak version deserves to be taken seriously. Maintaining an open-source package has never paid well. Most of it is unpaid, thankless, and increasingly a target for entitled bug reports from people who never once considered sponsoring the thing they depend on. The one currency maintainers actually got in return was visibility: downloads, stars, a line on a CV, the occasional âthis saved me hoursâ comment that made the whole thing feel worth it.
Take away the downloads and you take away the only reward that was ever reliably there. If an agent can reconstruct the useful 80% of your package from a two-sentence prompt, most people never learn your project exists, let alone star it. Fewer stars mean less motivation to keep going, and less motivation means slower fixes, staler docs, and eventually a repository nobodyâs watching when it actually breaks. People just stop showing up, one at a time, until nobodyâs left.
I maintain a small Laravel package called Truss, a live ER diagram (ERD) of an appâs real database schema, structure only, never data. As of September 21, 2026, it had a little over 24,000 installs on Packagist and 281 stars on GitHub, roughly 85 installs for every person who bothered to star it. That gap didnât come from agents. It was already there before Iâd ever pointed one at the code, which says something uncomfortable about how thin the reward was to begin with.
The case against
Except the agent didnât invent your package out of nothing. It learned the pattern by reading millions of real ones: your README, your test suite, the issue where someone explained exactly why the naive approach breaks, the pull request where a maintainer patiently rejected a bad idea and explained why. Every instant answer an agent gives you is a compressed rerun of work that a person did once, in public, and then gave away.
Thatâs the part the âopen source is dyingâ argument tends to skip. If nobody keeps writing that material in the open, agents donât get smarter, they get stale. They start confidently reproducing yesterdayâs bugs and last yearâs best practices, because nobodyâs left updating the ground truth they were built on. Killing the incentive to publish poisons the well that every agent drinks from. It hurts more than just the maintainers who stop getting thanked for it.
What actually happens to the boring part
Thereâs also a more immediate irony worth sitting with. A lot of the excitement around âjust have the agent build itâ comes from teams trying to escape dependency on someone elseâs project, its roadmap, its maintainerâs mood. But the tools doing the building are themselves products, made by companies, with their own roadmaps and their own mortality. Roo Code, a tool plenty of people had built real workflows around, shut down and had its repository archived in May 2026. The team that thought it had escaped depending on a strangerâs project ended up depending on a different strangerâs project, with the same mortality and none of the years behind it.
Agent-built code also tends to skip the part that made a mature open-source package worth trusting in the first place: years of someone else hitting the edge cases for you, no changelog, no history of âwe tried that and reverted it because,â no second engineer who ever argued with the author about whether the abstraction was worth it. It runs, until it hits the exact case nobody thought to ask the agent about, and then youâre the one debugging it without the years of hard-won experience that would tell you why it broke.
The part that doesnât show up in a download count
Maybe whatâs actually happening here isnât death or survival, itâs a change of job: the reference an agentâs answer is measured against, whether anyone ever downloads it or not. Somebody still has to write the canonical version of a pattern, correctly, in public, for the agent to have learned it from in the first place, and for anyone auditing its output to have something honest to compare it against. That role doesnât come with a star count, or even visible credit, but itâs arguably more load-bearing now than it was when people actually clicked âclone.â
I donât think thatâs a comfortable answer, and Iâm not sure itâs the right one either. It just feels closer to whatâs actually happening than either âopen source is overâ or ânothingâs really changing.â
The question I donât have a tidy answer to is this: if nobody ever installs your package again because the agent already learned the pattern from it, were you still the one who wrote it?