Anthropic Scion: لماذا استبدلت Anthropic نظام Git، وما الذي يمكن للفرق التي تشغل وكلاء البرمجة فعله اليوم

إجابة سريعة: يُعد Anthropic Scion نظامًا داخليًا للتحكم في الإصدارات طورته شركة Anthropic بعد أن تسببت وكلاء البرمجة (Coding Agents) في قفزة بعمليات الدمج (Merges) في مستودعها الموحد (Monorepo) من قرابة 2,500 عملية دمج يوميًا في مايو 2026 إلى أكثر من 30,000 عملية يوميًا بحلول سبتمبر. ينفّذ Scion عمليات الإيداع (Commits) والدمج وتعديل الأساس (Rebases) على الخادم مباشرة. إنه نظام داخلي، وتؤكد Anthropic أنه ليس بديلًا عامًا لنظام Git.

ما الذي فعلته Anthropic مع Scion، ولماذا؟

في 13 أكتوبر 2026، نشر الفريق الهندسي لشركة Anthropic مقالًا بعنوان Redesigning source control at Anthropic (إعادة تصميم نظام إدارة المصدر في Anthropic). وجاءت البداية بعبارة صريحة ومباشرة: «لم تعد كتابة الأكواد هي عنق الزجاجة أمام بناء الأنظمة أو إجراء الأبحاث». وبدلًا من ذلك، فإن عنق الزجاجة الحقيقي بحسب تعبيرهم يكمن في «كافة البنى التحتية للمطورين المصممة للتعامل مع النطاق البشري: أنظمة التحكم في المصدر، والبناء، والتكامل المستمر (CI)».

وتوضح الأرقام سبب ذلك؛ ففي مايو 2026، كانت الشركة تدمج نحو 2,500 تغيير برمجي يوميًا، لكن بحلول سبتمبر تجاوز هذا الرقم 30,000 عملية دمج. إنها قفزة بمقدار 12 ضعفًا خلال أربعة أشهر فقط، وتعزو Anthropic ذلك إلى تولي الوكلاء الأذكياء مهمة كتابة الأكواد.

صمد Git أمام النطاق البشري، لكنه تعثر أمام نطاق الوكلاء. تفيد تقارير Anthropic بتسجيل نحو 25 مليون عملية استرجاع (Checkout) لـ CI يوميًا، وسجل للفرع الرئيسي يقترب من 100 جيجابايت، وعدة مئات من خوادم Git المتطابقة (Mirrors) داخليًا في أوقات الذروة. ولو اعتمدت الشركة استراتيجية جلب (Fetch) عادية، لبلغت حركة مرور بيانات Git أكثر من 600 بيتابايت يوميًا.

لذا، عكف فريق مكوّن من سبعة مهندسين على بناء Scion، إلى جانب أداة لمراجعة الأكواد تُدعى Antique، ونظام للبحث في الكود، ونظام لإدارة أذونات الوصول على مستوى المجلدات. وتمكنوا من نقل المستودع الموحد (Monorepo) بالكامل بعيدًا عن Git خلال خمسة أشهر. بل وجعلت Anthropic نموذج Claude Mythos Preview يعيد كتابة مسار استيعاب ونقل البيانات من Git إلى Scion، فجاءت النسخة الجديدة باستهلاك ذاكرة أقل بمقدار 20 ضعفًا وبسرعة أعلى بـ 4 أضعاف.

إذا كنت تستخدم Claude Code أو Codex أو أي وكيل برمجي آخر عبر فريق عمل، فإن هذا المقال يمنحك نظرة مسبقة على عنق الزجاجة القادم الذي ستواجهه. ولهذا الغرض صُممت Sharkly لمعالجة هذه المشكلة تحديدًا: فهي تبقي عمل الوكلاء ونتائجهم وعمليات المراجعة مجمعة في مهام مشتركة (Tasks) بدلًا من تشتيتها عبر شاشات الأوامر الطرفية (Terminals).

