آنتروپیک: سامانه Scion مصرف منابع زیرساختی را ۲۰۰ برابر کاهش داد

تصور کنید هزاران برنامه‌نویس رباتیک در هر ثانیه کد می‌نویسند و تغییرات را روی یک پروژه ارسال می‌کنند؛ در چنین وضعیتی، ابزارهای سنتی برنامه‌نویسی مانند Git به جای کمک، تبدیل به سدی برای پیشرفت می‌شوند. این دقیقاً همان چالشی است که آنتروپیک با آن روبرو شد تا مجبور شود یکی از بنیادی‌ترین ابزارهای دنیای نرم‌افزار را بازطراحی کند.

به نقل از گزارش فنی این شرکت، تعداد ادغام‌های روزانه کد (Merge) در آنتروپیک (Anthropic) از ۲۵۰۰ مورد در می ۲۰۲۶ به بیش از ۳۰ هزار مورد در سپتامبر ۲۰۲۶ رسید. این رشد ۱۲ برابری نتیجه فعالیت کلود (Claude) بود که به‌طور خودکار در حلقه‌های پژوهشی تکرار، برنامه‌های پیچیده را بهینه‌سازی و سرویس‌ها را در مقیاسی می‌ساخت که ابزارهای توسعه انسانی را از کار انداخت.

در این مقیاس، دیگر نوشتن کد گلوگاه نیست، بلکه زیرساخت‌های توسعه است که برای مقیاس انسانی طراحی شده‌اند. مواردی مانند کنترل نسخه (Source Control)، فرآیندهای ساخت (Builds) و سیستم‌های یکپارچه‌سازی مداوم (CI) اکنون به مانع تبدیل شده‌اند. آنتروپیک پیش‌بینی می‌کند که این رشد ادامه یابد، زیرا تقاضای نهفته برای ادغام کد عملاً بی‌نهایت است؛ هر گلوگاهی که برطرف شود، بلافاصله منجر به افزایش بیشتر در تولید کد می‌شود.

بیشتر زیرساخت‌های نرم‌افزاری برای مقیاس انسانی ساخته شده‌اند. Git، که استاندارد صنعت است، فرض می‌کند برنامه‌نویسان به‌صورت آفلاین و با نسخه‌های محلی کامل از مخازن کار می‌کنند. برای آنتروپیک، این طراحی به یک نقطه ضعف تبدیل شد، زیرا تاریخچه Monorepo آن‌ها به ۱۰۰ گیگابایت رسید و نسخه‌های کاری فشرده از ۲۵ گیگابایت فراتر رفت.

همان‌طور که در تحلیل قبلی ما درباره‌ی اتصال کلود به عامل‌های سازمانی برای منابع انسانی و مالی اشاره کردیم، آنتروپیک اکنون همین منطق عامل‌محور را در مهندسی داخلی خود پیاده کرده است. این رویکرد در راستای استراتژی گسترده‌تر شرکت برای تبدیل دستیار چت به یک موتور ارکستراسیون است تا مدیریت وظایف پیچیده را تسهیل کند. آن‌ها دریافتند وقتی «برنامه‌نویس» اصلی یک عامل (Agent) — شبیه دستیاری هوشمند که می‌تواند به‌طور مستقل ابزارها را اجرا کند — باشد، فرضِ «کار آفلاین» که پایه و اساس Git است، منسوخ می‌شود.

طبق اعلام شرکت در گزارش فنی منتشر شده در ۱۳ اکتبر ۲۰۲۶، پنج ماه زمان برد تا کل مخزن کد (Monorepo) از Git به سامانه جدیدی به نام اسایون (Scion) منتقل شود. در همین بازه زمانی، آن‌ها ابزارهایی مانند آنتیک (Antique) را برای بررسی کد (Code Review)، سیستم جست‌وجوی کد و یک سامانه مدیریت دسترسی (IAM) غنی برای کنترل نسخه عرضه کردند.

