GitHub 用 Copilot 重写 83 万行 Rust，重点在于它没让 Agent 一次写完

GitHub 9 月 16 日披露，Copilot 的 Agent 运行时已经从 TypeScript、Node.js 和 V8 迁到 Rust。这个运行时不只服务 Copilot CLI，还被 Copilot App、SDK、VS Code、Visual Studio、Copilot Code Review、Copilot Studio 以及 Office 相关产品共用。

到 8 月 21 日，生产 Rust 代码达到 832,378 行，Rust 单元测试 468,689 行，端到端 TypeScript 测试还有 174,675 行。GitHub 称，AI Agent 写了大部分代码；项目主要由一名开发者在数月内推动完成。

文章还称，迁移后运行时性能提升了多个数量级。这个结论来自 GitHub 自己的项目记录，文章没有给出一套可供外部复测的统一基准，不能把它直接当成所有 TypeScript 项目迁移 Rust 都会得到的结果。

整个项目通过 128 个 Pull Request 合入主分支，边迁移边发布。最开始的两个 PR 先建立 Rust 工作区、工具链、代码检查、持续集成、构建流程和编码规则，再用没有 I/O、没有共享状态、已有测试的纯逻辑小组件试跑。

迁移顺序从底层往上走：先处理纯函数、内容过滤、Shell 工具和会话文件操作，再处理有状态的子系统、工具、钩子、模型客户端和 MCP，最后才碰耦合最多的会话编排。每个阶段都把接口、打包、测试和审查方式固定下来。

大型子系统也被拆开。MCP 支持用了七个专门的 PR，工具部分分成六段，临时互操作层随着 Rust 覆盖范围扩大逐步删除。这样做的好处很朴素：出问题时知道是哪一小段，修复后可以马上合回生产。

GitHub 记录的提示缓存命中率是 96.22%，新写入占 3.07%，全新输入只有 0.71%。Copilot 的 Agent 循环刻意保持系统提示、工具定义和已有对话的前缀稳定，让后续请求重复读取已经处理过的内容。

迁移期间，Copilot 自动压缩上下文 5,116 次；其中一次会话基础设施迁移的 PR 就压缩了 647 次。每次压缩都可能丢掉信息，能持续工作依赖摘要质量、子 Agent 分担和后续测试；上下文窗口并非无限记忆。

这些数字也解释了项目账怎么算。长任务的模型费用、工具调用、测试机时和人工审查都在持续发生；缓存降低一部分重复输入成本，却不能替代失败重跑和回归修复的预算。

项目日志里有 31,247 条用户角色消息，其中包含技能指令、自动合并消息和子 Agent 流量，开发者自己输入或说出的约 2,600 条。1,130,921 次工具调用来自子 Agent，占全部工具调用的 61%。这些数不能理解成一个人完全放手。

GitHub 对开发者工作的描述是：检查结果、质疑技术决策、设质量门槛、处理例外、推动下一步。人负责界定问题、选择迁移顺序、判断异常和决定是否合并，Agent 负责大量代码转换、测试调用和中间操作。

这也是项目能持续数月的原因。每个 PR 都有可见的差异、测试和回滚位置；人的判断落在边界和验收上，代码细节则尽量交给 Agent 批量完成。

先选低耦合、已有测试、容易回滚的部分，做两三个完整的小试验，再扩大范围。不要先承诺“重写整个系统”，先确认构建、依赖、接口和验收都能被自动执行。

把每个切片变成一个可以独立审查的变更，记录模型版本、提示词、工具权限、测试结果和人工修改。发现回归就停在当前切片，修完再继续，不要让错误一路叠到最后。

GitHub 的案例不能证明一名开发者配几个 Agent 就能复制同样规模。它能证明一件更实用的事：当任务被拆小、验证做密、上线持续发生时，AI 可以把大规模迁移从长期重写项目变成一串可管理的工程变更。