Vibe Coding 月提交量 29 亿次之后：GitHub 的危机、Azure 迁移，以及 .NET 的机会

AI 编程浪潮正在压垮为人类设计的开发基础设施。这场危机与 .NET 有什么关系？答案比"微软亲儿子"这个直觉复杂得多。

一、被 AI 负载压垮的 GitHub

几个数字先感受一下冲击的量级：

• 每月 29 亿次提交、1.3 亿次合并的 PR、2400 万个新仓库——而 2026 年 4 月，GitHub 处理"仅" 14 亿次提交时就已经很吃力 [1]
• 8 月 17 日宕机近 8 小时：根因是流量达到新峰值，而美国中部数据中心一个关键基础设施组件未能随之扩展，容量压力级联扩散，引发身份验证失败、多服务中断 [1]
• 增长的主力，是氛围编程（Vibe Coding）的流行和 AI 驱动下开发迭代速度的飙升 [1]

GitHub 并非没有动作。CTO Vlad Fedorov 披露：平台负载的 58% 已经跑在 Azure 上（5 月份还只有 12%），所有 Git 操作的一半由 Azure 处理；今年新增了 300 万个 CPU 核心和 120 PB 高速存储；自有数据中心已经"装了尽可能多的硬件"，到达物理极限 [1]。

但 Fedorov 自己也承认："我们已经取得了进展，但这些事故清楚地表明，我们必须加快这项工作。" [1]

补救措施包括：隔离关键系统、消除共享依赖、统一重试限制与预算、调整服务间超时以防止重试风暴 [1]。

一句话：这是在给"人类时代"的架构，打 agent 时代的补丁。

二、迁移的实质：算力现代化，不是 .NET 化

很多人看到"GitHub + 微软 + Azure"，第一反应是：那是不是要全面 .NET 化了？

事实恰恰相反。

GitHub 的核心从来是、现在仍然是一个大型 Ruby on Rails 单体应用，后端是 MySQL 关系型数据库，周围环绕着 Git 存储、Actions、Elasticsearch 搜索、PR/Issues 等服务——而这些服务共享数据库、缓存、认证路径和网络设施，这正是宕机会级联扩散的结构性原因 [11]。

现代化方向是：

• 把单体拆分为隔离性更强的服务和数据域
• 把性能敏感代码从 Ruby 迁往 Go
• 把部分负载移出 MySQL
• 基础设施迁往 Azure，换取更大机型和更多区域 [11]

注意这个组合：重写语言选了 Go，不是 C#。 即便在微软全资拥有、全面倒向 Azure 的情况下，GitHub 也没有把核心服务转向 .NET。

这说明迁移的驱动力是容量、区域弹性和硬件供给——300 万核心、120 PB 存储这种量级只有超大规模云给得起——而不是运行时或语言的替换。一篇针对 GitHub 2024–2026 可用性下降的学术分析还指出了一个隐忧：迁 Azure 买来了更大机器和更多区域，但代价是把平台绑定到单一云厂商的专有运维底座上，形成新的"共命运"集中风险 [11]。

三、.NET 在 GitHub 官方基础设施里的真实位置

.NET 在 GitHub 体系内确实存在，但集中在开发者工具链和 CI/CD 执行层，而非核心代码托管平台：

1. GitHub Actions Runner 是最重要的一块。

Actions 的 Runner 应用程序（actions/runner）是用 C# / .NET Core 编写的跨平台进程，负责接收 job、执行步骤、上报日志。也就是说，每一次 GitHub Actions 工作流的执行，最外层都跑着一个 .NET 进程。Runner 与其他工具一起预装在 GitHub 托管 runner 的虚拟机镜像中 [8]。

2. Runner 镜像中的 .NET SDK 生态。

GitHub 托管 runner 预装了多个版本的 .NET SDK，并有官方维护的 actions/setup-dotnet 动作，用于指定 SDK 版本、缓存依赖、注册 problem matcher、配置 NuGet 私有源认证 [2]。微软 .NET 团队也把 GitHub Actions 作为 .NET CI 的一等公民场景来经营 [5]。

3. Azure 侧的隐性 .NET 成分。

迁移后 GitHub 越来越多负载跑在 Azure 上，而 Azure 自身的控制面大量是 .NET（ASP.NET Core）构建的——但这是 Azure 的内部实现，不是 GitHub 的应用代码。

一张表总结：

四、"为 AI 负载而生"：危机的本质是人机负载模型错配

