GitHub负责人：40%代码由Agent写，PR流程该改了？

Jay Parikh 是微软 CoreAI 执行副总裁，也是 GitHub 的负责人。他如今已经不在所有项目里使用 Pull Request 了。在他看来，PR 不该成为每个开发者都得走的流程。有些个人项目只是用来验证想法，他连 PR 都不建，Issue 也不想管，直接把想法写成代码，接着往下开发。

这番话出现在一个微妙的时间节点上。GitHub 最新数据显示，截至今年 9 月，平台上超过 40% 的 Pull Request 首版由 Coding Agent 起草；今年 3 月，这个数字还只有 17%。半年左右，Agent 发起的 PR 数量涨了约 6 倍。代码越来越多地由 Agent 生成，过去照着人类开发者设计的协作流程，是不是也该跟着调一调？

11 月 7 日上线的 Latent Space 播客访谈里，Parikh 聊了 GitHub 对这件事的思考。除了 PR 还有没有必要，他还谈到多模型协作、代码审查、软件供应链安全，以及 AI 编程的投入产出。

有个话题挺有意思：AI 既然能快速生成代码，开发团队能不能用它重写大量开源依赖，把供应链风险降下来？Parikh 的提醒是，AI 替你重写代码，后面的维护活儿并不会凭空消失。

Pull Request 不必是所有项目的必经环节

传统软件协作里，Pull Request 一般用来提交代码变更，也给团队成员一个审查、讨论和合并代码的地方。Coding Agent 加入开发过程后，一些开发者开始重新琢磨：这套流程在所有场景下都还适用吗？

访谈中，主持人提到 OpenClaw 创建者 Peter Steinberger 曾提出 PR 或许会走向终结。Parikh 对此回应说，GitHub 会跟着新的开发范式和工作方式调整平台。某项功能如果对部分用户没用了，或者他们不希望它成为必需环节，平台可以考虑让它变成可配置的。

Parikh 拿自己的使用习惯举例：GitHub 用户对协作和管理流程的需求并不一样。大型企业那边，代码审查、权限管理、变更记录可能缺一不可；个人实验项目则未必，繁复的协作机制未必能带来额外价值。

不过这并不代表 GitHub 认为代码审查不必要了。Parikh 讨论的是不同开发场景要不要遵循同一套协作流程：个人实验项目可以图直接、图高效，涉及多人协作、权限管理和代码质量要求的企业项目，审查机制还是得有。

对 GitHub 来说，这意味着一个问题需要重新想：开发者能直接向 Agent 描述需求、让它完成代码修改，过去以人为中心设计的协作流程，还该不该是所有项目的默认选项？

至少 Parikh 的看法是，这个答案不该由平台替所有开发者来定。

AI 编程不必总用最强模型，GitHub 想让系统自己选

开发流程之外，Parikh 还谈到另一个具体问题：模型的能力、价格、响应速度各不相同，开发者怎么给每项任务挑合适的模型？不同开发任务对模型能力的要求并不一样。简单的代码修改，可能一个更快、更便宜的模型就够了；复杂的调试和架构调整，也许需要更强的推理能力，甚至要多个模型配合。

Parikh 希望把一部分选择工作交给系统。按他的说法，Copilot Harness 和 Copilot Fusion 可以打配合：前者负责接入模型和工具，编排开发过程中的工作；后者根据任务挑模型，省得开发者在能力、速度、成本之间反复权衡。

这套机制也有代价。参与的模型更多，通常意味着调用更多、耗时更长、AI 积分消耗更高。所以 GitHub 想让系统在质量、速度和成本之间做权衡，同时把模型和工具的选择权留给开发者。

GitHub 在大会上还公布了一组对比数据：在 Artificial Analysis Coding Agent Index 中，Fusion Max 与 Opus 5.5 Max 的分数差距不到 2 分，但前者单任务成本约为后者的一半，耗时减少约 40%。

模型选择之外，GitHub 还在试让开发者在不同设备和工具之间接着干活。Parikh 举例说，一个人可以先在手机上发起任务，之后打开电脑继续处理；有了新想法，也能通过手机补给 Agent，让它接着干。

GitHub 的 Session continuity 功能，支持开发者在 GitHub Copilot 应用、VS Code、命令行和网页之间跟进同一个云端 Agent 会话。按 GitHub 的介绍，切换设备或工具时，Agent 可以在云端继续工作，开发者也能回到同一会话里查看进展。

AI 能重写 2000 个开源依赖，维护责任却不会消失

Agent 生成的代码越来越多，开发团队要审查的内容也在增加。Parikh 表示，GitHub 正在加强代码审查和安全扫描的能力，希望开发速度提上去了，开发者还能发现代码里的问题。

