مكافحة الجاذبية (Antigravity) هي حلقة تكرارية. يقوم وكيلها بتحرير الملفات، وتشغيل أوامر الطرفية، وقراءة المخرجات، وتحديد الخطوة التالية. فلماذا لا تكون اختبارات واجهة برمجة التطبيقات (API) الخاصة بك ضمن هذه الحلقة؟ إنها موجودة في Apidog خلف واجهة رسومية وتعمل عندما يتذكر أحدهم النقر. الوكيل لا يلمسها أبدًا.
الحل هو كتلة تكوين واحدة. واجهة Apidog CLI هي حزمة npm، apidog-cli، تشغل سيناريوهات الاختبار التي أنشأتها في Apidog مباشرة من الطرفية. بمجرد تثبيت CLI ومعرفة Antigravity بوجودها، يقوم الوكيل بتشغيل سيناريو Apidog بنفس الطريقة التي يشغل بها اختبارات الوحدة الخاصة بك: يشغل الأمر، ويقرأ رمز الخروج، ويصلح الكود إذا كان أحمر.
إذا لم تكن قد قمت بتثبيت CLI بعد، فافعل ذلك أولاً. تشرح مقالة كيفية تثبيت Apidog CLI باستخدام وكيل برمجة ذكاء اصطناعي عملية تثبيت npm، والمصادقة، والتشغيل الأول، مع قيام الوكيل بالطباعة. تفترض هذه المقالة أن apidog --version تطبع رقمًا وأن حسابك في Apidog مصادق عليه.
عن أي Antigravity نتحدث هنا
Antigravity هي منصة التطوير الذاتية لوكلاء جوجل، مبنية على Gemini 3، والتي أطلقت في أواخر عام 2025. إنها تشغل الوكيل من خلال مدير وكلاء يخطط للعمل، ويحرر الملفات عبر مستودعك، وينفذ أوامر الشل في طرفيته الخاصة والمتصفح. الوكيل هو السطح الأساسي، ويعمل مباشرة على جهازك المحلي. إذا كنت قد فتحت Antigravity، وبدأت مهمة، وشاهدت الوكيل ينفذ الأوامر ويقدم التقارير، فأنت في المكان الصحيح. لمزيد من الجولة، راجع ما هو Google Antigravity وكيفية استخدامه.
يعد هذا التمييز مهمًا لأن Antigravity لديها طريقتها الخاصة لتعلم قواعد المشروع، وهذه الآلية تحول "تشغيل اختباراتي" لمرة واحدة إلى شيء يصل إليه الوكيل بمفرده.
الخطوة 1: امنح Antigravity ملف قواعد
يتعرف Antigravity على دليل خاص .agents/ في جذر مساحة العمل الخاصة بك. يوضح الكودلاب الخاص بجوجل حول بناء مسارات تطوير مستقلة في Antigravity كيف يلتقط الوكيل الملفات التي تضعها هناك بشكل طبيعي، وتعيش قواعد مساحة العمل في .agents/rules/. ضع قواعد مشروعك في ملف مثل .agents/rules/apidog.md. يقرأ Antigravity أيضًا ملف AGENTS.md عاديًا في جذر مساحة العمل كأساس مشترك للأدوات، وهو نفس الملف الذي يقرأه Codex لواجهة Apidog CLI؛ إذا كنت تحتفظ بواحد بالفعل، فأضف كتلة Apidog هناك بدلاً من الاحتفاظ بملفين.
ضع كتلة Apidog قصيرة في ملف القواعد هذا. شيء من هذا القبيل:
## API testing with the Apidog CLI
- لاختبار واجهة برمجة التطبيقات، قم بتشغيل سيناريو Apidog، لا تنقر عبر الواجهة الرسومية.
- الأمر: apidog run -t <scenario_id> -e <env_id> -r cli
- رمز الخروج 0 يعني أن جميع التأكيدات قد نجحت. أي رمز غير صفري يعني وجود فشل؛ افتح التقرير وقم بإصلاح الكود.
- الجهاز مصادق عليه بالفعل عبر `apidog login`. لا تقم أبدًا بإضافة علامة --access-token ولا تضع رمزًا مميزًا في هذا الملف.
هذا هو السبب في أنك تكتب CLI في ملف القواعد بدلاً من ذكره في الدردشة. Antigravity لا يتذكر ما تعلمته بين الجلسات؛ أغلق النافذة، أعد فتحها، وسيختفي التدريب. يختفي معرف السيناريو المكتوب في الدردشة عند انتهاء الجلسة. أما المعرف المكتوب في ملف القواعد الخاص بك، فسيبقى متاحًا لكل زميل في الفريق ولكل تشغيل لـ Antigravity من الآن فصاعدًا.
الخطوة 2: احصل على الأمر من Apidog
ليس عليك تخمين معرفات السيناريو والبيئة. افتح سيناريو الاختبار في Apidog، انتقل إلى علامة التبويب CI/CD الخاصة به، وانسخ الأمر الذي تم إنشاؤه. يبدو الأمر كالتالي:
apidog run -t 123456 -e 789012 -r cli
العلامة -t هي معرف سيناريو الاختبار، -e هي معرف البيئة، و -r cli تحدد المراسل الذي يطبع النتائج مباشرة. الصق هذه المعرفات الحقيقية في كتلة .agents/rules/apidog.md الخاصة بك حتى يقوم الوكيل بتشغيل الأمر الدقيق الذي أعطاك إياه Apidog. لكل علامة، راجع مرجع أمر تشغيل apidog.
الخطوة 3: اجعل الوكيل يشغل الاختبار
مع وجود الكتلة في مكانها، ابدأ مهمة في Antigravity. يقوم الوكيل بتحميل قواعدك عند البدء، لذا فهو يعرف بالفعل أن CLI موجودة. قم بإجراء تغيير يؤثر على واجهة برمجة التطبيقات الخاصة بك، أو اطلب منه فقط تشغيل الفحص:
Run the Apidog test scenario and tell me the exit code.
يصدر الوكيل أمر apidog run من ملف القواعد الخاص بك في طرفيته الخاصة. يعتمد تشغيله بدون سؤال على إعدادات الأذونات الخاصة بك. يحدد الإعداد المسبق للأمان في Antigravity ما إذا كانت أوامر الطرفية والوصول إلى الملفات تخضع لمراجعتك قبل أن يتصرف الوكيل، كما هو موضح في كودلاب البدء مع Antigravity من جوجل. إذا طلب الإعداد المسبق المراجعة، وافق على أمر apidog run عندما يُطلب منك ذلك؛ فسيناريو الاختبار للقراءة فقط مقابل بيئة التطوير هو بالضبط النوع الآمن من الأوامر داخل مساحة العمل الذي يمكن الموافقة عليه. إذا كنت قد قمت بتعيين الوكيل للمضي قدمًا بمفرده، فإنه يشغل الأمر ويقدم التقارير دون توقف.
أنت تريد أن ترى التشغيل قيد التنفيذ والوكيل يبلغ عن الملخص ورمز الخروج، وليس إعادة صياغة.
الخطوة 4: اقرأ التقرير داخل Antigravity
عندما يفشل التشغيل، يحتوي التقرير على الإجابة. باستخدام -r cli، يحصل الوكيل على تفصيل قابل للقراءة في طرفيته: كل طلب، وكل تأكيد، وأي واحد فشل مع القيمة المتوقعة مقابل القيمة الفعلية. يذكر التأكيد الفاشل الحقل أو رمز الحالة الدقيق، وهو ما يكفي عادةً للوكيل لإيجاد الحل.
للحصول على تقرير يمكنك فتحه في المتصفح أو تقديمه لزميل في الفريق، أضف مراسل HTML:
apidog run -t 123456 -e 789012 -r cli,html
يكتب مراسل html ملفًا مستقلاً إلى ./apidog-reports. احتفظ بـ cli في القائمة حتى يستمر الوكيل في الحصول على الإخراج المباشر الذي يقرأه لتحديد خطوته التالية. للمجموعة الكاملة من المراسلين، بما في ذلك لوحات تحكم CI بتنسيق JUnit، راجع الدليل الكامل لـ Apidog CLI و كيفية قراءة تقارير اختبار Apidog CLI.
اختبار Antigravity ضمن حلقته الخاصة
النقطة المهمة هي ما يحدث عندما تتوقف عن السؤال ويقوم الوكيل بتشغيل السيناريو بمفرده لأن ملف القواعد أخبره بذلك.
تخيل أن الوكيل يقوم بتحرير معالج يقوم ببناء استجابة الدفع. تتغير حلقته. يقوم بتحرير الكود، ثم بدلاً من إعلان النصر، يشغل سيناريو Apidog الخاص بك مقابل بيئة التطوير، ويقرأ رمز الخروج، ويتصرف بناءً عليه. إذا كان أخضر، يمضي قدمًا. إذا كان أحمر، يفتح التقرير، يقرأ أي تأكيد فشل (رمز الحالة، الحقل المفقود، القيمة الخاطئة)، يحاول إصلاحًا، ويعيد التشغيل. يصبح اختبار واجهة برمجة التطبيقات جزءًا من نفس حلقة التحرير-الاختبار-الإصلاح التي يشغل الوكيل اختبارات الوحدة الخاصة بك من خلالها بالفعل. لقد كتبت تعليمات واحدة وقام الوكيل بدمج الأمر في طريقة عمله بالفعل.
هذا هو نموذج التفويض ثم التحقق الذي يجعل أي سير عمل للوكيل آمنًا. يقوم Antigravity بتشغيل الأمر وقراءة النتيجة؛ أنت تستمر في تأليف السيناريوهات بصريًا في Apidog وتتحقق بشكل فوري من أن الوكيل يقرأ رموز الخروج بصدق. للحصول على النمط الأوسع، راجع كيفية استخدام وكلاء الذكاء الاصطناعي لاختبار واجهة برمجة التطبيقات و أداة اختبار Apidog AI.
تحقق من أن Antigravity تقوم بالفعل بتشغيل CLI
يبلغ الوكلاء عن نجاح لم يكسبوه، و Antigravity ليست استثناءً. ثلاث عمليات تحقق، بترتيب مدى تكرار اكتشافها للمشاكل.
أولاً، تأكد من تشغيل الأمر على الإطلاق. يعرض Antigravity الأوامر التي نفذها ومخرجاتها في طرفيته. ابحث عن السطر الحرفي apidog run ... ونتيجة تحته. إذا قال الوكيل إنه أجرى الاختبارات ولكنك لا ترى الأمر، فقد لخص شيئًا لم يفعله أبدًا. اطلب منه التشغيل مرة أخرى وإظهار الإخراج الخام.
ثانيًا، تأكد من رمز الخروج، وهو الرمز المهم. اسأل مباشرة:
What was the exit code of that apidog run command?
يخرج apidog run بالرمز 0 عندما تنجح جميع التأكيدات، وغير صفري عندما يفشل أي شيء. هذا السلوك الفردي يتيح للوكيل، أو لخط أنابيب، التعامل مع التشغيل كبوابة نظيفة. عندما يقول نص الوكيل "تم اجتياز الاختبارات" ولكن رمز الخروج غير صفري، فإن رمز الخروج هو الصحيح.
ثالثًا، تأكد من استخدامه للسيناريو الحقيقي. إذا فشل التشغيل بعبارة "لم يتم العثور على السيناريو"، فقد يكون الوكيل قد اختلق أو أخطأ في تذكر معرف. أعد التحقق من قيم -t و -e مقابل ملف القواعد الخاص بك والأمر الذي أنشأه Apidog في علامة تبويب CI/CD. المعرفات في ملف القواعد الخاص بك هي الحقيقة.
اختياري: ربط خادم Apidog MCP
تشغيل apidog run من ملف القواعد الخاص بك يغطي معظم ما تحتاجه. للمضي قدمًا، قم بتوصيل خادم MCP.
يدعم Antigravity بروتوكول Model Context Protocol (MCP)، ويتم تكوين خوادم MCP الخاصة به في ملف $HOME/.gemini/config/mcp_config.json، وفقًا لكودلاب البدء من جوجل. يمكنك إضافة خادم كمدخل في كائن mcpServers لهذا الملف مع command و args و env الخاص به، ثم تحديث MCP في إعدادات Antigravity. يقوم خادم Apidog MCP بكشف مواصفات واجهة برمجة التطبيقات الخاصة بك عبر MCP، بحيث يمكن للوكيل قراءة مخططك أثناء كتابته للكود، وليس فقط بعد الانتهاء. يقوم CLI بتشغيل الاختبارات؛ ويقوم MCP بتزويد الوكيل بالمواصفات.
عندما يخطئ Antigravity
تظهر بعض الإخفاقات بشكل متكرر أثناء الإعداد.
إنه يتجاهل ملف القواعد. إذا كان الوكيل يقوم بتشغيل أمر عام أو لا يشغل أي شيء على الإطلاق، فقد لا يتم تحميل القواعد. تأكد من أن الملف مسمى بشكل صحيح ويقع حيث يتوقعه Antigravity لمساحة العمل الخاصة بك، ثم ابدأ مهمة جديدة حتى يعيد قراءة القواعد.
يمرر رمز وصول على أي حال. إذا حاول الوكيل إضافة --access-token، فإنه يخمن من أمثلة عامة. تخبره كتلة القواعد الخاصة بك بالفعل بعدم القيام بذلك، نظرًا لأن الجهاز مصادق عليه عبر apidog login. عزز السطر، ولا تضع رمزًا حقيقيًا أبدًا في ملف القواعد. لمعرفة كيفية عمل المصادقة بالفعل، راجع مصادقة Apidog CLI.
إنه يخترع علامة (flag). يعني خطأ "خيار غير معروف" أن الوكيل خمن علامة لا يمتلكها إصدارك. أخبره بتشغيل apidog run --help ونسخ العلامة الدقيقة من هناك، والتي تكون دائمًا صحيحة للإصدار المثبت لديك.
يُبلغ عن نجاح في تشغيل فاشل. هذا هو الأغلى، والسبب في وجود قاعدة رمز الخروج في ملف القواعد الخاص بك وخطوة التحقق الخاصة بك. عندما يتعارض الملخص ورمز الخروج، يفوز رمز الخروج.
من وكيل يومي إلى حلقة اختبارية
هذا هو الإعداد. قم بتثبيت apidog-cli مرة واحدة باتباع دليل التثبيت، أضف كتلة Apidog قصيرة إلى ملف قواعد Antigravity الخاص بك، وسيعرف الوكيل كيفية تشغيل اختبارات واجهة برمجة التطبيقات الخاصة بك وقراءة النتيجة داخل نفس الحلقة التي يستخدمها بالفعل لتحرير الكود. يتم اكتشاف نقطة نهاية معطلة بينما لا يزال الوكيل يعمل على التغيير، وليس بعد إطلاقه.
يعمل الاختبار خلف واجهة رسومية عندما ينقر عليه إنسان؛ ويتم تشغيل أمر من سطر واحد كلما قرر Antigravity ذلك. تستمر في بناء السيناريوهات بصريًا في Apidog، ويشغل وكيلك هذه السيناريوهات حيث لا تشاهدها. قم بتنزيل Apidog، قم ببناء سيناريو واحد، أسقط أمر apidog run الخاص به في ملف القواعد الخاص بك، وشاهد الوكيل يلتقطه في التغيير التالي. عندما تكون مستعدًا لتشغيل نفس الأمر في مسار عمل بدون وجود الوكيل، يغطي Apidog CLI في GitHub Actions الأسرار، والمراسلين، وتحديد رمز الخروج.