不再欢迎外部 PR？开源项目转向智能体协作
过去，向开源项目贡献代码的典型路径是提交拉取请求（Pull Request，简称 PR），再由维护者审查、合并。如今，一些项目正在改变这套协作方式：社区提出问题，项目自己的智能体负责实现，维护者做最终把关。
这并不意味着所有项目都关闭了外部贡献入口。不同项目的调整程度并不相同：Flue、tldraw 拒绝接受外部贡献者的 PR；Vercel 的 AI SDK 则引入了多智能体工作流，处理不断积压的 Issue 和 PR。
为什么不再直接接受外部 PR？
Flue、tldraw 拒绝外部 PR 的部分原因，是这些提交往往由 AI 生成。相比接收社区成员使用各自工具生成的代码，维护者更倾向于使用自己配置和管理的智能体来创建、处理 PR。
这里的关键区别，不只是代码由人还是 AI 编写，而是维护者是否熟悉并信任生成代码的工作流程。
对维护者而言，自己配置的智能体有明确的任务范围、经过优化的提示词，以及可供参考的历史表现。这些条件有助于形成对特定智能体配置的信任，并减少审查所需的时间。
Vercel：用“软件工厂”处理积压
Vercel 为 AI SDK 建立了一套“软件工厂”，尝试通过智能体分工来管理社区贡献。
AI SDK 的 npm 每周下载量超过 2,000 万次。在其披露的六月底积压情况中，项目有超过 1,000 个未关闭的 Issue，以及接近 800 个 PR。
这套系统并非让单个智能体包办所有工作，而是为不同任务设置不同角色。例如：
- 问题复现智能体：尝试复现报告中的缺陷。
- 修复智能体：针对问题实施修复。
- 审查智能体：检查修复结果。
在这类“软件工厂”的典型流程中，智能体团队会完成任务分流、问题复现、缺陷修复或功能实现，以及代码审查，最后交由人类决定是否合并。
自动化覆盖了更多开发步骤，但最终合并仍由人类把关。
信任从单次提交转向可重复的流程
Vercel 工程师 Lars Grammel 对这套做法的解释是：当一个智能体使用特定且经过优化的提示词，并在某类缺陷修复中持续取得良好表现时，团队就能逐步建立对这一配置的信任。
因此，维护者需要评估的不再只是某一次提交的代码，也包括一套已知配置在特定任务上的可靠性。与逐一审查社区成员通过不同智能体生成的实现相比，使用项目自己的智能体配置，可能降低审查负担。
需要区分两种变化
这些案例涉及两个相关、但并不相同的选择：
- 调整贡献入口：如 Flue、tldraw，拒绝外部 PR，改由维护者自己的智能体处理实现。
- 调整内部流程：如 Vercel AI SDK，用多个智能体分工处理积压任务，并保留人工合并环节。
不能据此认定所有开源项目都将停止接受外部 PR，也不能把采用“软件工厂”等同于关闭社区贡献。更准确地说，这些项目正在重新划分社区、智能体与维护者之间的职责：谁提出问题、谁编写实现，以及谁对最终合并负责。