xAI تطلق /goal في Grok Build: وكيل مستقل يخطط للمهام متعددة الخطوات ويتحقق من نتائجها

أطلقت xAI في Grok Build وضع /goal، وهو أداة لتنفيذ المهام الطويلة متعددة الخطوات بصورة مستقلة: تضع الخطة بنفسها، وتتقدم وفق قائمة مهام، وتتحقق من النتيجة حتى الاكتمال التام.

كيف يعمل /goal

يختلف مبدأ العمل عن الحوار المعتاد مع LLM. تصوغ هدفًا واحدًا، مثل «نفّذ المصادقة عبر OAuth» أو «اكتب محلل JSON واختبره» أو «انقل المكوّن من class إلى hooks»، ثم تسلّمه للوكيل. بعد ذلك يتولى /goal زمام الأمور.

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

في النمط المعتاد، يدير المطوّر حوارًا مع LLM: يكتب الأمر (prompt)، ويتلقى الإجابة، ثم يصحح ويوضح ويطلب من جديد. أما في /goal فأنت تفوّض الوكيل لا تنفيذ المهمة وحدها، بل إدارة العملية بأكملها. وهذا مستوى مختلف جذريًا من الاستقلالية.

تحقق مدمج من النتيجة

الميزة الأساسية في هذا الوضع هي الفحص المدمج في كل خطوة. لا ينفذ /goal الخطوات آليًا واحدة تلو الأخرى؛ فبعد كل مرحلة يقيّم الوكيل ما إذا كانت النتيجة الوسيطة تطابق التوقعات، ثم يتقدم بعد ذلك فقط. وهذا أمر بالغ الأهمية لمهام البرمجة (coding) متعددة الخطوات:

• كتابة الكود هي الخطوة 1، وليست النهاية
• تشغيل الاختبارات والتأكد من نجاحها هو الخطوة 2
• التحقق من أن الكود الجديد لم يُفسد السلوك القائم هو الخطوة 3
• التأكد من تحقق الهدف بالكامل هو التحقق النهائي

وغياب التحقق تحديدًا هو من أكثر الانتقادات شيوعًا لوكلاء البرمجة (coding) الحاليين. فالأداة «تنفذ» المهمة من الناحية التقنية، لكن النتيجة لا تطابق المطلوب. أما الأخطاء «الصامتة»، حين يمضي الوكيل بثقة في مسار خاطئ، فهي من أصعب السيناريوهات في الأنظمة المستقلة. ويحاول /goal معالجتها.

/goal في سياق السوق

تضع xAI منصة Grok Build كبيئة تطوير متكاملة يشارك فيها Grok في دورة إنشاء الكود، بدل الاكتفاء بالإجابة عن الأسئلة. ويمثل /goal الخطوة التالية في هذه الاستراتيجية.

«تمنح الوكيل هدفًا واحدًا، فيخطط للنهج، ويمر على قائمة المهام، ويتحقق

من النتيجة حتى الاكتمال»، هكذا يصف فريق xAI هذا الوضع.

يزداد سوق الوكلاء الموجهة للمطورين ازدحامًا. تقدم GitHub Copilot Workspace جلسات تخطيط متعددة الخطوات مباشرة داخل المستودع. ويُطرح Devin من Cognition بوصفه وكيل مطوّر مستقلًا بالكامل. وتدمج JetBrains وCursor وبيئات تطوير أخرى (IDE) قدرات الوكلاء. وتطوّر Google وAnthropic أوضاعًا وكيلية في منصاتهما. وفي هذا المشهد يبدو /goal ردًا منطقيًا من xAI: وضع مستقل في المكان الذي يعمل فيه المستخدمون بالفعل مع الكود.

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

ماذا يعني ذلك

حين تخطط الأداة وتنفذ وتتحقق بنفسها، ينتقل المطوّر إلى دور تحديد المهام بدلًا من الإدارة التفصيلية لكل خطوة. وبالنسبة لمشاريع البرمجة (coding) الطويلة، يغيّر هذا سيناريو العمل بأكمله.

لم يعد السؤال: هل نحتاج إلى وكلاء مستقلين؟ فهم موجودون بالفعل. السؤال هو: ما مدى موثوقيتهم في التحقق حين تكون المهمة معقدة فعلًا؟