شکست Git در مقیاس عامل‌ها

ماهیت غیرمتمرکز Git نیازمند انتقال حجم عظیمی از داده است. آنتروپیک تنها برای سیستم‌های یکپارچه‌سازی مداوم (CI)، روزانه ۲۵ میلیون بار عملیات دریافت کد (Checkout) انجام می‌داد؛ این رقم بدون احتساب کارهای پژوهشی، محیط‌های Sandbox عامل‌ها و محیط‌های توسعه برنامه‌نویسان است. اگر این فرآیند به‌صورت ساده و بدون بهینه‌سازی انجام می‌شد، روزانه بیش از ۶۰۰ پتابایت ترافیک ایجاد می‌کرد.

تیم مهندسی برای بقا در ابتدا از تمام ابزارهای مقیاس‌بندی موجود در Git استفاده کرد. این ابزارها شامل Shallow Clones (کلون‌های کم‌عمق)، Sparse Checkouts (دریافت‌های پراکنده) و Promisor Remotes بود. آن‌ها همچنین از آینه‌های داخلی Git و اسنپ‌شات‌های مخزن (Seeds) که در فضای ذخیره‌سازی Blob نگهداری می‌شدند، بهره بردند. در اوج فشار، آن‌ها چندین صد آینه داخلی Git را برای مدیریت بار ترافیکی فعال کرده بودند.

با این حال، با افزایش نرخ ادغام، مدیریت این آینه‌ها غیرممکن شد. اسنپ‌شات‌ها (Seeds) بین هر بار به‌روزرسانی، بیش از حد از شاخه اصلی عقب می‌افتادند. همچنین عملیاتی که به تاریخچه وابسته بودند، مانند diff و blame در کلون‌های جزئی (Partial Clones) ناپایدار شدند. تیم به این نتیجه رسید ویژگی‌هایی که Git را برای کار توزیع‌شده و آفلاین عالی می‌کند، اکنون فعالانه توانایی آن‌ها در مقیاس‌پذیری را تخریب می‌کند.

معماری هسته Scion

اسایون بر این اصل استوار است که کلاینت‌ها همیشه آنلاین هستند. به‌جای داشتن یک مخزن محلی، کلاینت تنها یک حافظه موقت (Cache) محدود از اشیاء را نگه می‌دارد و داده‌ها را در لحظه و بر اساس نیاز از سرور می‌گیرد. این سیستم با بهره‌گیری از تجربیات پروژه‌های بزرگ مانند Piper گوگل و Sapling متا ساخته شده است:

• ناهمگونی کلاینت-سرور: کارهای سنگین مانند محاسبه تاریخچه، ایجاد کامیت‌ها و انجام ادغام‌ها بر عهده سرور است. کلاینت صرفاً فایل‌ها را روی دیسک می‌چیند و تغییرات سیستم فایل را رصد می‌کند. کلاینت به‌تنهایی محاسبات بسیار کمی انجام می‌دهد و در نتیجه به داده‌های محلی بسیار کمتری نیاز دارد.
• مقیاس‌پذیری افقی: هیچ کپی واحد و متمرکزی از مخزن در هیچ کجا، حتی روی سرور، وجود ندارد. داده‌ها توزیع شده‌اند و هر جزء سیستم به‌طور مستقل مقیاس می‌پذیرد. در این سیستم هیچ Packfile (بسته‌های فشرده اشیاء) وجود ندارد، به این معنی که هیچ نیازی به نگهداری (Maintenance) مخزن نیست.
• کامیت‌های بدون قفل: هر کامیت، Rebase یا Merge روی سرور رخ می‌دهد. هزینه یک کامیت با اندازه تغییرات متناسب است، نه با اندازه کل مخزن. برای جلوگیری از مشکلات مقیاس‌پذیری در وضعیت سراسری (Global State)، اسایون استفاده از Refها (اشاره‌گرهایی مانند شاخه‌ها و تگ‌ها) را منع می‌کند، مگر برای Ref اصلی یا شاخه‌های انتشار (Release).
• دریافت مجازی (Virtual Checkout): سیستم‌های CI می‌توانند از طریق API درخواست Diffهای خاصی را بدهند بدون اینکه هرگز کل کد را دریافت کنند. پروتکل اسایون بر پایه Sparse Checkouts (شامل دایرکتوری‌های درخواستی) و Virtualized Checkouts (تجسم فایل‌ها در لحظه نیاز) است.
• دسترسی برنامه‌نویسی شده: تمام پرس‌وجوهای کنترل نسخه که توسط کلاینت استفاده می‌شود، از طریق API در دسترس است. این امر به ابزارهای داخلی، مانند خط لوله‌های خودکار Bisect و Revert اجازه می‌دهد بدون نیاز به مخزن محلی عمل کنند.