كيف يختلف Scion عن Git؟

يفترض Git أن كل نسخة مستنسخة (Clone) هي نسخة كاملة ومكتفية ذاتيًا من السجل التاريخي وتعمل دون اتصال بالإنترنت. في المقابل، يفترض Scion العكس تمامًا: الأجهزة العميلة متصلة دائمًا بالإنترنت وتقوم بالحد الأدنى من المعالجة محليًا.

تتألف البنية الهندسية من ثلاثة مستويات: scion-daemon على كل عقدة، وscion-cache لكل منطقة، والخادم المرجعي الأساسي scion-server. أما واجهة سطر الأوامر للعميل (CLI) فهي scn. وتتجاوز معدلات الإصابة في الذاكرة المؤقتة (Cache hit rates) نسبة 99% في كل مستوى.

وكان العائد ضخمًا؛ إذ انخفض استهلاك المعالج والذاكرة بمقدار 200 ضعف مقارنة بإعدادات النسخ المتطابق السابقة في Git. وباتت عمليات استرجاع الكود لـ CI والأبحاث تستغرق ثوانٍ معدودة بدلًا من دقائق، كما اكتسبت بيئة التكامل المستمر سعة إضافية في المعالجة بنسبة 25%.

ما الذي تتخلى عنه عند تنفيذ الإيداعات على جانب الخادم؟

التخلي عن الإيداعات المحلية لصالح الإيداعات على جانب الخادم يعني التضحية بالميزة الأهم التي جعلت Git ينتصر: وجود سجل تاريخي كامل محليًا يمكنك العمل عليه حتى وأنت على متن طائرة. وتصرح Anthropic بذلك بوضوح؛ إذ تؤكد أن Scion «ليس بأي حال من الأحوال بديلًا مناسبًا لـ Git للاستخدام العام»، وأن تقديمه بشكل يمكن للمؤسسات الأخرى استخدامه سيكون أمرًا بالغ الصعوبة. كما أنه لم يُطرح للعامة، ولم يصفه المقال بأنه مفتوح المصدر.

كما تختلف آلية إدارة التزامن (Concurrency) عما قد تتوقعه؛ إذ لا تُرتّب Anthropic كل عملية دمج في طابور متسلسل خلف قفل عام (Global lock). فالتعارض بين التغييرات المتزامنة وارد، ويتدارك الفريق ذلك عبر اختبارات ما بعد الدمج (Post-merge) واختبارات ما قبل النشر (Pre-deploy).

نظام Git لوكلاء الذكاء الاصطناعي: الدرس المستفاد للفرق التي لا تملك Scion

لن تحصل على Scion، ولست بحاجة إليه أساسًا؛ فمستودعك لا يبلغ حجمه 100 جيجابايت، ولا تجري 25 مليون عملية استرجاع يوميًا. لكن الجانب المفيد في المقال هو فهم طبيعة المشكلة، التي تظهر بغض النظر عن حجم الفريق أو المشروع.

عندما يتولى الوكلاء كتابة الكود، ينتقل عنق الزجاجة إلى المراحل التالية؛ ينتقل أولًا إلى مرحلة الدمج، ثم إلى المراجعة. وتصف كل من تغطية DevOps.com وتقرير TechSpot نظام Scion بأنه بنية تحتية تحاول مواكبة مخرجات الوكلاء. وفريق مكون من خمسة أفراد يشغّلون عشرة وكلاء سيصطدم بنسخة مصغرة من هذا الجدار نفسه.

وستتعرف على الأعراض بسهولة:

1. يقوم وكيلان بتعديل الملف نفسه في فترة ما بعد الظهر نفسها، وتضطر لحل التعارض يدويًا.
2. تتراكم طلبات السحب (Pull Requests) بمعدل أسرع من قدرة أي شخص على قراءتها ومراجعتها.
3. تزداد طوابير انتظار التكامل المستمر (CI) طولًا أسبوعًا تلو الآخر، بينما تواصل الوكلاء عملها بسرعة فائقة.
4. لا أحد يستطيع تحديد أي وكيل أجرى هذا التغيير أو ذاك، أو ما هو السبب.
5. فرع بدأ العمل عليه يوم الثلاثاء يتحول عند تعديل أساسه (Rebase) يوم الجمعة إلى فوضى عارمة.

