گیت‌هاب ران‌تایم عامل Copilot را به بیش از ۸۰۰ هزار خط Rust تولیدی منتقل کرد

/images/github-copilot-runtime-rust.png

Copilot CLI و Copilot app و Copilot SDK همه به یک agent runtime تکیه دارند. قبلاً TypeScript روی Node و V8 بود؛ SDK برای این‌که همان حلقه را در C# یا Python صدا بزند، یک پروسهٔ CLI می‌ساخت و JSON-RPC از روی stdin می‌فرستاد. یعنی هر CopilotClient یک Node اضافه، یک V8، و حدود صد مگابایت working set برای زبانی که میزبان اصلاً نمی‌خواست.

۱۶ سپتامبر ۲۰۲۶ Stephen Toub نوشت این لایه حالا بیش از ۸۰۰ هزار خط Rust تولیدی است. agentها بیشتر کد را نوشتند؛ ۱۲۸ pull request تدریجی به main آمد، نه یک cutover آخر کار. تا ۲۱ اوت ۲۰۲۶ runtime ۱۰۰٪ Rust تولیدی شد: ۸۳۲٬۳۷۸ خط production به‌علاوهٔ ۴۶۸٬۶۸۹ خط unit test؛ E2E تایپ‌اسکریپت جدا، و حدود ۱۳۰ هزار خط تست در مخزن SDK برای شش زبان.

هدف را این‌طور خلاصه می‌کند: نخواست Rust را به‌خاطر Rust بردارد؛ خواست از Node و V8 جدا شود تا embed با C ABI، استارت و حافظهٔ کمتر، و SDK داخل‌پروسه بدون دومین runtime ممکن باشد.

عددهایی که از SDK سی‌شارپ گرفته

بنچمارک با C# SDK، سرور chat محلیِ قطعی، بدون latency مدل:

سناریو۱۲ مه (Node)۲۱ اوت out-of-process۲۱ اوت in-process
Client + session + یک turn۵٫۲۵ ث۱٫۳۳ ث (۴×)۲۹۲ ms (۱۸×)
Resume نشست ۳۲ نوبتی۵٫۶۴ ث۱٫۵۲ ث۲۶۴ ms
ده چرخهٔ همزمان کلاینت۱۲٫۳۴ ث۴٫۱۸ ث۷۴۲ ms

پورت درجا بود: هر PR یک قطعه TypeScript را با shim نازک به Rust عوض می‌کرد و main قابل‌شیپ می‌ماند. napi-rs پل موقت Node بود تا آخرین caller هم پورت شود. Toub می‌گوید «اگر کامپایل شد، درست است» اینجا شوخی است؛ رگرسیون‌ها همه compile شده بودند.

اگر SDK را داخل سرویس embed می‌کنید، همان جدول in-process دلیل این پورت است: یک turn دیگر پنج ثانیه بوت Node نیست.

آخرین مطالب