جریان داده‌ها و مکانیزم‌های کش

در اسایون، واحد کار یک «مجموعه تغییرات» (Changeset) است که در واقع یک ورودی در یک لاگ Write-ahead است. برخلاف کامیت‌های Git که به یک درخت (Tree) اشاره می‌کنند، یک Changeset لیستی از فایل‌هایی را ذخیره می‌کند که نسبت به اولین والد خود تغییر کرده‌اند، به همراه اشاره‌گرهای Content-addressed به محتویات فشرده فایل‌ها در Blob Storage.

از آنجایی که Changesetها در سمت سرور ایجاد می‌شوند، فوراً در همه جا در دسترس هستند. جابجایی یک Ref به صورت یک عملیات ساده Compare-and-swap روی یک ردیف در Spanner مدیریت می‌شود که از فرآیند ایجاد خودِ Changeset مجزا است.

برای پاسخ به پرسش‌هایی مثل «چه کسی آخرین بار این خط را ویرایش کرد» یا «کدام کامیت‌ها روی این فایل اثر گذاشتند»، اسایون «داده‌های مشتق‌شده» (Derived Data) را به‌صورت بازگشتی محاسبه می‌کند. این شامل ساختارهای اختصاصی برای File Blame، تاریخچه مسیر (Path History) و Skip Listها برای گراف کامیت‌ها است. این مکانیزم به تیم اجازه می‌دهد:

1. به‌راحتی ساختارهای داده جدید (مثلاً ایندکس‌هایی برای تشخیص کپی یا جست‌وجوی مسیر-محور) برای سرعت بخشیدن به عملیات اضافه کنند.
2. انتخاب کنند که داده‌ها را به‌صورت مشتاقانه (Eager) محاسبه کنند یا برای جلوگیری از تجسم غیرضروری، آن را به تعویق بیندازند.
3. internals سیستم را بدون نیاز به تغییر در کلاینت بهینه کنند.

برای کاهش فشار روی پردازنده، کلاینت scn اسایون از پروتکل‌های Fetch گیت فاصله گرفته است. به‌جای اینکه به سرور بگوید چه چیزهایی را دارد، کلاینت منحصراً روی درخت‌ها و Blobهایی که «می‌خواهد» عمل می‌کند. از یک درخت ریشه شروع کرده و به‌صورت بازگشتی درخت‌های گم‌شده و سپس Blobها را درخواست می‌کند. چون هر درخواست برای یک شیء خاص و تغییرناپذیر است، هر کشی می‌تواند به آن پاسخ دهد.

سیستم از یک استراتژی کش سه‌لایه برای به حداقل رساندن بار CPU استفاده می‌کند:

• scion-daemon: دیمونی روی هر گره که اشیاء را برای کل آن گره ذخیره می‌کند. کارهای روی یک گره از این اشیاء مشترک استفاده می‌کنند. این دیمون از یک اسنپ‌شات که به‌طور دوره‌ای به‌روز می‌شود شروع می‌کند.
• scion-cache: سرورهای منطقه‌ای که اشیاء را مستقیماً از حافظه (RAM) در فرمت دیسکی که دیمون مصرف می‌کند، استریم می‌کنند. این کار نیاز به فشرده‌سازی Delta یا محاسبه اشیاء گم‌شده را از بین می‌برد.
• scion-servers: لایه مرجع که در صورت نبود داده در کش (Cache Miss)، از Spanner یا فضای ذخیره‌سازی ابری می‌خواند.

