GitHub 发明了拉取请求（pull request），18 年来它们一直默认开放。但如今一些顶尖的 AI 原生开源项目正在关闭 PR，因为他们找到了更好的方式。
这些项目包括 Flue 和 tldraw，拒绝接受外部贡献者的 PR——部分原因是它们通常是 AI 生成的。相反，维护者更倾向于使用自己的智能体来创建和管理 PR。
此外，许多项目已开始使用“软件工厂”来管理社区贡献。 通常这涉及一个智能体“团队”对 PR 进行分诊、复现问题（如果是 bug）、实现修复或新功能、进行审查，然后交回人类进行合并。
Vercel 为 AI SDK 打造的软件工厂
Vercel 最近发布了一篇题为“为 AI SDK 构建软件工厂”的文章。它描述了开源 AI SDK 项目——每周 npm 下载量超过 2000 万——如何部署智能体来控制其 PR 和 issue 积压——到 6 月底，积压已达到“超过 1,000 个未解决 issue 和近 800 个拉取请求”。
Vercel 的系统中有多种类型的智能体，每种都专注于不同的任务。例如，有一个智能体负责复现 bug，另一个负责应用修复，还有一个负责审查修复。
Vercel 建立这个软件工厂的关键原因之一是，它信任自己的智能体来完成工作，胜过信任社区成员运行的智能体。
“如果我们有一个非常具体的智能体，带有我们优化过的非常具体的提示词——并且我们知道，从历史来看，它在修复某一类 bug 方面非常成功——那么我们就会对那个特定的智能体配置建立信任，”Vercel 工程师 Lars Grammel 在
一段 YouTube 视频中解释道。
“对于开源项目，值得考虑拥有自己的智能体和自己的设置，而不一定信任社区，因为这实际上可以减少你的审查时间，”他补充道。
Grammel 还展示了其系统的部署架构，指出“有一个 UI，有一个 Web 应用，有一个底层 API，有一个执行空间，还有沙箱。”然后它与 GitHub 同步，自动触发其他操作。Grammel 提到的 UI 是定制的。
在这个软件工厂实施仅四周后，Vercel 声称该工厂现在“撰写我们合并的 25% 到 35% 的 PR，并关闭 70-80% 的 issue。”
Astro 的自动分诊系统
Astro Web 框架在 GitHub 上有 62,000 颗星，也采用了其创建者 Fred Schott 所称的“那个软件工厂理念”。
“五年来，我们一直处于问题涌入速度快于我们处理速度的境地，”Schott 告诉 Latent Space。
但现在，由智能体处理分诊工作，他们重新建立了控制。
“在过去六个月里，情况完全改变了，”他说。“我们现在可以用这些自动化来解决这些问题——处理分诊、复现、让用户在我们甚至还没看之前就实际验证机器人建议的修复。”
结果不仅是未解决 issue 大幅减少，而且 Astro 团队处理社区传入请求的方式也彻底改变。
“在我十多年参与开源的经验中，我从未见过这种情况，” Schott 说。“能够基本上把 issue 当作每周都要优先处理的事情——无论如何——而不是一个你不断修剪的积压清单。”
此外，Astro 的“自动分诊”系统直接促使 Schott 创建了一个全新的 agent 框架，名为 Flue。
Flue 不接受你的 PR，但欢迎讨论
借助 Flue，Schott 正在尝试一种对 PR 更为激进的做法。Flue 的贡献者指南指出，“我们将尝试重新构想一些事情”——部分是为了防止它所称的“顺手提交的 AI 垃圾 PR”。
Schott 解释说，基本上，Flue 项目中的每一个外部 pull request 都会被自动关闭，并转换为一个 issue 或 discussion。 Bug 报告和修复提案会变成 issue，功能请求会变成 discussion。
“如果你提交了一个 PR，没有恶意，我们只是会去替你把它表示为 issue 和 discussion。然后从那里开始，尝试找出正确的方式把人带进来。”
这有点像把收到的请求当作 * 潜在客户*，而不是维护者有义务去审查的一项工作。贡献者指南解释说，它利用团队自身的专业知识，结合
“我们所能获取的最好的 SOTA [State-of-the-Art，最先进] LLM”来帮助他们决定接下来要做什么。
一旦在 issue 或 discussion 中做出决定，agent 就会被部署去进行“研究、设计、实现和初步审查”。
如果我们的 agent 写代码，你的外部 PR 就毫无价值
与 Flue 一样，“源码可用”的 React 绘图工具 tldraw（50,000 颗星）会自动关闭外部 PR。
项目创建者 Steve Ruiz 在 1 月宣布了这一政策，五个月后又重申了该政策，指出这是“一个带有主见的决定，是为了回应我们编码方式的变化（更多讨论、更多 agent）、围绕公共贡献的社会实践，以及代码安全方面不断变化的格局。”
HashiCorp 联合创始人、Ghostty 创建者 Mitchell Hashimoto，如今是 Superlogical 的联合创始人，他更进一步。他认为“未来是大型开源项目将完全关闭贡献。”
Ruiz 回应道，“如果 issue 被相当好地明确指定，而且代码可以由 agent 编写，那么让人贡献代码就变得没那么有意义了。”
但是……社区会怎样？
传统上在开源中，pull request 由维护者审查，不仅是为了代码，也是为了教导贡献者并评估他们作为未来维护者的潜力。 如果像 AI SDK 和 Astro 这样的项目正在使用它们的 agent 来完成大部分代码审查和实现，那么那些想要更积极参与的社区成员又该何去何从？
Schott 认识到这是一个风险。
“它仍然留下了这个未填补的漏洞，好吧，如果你只是一直缩小项目范围，到了某个时候，你和我去度假了——会发生什么？它并不能真正解决所有问题。”
然而，Flue 和 tldraw 都不接受 PR，但确实接受新 issue 和讨论，这一事实或许指向了一种解决方案。那就是，通过更多地相互交流，社区成员能更好地了解——并信任——彼此，这既是一种向同行学习的方式，也可能证明你自己有资格成为维护者。
至于代码，如果维护者自己使用 AI 比接受外部代码贡献更容易，那么正如 tldraw 创始人 Steve Ruiz 所说，“最好将社区贡献限制在它仍然重要的地方：报告、讨论、视角和关怀。”