عالجت Anthropic البندين 1 و3 عبر بناء بنية تحتية جديدة. أما أنت، فيمكنك معالجة البنود الخمسة جميعها من خلال تنظيم الإجراءات واستخدام أدوات Git المتوفرة لديك بالفعل.

تعارضات الدمج مع وكلاء البرمجة: لماذا تتضاعف؟

تتزايد تعارضات الدمج بالتوازي مع التداخل، وليس مع عدد الأفراد أو الوكلاء. فعشرة وكلاء يعملون على هدف واحد واسع سيلمسون الملفات ذاتها باستمرار، في حين أن عشرة وكلاء يعملون على عشر مهام محددة بدقة نادرًا ما يتصادمون. فحجم كل مهمة ونطاقها أهم بكثير من عدد الوكلاء.

وتزيد الفروع طويلة الأمد الطين بلة؛ فمع كل ساعة يظل فيها الفرع مفتوحًا، يتقدم الفرع الرئيسي خطوات للأمام مبتعدًا عنه. ويزيد الوكلاء من حدة ذلك لأنهم ينشئون فروعًا بوتيرة أسرع من قدرة البشر على إغلاقها ودمجها. ويوضح مقالنا السابق حول كم عدد أيام عمل الوكلاء التي يمكن ليوم عمل بشري واحد مراجعتها هذه الفجوة بالأرقام.

ما يمكنك فعله اليوم دون الحاجة إلى Scion

تغطي هذه العادات الخمس معظم ما يحتاجه أي فريق عادي، ولا يتطلب أي منها نظامًا جديدًا للتحكم في الإصدارات.

خصص لكل مهمة مساحة عمل خاصة بها (Worktree)

تُعد شجرة عمل Git (Git worktree) بمثابة مجلد عمل إضافي مرتبط بالمستودع نفسه. وتخصيص شجرة عمل واحدة لكل مهمة يضمن عدم قيام وكيلين بالكتابة في المجلد ذاته في الوقت نفسه.

git worktree add ../tasks/COIN-212 -b agent/COIN-212 origin/main
cd ../tasks/COIN-212
# run the agent here, commit, push, open a PR
git worktree remove ../tasks/COIN-212

نستعرض تفاصيل هذا الإعداد في مقال Git worktrees for AI coding agents، ونغطي جانب التنظيف في مقال managing worktrees without the cleanup pain.

اجعل المهام صغيرة ومحددة النطاق

صغ كل مهمة بحيث تحدد بوضوح الملفات أو الوحدة البرمجية (Module) التي يمكن تعديلها، إلى جانب الاختبار أو المعيار الذي يثبت اكتمالها. المهمة التي تنحصر في فارق كود (Diff) واحد قابل للمراجعة تندمج بسلاسة، بينما مهمة فضفاضة مثل «إعادة هيكلة نظام المصادقة» لا تندمج بسلاسة أبدًا.

ضع طابور دمج أمام الفرع الرئيسي

يختبر طابور الدمج (Merge queue) كل طلب سحب مقابل أحدث إصدار من الفرع الرئيسي بالإضافة إلى كل التعديلات التي تسبقه في الطابور، ثم ينفذ الدمج بالترتيب. توفر خاصية Merge queue في GitHub ذلك للفروع المحمية. وهي تمثل النسخة المناسبة للفرق الصغيرة مما تتعامل معه Anthropic عبر اختبارات ما بعد الدمج: بحيث لا تتفاجأ بالأخطاء الناتجة عن تضارب التعديلات بعد أن تصبح جزءًا من الفرع الرئيسي.

اربط المراجعة بالمهمة، مدعومة بالأدلة

