Google Antigravity: كيف تربط القواعد والمهارات وسير العمل لبناء وكلاء ذكاء اصطناعي موثوقين

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

ثلاثة عناصر: rules وskills وworkflows

تدور الفكرة المحورية حول ثلاثة عناصر. تضع rules القيود الأساسية للوكيل: أسلوب كتابة الشيفرة، والممارسات المعتمدة، والأطر التقنية للمشروع. أما skills فهي حزم معرفة قابلة لإعادة الاستخدام لمهمة بعينها، مثل المراجعة أو النشر أو كتابة الاختبارات. وتربط workflows هذه العناصر في تسلسل من الإجراءات يمكن استدعاؤه بأمر slash. وفي وثائق Google تُشبَّه workflows بالأوامر النصية (prompts) المحفوظة، وrules بتعليمات النظام. والغاية من هذا الفصل بين الطبقات ألّا يحمل الوكيل إلى السياق مجموعة التعليمات كلها دفعة واحدة، وألّا يستدعي التعليمات المتخصصة إلا عند الحاجة.

Progressive disclosure وبنية المهارة

وتراهن Google بشكل خاص على progressive disclosure. فالمهارة (skill) لا تبقى في سياق النموذج بصورة دائمة: في البداية لا يرى الوكيل سوى وصف موجز لها، ولا يجلب تعليماتها الكاملة إلا حين تتطابق المهمة فعلًا مع غرضها. وهذا يخفف الحمل الناتج عن الأدوات والقواعد الزائدة، ويقلل زمن الاستجابة، ويساعد على ألّا يتشتت سلوك النموذج. وقد تكون المهارة نفسها أكثر من مجرد ملاحظة نصية، إذ يمكن أن تكون مجلدًا مشروعيًا صغيرًا يضم ملف SKILL.md وسكربتات إضافية ومواد مرجعية وأصولًا (assets). ويمكن حفظ المهارات على المستوى العام لجميع المشاريع، أو محليًا داخل مساحة عمل (workspace) محددة إذا كانت مرتبطة بحزمة التقنيات وعمليات فريق واحد.

سيناريو عملي: فحص QA لشيفرة Python

السيناريو العملي الذي يُشرح لـ Antigravity بسيط وواقعي: فحص QA لشيفرة Python. في مساحة العمل يُنشأ المجلدان .agents/rules و.

agents/skills، ثم تُضاف لـ Python قاعدة تتضمن متطلبات PEP 8 واستخدام black للتنسيق وقيدًا يقتصر على التبعيات المجانية مفتوحة المصدر. ويمكن ربط هذه القاعدة بقناع glob لجميع ملفات .py، فتُطبَّق تلقائيًا على أي شيفرة Python.

وتُنشأ على حدة skill لتوليد الاختبارات: توجد في مجلدها الخاص، وتحتوي على ملف SKILL.md الإلزامي، وتصف كيف ينبغي للوكيل كتابة التغطية للشيفرة التي جرى فحصها. يجعل هذا النهج الإعداد معياريًا: فمعايير المشروع تعيش بمعزل عن الأوامر المؤقتة في المحادثة.

بعد ذلك يُبنى فوق هذه الكتل workflow باسم مثل qa-check. يُكلَّف الوكيل فيه بالتسلسل بفتح ملف Python الحالي، وإيجاد الأخطاء ومخالفات الأسلوب، وتبسيط المواضع غير الفعّالة عند الحاجة، ثم استدعاء skill الاختبارات، وفي النهاية إخراج اختبارات unit الجاهزة مع توصية بتشغيل pytest في الطرفية. وللعرض التوضيحي تُؤخذ دالة قسمة مهملة عن قصد، سيئة التنسيق وبلا معالجة للقسمة على صفر.

وبعد تشغيل workflow لا يكتفي الوكيل بإعادة كتابة الشيفرة بصورة أنظف، بل يقترح مجموعة اختبارات للقيم العادية والسالبة والكسرية، إضافة إلى حالة مستقلة للقسمة على صفر مع خطأ متوقع. وهذه نقطة مهمة: لا يقتصر Antigravity هنا على إعادة هيكلة شكلية، بل يوصل المهمة إلى نتيجة قابلة للتحقق، تُثبت جودتها منطق الاختبارات.

ماذا يغيّر ذلك بالنسبة للفرق

لهذا النهج نتيجتان عمليتان. أولًا، تستطيع الفرق بناء طقوس هندسية قابلة للتكرار داخل IDE دون طبقة أتمتة منفصلة فوق المحرر. ثانيًا، يبدأ وكيل الذكاء الاصطناعي بالعمل لا كمحاور عام، بل كمنفّذ متخصص له نطاق مسؤولية واضح. وبالنسبة للتطوير يعني ذلك تنقلًا يدويًا أقل بين المراجعة والتعديلات والاختبار، وبالنسبة لـ Google خطوة إضافية نحو أن ينافس Antigravity لا مساعدات الشيفرة فحسب، بل بيئات العمل القائمة على الوكلاء بأكملها.

باختصار:

• يجعل Antigravity مساعد الذكاء الاصطناعي وكيلًا هندسيًا قابلًا للإعداد مع QA قابل للتكرار بأمر واحد.
• ثلاثة عناصر: rules (القيود)، وskills (حزم المعرفة)، وworkflows (أمر slash)، إضافة إلى progressive disclosure.
• في سيناريو QA يوصل الوكيل المهمة إلى اختبارات unit قابلة للتحقق، لا إلى إعادة هيكلة الشيفرة فحسب.