هر سه لایه به RPCهای یکسانی پاسخ می‌دهند، بنابراین کلاینت از توپولوژی کش بی‌اطلاع است. این لایه‌بندی، دامنه‌های شکست را ایزوله می‌کند و مانع از آن می‌شود که شکست یک کش منطقه‌ای، سرورهای بالادستی را فلج کند.

مزیت «ساخته شده توسط AI»

آنتروپیک از خودِ کلود برای ساخت سیستمی استفاده کرد که قرار بود از خودِ کلود پشتیبانی کند. تیمی متشکل از تنها ۷ مهندس، این مهاجرت به Scion و Antique را در ۵ ماه به پایان رساندند، حتی در حالی که حجم کدهای ادغام شده روزانه ۱۰ برابر شده بود.

در یک مورد، یک اسنپ‌شات اولیه از Claude Mythos Preview خط لوله انتقال داده (Ingestion Pipeline) از Git به Scion را بازنویسی کرد. نسخه تولید شده توسط AI، چهار برابر سریع‌تر بود و ۲۰ برابر حافظه کمتری نسبت به نمونه اولیه انسانی مصرف می‌کرد، در حالی که تمام ناپایدارهای ضمنی (Implicit Invariants) مربوط به ساختارهای داده و ترتیب انتقال را حفظ کرده بود.

با این حال، مهندسان انسانی برای طراحی سطح بالا و هدایت پروژه حیاتی بودند. تیم دریافت که عامل‌ها اغلب سعی می‌کنند راهکارها را با «زور» (Brute Force) پیاده کنند؛ مثلاً به‌جای استفاده از ابزار بررسی کد، لاگ‌های کامیت را به‌صورت خطی می‌خواندند. این موضوع باعث شد انسان‌ها وارد عمل شوند و محدودیت‌های سیستمی را اعمال کنند.

مهندسان همچنین مجبور بودند سیستم را در برابر بررسی‌های متخاصم «کوته‌بینانه» (Myopic) محافظت کنند. در یک مورد، یک بررسی بیش از حد محافظه‌کارانه درباره اعتماد به یک سرویس داخلی باعث شد کلود اعتبارسنجی‌ها و پیچیدگی‌های بیش از حدی اضافه کند. اکنون مهندسان درخواست‌های تغییر را با بررسی «قصد» (Intent) تغییر بررسی می‌کنند، به‌جای اینکه هر خط کد را بخوانند.

نتایج عملیاتی و بازنگری در چرخه توسعه

این تغییر نتایج ملموس و فوری در بهره‌وری داشت. ردپای زیرساختی (Infrastructure Footprint) برای کنترل نسخه اکنون از نظر CPU و حافظه ۲۰۰ برابر کوچک‌تر از تنظیمات آینه‌سازی Git است.

کارهای CI و پژوهشی اکنون کدها را در عرض چند ثانیه دریافت می‌کنند، نه چند دقیقه. این افزایش بهره‌وری به‌تنهایی ۲۵٪ از کل ظرفیت پردازشی خوشه CI را بازپس گرفت. علاوه بر این، حذف نیاز به نگهداری مخزن (Repository Maintenance)، مدیریت چرخه حیات تمام Jobها را ساده‌تر کرد.

آنتروپیک اکنون حتی استانداردهای انسانی مانند «صف ادغام» (Merge Queue) — که بر قفل‌های سراسری مخزن متکی است — را به چالش کشیده است، زیرا وقتی هزاران تغییر هم‌زمان ادغام می‌شوند، این روش‌ها کار نمی‌کنند. به‌جای آن، آن‌ها به سمت تست‌های خودکار «پس از ادغام» و «پیش از استقرار» حرکت کرده‌اند. وقتی تغییرات هم‌زمان تداخل (Conflict) دارند، کلود معمولاً تداخل را سریع‌تر از آنکه یک انسان حتی بتواند آن را شناسایی کند، حل می‌کند.

