GitHub Octoverse 2026：活动激增，智能体发起超过 40% 的 Pull Request
GitHub 于 10 月 28 日发布了 Octoverse 2026 报告，称 9 月份超过 40% 的 Pull Request 首稿由智能体提供。Pull Request 是指在代码变更并入项目之前，提交以供审查的变更提案。这一发现表明，自动化起草已进入软件开发的核心工作流，但生产力与质量仍是两个不同的问题。
GitHub Octoverse 2026 还报告称，其平台上的活动量创下纪录。这让“产出变更”与“交付有用的软件”之间的区别变得更加重要。AI 编程智能体是使用 AI 模型执行开发任务的软件，其生成的工作成果仍可能需要大量人工判断。
对工程负责人而言，核心矛盾在于代码产出增长与评估能力之间的平衡。METR 早期研究表明，为什么应将这两项指标分开看待。与此同时，GitHub 对 Anthropic 和 OpenAI 智能体的支持，使相互竞争的供应商进入同一审查环境。实际问题在于，有多少有用工作能经受住完整流程的检验。
GitHub Octoverse 2026 记录了变更发起方式的转变
根据 GitHub 的 Octoverse 研究结果，开发者在报告年度内进行了 179 亿次 push，并合并了 13 亿个 Pull Request。Push 指将已保存的代码变更发送到 GitHub。Push 总量超过此前两年的总和。
统计窗口为 2025 年 10 月 1 日至 2026 年 9 月 30 日。多数数据涵盖公开和私有项目。GitHub 使用可比定义重新计算了早年数据；在将这些数字与此前发布的报告比较时，这是一项重要限定。
由智能体发起的占比从 3 月的 17% 上升至 9 月的 40% 以上。GitHub 将此类请求定义为可检测到由智能体生成首稿的请求。
这一采用率指标衡量的是变更提案如何开始，而非智能体独立完成了多少成品软件。
这一区别改变了标题数字的含义。开发者可能定义任务、否决初步方案、重写部分结果，并作出最终批准决定。将最终成果称为完全自主完成，会抹去这些贡献。
分母同样重要。Pull Request 的占比不能直接换算为代码占比、工时占比或产品功能占比。变更提案在规模、难度和重要性上各不相同。
不妨比较一处文档修正与支付授权机制的改动。两者都可以形成一个 Pull Request。即使平台将每个请求都记录为单项提案，它们的审查要求和影响也大相径庭。
同样，提案数量上升可能反映多种发展。团队可能尝试更多项目、将工作拆分为更小部分，或生成更多修订。这些可能性需要不同的解读。
因此，这份报告值得关注，但不应承载 AI 编程争论附加的所有结论。它记录了可观测开发行为的重大变化。要确定这种行为的经济价值，还需要额外证据。
因此，对于关注 GitHub 智能体采用情况的读者而言，有用的起点是准确归因。这些是 GitHub 的平台测量结果，采用该公司的定义和检测边界。它们并非对 AI 在全部软件开发中贡献的独立审计估算。
即使如此，这项消息仍具有意义。起草是工程工作的重要入口。当智能体参与其中时，审查系统便成为其提案与项目要求及人工问责相遇的场所。
这让维护者、工程经理和安全审查人员都直接置身于这一故事之中。他们的决定决定了额外活动会转化为有用软件，还是变成更多未完成提案的集合。
更多草稿给审查能力带来压力
当工程团队能够在不失去对质量或优先级控制的前提下评估变更时，更快的起草速度才能带来收益。
这是一项运营层面的论点，并非声称每个团队都已面临审查队列过载。压力源于工作流本身：产出一项提案与为其承担责任，所需工作并不相同。
审查者必须先确定这项变更意图实现什么，然后判断其实现是否符合这一意图。自动化测试可以支持这种判断，但其效用取决于它们实际检验了什么。
确认预期输出的测试，仍可能忽略关于客户行为的错误假设。一项变更可以满足分配给它的任务，却与产品的另一部分发生冲突。这些都是需要审查提案证据的原因。
影响也不止于提交时的正确性。还必须有人维护实现、解释其中的决策，并在需求变化时作出响应。额外代码在带来即时价值的同时，也会产生相应义务。
对工程经理而言，这带来一个能力问题：如果起草变得更容易，团队应如何在新提案、既有维护和生产可靠性之间分配注意力？若不调整这些优先级就增加提交量，约束只会被推向下游。
Google Cloud 的 DORA 研究人员在对 AI 开发权衡的分析中描述了相关矛盾。他们报告称，创建阶段节省的时间往往会转移到审计和验证环节。他们将 AI 视为既有组织优势与弱点的放大器。
这一观察为解读平台数据提供了有用框架。需求清晰、检查可靠的团队，与所有权不明确的团队，起点并不相同。为两者提供更快的起草能力，并不会消除这些差异。
直接压力落在批准变更并对其后果负责的人身上。维护者不能合理地将智能体的自信视为证据的替代品。工程经理也不能仅凭提交数量增加就推断客户价值。
安全团队也面临类似的资源分配问题。某项提案可能需要仔细审查，因为它改变了访问规则、处理敏感信息，或引入了外部组件。其来源并不决定其风险。
产品团队同样扮演角色。实现更容易时，团队更容易追逐定义松散的需求。当生成看似合理的实现所需付出更少时，清晰的验收标准就更有价值。
对个人开发者而言，其含义比“学会如何提示”更具体。有价值的技能，是将所需变更与证明其有效且适合项目的证据联系起来。
这还包括保留决策背后的推理。试图构建 可搜索知识库的团队面临相关挑战：当原作者不在场时，如何让技术上下文仍然可用。
文档无法批准一项变更。但它可以帮助审查者理解批准所依赖的约束。随着起草加速，这种共享上下文与生成工具本身一样值得关注。
Copilot、Claude 和 Codex 在同一工作流中竞争
竞争背景有助于解释，为什么智能体采用正成为一个工作流问题。开发者无需离开团队讨论和批准变更的场所，就能接触不同供应商。
GitHub 在 2 月的公告中推出了处于公开预览阶段的 合作伙伴编程智能体，其中包括 Anthropic 的 Claude 和 OpenAI 的 Codex。公告描述了从 GitHub 分派工作，以及审查这些智能体生成的 Pull Request 草稿。
这项公告确立了报告年度内的产品方向，但不应被解读为当前可用性或访问条件的完整清单。
对 GitHub 而言，托管相互竞争的智能体，使审查工作流与其自身编程助手一样成为战略资产。
即使开发者针对某项任务偏好不同供应商，平台仍可保持核心地位。工作仍需要一个归宿、历史记录、讨论空间和批准流程。
对 Anthropic 和 OpenAI 而言，进入这一环境为其切入开发工作提供了另一条路径。在团队已管理软件变更的地方，它们的智能体可以竞争任务分配。
这种比较并不能证明哪个智能体产出的结果更好。分发协议和产品公告无法回答这个问题。它们展示的是供应商如何触达用户，而不是如何可靠地完成可比任务。
这一区别在解读 GitHub 智能体采用情况时很重要。更多由智能体发起的提案，并不会自动说明某个供应商胜出。工作流的采用与该工作流内的竞争是两项不同的发展。
2 月公告中出现了一个具体例子：开发者可以将一个 issue 分配给智能体，并收到供审查的草稿。Issue 记录一项请求的任务或问题。这让委派具有可识别的起点和可审查的结果。
重要性在于交接过程。一项请求变成一次尝试性的实现，随后回到一个人们可以检查变更并要求修订的系统中。智能体参与的是既有的问责结构。
对于评估供应商的团队而言，这种结构应使比较更有意义。相关问题是，供应商能否以可接受的审查成本完成团队的实际工作。一场精致的演示无法证明这一结果。
设想在一项重复性的维护任务上比较智能体。一项有用的评估应考虑每份提案是否回应请求、遵守项目惯例，并提供可信的验证。统计生成的文件数量，回答的是另一个问题。
将智能体整合进团队也是如此。获得工具访问权限只是开始。权限、任务边界和批准责任仍需要明确决定。
保留一致的审查环境还有实际好处。团队可以在不同时替换每一项周边流程的情况下评估新供应商。这使供应商差异更容易与工作流变化区分开来。
因此，竞争故事支撑了核心矛盾。供应商正在既有工程环境中让起草更易获得。这种可及性的价值，取决于团队能否成功地将相互竞争的提案转化为已接受、可维护的变更。
更快的合并仍留下重要质量问题
GitHub 报告称，9 月涉及智能体的请求在两周内的合并率达到 90%，而未检测到智能体参与的请求约为 86%。
合并记录的是对项目的接受；它并不能证明这项变更具备长期可靠性或商业价值。
这种限制同样适用于由人工发起的改动。基于现有证据作出的批准可以是合理的，但后续行为仍可能暴露此前遗漏的交互影响。软件质量会随时间逐渐显现。
更快获得批准，可能体现了改进；也可能反映提交任务、项目实践或所需审查力度的差异。观察性比较无法自动区分这些解释。
任务选择尤其重要。团队可能会将自己已知如何定义和验证的工作交给代理。更模糊的任务则可能继续由开发者承担。若不考虑这些群体之间的差异，直接比较会有夸大结果的风险。
反过来的可能性也值得考虑。代理可能让过去被忽视的维护工作变得可行，从而扩展团队尝试处理的工作范围。公平的评估应当计入这些有价值的新增产出。
这正是简单化解读在两个方向上都会失效的地方。更多活动并不足以证明每个团队都变得更高效；缺少普适的生产率估计，也不足以证明这些活动没有价值。
METR 的开发者生产率实验说明了测量为何重要。其于 2025 年初开展的随机研究，涵盖 16 名经验丰富的开发者，他们在熟悉的开源项目中完成了 246 项任务。允许使用 AI 后，完成时间增加了 19%。
这些发现描述的是特定人群、任务场景和一代工具。它们不应被视为对 2026 年末代理性能的直接测量。
该研究在此的相关性在于方法论。观察到开发者使用某种工具，并不能说明他们完成等效工作快了多少。这需要可信的对照比较。
随着行为变化，历史研究也需要更新。一项结果可以在其原始场景中继续有效，却对较新的工作流越来越缺乏参考价值。把它当作永恒不变的结论，同样是一种测量误差。
质量比较也需要类似谨慎的边界。一项拟议改动可能通过现有检查，却增加了未来维护者必须承担的复杂性。反之，规模更大的实现也可能移除笨拙的变通方案，减少未来工作量。
因此，审查者需要与任务相关的证据。相关检查、可理解的推理，以及对行为变化的清晰说明，比来源标签提供的信息更多。
对企业采购方而言，这带来了评估挑战。采用情况仪表盘很容易概括，而避免的事故和降低的维护负担则需要更长时间来确认。有说服力的评估应承认这种差异。
恰当的结论应当具体。GitHub 的接受数据提供了关于改动如何通过其平台流转的信息，但仍为进一步研究返工、可靠性、审查者投入和有效交付留出了空间。
这一缺口正是测量议程的一部分。它并不要求假定代理普遍有益，也不要求将其贡献视为纯粹噪声。
随着工作变化，衡量代理生产率变得更困难
测量挑战不止于选择正确的仪表盘。代理的使用可能改变开发者尝试哪些任务，以及他们如何分配注意力。
在其 2026 年 2 月的生产率研究更新中，METR 表示，其后续实验对当前 AI 生产率影响的估计并不可靠。招募方式、任务选择和并发使用代理都使解读变得复杂。
研究人员认为，开发者很可能比早期估计获得了更多收益。但他们也强调，其数据对这种改进幅度只能提供较弱的证据。
可靠的评估必须同时考虑工作本身的变化，以及执行工作的工具变化。
这很重要，因为固定任务的比较回答的是一个有边界的问题。它可以估计辅助工具如何影响某项具体任务，却无法完整捕捉当辅助工具改变人们选择的任务时所发生的变化。
假设一名开发者此前因需要投入过多连续精力而推迟了一项繁琐的迁移工作。代理可能让这项工作在原本忙碌的一周内变得可行。其收益包括完成原本会一直搁置的事项。
再看相反的情况。更容易的草拟过程可能鼓励团队在尚未确认用户确有需求前就实现某项功能。实现本身可以在技术上成功，却消耗了本应投入其他更重要事务的注意力。
这些例子是分析上的可能性，而非 Octoverse 数据集中的报告结果。它们说明了为何有效交付需要与意图和结果建立联系。
并行工作又带来另一项复杂因素。开发者可能在审查一个提案的同时，让代理处理另一项任务。将代理的实际运行时长当作人工工作时间，会误述这种安排。
但忽略监督同样会扭曲结果。任务准备、被打断的工作、被否决的方法和最终审查，都应纳入对工作流的评估。核算边界会影响结论。
对组织而言，这意味着应采用多种互补证据。可比任务评估可以考察完成成本；运营记录可以反映接受情况和返工；产品结果则可以确认交付的改动是否帮助了用户。
没有单一指标能捕捉一切。因此，更合理的做法是明确某项指标代表什么，而不是将不同结果压缩为一个通用生产率分数。
一个团队可能提升交付速度，却在维护上遇到困难。另一个团队可能减少重复性劳动，但由于审批仍受其他环节限制，发布频率并未提高。这两种情况都应以符合其实际体验的方式描述。
比较团队时也应遵循同样的纪律。一个具有严格可靠性要求的成熟服务，与一个新的实验性项目并不相同。它们的提交数量不应变成开发者效能的排名。
GitHub Octoverse 2026 可作为开发环境变化的证据。当平台活动与任务级研究及组织成果一并考量时，其更广泛的意义会更加清晰。
对开发者而言，实际关切在于工作是否更容易完成、也更容易维护。对管理者而言，关切则在于这些收益能否在整个团队中持续存在。当草拟变得普遍时，这两个问题都不会消失。
关注审查投入、可靠性和可比任务结果
下一类有用证据，应将代理参与与提案出现后发生的情况联系起来。在未来数月里，读者应关注能够澄清草拟与交付关系的变化。
最有力的后续证据，将把代理参与的工作与审查投入、生产结果和可信的任务比较联系起来。
第一个信号是更完善的审查投入报告。平台供应商和工程团队应展示，获接受的代理提案需要多少人工关注。仅凭等待时间无法证明这一点。
一个请求可能在队列中等待很久，却几乎不消耗审查者精力。另一个请求可能快速推进，却需要密集讨论。区分这些情况，会使接受统计数据更具信息价值。
如果可比工作中的审查投入下降，将强化代理改善整个工作流的论点。审查投入上升则意味着部分草拟节省转移到了监督环节。
读者还应考察团队如何记录被拒绝的工作。仅关注成功合并的仪表盘，可能遗漏了评估那些从未获得接受的提案所花费的精力。这些尝试仍应纳入评估。
第二个信号是接受后的可靠性。应关注那些在合并后继续跟踪改动，并考察其是否需要修正、撤销或事故响应的评估。
撤销是指移除或取消此前的改动。其意义取决于具体背景，因为产品决策可能因与代码质量无关的原因而变化。有用的报告需要提供足够细节，以区分这些解释。
稳定的可靠性与更快的交付并存，将强化净收益的论点。更多后续修复则会限制这一结论。相关比较应考虑任务风险和项目成熟度。
这对评估组织范围内部署的采购方尤其重要。在范围有限的维护工作中成功试点，并不能自动证明已具备在敏感系统中应用的条件。扩展应当为新的范围提供证据。
第三个信号是使用当前工具比较等效工作的更新研究。研究应说明其如何处理任务选择、并发代理以及生成过程周围的人力投入。
若可信评估中持续呈现改进，将强化生产率论点。若结果喜忧参半，则表明收益取决于任务、开发者或组织。无论哪种结果，都比普遍性断言更有价值。
研究人员还应让边界清晰可见。任务级结果、团队交付结果和开发者满意度结果都可能有效，但它们描述的是体验的不同维度。
对于评估 GitHub Octoverse 2026 的读者而言，随着新的公告到来，应始终保留这些核心区分。要问：代理开始处理哪些工作，谁来评估这些工作，以及批准后会发生什么。关注组织是否在采用情况之外，同时公布有关审查投入和可靠性的证据。比较工具时，应寻找与自身任务相似、且将监督纳入核算的结果。保留重要改动背后的背景，以便未来审查者理解其目的。该报告让人难以忽视代理的参与；你的下一项决策应取决于这种参与帮助完成了哪些工作。哪些证据能够表明，你的团队以更少的总投入交付了更多有用的软件？