GitHub Universe 大会上，GitHub 介绍了 Copilot code review Max，帮开发者找出更严重、更隐蔽的代码问题。另一项现场演示展示的是密钥保护：开发者不小心把密钥推送到仓库时，系统在推送过程中就识别并拦下了潜在泄露。

密钥泄露要防，软件供应链里的安全问题也得面对。Parikh 表示，GitHub 正与微软安全团队、开源项目维护者合作，降低包管理器面临的风险，并处理已经被攻陷的代码仓库。

开源软件安全这块，播客主持人又往前想了一步：要是 AI 把写代码和安全审查的开销都压下来，开发团队能不能自己实现一部分功能，从而少依赖外部开源组件？他举了个例子——一个项目依赖 2000 个开源组件，每个组件都可能成为潜在的风险面；假如只留其中 20 个，剩下那些由团队自己写，风险是不是就能降下来？

Parikh 觉得这事可以聊，但拿自研替代开源依赖并非包治百病。哪怕团队只保留 20 个开源项目，其余 1980 个组件原本承担的功能，往后还是得由团队自己维护。

AI 让代码实现的门槛低了，可软件维护不只是写代码和改代码。一个组件要不断适配外部接口、补安全漏洞、处理兼容性问题，还得有人判断改动靠不靠谱、会不会波及依赖它的其他系统。这些活就算有一部分能交给 Agent 自动干，最后担维护责任的仍然是人。

对企业来说，重写开源组件实际上是把原来由开源社区共同分摊的维护成本挪到了内部。代码生成便宜了，软件的长期拥有成本未必跟着降。况且，少依赖外部组件也不等于风险就没了——企业自己写的组件照样可能有漏洞，后续一样得持续检查和修复。

所以 Parikh 提醒开发者，别光想代码写不写得出来，还得想资金、人力、时间该往哪儿投。在他看来，开源软件对企业、开发者和创作者依然有价值。他更愿意和开源社区一道解决软件安全问题，而不是让每个团队都关起门来自己搞。

从 Token 成本到实际交付：企业该怎么衡量 Coding Agent？

Agent 接手的开发任务多了，企业自然也得摸清 AI 到底用了多少、花了多少。

Parikh 说，GitHub 正在提供相应工具，帮组织查看费用，还会在模型选择上给优化建议。比如某个团队正用某种模型处理某类任务，系统能提示有没有别的模型可选。面向大型企业，还得有使用限额这类治理手段。

不过花销只是衡量的一部分。主持人提到，企业负责人未必在乎团队买 Token 花的那点钱，更在意这些投入值不值。Parikh 同意这个说法，并认为团队得在投入和结果之间建立起反馈。

两人衡量结果的侧重点不太一样。Parikh 举例说，Token 支出要是带来了收入，企业就能据此判断投入划不划算；主持人则指出，程序员一般不对收入直接负责，他们能直接看到的成果，可能是某个功能交付了。

Parikh 接着讲，除了收入，还能看成本节省、用户参与度、留存率和客户满意度这些指标。在他看来，产品团队和工程团队都该盯住这些能衡量的结果。

这也点出企业衡量 AI 编程价值时的现实难题：Token 消耗好统计，代码提交和功能交付也相对好数，可这些产出有没有真的提升软件质量、开发效率或业务表现，往往得等更长时间才看得清。

比如 Agent 短时间就能生成大量代码，但这些代码能不能过审查、要不要返工、最终跑不跑得稳，都会影响实际交付。代码生成量上去了，团队的效率未必就涨了同样的幅度。

所以对已经开始规模化用 Coding Agent 的企业来说，除了盯模型调用成本，还得琢磨怎么衡量 Agent 实际干了多少活，以及这些活最终创造了什么价值。

Agent 时代，GitHub 自己也得重建基础设施

Agent 带来的变化，不只出现在开发者手里的工具上，也正在改变 GitHub 平台自身的基建需求。

自动化开发活动一多，GitHub 要处理的代码提交、仓库操作和计算任务都跟着涨。Parikh 表示，团队一直在调整底层技术架构，好适应新的使用规模。

其中一项重头工作是迁到 Azure 多区域部署。按 Parikh 在 GitHub Universe 2026 期间发的文章，GitHub 预计 2027 年初完成这次迁移，并会持续扩充计算、存储和网络容量。

可对 Parikh 来说，将来真正难猜的也许不是 GitHub 要处理多少代码，而是开发者会怎么组织 Agent 干活。一个开发者未来管几十个、几百个还是几千个 Agent，他自己也说不准。

对 GitHub 而言，挑战也在变：软件开发越来越多由 Agent 执行，平台要支撑的就不只是代码存储和协作，还包括任务调度、模型选择、持续执行、安全审查，以及围绕这些事的控制权。