فارق الكود (Diff) بمفرده لا يوضح للمراجع ما طُلب من الوكيل فعله أو ما قام باختباره والتحقق منه. وتصبح عملية المراجعة أسرع بكثير عندما تجتمع تفاصيل الطلب، وتشغيل المهمة، ومخرجات الاختبارات، وفارق التعديلات في مكان واحد. راجع مقالينا how to review AI-generated code with task-level evidence وwhy human review becomes the bottleneck.

اجعل الوكلاء ينتظرون الموافقة

دع الوكلاء يبحثون، ويكتبون الكود، ويجرون الاختبارات، ويقدمون التقارير؛ واترك للبشر مهمة تحديد التوجه، والموافقة على الخطوات عالية المخاطر، واعتماد النتيجة النهائية. فوكيل يتوقف وينتظر مراجعة بشرية قبل الدمج يكلفك بضع دقائق، بينما وكيل يدمج عملًا لم تتم مراجعته في الفرع الرئيسي قد يكلفك يوم عمل كاملًا. ويوضح دليلنا حول approval gates for coding agents المواضع الأنسب لوضع نقاط التوقف هذه.

أين يأتي دور Sharkly؟

لا تحل منصة Sharkly محل Git، ولا تقوم بحل تعارضات الدمج نيابة عنك؛ فوكلاؤك يواصلون إيداع الكود في مستودعك عبر منصة استضافة Git الحالية لديك. ما تنظمه Sharkly هو سير العمل المحيط بتلك الإيداعات.

يمثل كل جزء من عمل الوكيل مهمة (Task) لها مسؤول (Assignee)، وحالة، وسجل تنفيذ. وتعمل الوكلاء على حواسيبك الخاصة (Computers)، باستخدام بيئات التشغيل مثل Claude Code أو Codex أو غيرها مما تدفع رسومها بالفعل. وفي الوضع المؤقت (Temporary mode)، تحصل كل مهمة على مجلد معزول، كما يمكن لعمليات التشغيل المرتبطة بمستودع إعداد مساحة عمل (Worktree) منفصلة، وبذلك لا تكتب المهام المتزامنة في مجلد مشترك واحد.

وعندما ينهي الوكيل عمله، يمكنه ترك المهمة بانتظار المراجعة البشرية. يصل هذا الإشعار إلى صندوق الوارد (Inbox)، حيث يفتح الشخص المسؤول المهمة، ويطّلع على النتيجة ضمن سياقها الكامل، ويتخذ قراره بالقبول أو إعادة المحاولة أو إعادة التعيين. ويعود تنفيذ المهمة (Task execution) والنقاشات اللاحقة به إلى الخط الزمني للمهمة، لتتحول لوحة العمل بأكملها إلى طابور مراجعة منظم لك.

يجمع هذا الأسلوب بين عادات التعامل مع Git المذكورة أعلاه وتوفير مكان مشترك واحد يضم الطلب، والتنفيذ، والأدلة، واتخاذ القرار. وإذا كنت تقارن بين الخيارات المتاحة، فإن استعراضنا لأفضل أدوات إدارة وكلاء البرمجة المتوازية يغطي هذا المجال بشكل شامل.

من ينبغي له التحرك الآن؟

الفرق التي تشغّل ثلاثة وكلاء أو أكثر يوميًا: أنتم على مقربة من الاصطدام بجدار مشاكل الدمج؛ بادروا بتفعيل مساحات العمل (Worktrees) وطابور الدمج هذا الأسبوع.

المطورون المستقلون الذين يشغّلون وكلاء بالتوازي: عنق الزجاجة لديكم يكمن في المراجعة، وليس في الدمج؛ قسّموا المهام إلى أجزاء أصغر حتى لا يستغرق فحص كل فارق كود (Diff) أكثر من عشر دقائق.

