الكاتبة: Zheng Jiamei
التحرير: Cen Feng
لقد دعم Git تطوير البرمجيات لأكثر من عشرين عامًا، ومع ذلك قررت Anthropic استبداله. ولضمان انسياب الأكواد التي يولّدها Claude باستمرار في مسار التطوير، أمضى 7 مهندسين 5 أشهر في تطوير نظام التحكم بالإصدارات Scion، ونقلوا مستودعات الأكواد الأساسية إليه. في مايو من هذا العام، كان Anthropic يدمج في المتوسط نحو 2500 تغيير برمجي يوميًا، وبحلول الشهر 9 (سبتمبر) تجاوز العدد 30,000 تغيير، وكان نظام CI وحده ينفذ يوميًا نحو 25 مليون عملية سحب (checkout) للأكواد. تحسّنت سرعة كتابة الأكواد، لكن تجهيز المستودعات ومزامنة الكائنات والاستعلام عن السجل أصبحت تستهلك موارد حوسبية متزايدة. وفي الفترة نفسها تقريبًا، استبدلت GitHub الأحكام الصادرة عن نموذج LLM العام في فحص المفاتيح بـ ModernBERT بعد ضبطه الدقيق. في حين قامت جامعة كولومبيا وGoogle DeepMind ومؤسسات أخرى، عبر BTTF، بتحويل أشكال الموجات لمحاكاة الرقائق إلى SQLite، لتمكين الوكلاء (Agent) من استخدام SQL للتحقيق في الحالات الشاذة. Scion متصل بالشبكة افتراضيًا، وBTTF حوّلت أشكال الموجات إلى واجهة استعلام، وGitHub سلّمت الأحكام عالية التكرار إلى مصنف. الأنظمة التي صُممت حول إيقاع التطوير البشري بدأت تتحمل نوعًا مختلفًا من الأحمال تفرضها الوكلاء.
01
لماذا أصبحت قدرة Git على العمل دون اتصال عبئًا؟
تصميم Git الموزّع يتيح للمهندسين بعد استنساخ المستودع الالتزام والدمج واستعراض التاريخ حتى دون اتصال بالشبكة. لكن مهام Anthropic كثيرة القراءة للأكواد هي وظائف CI متصلة بالشبكة دائمًا وبيئات عزل للوكلاء (Agent sandboxes)، تُدمَّر بعد دقائق من التشغيل، وقد تحتاج فقط إلى ملفات قليلة أو diff واحد أو التحقق من علاقة السلف بين إلزامين (commits). وتجهيز مستودع محلي لهذه العمليات يتكلف بصورة متزايدة التكرار. يبلغ تاريخ الفرع الرئيسي لدى Anthropic نحو 100 GB، وتتجاوز النسخة العاملة المضغوطة 25 GB. وإذا حصلت كل عملية من عمليات الاستخراج البالغة 25 مليونًا يوميًا على نسخة كاملة، فستتجاوز حركة البيانات النظرية 600 PB. ورغم أن الشركة تستخدم الاستنساخ السطحي والاستخراج المتناثر واللقطات ومئات خوادم مرايا Git، تبقى المرايا بحاجة إلى مزامنة، وتنتهي صلاحية اللقطات، وتتطلب استعلامات التاريخ استكمال الكائنات. كلما نشط المستودع ارتفعت تكلفة الصيانة. اختصرت Scion البرنامج العميل إلى مدخل خفيف. نُقلت إنشاء الإلزامات والدمج وإعادة الأساس (rebase) واستعلامات التاريخ إلى خدمة مركزية، ويقتصر العمل المحلي على مراقبة تغيّرات الملفات والحفاظ على ذاكرة تخزين مؤقت صغيرة، مع توسيع دليل العمل عند الحاجة فقط. وإذا أراد CI حساب diff فقط، يمكنه استدعاء الـAPI مباشرة دون استخراج كامل. تم تضحية الاستقلال دون اتصال، لكن تكرار التهيئة قلّ. تغيّرت صيغة الإلزام أيضًا. يشير Git commit إلى شجرة أدلة تصف حالة المستودع، أما changeset في Scion فيسجّل في مدخلات سجل الكتابة المسبقة (write-ahead log) الملفات المعدّلة نسبةً إلى أول إلزام أب، ويشير إلى البيانات عبر مؤشرات معنونة بالمحتوى. إنشاء changeset لا يتطلب توليد Git packfile ولا تحريك الفروع المشتركة فورًا، وعند تحديث المراجع مثل main فقط ينفّذ النظام عملية compare-and-swap على سجل أحادي الصف في Spanner. يمكن للوكلاء توليد التغييرات بشكل متزامن، ويتركز التنافس عند تحريك مراجع الفروع. لكن استعلامات التاريخ ما تزال تواجه صعوبة: لا يمكن للسجلات التزايدية الإجابة مباشرة عن هوية من عدّل سطرًا معينًا أو ما مرّ به ملف. تحتفظ Scion ببيانات مشتقة (derived data) لـblame وتاريخ المسارات وجدول القفز لرسم الإلزامات، محسوبة مسبقًا وفق علاقات الإلزامات الآباء، أو مولّدة بعد وقوع الاستعلام. يمكن للتوسّع في الكتابة والتحليل التاريخي أن يتم بشكل مستقل. أثناء الاستخراج، يبدأ العميل scn من شجرة الأدلة الهدف ويطلب فقط الـtree والـblob الناقصة. تمر الطلبات تتابعيًا عبر scion-daemon على العقدة، ثم scion-cache على مستوى المنطقة، ثم يعود scion-server إلى المصدر: Spanner أو مخزن الكائنات. الكائنات غير قابلة للتغيير بعد الكتابة، ويمكن للذاكرة المؤقتة إعادة استخدامها عبر المهام، ما يقلل التفاوض والضغط والنقل المتكرر. تقول Anthropic إن نسبة إصابة الذاكرة المؤقتة تجاوزت 99%، وأنها تحدّ من حركة العودة إلى المصدر عند الأعطال. بعد الترحيل، انخفضت احتياجات Scion من CPU والذاكرة مقارنة بنظام مرايا Git القديم بنحو 200 مرة، وانخفض الاستخراج من مستوى الدقائق إلى مستوى الثواني، وأفرِج عن نحو 25% من سعة CPU في CI. أما «200 مرة» فهي تتعلق باستهلاك موارد البنية التحتية، لا بتسريع عمليات Git ككل. كما أنشأت Anthropic بالتوازي أدوات Antique لمراجعة الأكواد والبحث في الشيفرة المصدرية وإدارة الهويات (IAM) والدمج الجماعي، لتناسب البروتوكول الجديد. وصارت صيانة الخدمات المتصلة بالإنترنت تكلفة جديدة.02
جعل قاعدة البيانات تقرأ الموجات ليتسنى للوكيل تعقّب الأعطال
يواجه التحقق من الرقائق عقبة من نوع آخر. تسجّل الموجات الناتجة عن محاكاة RTL من نوع VCD وFSDB حالة آلاف الإشارات مع الزمن، وقد تبلغ المُخدّسات (dumps) للتصاميم المعقدة عشرات GB بل حتى TB. يمكن للمهندسين البحث في عارض الموجات عن الشذوذ على طول المحور الزمني، أما إذا حوّل الوكيل الموجات الخام إلى نص، فسرعان ما يمتلئ سياقه بالطوابع الزمنية وأسماء الإشارات والقفزات المتكررة، وقد يعيد قراءة الملفات لتعقّب إشارات أخرى. كذلك، اعتاد البشر أن يستخدموا أعينهم في «إبرة في كومة قش» داخل الرسوم البيانية، لكن لا يتسع لأي سياق مهما كبر أن يحتوي عشرات GB من الملفات الفيزيائية. لذلك فإن تحويل هذه «الملفات الميتة» إلى «واجهات حية» قابلة للاستدعاء الدقيق عبر SQL هو الحل الأمثل لإطعام البيانات للذكاء الاصطناعي. سلّمت BTTF الوصول إلى البيانات لـSQLite. يحفظ الجدول signal_metadata المعلومات الثابتة كأسماء الإشارات وأنواعها وتسلسلها الهرمي، ويسجّل الجدول signal_changes معرّف الإشارة والطابع الزمني والقيمة بعد التغيّر، ويرتبط الجدولان عبر المعرّف. للاستعلام عن حالة إشارة في لحظة محددة، يجد SQL أقرب سجل تغيير قبل تلك اللحظة، وللتحقق من الانقلابات خلال فترة زمنية، يُجرى التصفية والتجميع حسب نافذة زمنية. تبقى الحالة ثابتة بين قفزتين، ولا يجوز اعتبار غياب سجل جديد حالة مجهولة. يحتاج النموذج فقط إلى معالجة السؤال وعدد قليل من الأحداث المرجعة. فمثلًا، إذا انتهت مهلة بروتوكول مصافحة معين، يمكن للوكيل أولًا استرجاع تغيّرات إشارتي الطلب والاستجابة، ثم تضييق النطاق إلى الفترة الشاذة وفحص العلاقات الزمنية. قاعدة البيانات تتولى الاسترجاع، والنموذج يقرر ما يستعلم عنه لاحقًا. يجب أن تتوافق الاستعلامات مع معرّف الإشارة ووحدة الزمن وإصدار RTL. لكن نقل الموجات إلى قاعدة البيانات لا يزيل الضغط تلقائيًا. تنتج الساعات عالية التردد سجلات كثيفة، وللإدراج سطرًا بسطر (INSERT) تكلفة معاملات. تؤسس BTTF عند الاستيعاب خرائط من معرّفات الموجات إلى معرّفات قاعدة البيانات، وتحصي انقلابات الإشارات، وتجمع بين تصفية الساعات واقتصاص الإشارات عديمة الانقلاب والإدراج الدفعي. دون اقتصاص تشغل قاعدة البيانات 1420 MB ويستغرق الاستعلام نحو 410.5 مللي ثانية، وبعد تصفية الساعات والإشارات عديمة الانقلاب انخفض الحجم إلى 395 MB وانخفض الزمن إلى 94.8 مللي ثانية. وإذا استُبعدت أيضًا الإشارات التي يقل معدل انقلابها عن المتوسط، يمكن تقليص قاعدة البيانات إلى 185 MB، لكن تغطية الأنشطة لا يبقى منها سوى 64.23%. قد تظهر الأعطال النادرة تحديدًا في إشارات تحكم نادرة الانقلاب. فإذا حُذفت البيانات عند مرحلة الاستيراد، لن يستطيع الوكلاء اللاحقون استعادة الأدلة. يجب أن يخضع الاقتصاص للاجتراءات واحتياجات التنقيح. ومع توفر واجهة SQL، نظّمت BTTF توزيع أدوار بين وكلاء مختلفين: Orchestration Agent يفكك المهام، وAnalysis Agent يولّد الاستعلامات، وVerification Agent يفحص الاجتراءات ويربطها بشيفرة RTL المصدرية، وEvaluation Agent يتحقق من النطاقات الزمنية وعلاقات الحقول واكتمال النتائج. مثلًا، إذا اكتشف ASSERT_KNOWN حالة مجهولة X/Z في إشارة، يحدد النظام أولًا لحظة المخالفة، ثم يفحص للأمام حالة المعاملات المرتبطة، محدّدًا تدريجيًا الوحدة المحتملة. ويمكن تصحيح أخطاء SQL ومتابعة العمل. وفي تجربة شملت موجات بحجم 4.2 GB و18450 إشارة و150 استعلامًا موسومًا من خبراء، حقق الفريق البحثي دقة تنفيذ 95.33%. ارتفع تقييم جودة Multi-Agent بنسبة 17.3% مقارنة بالوكيل الواحد، وارتفع زمن الاستجابة المتوسط أيضًا إلى نحو 1.96 مرة، بينما بلغت دقة فحص SVA الثابت 84.62%. يمكن للحل أن يدعم تحليل ما بعد المحاكاة، لكن الاستيعاب المستمر والإسناد المعقد ما يزالان بحاجة إلى تحقق.03
لماذا عاد مسح المفاتيح إلى المصنّفات
قد تكون السلاسل عالية الإنتروبيا بيانات اعتماد حقيقية، أو بيانات اختبارية أو عناصر نائبة أو مجاميع تحقق. تسرع التعبيرات النمطية (regex) في العثور على الصيغ المشبوهة، لكنها ضعيفة في الحكم على سياق الشيفرة، ويمكن لنموذج LLM عام أن يساعد في التمييز، لكن كلما زاد المرشحون تراكمت تكلفة الاستدلال والتأخير. وبالنسبة إلى Push Protection الذي يلزمه إعطاء نتيجة قبل قبول الإلزام البرمجي، يؤثر هذا الانتظار مباشرة في تجربة التطوير. أبقت GitHub التعبيرات النمطية كمدخل للمرشحين، وسلّمت الحكم اللاحق إلى ModernBERT بعد ضبطه الدقيق. يقرأ النموذج السلسلة المرشحة ونوع المفتاح واسم المتغير ومسار الملف والشيفرة المجاورة، ويخرج درجة تصنيف للمخاطر، ثم يحدد عتبة ما إذا كان سيُطلق إنذار. يمكن للمرمّز (encoder) إرجاع الفئة بحساب أمامي واحد، دون الحاجة إلى توليد تفسير رمزًا برمزًا (token) كالنماذج التوليدية، ما يجعله مناسبًا للمعالجة الدفعية للطلبات المتشابهة. تتمثل الصعوبة في hard negatives: سلاسل تشبه المفاتيح لكنها أمثلة غير ضارة. جمعت GitHub ملاحظات المنتج والتوسيم اليدوي، والمرشحين عالي الاستدعاء من مستودعات حقيقية، والعينات السلبية الصعبة المُصنّعة خصيصًا، وقسّمت مجموعات التدريب والتقييم حسب المستودع وقيمة المرشح وعلاقات الارتباط، لتقليل انحياز التقييم الناتج عن البيانات المتشابهة. وإلا فقد يحفظ النموذج أسماء الملفات لكن يعجز عن تمييز بيانات الاعتماد في مشاريع مألوفة. عند النشر، صُدّر النموذج إلى ONNX وخُفّض كميًا إلى 8 بت لتقليل تكلفة موارد الاستدلال. كما يجب معايرة العتبة مع Precision وRecall وحركة الإنتاج الفعلية: التساهل الزائد يسبب إنذارات كاذبة، والصرامة الزائدة قد تسمح بمرور مفاتيح حقيقية. وعند ظهور صيغ مفاتيح جديدة، يلزم تحديث مجموعة التدريب والقواعد. مقارنة بخط أنابيب LLM القديم، ارتفع Precision دون الاتصال في الحل الجديد بنسبة 13%، وارتفع Recall بنسبة 19%. وأظهرت تجربة A/B على الإنتاج أن الوسيط لزمن تنفيذ مسح Post-push انخفض بنسبة 86%، وانخفضت تكلفة خدمة النموذج بأكثر من 98%، وارتفع مؤشر قبول الإنذارات الموزون بمالكي المستودعات بنسبة 11.5%. ونشير إلى أن نسبة 98% هنا تشير إلى رسوم خدمة النموذج، لا إلى التكلفة الإجمالية لنظام الأمن ككل. كما لا يستطيع المصنّف إلا الحكم على المرشحين الذين عثرت عليهم التعبيرات النمطية، ويظل تغطية القواعد المسبقة قاصرة على أداء تجنّب الإنذارات الناقصة. القواعد تكتشف الأدلة، والمصنّف يُتمّ الحكم، ويمكن ترك التحليل المفتوح لنماذج LLM العامة، تفاديًا لتحمّل تكلفة الاستدلال التوليدي في كل حكم ثابت.04
قد يأتي بعدها دور CI
اختصر GitHub زمن التغذية الراجعة للمسح الأمني، لكن ما زال على الكود أن يمر بعد ذلك بالبناء والاختبار والنشر. وبعد أن حلت Anthropic مشكلة سحب الكود المصدري، واجهت هيكلًا جديدًا: قبل أن تنتهي جولة اختبار واحدة، قد يُدمج في الفرع الرئيسي مئات بل آلاف التعديلات. الاستمرار في الاعتماد على القفل العام يجعل التغييرات تتراكم باستمرار، بينما فتح التزامن يجلب مخاطر جديدة؛ فحتى لو نجح اختبار ما، قد تختلف حالة الكود المقابلة له عن النسخة المعدّة للنشر. هذا يعني أن ما سيتعين على CI معالجته بعد ذلك هو كيفية بقاء نتائج التحقق صالحة وسط التغييرات عالية التكرار. يحتاج ذاكرة تخزين البناء المؤقتة إلى التعرف على تغيّرات الكود المصدري وعلاقات الاعتماد، ويجب أن ترتبط سجلات الاختبار بعمليات الإرسال (commits) ومخرجات البناء بعينها، كما يتعين على النظام أن يحدد أي النتائج قابلة لإعادة الاستخدام وأي التعديلات تُبطل عمليات التحقق السابقة. بالنسبة إلى Monorepo ذات علاقات اعتماد معقدة، يصعب على مجرد زيادة أجهزة الاختبار أن تحل مشكلة اتساق الإصدارات الناتجة عن التعديلات المتزامنة. بدأت Anthropic بالفعل في تعزيز الاختبارات بعد الدمج والتحقق قبل النشر. أما بالنسبة للفرق العادية، فتحسين تحليل الاعتماد والاختبار التزايدي وذاكرة البناء المؤقتة أولاً أكثر واقعية من إعادة بناء نظام التحكم في الإصدارات من الصفر. ومع استمرار الـ Agents في رفع إنتاجية الكود، سيستمر عنق الزجاجة في هندسة البرمجيات بالتحرك للخلف على طول سلسلة التسليم. يمكن أن تتسارع وتيرة دخول الكود إلى الفرع الرئيسي أكثر فأكثر، لكن يجب الحفاظ على علاقات تحقق موثوقة بين البناء والاختبار والنشر. قد تزداد الأمثلة مستقبلاً التي توضح أنالاندفاع الجامح للذكاء الاصطناعي في كتابة الكود اضطر في نهاية المطاف خط إنتاج هندسة البرمجيات بأكمله إلى "إعادة عمله من جديد".وستتجلى قيمة البنية التحتية الهندسية أكثر فأكثر في قدرتها على تمكين الكود سريع التغير من الاحتفاظ باستمرار بأساس تسليم موثوق.رابط مرجعي:https://www.anthropic.com/engineering/redesigning-source-controlانضم إلينا لمشاهدة خلاصة أفضل المؤتمرات العالمية للذكاء الاصطناعي
معاينة حصرية:
عروض PPT التقديمية للخبراء
النص الكامل لتقارير المؤتمرات
تفسيرات الأوراق البحثية الأكثر رواجًا
مقابلات مع النجوم الأكاديميين الصاعدين
امسح رمز QR أعلاه
أو انقر "قراءة النص الأصلي" لمتابعة القسم المخصص.
مقالات Leiphone الأصلية، يُمنع إعادة نشرها دون إذن. للتفاصيل راجعشروط إعادة النشر。