GitHub把Copilot运行时重写成了超过800,000行生产Rust代码，大部分代码由AI代理编写。原来的运行时已经能够工作，为什么还要做这样的迁移？原文介绍的原因，藏在它被越来越多产品共享之后。
这是一篇基于GitHub原文片段的解读，不是第一手测试。2026-09-17，GitHub介绍了这次迁移。Copilot CLI、Copilot app和Copilot SDK背后，都有同一个Copilot agent runtime。
这个运行时最初为现在的GitHub Copilot cloud agent，也就是CCA，以TypeScript运行在Node.js和V8 JavaScript引擎上。随着能力快速增加，运行时仍留在原来的技术栈中。
在终端应用里，这种选择并不失当。TypeScript和Node.js容易使用，也适合快速开发。原文称，对控制台应用而言，启动、响应、吞吐和内存方面的性能影响原本处于合理范围。
麻烦出现在共享场景。这个运行时后来不只服务Copilot CLI，还支持Copilot app、VS Code、Visual Studio、CCA、Copilot Code Review、Copilot Cowork、Copilot Studio，以及Excel、Outlook和PowerPoint等产品。
这些产品的形态不同，却都需要智能、安全性、可靠性和性能。理想状态是把这些能力放进共享运行时，某个地方的修复也能被其他产品共同使用，而不是每个产品各自维护一套生产级代理循环。
共享之后，约束也变了。服务器环境更在意快速启动和较高的服务密度，低内存开销成为这些部署要求的一部分。原文指出，原本对命令行程序尚可接受的实现，在这些环境中就不那么合适。
架构还留下了另一笔成本。Copilot CLI最初快速开发并发布，终端界面和运行时没有清楚拆成独立层。后来需要提供SDK时，实际采用了在CLI之上叠加SDK的办法。
为了让外部程序调用运行时，CLI增加了无界面模式，通过标准输入读取命令、通过标准输出返回结果，再用JSON-RPC在进程之间传递函数调用。这个方案上线快，也足够灵活。
但通过SDK创建并启动CopilotClient时，需要启动另一个CLI进程。这个进程还要加载Node和V8，解析由TypeScript生成的大量JavaScript，生成字节码，并可能在后续阶段优化热点代码。
因此，使用C#、Python、Go、Java或Rust SDK的应用，也要为一个自身可能并不需要的Node.js或V8运行时付出成本。GitHub给出的量级是每个客户端至少约100 MB工作集。
额外成本不只在内存。每个事件、消息，以及抽象会话文件系统的读写，都要跨过进程边界。Node崩溃会带走会话，部署者至少还要监管、监控和调试两个进程。
从提供的片段看，迁移动机主要集中在共享运行时的启动、内存、吞吐和可靠性约束。片段同时描述了由外部CLI进程承载运行时带来的成本。这里讨论的是迁移原因，具体改造方式还需要结合原文的后续内容了解。
迁移并非一次性切换。GitHub称，AI代理写下了大部分代码，改动分布在128个合并进主分支的拉取请求中，并逐步交付。期间出现的回归问题被发现并修复，运行时性能则提升了多个数量级。
原作者还给出人员与周期的对比。一项过去可能需要一整个开发团队投入一到两年的项目，在代理参与后，主要由一名开发者用几个月完成，同时其他团队成员继续扩展运行时能力和覆盖范围。
这里需要保留边界。提供的片段没有列出迁移前后的性能基准对照数据或逐次回归细节，完整评估还需查阅原文后续内容。不能只凭其中的性能陈述，推断其他Rust项目也会得到同样结果。
如果你正在评估一个代理SDK，可以先做一个很小的检查。查看创建并启动客户端时是否会额外启动进程，并记录它是否携带另一套语言运行时。这个动作正好回到Copilot迁移最初面对的问题。
原始来源：Migrating the GitHub Copilot runtime to Rust, using Copilot
AI辅助撰写与核验，依据标注来源进行编辑解读，非产品实测。