Anthropic 不用 Git 了，GitHub 也在为智能体重建存储 · 11-06

今天值得看的

GitHub Copilot 用量 API 新增遥测缺失和版本差距字段，企业管理员可以按人查

Anthropic 放弃 Git 自建源码控制系统，原因写在工程博客里

GitHub 新存储架构内部测试数据：单仓库 5000 并发智能体、每秒 7200 次推送

GitHub Copilot 的用量指标 API 现在能查出哪些用户的编辑器没上报遥测，以及谁在用低于最低版本的 IDE 或插件。之前企业管理员只能看到总量，现在可以定位到具体的人。

新增字段：

client_telemetry_present：当天是否收到该用户的客户端遥测。为 false 说明 Copilot 知道用户有活动，但编辑器没发来用量事件。
usage_metrics_requirements：列出该用户的每个 IDE 和 Copilot 扩展，标记为 met、unmet 或 unknown，对照最低支持版本。
missing_client_telemetry_user_count：当天 client_telemetry_present 为 false 的人数。
below_usage_metrics_minimum_user_count：当天至少有一个 IDE 或扩展低于最低版本的人数。

前两个字段出现在用户级报告里，后两个出现在企业级和组织的汇总报告里。

我的判断：管 Copilot 席位的话这几个字段比之前有用得多。版本低于最低线的用户可能拿不到订阅里包含的新功能，该推更新就推。遥测缺失也可能是插件没装对或者被安全策略拦了，比对着总数瞎猜强。

Anthropic 在工程博客里解释了为什么不再用 Git，自己写了一套源码控制系统。直接原因不是 Git 不好，是 AI 编程的产出速度让人类开发者时代的基础设施跟不上了。

原文：

"在 Anthropic，编码不再是构建系统或做研究的瓶颈。Claude 能够自主迭代研究循环、微调复杂程序、以我们前所未见的速度和规模从零构建新服务。现在的瓶颈，是所有为人类开发者设计的基础设施。"

Claude 的工作模式是同时处理数千个文件、大量微小增量提交，这暴露了 Git 在并发和元数据开销上的问题。新系统围绕「代码图」而非文件树组织，读写路径针对大规模并行操作重新设计。

我的判断：不会让你明天就换掉 Git。但如果你们团队已经让 AI 工具大量产出代码，Git 的锁和 push 速度迟早会成为痛点。Anthropic 的做法像个预告------Git 被当数据库在用，它本来不是干这个的。

GitHub 在 Universe 大会上公布了新的 Git 存储架构，工程博客给出了内部测试数据和设计思路。目标是支撑智能体以远超人类开发者的频率读写仓库。

内部测试数据：

架构核心两件事：减少协调开销，存储和计算解耦。前一篇博文提到，过去一年 99.99999% 的 Git 仓库已经在 GitHub 自家数据中心和 Azure 上各存一份，只有流量最高的一批仓库被 25ms 往返延迟卡住。这次的改动让最忙的仓库也能迁过去，同时副本可以不保留持久状态。

我的判断：这几个数字对个人开发者没什么直接意义。但维护 CI/CD 或自建 Git 服务的人值得留意------如果内部 Git 开始因为 AI 工具的推送频率出问题，GitHub 遇到的瓶颈位置（并发写入、元数据锁）是通用的，他们的解法不一定能照搬，但方向可以参考。