برای نگهداری سیستم، تیم از «سوپرفن‌ها» (Superfans) استفاده می‌کند؛ نمونه‌های اختصاصی از Claude Tag که به‌طور وسواسی تله‌متری و لاگ‌های اجزای خاص را رصد می‌کنند. این‌ها شامل موارد زیر است:

• یک سوپرفن برای scion-daemon
• یک سوپرفن برای scion-cache
• یک سوپرفن برای صف ادغام Antique

این عامل‌ها مانند مهندسان باتجربه‌ای عمل می‌کنند که تمام وقت خود را صرف رصد نمودارها می‌کنند تا مسائل ظریف و جدیدی را شناسایی کنند که هشدارهای تک‌بعدی سنتی از آن‌ها می‌گذرند.

امنیت نیز از ابتدا در سیستم گنجانده شد. اسایون از کنترل دسترسی غنی روی مخازن و مجوزها برای دایرکتوری‌های مجزا برای محافظت از کدهای حساس پشتیبانی می‌کند. ابزارهای بررسی کد می‌توانند محدودیت‌های معنایی پیچیده‌ای را بیان کنند و به بررسی‌کنندگان انسانی اجازه دهند تغییرات صرفاً متنی (Comment-only) را نادیده بگیرند و بر تغییرات منطقی اثرگذار تمرکز کنند.

این گذار نشان می‌دهد که با به دست گرفتن بخش عمده کدنویسی توسط عامل‌های AI، گلوگاه از «عمل نوشتن کد» به «زیرساختی که آن را مدیریت می‌کند» منتقل می‌شود.

مشارکت در اکوسیستم

آنتروپیک اشاره می‌کند که اسایون جایگزینی عمومی برای Git نیست. این سیستم برای Monorepoهای عظیم با ده‌ها هزار مهندس یا ارتش‌هایی از عامل‌ها طراحی شده است. مهاجرت به اسایون مستلزم آن است که یک شرکت کل چرخه توسعه خود، از جمله بررسی کد، جست‌وجو و CI را جایگزین کند.

با این حال، آن‌ها پیش‌بینی می‌کنند که این مشکلات مقیاس‌پذیری در ۶ تا ۱۲ ماه آینده رایج شوند. آن‌ها پیشنهاد می‌کنند تیم‌های دیگر می‌توانند درس‌های اسایون را بدون ترک کامل مدل Git به کار ببرند؛ مثلاً با پیاده‌سازی RPCهای جامع در سمت سرور یا معماری‌های جدید سرور که عملیات سرور را از کلاینت جدا می‌کند.

منتظر باشید تا سایر آزمایشگاه‌های بزرگ AI نیز در سال آینده، زمانی که جریان‌های کاری عامل‌محور آن‌ها به همان دیوار مقیاس‌پذیری برخورد می‌کند، از Git فاصله بگیرند.

گام بعدی شما

• اگر در پروژه‌های بزرگ با کندی Git مواجهید، بررسی کنید آیا استفاده از Sparse Checkout یا انتقال به معماری‌های Server-side RPC می‌تواند کمک کند.
• برای تیم‌های DevOps: بررسی کنید که چگونه می‌توان بخش‌های دریافت کد در CI را مجازی کرد تا زمان بوت شدن محیط‌های تست کاهش یابد.
• رصد کنید که آیا سایر آزمایشگاه‌های AI نیز برای مدیریت عامل‌های خود از Git فاصله می‌گیرند یا خیر.

اما داستان سخت‌افزاری این تحول حتی شگفت‌انگیزتر است — به تحلیل ما درباره‌ی تراشه‌های Blackwell مراجعه کنید.