顶级 AI 开源项目如何用智能体工厂管理贡献者

GitHub 的拉取请求机制自诞生以来一直是开源协作的核心，但这一惯例正在被部分 AI 原生项目打破。Flue 和 tldraw 已明确拒绝接受外部贡献者的 PR，原因之一是这些 PR 大多由 AI 自动生成，内容质量难以保证。维护者们认为，与其花大量时间审查来路不明的代码，不如由项目方自己的智能体来主导开发流程，从而将人工精力集中在真正需要判断的决策上。

Vercel 为其开源 AI SDK 项目构建了一套完整的「软件工厂」。该项目每周 npm 下载量超过 2000 万次，到 2026 年 6 月底已积压逾 1000 个 issue 和近 800 个 PR。Vercel 的工厂由多类专职智能体组成：有的负责复现缺陷，有的负责实施修复，还有的专门负责代码审查。工程师 Lars Grammel 解释称，项目方对自己精心调优的智能体配置更有信心，因为其历史表现可追溯、可量化，而社区成员运行的智能体则缺乏这种可信度。

Astro 框架的创始人 Fred Schott 同样采纳了软件工厂的理念。他表示，过去五年里 issue 涌入的速度始终快于团队处理的速度，而引入智能体自动分类系统后，局面在六个月内彻底改变。现在，智能体会自动完成分类、复现，甚至在维护者介入之前就让用户验证修复方案。Schott 将这种变化描述为开源维护方式的根本性转变——issue 从无底洞式的积压变成了每周可按优先级处理的有序队列。

Astro 的自动分类系统还直接催生了一个全新的智能体框架——Flue。Flue 的贡献指南明确说明，所有外部 PR 将被自动关闭并转换为 issue 或讨论：缺陷报告和修复提案变为 issue，功能请求则变为讨论。这种方式将外部贡献视为「线索」而非「待办任务」，由项目团队结合最先进的大语言模型来决定优先级，再由智能体负责研究、设计、实现和初步审查。

tldraw 的创始人 Steve Ruiz 早在 2026 年 1 月便宣布自动关闭外部 PR，并在五个月后重申了这一立场。他认为，当 issue 描述足够清晰、智能体能够胜任代码编写时，接受人工贡献的意义便大打折扣。HashiCorp 联合创始人 Mitchell Hashimoto 则预言，未来大型开源项目将完全关闭外部代码贡献通道。这一趋势引发了社区的广泛讨论：传统上，PR 审查不仅是代码把关，也是培养未来维护者的重要途径，而这一功能正在被智能体流水线所取代。

尽管软件工厂显著提升了维护效率，但开源社区的参与问题并未得到根本解决。Schott 坦承，如果项目持续收窄贡献渠道，一旦核心维护者缺席，项目的可持续性将面临风险。Flue 和 tldraw 保留 issue 和讨论入口的做法，或许指向了一种新的平衡：社区成员通过提出问题、参与讨论来影响项目方向，而具体的代码实现则交由智能体完成。人类贡献者的价值，正在从「写代码」向「定义问题」迁移。

要点

• Vercel、Astro、Flue、tldraw 等顶级开源项目正以「软件工厂」取代传统社区 PR 流程，由多智能体流水线完成分类、复现、修复与审查。
• Vercel 的软件工厂上线四周内，已承担 25%–35% 的 PR 合并工作，并关闭了 70%–80% 的积压 issue，效果显著。
• 项目方对自己调优的智能体配置更具信任，认为其可追溯的历史表现优于社区成员提交的 AI 生成 PR。
• Flue 和 tldraw 将所有外部 PR 自动转换为 issue 或讨论，社区参与方式从「贡献代码」转向「定义问题与需求」。
• 开源社区面临新挑战：当智能体接管代码贡献，如何培养下一代维护者、保障项目长期可持续性，仍是待解难题。