GitHub 的代理时代：为 2 亿开发者扩容以及 Copilot 的未来

向代理时代的转变

GitHub 正在从一个代码托管和补全工具转型为以代理为中心的平台，在这里 AI 不仅仅是帮助编写代码，而是能够编排整个工作流。这一转变由用户规模的巨大扩张驱动——现在已超过 2 亿开发者——以及活动量的天文增长，提交量同比增长约 14 倍。

从代码补全到代理 SDK

GitHub Copilot 正在超越其作为代码补全工具的起点。最初的工作侧重于微调模型以提升准确性，而当前的策略强调统一的 SDK 与编码代理的集线器。这使得代理能力能够在多种形态上部署，包括全新的桌面应用、CLI 和云端代理。目标是从简单的“调用‑响应”交互，转向能够自主处理安全修复、文档提取等复杂任务的代理。

环境感知 AI 的概念

在 AI 时代实现真正的生产力需要“环境感知 AI”——拥有开发者环境完整上下文的智能，超越 IDE 本身。这包括对规范文档、电子邮件以及跨团队对话的访问。目标是构建一个系统，使 AI 能够理解特定开发者或团队的“口味与判断”，而不仅仅是提供语法正确的代码。

为指数级增长扩容 GitHub

由于 AI 生成活动的激增，GitHub 正面临其历史上最重大的扩容挑战。

14 倍提交激增

活动水平急剧上升；2025 年约有 10 亿次提交，而平台目前的速度预计今年将达到约 140 亿次提交。这种增长以全新的方式冲击系统，超出单纯可靠性问题，涉及复杂的权限管理和基础设施瓶颈。

基础设施瓶颈与解决方案

• 计算需求：代理和 Pull Request（PR）的增加导致构建需求激增，需要大幅扩展 CPU 资源。GitHub 正在越来越多地利用 Azure 的开发计算，快速启动小型、快速的 VM 来运行容器化工具调用。
• 权限层：许多故障被追溯到旧的权限层（特别是 “MySQL 1”）。GitHub 正在积极将这些层迁移到更现代、分片的基础设施，以提升可用性。
• 单体仓库趋势：观察到向大型单体仓库（monorepo）的回归。由于大仓库会因巨大的二进制对象产生独特的性能问题，GitHub 正在更新底层 Git 基础设施，以更高效地处理这些情况。

开源与信任的演进

随着 AI 代理开始生成大多数 Pull Request，开源的社会和技术属性正在改变。

代理生成代码的信任问题

当一个代理编写代码，另一个代理审查时，传统的人类信任信号被稀释。GitHub 正在探索将信任形式化的方法，尽管这仍是一个社会问题。当前的星标数量等信号被视为被动且易于被游戏化；平台正转向更主动的信号以及可塑的工具，让维护者自行定义信任启发式（例如，要求特定历史的已接受 PR 或绑定的社交账号）。

依赖管理与 “松散分叉”

关于 npm 等包管理器的未来存在持续争论。有观点主张转向 “AI vendoring”，即代理分析源代码，仅将库中必要的子集适配到项目中。然而，GitHub 坚持认为，无论项目是 vendored 还是通过包管理器导入，静态代码分析和运行时测试仍是防御漏洞的主要手段。

内部 AI 工作流与领导力

Kyle Daigle 利用 AI 架起技术领导与实际创作之间的桥梁，采用 “微技能” 策略。

原子微技能 vs. 大技能

与构建庞大、全能的 AI 工作流（“大技能”）不同，趋势正转向原子微技能——专注单一任务、极致表现的小工具。这些工具随后通过编排技能串联起来。这种模块化避免了过去的 “插件地狱”，并在需求变化时实现快速迭代。

AI 在高管运营中的应用

AI 正改变幕僚长和高管的角色，通过自动化 “递归向后循环”。高管不再花数小时制作幻灯片，而是使用代理从 Teams、Slack 和 Obsidian 笔记中合成转录，识别上周的模式并规划下周。这将角色的人性化部分转向管理人际关系和战略编排，而非手动文档生产。