月提交量翻倍只是表象。真正的结构性问题是：Git 托管平台是为人设计的，而负载主力正在变成 agent。

前 GitHub CEO Thomas Dohmke 的表述非常直接：GitHub 这类服务是为人类构建的，而不是为一支"以数千个并行请求克隆、读取、处理代码的自治 agent 大军"构建的——"问题不是 Git 能否靠生态惯性存活，而是如何为 AI agent 成为代码主要生产者的世界去扩展、重接、进化 Git 托管" [15]。

错配体现在三层：

1. 流量形态变了。 人类开发者一天 commit 几次、clone 几次；agent 会话是高频、并行、突发的 fetch/clone/push 风暴。8 月 17 日宕机正是负载模型假设失效的典型症状 [1]。
2. 数据模型不够了。 Agent 产出的不只是代码，还有 prompt、推理链、工具调用记录。传统 PR review 看不到 agent 的"为什么"，形成"评审瓶颈"——agent 写得越多，人类评审队列越长，且缺乏评审所需的上下文 [22]。
3. 架构耦合放大冲击。 共享数据库、共享认证路径的单体拓扑，让一个组件的容量压力级联成全局故障 [1]。

竞争者正是沿着这三层切入：Dohmke 的 Entire 拿了 6000 万美元种子轮（Felicis 领投，微软 M12 参投），提出 git 兼容数据库 + 多 agent 语义推理层 + agent 会话上下文版本化（Checkpoints），宣称其网络可承载每小时 210 万次 push、57 万次 clone，远超 Cursor Origin 的 8.1 万 / 29.6 万 [21][15]。

五、.NET 的四个机会窗口

GitHub 的危机对 .NET 不是直接利好（核心平台重写选了 Go），但"为 AI 负载而生"这个新基础设施层，打开了几个 .NET 有真实结构性优势的位置。

机会一：Agent 编排层——企业级筹码的正面对决场

Agent 时代的核心中间件是多 agent 编排框架，这正是微软 2026 年 4 月 GA 的 Microsoft Agent Framework 1.0 的主战场——它合并了 Semantic Kernel 的企业级管道（状态管理、类型安全、中间件、遥测）和 AutoGen 的 agent 抽象，原生支持 MCP 和 A2A 协议，提供图式多 agent 工作流 [14][24]。

机会点在于：当 agent 从玩具变成生产负载，企业最缺的不是框架灵活性，而是治理——合规、可观测、身份绑定、确定性策略执行。有评测直接把 Semantic Kernel/MAF 一系描述为"伪装成 AI 框架的企业中间件"，在金融、医疗、国防等强监管 Azure 环境中是"无可争议的选择" [25]。

GitHub 危机揭示的"评审瓶颈"和"审计需求"（哪行代码是哪个 agent、为什么改的），恰恰是强治理框架的甜点区。

机会二：Agent 执行基础设施——Runner 经验的复用

编码 agent 需要海量隔离沙箱来运行不可信代码（E2B 的 Firecracker microVM、Daytona 的容器隔离都是这个赛道，E2B 自称被 88% 的财富 100 强使用）[19]。

.NET 的机会是：

• 执行代理这一层对跨平台、长驻、高并发进程的要求，正是 .NET（AOT、低内存占用、gRPC/ASP.NET Core）的强项，而且 .NET 团队已经在 Actions Runner 上积累了全球最苛刻的 CI 执行代理实战经验
• Runner 镜像 + setup-dotnet 工具链意味着 .NET 已经是每条 Actions 流水线的"原住民"，把 agent 执行环境做成 .NET 一等公民几乎没有分发阻力 [2]

开源样本：OpenClaw.NET 推断已经有了现实样本。OpenClaw.NET 是一个 NativeAOT-friendly 的 .NET AI agent runtime 与网关（MIT 协议），把 Actions Runner 的"接 job、跑步骤、报日志"模式扩展成了完整的自托管 agent 网关：工具执行、流式输出、取消、重试、记忆、会话，外加 OpenAI 兼容端点、MCP、WebSocket、80+ 原生工具面和 9 个渠道适配器（TG/Slack/Teams/WhatsApp 等）[32]。 它恰好踩中了执行代理层的三个关键属性：

