خط أنابيب من 7 خطوات للتحقق من الكود الذي يكتبه وكلاء الذكاء الاصطناعي
حين يدفع الوكلاء 3,000 commit يومياً، لا يستطيع البشر مراجعتها جميعاً. إليك كيفية بناء خط أنابيب تتحقق منه الآلات لتكتشف ما يعجز البشر عن اكتشافه.
هذا هو الموضوع الأكثر سخونةً في الوقت الراهن. الوكلاء يُفرزون مئات الـ commits يومياً، ولا أحد يستطيع مراجعتها كلها.
Peter، وهو مطوّر في OpenClaw، يدفع أحياناً أكثر من 3,000 commit في يوم واحد. هذا يتجاوز بكثير ما يستطيع أي إنسان معالجته. لقد باتت مهمةً يعجز البشر وحدهم عن تحملها.
في البداية ظننت أن لا حل. ثم قرأت “Code Factory” لـ Ryan Carson، فاتضحت الصورة. بدلاً من محاولة قراءة كل شيء، تبني هيكلاً تتحقق فيه الآلات من الكود.
حدّد قواعد الدمج في ملف JSON واحد
دوّن المسارات عالية الخطورة والفحوصات الواجب اجتيازها، كل ذلك في ملف واحد. الفكرة الجوهرية هنا أن هذا يمنع التباعد بين التوثيق والسكريبتات.
- المسارات عالية الخطورة تستلزم Review Agent إضافةً إلى أدلة مستندة إلى المتصفح
- المسارات منخفضة الخطورة يمكن دمجها بعد اجتياز policy gate وCI وحدهما
شغّل فحوصات التأهيل قبل CI
تشغيل builds على PRs لم تجتز المراجعة بعد إهدارٌ للمال. ضع risk-policy-gate أمام CI fanout. هذا وحده يُخفّض تكاليف CI غير الضرورية بشكل ملحوظ.
- ترتيب ثابت: policy gate ← تأكيد Review Agent ← CI fanout
- PRs غير المؤهلة لا تدخل مرحلة الاختبار/البناء أبداً
لا تثق أبداً بـ “pass” من commit قديم
هذا ما شدّد عليه Carson أكثر من أي شيء. إذا بقي “pass” من commit قديم، يُدمج آخر كود دون تحقق. أعد تشغيل المراجعات عند كل push، وأوقف البوابة إن لم تتطابق.
- Review Check Run صالح فقط حين يتطابق مع
headSha - أجبر على إعادة التشغيل عند كل حدث
synchronize
أصدر طلبات إعادة التشغيل من مصدر واحد فقط
حين تطلب سير عمل متعددة إعادة التشغيل، تنشأ تعليقات مكررة وحالات تسابق. يبدو الأمر تافهاً، لكن إن لم تُعالجه، اهتزّ خط الأنابيب بأكمله.
- امنع التكرار بنمط
Marker + sha:headSha - تجاوز الطلب إن كان SHA قد أُرسل مسبقاً
دع الوكلاء يتولّون الإصلاحات أيضاً
حين يكتشف Review Agent مشكلةً، يُصلحها Coding Agent ويدفعها إلى نفس الفرع. أبرز ما تنبّه إليه Carson في مقاله: ثبّت إصدار النموذج. وإلا حصلت على نتائج مختلفة في كل مرة، وضاعت قابلية الاستنساخ.
- Codex Action يُصلح ← يدفع ← يُشغّل المراجعة من جديد
- إصدارات النماذج المثبّتة تضمن قابلية الاستنساخ
أغلق تلقائياً محادثات البوت مع البوت فقط
لا تمس خيوط النقاش التي شارك فيها إنسان. بدون هذا التمييز، تُطمر تعليقات المراجعين.
- الحل التلقائي يكون فقط بعد إعادة تشغيل نظيفة على الـ head الحالي
- خيوط ذات تعليقات بشرية تظل مفتوحةً دائماً
اترك أدلةً مرئية وقابلة للتحقق
إن تغيّرت واجهة المستخدم، لا تكتفِ بلقطة شاشة. اشترط أدلةً قابلةً للتحقق من خلال CI. حوّل حوادث الإنتاج إلى حالات اختبار حتى لا يتكرر الفشل ذاته.
- انحدار ← ثغرة في harness ← إضافة حالة اختبار ← تتبع SLA
اختيارات Carson من الأدوات
للرجوع إليها، إليك ما اختاره Carson: Greptile وكيلاً لمراجعة الكود، وCodex Action للمعالجة، فيما تضطلع ثلاثة ملفات لسير العمل بالعبء الأكبر greptile-rerun.yml لإعادة التشغيل الأساسية، وgreptile-auto-resolve-threads.yml لتنظيف الخيوط القديمة، وrisk-policy-gate.yml لسياسة ما قبل الطيران.
ما وراء الصحة: التحقق المرئي
كل ما سبق يكشف إن كان الكود صحيحاً أم لا. لكن في الواقع العملي، تحتاج أيضاً إلى التحقق من شكل المخرجات.
ثمة مقاربتان تبرزان.
المُفسِّر المرئي لـ Nico Bailon يُقدّم فروق الطرفية كصفحات HTML بدلاً من ASCII، مما يجعل مجموعات التغييرات قابلةً للقراءة الفورية بنظرة واحدة.
متصفح الوكيل لـ Chris Tate يسلك اتجاهاً مختلفاً. يقارن شاشات المتصفح الفعلية pixel بـ pixel لاكتشاف أعطال CSS والتخطيط. مقروناً بـ bisect، يستطيع تحديد الـ commit الذي سبّب الانحدار بدقة.
كنت أفكر في هذا أثناء بناء codexBridge. تتبّع الوكيل الذي كتب أي كود لا يكفي بمجرد سجلات الجلسة. أنت بحاجة إلى هيكل بحث يسهّل الاسترجاع.
خلاصة القول
الجواب على سؤال “من يتحقق من الكود الذي يكتبه الوكلاء؟” ليس البشر. بل هو هيكل تحكم فيه الآلات على الأدلة التي أنتجتها الآلات. هذا هو الجواب.
انضم إلى النشرة الإخبارية
احصل على تحديثات حول أحدث مشاريعي ومقالاتي وتجاربي في الذكاء الاصطناعي وتطوير الويب.