بازنویسی ران‌تایم گیت‌هاب کوپایلوت با ۸۰۰ هزار خط کد Rust

بر اساس گزارش منتشرشده در وبلاگ مهندسی گیت‌هاب (GitHub Engineering Blog)، ران‌تایم زیربنایی ایجنت‌های GitHub Copilot از استک قبلی مبتنی بر TypeScript و Node.js به‌طور کامل به بیش از ۸۰۰,۰۰۰ خط کد پروداکشن در زبان Rust بازنویسی شد. بخش عمده این کدها با استفاده از خود ایجنت‌های هوش مصنوعی گیت‌هاب (GitHub Copilot app و Copilot CLI) در قالب ۱۲۸ پول‌ریکوئست (PR) مستقیماً روی شاخه اصلی (main) ادغام و به‌صورت گام‌به‌گام عرضه شده‌اند. پروژه‌ای که در گذشته نیازمند یک تیم کامل در طول یک تا دو سال بود، توسط یک مهندس و طی چند ماه تکمیل شد.

چرا بازنویسی ران‌تایم Copilot ضرورت داشت؟

ران‌تایم ایجنت کوپایلوت تنها موتور Copilot CLI نیست، بلکه هسته مشترک طیف وسیعی از ابزارهای مایکروسافت و اکوسیستم گیت‌هاب را تشکیل می‌دهد. این سرویس‌ها عبارتند از:

• GitHub Copilot CLI و اپلیکیشن GitHub Copilot
• نسخه‌های جدید VS Code و Visual Studio
• سرویس ابری GitHub Copilot cloud agent (CCA)
• ابزارهای Copilot Code Review (CCR) و Copilot Cowork
• سرویس Copilot Studio و برنامه‌های آفیس (Word، Excel، PowerPoint، Outlook)

تمامی این ابزارها برای پرهیز از پیاده‌سازی حلقه ایجنت (Agent Loop) مجزا، از GitHub Copilot SDK به‌عنوان نقطه ورود به این ران‌تایم مشترک استفاده می‌کنند.

مشکلات معماری پیشین (TypeScript و Node.js)

ران‌تایم اولیه با زبان TypeScript روی پلتفرم Node.js و موتور جاوااسکریپت V8 توسعه یافته بود و برای رابط خط فرمان (CLI) از کتابخانه‌های React و Ink استفاده می‌کرد. توسعه سریع باعث درهم‌تنیدگی رابط ترمینال (TUI) با ران‌تایم شد؛ در نتیجه SDK مجبور بود با اجرای یک زیرپردازش (Subprocess) مجزا در پس‌زمینه از طریق پروتکل JSON-RPC روی ورودی/خروجی استاندارد (stdin/stdout) با موتور CLI ارتباط برقرار کند:

const client = new CopilotClient();
await client.start(); // spawns the CLI as a subprocess
const session = await client.createSession({
    /* ... */
});

معماری پردازش فرعی هزینه‌های فنی سنگینی به همراه داشت:

• مصرف رم بالا: بارگذاری مجزای موتور V8 و ران‌تایم Node.js برای هر کلاینت، حداقل ۱۰۰ مگابایت حافظه فعال (Working Set) تحمیل می‌کرد.
• وابستگی اجباری در تمام زبان‌ها: کاربران SDK در زبان‌های C#، Python، Go، Java و Rust ملزم به حمل باینری یا پکیج حجیم Node.js/V8 در برنامه‌های خود بودند.
• سربار IPC و ریسک کرش: انتقال تمام پیام‌ها، رویدادها و عملیات خواندن/نوشتن فایل از مرز پردازشی (Process Boundary) انجام می‌گرفت و کرش Node کل نشست کاری را نابود می‌کرد.
• محدودیت نخ‌ها (Threading): مدل تک‌نخی Node پردازش‌های سنگین CPU را صف‌بندی (Serialize) می‌کرد.

اهداف انتقال به Rust

تیم گیت‌هاب معماری جدید را با چهار هدف اصلی پیاده‌سازی کرد:

1. جداسازی کامل ران‌تایم از رابط متنی (TUI) در قالب یک کتابخانه مستقل.
2. استفاده از زبانی با حداقل وابستگی‌ها، کمترین سربار اجرایی و بالاترین کارایی.
3. امکان تعبیه مستقیم موتور در درون پردازش میزبان (In-Process) به‌جای تحمیل پردازش جانبی (Out-of-Process).
4. ارتقای چشمگیر تراکم سرور (Server Density)، سرعت بوت و بازدهی چندبرابری مصرف منابع.