• NativeAOT-friendly 是对云厂商沙箱路线的差异化回答。 E2B/Daytona 走 microVM/容器隔离路线；OpenClaw.NET 走另一条路——AOT 编译产物意味着冷启动快、内存占用低、单二进制分发、无运行时依赖，桌面 bundle 解压即用。对"每个开发者机器上都跑一个 agent 网关"这种边缘部署模型，AOT 二进制比容器更轻——这也是 .NET 相对 Python/Node 在 agent 执行层的结构性优势。
• 治理面直接呼应 GitHub 危机揭示的审计需求。 Passive Harness Contracts 与 Evidence Bundles 让 agent 工作计划和运行证据可检查、可人工评审且不打扰默认行为；可选的 Plan-Execute-Verify 模式为高风险工具执行加上契约、证据和验证，配合 Governance Ledger 持久化审批决策；openclaw harness test 回归套件在信任 harness 变更前先做离线检查 [32]。这基本是"agent 会话可审计、工作流可治理"叙事的一个 .NET 开源实现。
• 生态策略务实。 兼容复用 OpenClaw 的 TS/JS 插件和 SKILL.md 包，同时提供 Microsoft Agent Framework 适配器（Runtime.Orchestrator=maf）与 A2A、持久化工作流后端——不与官方编排框架对打，而是定位成"自托管运行时 + 官方框架的落地点" [32]。

值得注意的是，该项目声明与 OpenClaw（TS 生态）无隶属关系，是独立的 .NET 实现；文档站已转向 AgentQi.dev，未来运行时身份可能更名 AgentQiX [32]。

机会三："上下文即基础设施"——被低估的一张牌

Entire 的核心洞察是：agent 时代最有价值的资产不是代码本身，而是产生代码的上下文（prompt、推理链、约束条件），它把 Checkpoints 直接版本化进 Git [21]。

有分析指出，编排框架解决的是应用侧问题，但解决不了"缺失的上下文"——表的含义、哪个指标定义是权威的、agent 行动前适用哪些策略，需要编排层之下的 Context Layer 供给 [14]。

这引出一个关键判断：agent 需要的上下文，本质上是结构化的领域语义，而非自然语言日志。.NET 的机会在于：企业领域的知识本来就沉淀在 C# 领域模型里（ERP、金融、医疗系统大量是 .NET）。用 .NET 的类型系统 + JSON-LD 投影把领域对象暴露为 agent 可消费的语义上下文层，再把工作流投影为 agent 可调用的技能 DAG——这条路上 .NET 几乎没有竞争者，因为 Java 生态的 AI 编排投入远弱，Python 生态又缺乏企业领域模型的存量。

机会四：GitHub 危机本身创造的分发窗口

GitHub 频繁宕机 + Entire/Origin 分流，意味着"代码托管 + CI + agent 执行"的一体化默认选项正在松动。对 .NET 生态而言，MAF + MCP/A2A + Azure 的组合如果能率先给出"agent 会话可审计、agent 工作流可治理"的完整叙事，就能把 GitHub 的危机转化为 .NET 在 agent 基础设施层的入场券 [16]。

六、冷静的一面：三个约束

• 语言惯性是双向的。 GitHub 核心重写选 Go 说明，在超高吞吐基础设施层，.NET 并没有因为"微软亲儿子"而胜出；机会在编排、治理、执行代理层，不在 git 数据面。
• Python 生态的先发优势。 LangGraph 在生产案例和社区规模上仍领先（8 万+ stars vs MAF 的 1.19 万），MAF 的优势在 Python + .NET 双语对等和托管化部署 [16]。
• 窗口期有限。 Entire 计划开源其网络并支持自托管 [15]，如果"agent 原生 Git"的标准被开源项目先定义，.NET 的机会会收缩为"实现者"而非"定义者"。

结语

GitHub 的危机证明：为人类设计的开发基础设施已到极限，下一个平台层将围绕 agent 的流量形态、上下文治理和审计需求重建。

而 Azure 迁移的真相是：它改变的是"跑在哪"，而不是"用什么写"。

.NET 的机会不是去重写 GitHub，而是在三个新层占位：

• 企业级 agent 编排（Microsoft Agent Framework）
• agent 执行代理（Actions Runner 模式的延伸）
• 领域语义上下文层（DDD + JSON-LD 投影）

语言选型服从于既有代码资产和团队惯性——但在 agent 时代，谁掌握了上下文和治理，谁就掌握了平台的话语权。这或许是 .NET 二十年来最好的一次卡位机会。

1

参考资料

1. Entire：Git for Agents（The New Stack） ↩︎
2. GitHub now sees 2.9 billion commits a month -- and it can't keep up（The New Stack）及 GitHub 官方 8 月 17 日宕机事后分析 ↩︎