قادة المنصات والبنية التحتية: راقبوا مدة انتظار طابور CI وعمر طلبات السحب (PRs). يوضح مقال Anthropic أن نظام إدارة المصدر والتكامل المستمر انهارا قبل أي شيء آخر، وتوقعوا أن يحدث لديكم الأمر بالترتيب نفسه. إن إعداد الوكلاء المتوازية مع مساحات عمل معزولة يمنحكم الوقت الكافي للاستعداد.

خاتمة

يمثل Anthropic Scion مؤشرًا استشرافيًا وليس منتجًا متاحًا للاستخدام؛ فقد تضاعف حجم الدمج لدى Anthropic بمقدار 12 ضعفًا في أربعة أشهر، ولم يعد تصميم Git القائم على العمل دون اتصال ملائمًا، مما دفع فريقًا من سبعة أشخاص إلى إعادة بناء نظام إدارة المصدر ليناسب أجهزة عميلة معظمها وكلاء برمجة ذكية. ولن تحتاج معظم الفرق إلى مثل هذا الحل أبدًا.

مع ذلك، سيواجه كل فريق يعتمد على وكلاء البرمجة هذا التحول عينه؛ فكتابة الكود أصبحت زهيدة التكلفة، في حين بات دمجه ومراجعته باهظ الثمن. لذلك، اعزل كل مهمة، وحافظ على صغر حجم المهام، ونظّم عمليات الدمج في طوابير، واعتمد في المراجعة على الأدلة الواضحة.

ولتجميع جانب المراجعة في مكان واحد، اربط حاسوبًا واحدًا بـ Sharkly، وأنشئ وكيلًا واحدًا، وكلّفه بمهمة صغيرة ومنخفضة المخاطر؛ راقب أين تستقر النتيجة، وانطلق في قراراتك من هناك.

الأسئلة الشائعة

ما هو Anthropic Scion؟

هو نظام داخلي للتحكم في الإصدارات خاص بشركة Anthropic، وقد حل محل Git لمستودع الشركة الموحد في عام 2026. يقوم الخادم بتنفيذ عمليات الإيداع والدمج وتعديل الأساس، بينما تحتفظ الأجهزة العميلة فقط بذاكرة تخزين مؤقتة محلية محدودة.

لماذا استبدلت Anthropic نظام Git؟

رفعت وكلاء البرمجة وتيرة عمليات الدمج اليومية من قرابة 2,500 في مايو 2026 إلى أكثر من 30,000 بحلول سبتمبر. ولم تتمكن عمليات النسخ المتطابق في Git واسترجاع الكود والتكامل المستمر (CI) من مواكبة هذا الحجم الهائل، مما جعل التحكم في المصدر عنق الزجاجة الأساسي.

هل Scion مفتوح المصدر أو متاح للاستخدام؟

لا يتوفر أي إصدار عام منه. وتصرح Anthropic بأن Scion ليس بديلًا عامًا ملائمًا لنظام Git، وسيكون من الصعب تقديمه لمؤسسات أخرى. وقد شاركت تفاصيل تصميمه ليتمكن الآخرون من تطبيق أفكاره على Git.

كيف يمكنني تقليل تعارضات الدمج بين وكلاء البرمجة؟

خصص لكل مهمة مساحة عمل (Worktree) خاصة بها، واجعل المهام محددة بما يكفي لتنحصر في فارق كود (Diff) واحد قابل للمراجعة، وادمج التعديلات بوتيرة متكررة، وضع طابور دمج أمام الفرع الرئيسي. فالتعارضات تنشأ من تداخل التعديل على الملفات، لذا فإن تحديد النطاق أهم من عدد الوكلاء.

هل تحتاج الفرق الصغيرة إلى نظام جديد للتحكم في الإصدارات؟

نادرًا جدًا؛ فمشكلة Anthropic نشأت من سجل تاريخي بحجم 100 جيجابايت و25 مليون عملية استرجاع يوميًا. أما في النطاق الطبيعي، فإن مساحات العمل وطوابير الدمج والمراجعة على مستوى المهام قادرة على استيعاب عبء العمل بالكامل.