GitHub负责人：超40%的PR由Agent起草，传统流程该改改了

连 GitHub 的负责人自己，都已经不是所有项目都走 Pull Request 了。

微软 CoreAI 执行副总裁、GitHub 负责人 Jay Parikh 认为，PR 不该是每个开发者都得照走的流程。像那种用来验证想法的个人项目，他连 PR 都懒得建，Issue 也不想管，直接把想法写成代码，接着往下做。

这个表态来得不是时候吗？其实正赶上一个微妙节点。GitHub 最新数据显示，截至今年 9 月，平台上超过 40% 的 Pull Request 首版已由 Coding Agent 起草，而今年 3 月这个数字还只有 17%。半年光景，Agent 发起的 PR 数量涨了约 6 倍。代码越来越多由 Agent 生成，那过去照着人类开发者设计的软件协作流程，是不是也该动一动了？

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

有个讨论挺有意思：AI 既然能飞快生成代码，开发团队能不能拿它把大量开源依赖重写一遍，以此降低供应链风险？Parikh 的提醒是，AI 能替你重写代码，可后面的维护活儿不会因此凭空消失。

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

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

访谈中，主持人提到 OpenClaw 创建者 Peter Steinberger 曾说过 Pull Request 或许会走向终结。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，用来帮开发者发现更严重、更隐蔽的代码问题。另一项现场演示展示的是密钥保护：开发者不小心把密钥推送到仓库时，系统在推送过程中就识别并拦下了潜在泄露。

密钥泄露要防，软件供应链里的安全问题 GitHub 也得面对。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 执行，平台要撑的不只是代码存储和协作，还有任务调度、模型选择、持续执行、安全审查，以及围绕这些工作的控制权。