لديك بالفعل وكيل برمجة يعمل بالذكاء الاصطناعي مفتوح. يقوم بتعديل ملفاتك، وتشغيل اختباراتك، وقراءة مخرجات الطرفية. فلماذا أنت على وشك تثبيت أداة سطر أوامر يدويًا، ونسخ أوامر npm من علامة تبويب ولصقها واحدة تلو الأخرى؟
لا داعي لذلك. Apidog CLI هو حزمة npm تسمى apidog-cli تقوم بتشغيل سيناريوهات اختبار API التي قمت بإنشائها في Apidog، مباشرة من الطرفية. تثبيتها عبارة عن تسلسل قصير من أوامر shell، وخطوة مصادقة، وتشغيل أول. هذا بالضبط نوع العمل الميكانيكي الذي يتقنه وكيل مثل Claude Code، Cursor، Windsurf، أو GitHub Copilot في وضع الوكيل. أنت تصف الهدف، ويقوم الوكيل بتشغيل الأوامر الفعلية، وأنت تتحقق من عمله.
يوضح هذا الدليل سير العمل هذا من البداية إلى النهاية. سترى المطالبات الدقيقة التي ستقدمها لوكيلك، والأوامر التي سيقوم بتشغيلها، وكيفية التحقق من كل خطوة بدلاً من أخذ كلام الوكيل على محمل الجد. المكافأة في النهاية هي الجزء الذي يستحق الإعداد: بمجرد تثبيت CLI ومصادقته، يمكن لوكيلك تشغيل اختبارات Apidog الخاصة بك بنفسه، داخل حلقته الخاصة أو في CI، وقراءة نتيجة النجاح أو الفشل. للمتابعة، تحتاج إلى حساب Apidog مع مشروع واحد على الأقل. قم بتنزيل Apidog أولاً إذا لم يكن لديك واحد بعد.
لماذا تسمح لوكيل بالقيام بالتثبيت
لا يتغير أي شيء في أوامر التثبيت عندما يقوم وكيل بتشغيلها. إنه نفس الأمر npm install -g apidog-cli@latest الذي كنت ستكتبه بنفسك. ما يتغير هو من يكتبه ومن يقرأ المخرجات.
الوكيل جيد في هذا لثلاثة أسباب ملموسة. يمكنه تشغيل أمر، وقراءة حالة الخروج والنص المطبوع، وتحديد الخطوة التالية مما رآه بالفعل، لذا فإن "الأمر غير موجود" لا يعيق العملية كما يحدث في حلقة النسخ واللصق. لديه بالفعل shell الخاص بك، وإصدار Node الخاص بك، و PATH الخاص بك أمامه، لذا فهو يكيف الإصلاح مع جهازك بدلاً من إصلاح عام. ويقوم بالأجزاء المملة، والتحقق من Node أولاً، والتحقق من الإصدار بعد التثبيت، وتأكيد المصادقة، دون أن تشرف أنت على كل سطر.
ما تحتاجه قبل أن تبدأ
يتم شحن CLI كحزمة npm، لذا فإن الاعتماد الوحيد على النظام هو بيئة تشغيل Node.js. ثلاثة أمور يجب أن تكون صحيحة:
- Node.js و npm مثبتان. يتم تثبيت الحزمة عبر npm وتعمل على Node. إصدار LTS الحالي هو الخيار الآمن على أي جهاز مطور.
- حساب Apidog مع صلاحية الوصول إلى المشروع. لا يقوم CLI بتخزين الاختبارات الخاصة به. يصل إلى مشروع Apidog الخاص بك ويشغل السيناريوهات الموجودة هناك، لذا فأنت بحاجة إلى حساب يمكنه رؤية مشروع واحد على الأقل.
- سيناريو اختبار للتشغيل. يقوم المشغل بتنفيذ السيناريوهات، وليس الطلبات الفردية. أنشئ واحدًا في تطبيق Apidog أولاً: اربط بضعة طلبات، وأضف تأكيدات، ثم احفظه. إذا كنت جديدًا في كتابة التحققات ضد الاستجابات، فإن تأكيدات API: دليل عملي يشرح ذلك بالتفصيل.
تحتاج أيضًا إلى وكيل برمجة بالذكاء الاصطناعي لديه إذن لتشغيل أوامر shell. Claude Code، ووكيل Cursor، و Cascade من Windsurf، ووضع الوكيل في GitHub Copilot جميعهم مؤهلون. الشيء الوحيد الذي يجب تأكيده قبل البدء هو أن وكيلك مسموح له بتنفيذ الأوامر في الطرفية الخاصة بك، وليس فقط اقتراحها. إذا كان بإمكانه فقط طباعة الأوامر لتلصقها، فلا يزال بإمكانك متابعة هذا الدليل، وستكون أنت من يضغط على Enter.
الخطوة 1: اجعل الوكيل يتحقق من البيئة
ابدأ بالسماح للوكيل بتأكيد وجود Node، حتى يعرف ما إذا كان يمكنه التثبيت على الإطلاق. المطالبة التالية تعمل:
تحقق مما إذا كان Node.js و npm مثبتين على هذا الجهاز. قم بتشغيلnode -vوnpm -vوأخبرني بالإصدارات. إذا كان أحدهما مفقودًا، أخبرني، ولا تحاول تثبيت Node بنفسك.
سيقوم الوكيل بتشغيل:
node -v
npm -v

يجب أن يبلغك برقمين إصدار. التحقق الخاص بك: اقرأ الإصدارات التي يطبعها. إذا ادعى أن Node مثبت ولكنه لا يعرض لك سلسلة إصدار، اطلب منه لصق مخرجات الأمر الخام. سبب عبارة "لا تثبت Node بنفسك" في المطالبة هو أن تثبيت بيئة تشغيل هو قرار أكبر خاص بالجهاز وتريد اتخاذه عمدًا، وليس شيئًا لتسليمه بشكل أعمى. إذا كان Node مفقودًا، قم بتثبيته من nodejs.org بنفسك، ثم تابع.
الخطوة 2: اجعل الوكيل يقوم بتثبيت CLI
بمجرد تأكيد Node، سلم أمر التثبيت:
اقرأ https://apidog.com/apidog-cli-installation-guide.md واتبع التعليمات.
سيقوم الوكيل بتشغيل أمر التثبيت.
تضع علامة -g الثنائي apidog على PATH العام الخاص بك بدلاً من وضعه في node_modules الخاص بمشروع واحد. تسحب علامة @latest أحدث إصدار منشور، وهو ما تريده للتثبيت الأول. عندما ينتهي npm، يتم تسمية الثنائي apidog، لذا يبدأ كل أمر من هنا بـ apidog.

ثم سيتحقق:
apidog --version
apidog --help

التحقق الخاص بك: هذا هو أهم تحقق في العملية برمتها، لأنه أسهل مكان يمكن للوكيل أن يدعي فيه نجاحًا لم يحققه. تأكد من أن apidog --version طبع رقم إصدار فعلي، وليس "أمر غير موجود" تجاهله الوكيل. يجب أن يدرج مخرجات --help الأمر apidog run وخياراته. إذا كنت تريد سطرًا واحدًا يمكنك تشغيله بنفسك لتأكيد أن الثنائي وبيئة التشغيل خلفه كلاهما يعملان، اطلب من الوكيل تشغيل هذا ولصق النتيجة:
node -v && apidog --version && which node && which apidog
إذا أعاد كل سطر إصدارًا أو مسارًا، فإن التثبيت نظيف. إذا أبلغ الوكيل عن مشكلة، فإن السبب الأكثر شيوعًا هو أن الدليل الثنائي العام ليس على PATH الخاص بك؛ يغطي قسم استكشاف الأخطاء وإصلاحها بالقرب من النهاية ذلك.
إذا كنت تفضل ألا يقوم الوكيل بتعديل حزمك العامة، فأخبره باستخدام npx بدلاً من ذلك. يجلب npx apidog-cli --version الحزمة، ويقوم بتشغيلها، ولا يترك شيئًا خلفه على PATH الخاص بك، وهو ما يناسب جهازًا مشتركًا أو عامل CI مؤقت. للجهاز الذي تستخدمه كل يوم، التثبيت العام أبسط وأسرع عند تكرار الاستدعاءات.
الخطوة 3: اجعل الوكيل يصادق، لكنك تتعامل مع الرمز المميز
يقوم CLI بتشغيل السيناريوهات من حسابك، لذلك يجب أن يثبت أنه مسموح له بذلك. يفعل ذلك باستخدام رمز وصول. هذه هي الخطوة الوحيدة التي لا تفوضها بالكامل، لأن الرمز المميز سري ولا تريد لصقه في سجل دردشة، أو ملف سجل، أو أي مكان قد يعكسه الوكيل.
أنشئ الرمز المميز بنفسك أولاً. افتح تطبيق Apidog أو وحدة التحكم على الويب، انقر فوق صورة المستخدم الخاصة بك، انتقل إلى إعدادات الحساب، ثم رمز الوصول إلى API، وقم بإنشاء رمز جديد. انسخه إلى مكان آمن وتعامل معه ككلمة مرور، لأن أي شخص يمتلكه يمكنه تشغيل السيناريوهات بصفتك.
ثم وجه الوكيل دون وضع الرمز المميز في المطالبة مطلقًا:
سأصادق Apidog CLI بنفسي حتى يظل الرمز المميز خارج هذه الدردشة. أخبرني بالضبط بأمرapidog loginللتشغيل، ثم بعد أن أؤكد أنني قمت بتشغيله، قم بتشغيلapidog whoamiللتحقق من أن CLI مصادق وأظهر لي النتيجة.
تقوم بتشغيل أمر تسجيل الدخول في الطرفية الخاصة بك:
apidog login --with-token YOUR_ACCESS_TOKEN
دع الوكيل يقوم بالتحقق:
apidog whoami
التحقق الخاص بك: يجب أن يطبع apidog whoami حسابك. إذا فعل ذلك، فقد تم تعيين المصادقة. سبب الاحتفاظ بالرمز المميز في يديك هو النظافة التشغيلية البسيطة: الرمز المميز الذي يصل إلى نافذة سياق الوكيل يمكن أن ينتهي به المطاف في السجلات أو نص محفوظ. يخزنه أمر تسجيل الدخول محليًا على جهازك، لذلك لا يحتاج الوكيل أبدًا إلى رؤية السلسلة الخام لتشغيل الاختبارات بعد ذلك. بالنسبة لـ CI، القاعدة هي نفسها ولكن أكثر صرامة، والتي يغطيها القسم الأخير.
الخطوة 4: اجعل الوكيل يقوم بأول تشغيل اختباري
الآن انتقل من "مثبت" إلى "تم تشغيله بالفعل". الأمر الأساسي هو apidog run، الموجه إلى سيناريو بواسطة معرفه.
أنظف طريقة للحصول على أمر صحيح هي السماح لـ Apidog ببنائه لك. افتح سيناريو الاختبار في Apidog، وانتقل إلى علامة التبويب CI/CD الخاصة به، واختر خيار سطر الأوامر، وينشئ Apidog أمر apidog run الكامل بمعرف السيناريو، ومعرف البيئة، ورمز وصول مملوء مسبقًا. انسخ ذلك، ولديك نقطة بداية مضمونة الصلاحية. يبدو هكذا:
apidog run --access-token YOUR_ACCESS_TOKEN -t 605067 -e 1629989 -n 1 -r cli
إليك ما يفعله كل جزء. --access-token يصادق التشغيل. -t يسمي سيناريو الاختبار بواسطة المعرف (605067 هو عنصر نائب؛ سيكون معرفك مختلفًا). -e يختار البيئة التي سيتم التشغيل ضدها، مثل dev أو staging. -n 1 يشغل السيناريو مرة واحدة. -r cli يكتب تقريرًا قابلاً للقراءة إلى الطرفية الخاصة بك.
نظرًا لأنك قمت بتسجيل الدخول بالفعل، يمكنك تسليم المعرفات للوكيل بدون الرمز المميز والسماح له بالتشغيل:
قم بتشغيل سيناريو اختبار Apidog الخاص بي باستخدام CLI. لقد تم مصادقتي بالفعل، لذلك لا تمرر رمز وصول. استخدم: apidog run -t 605067 -e 1629989 -n 1 -r cli. أظهر لي المخرجات الكاملة وأخبرني برمز الخروج.سيقوم الوكيل بتشغيل السيناريو والإبلاغ عن التنفيذ خطوة بخطوة وملخص. التحقق الخاص بك: اطلب رمز الخروج صراحة، لأنه الإشارة التي يعتمد عليها كل شيء لاحقًا. يخرج apidog run بـ 0 عندما تمر جميع التأكيدات ورمز غير صفري عندما يفشل شيء ما. هذا السلوك الوحيد هو ما يسمح لخط أنابيب، أو وكيل، بمعاملة التشغيل كبوابة نجاح أو فشل نظيفة بدون توصيلات إضافية. إذا قال الوكيل "الاختبارات مرت" ولكن رمز الخروج كان غير صفري، فهو مخطئ، ثق بالرمز، وليس بالنص.
هل تريد تنسيق تقرير مختلف أو المزيد من التكرارات؟ اجعل الوكيل يشغل apidog run --help، والذي يطبع كل علامة يدعمها المشغل، بما في ذلك التقارير الأخرى وخيارات التكرار المعتمدة على البيانات. للرجوع إلى العلامة الكاملة وأمثلة CI، يغطي دليل Apidog CLI الكامل كل واحدة منها.
المكافأة: الآن يمكن للوكيل الاختبار بمفرده
لهذا السبب كان الإعداد يستحق العناء. مع تثبيت ومصادقة CLI، أصبح تشغيل اختبار Apidog الآن أمرًا واحدًا في سطر الأوامر يمكن لوكيلك إصداره في أي وقت، وقراءة نتيجته. هذا يدمج اختبار API في حلقة الوكيل العادية.
تخيل أن الوكيل يغير معالجًا يؤثر على نقطة نهاية. بدلاً من تعديل الكود وإعلان النصر، يمكنه تشغيل سيناريو Apidog الخاص بك مقابل البيئة المتأثرة، وقراءة رمز الخروج، والتصرف بناءً عليه: إذا كان أخضر، ينتقل؛ إذا كان أحمر، يقرأ التأكيد الفاشل في التقرير ويحاول إصلاحًا. يصبح الاختبار جزءًا من حلقة التغذية الراجعة للوكيل، بنفس الطريقة التي يشغل بها بالفعل اختبارات الوحدة الخاصة بك. للحصول على نظرة أوسع على هذا النمط، يغطي كيفية استخدام وكلاء الذكاء الاصطناعي لاختبار API أين يتناسب وأين لا يتناسب.
ينتقل هذا مباشرة إلى CI، حيث لا يكون الوكيل موجودًا. بمجرد أن تشاهد الأمر يعمل محليًا، يمكنك أن تجعل الوكيل يكتب خطوة مسار التنفيذ التي تشغله في كل عملية دفع. آليات ذلك، والأسرار، والمبلغون، وبوابة رمز الخروج، موجودة في Apidog CLI في GitHub Actions.
إذا كنت تريد أن يكون تكامل الوكيل أعمق من تشغيل أوامر shell، فإن ميزتين من Apidog تربط الوكلاء بمواصفات و escenarios API الخاصة بك بشكل مباشر أكثر. يعرض خادم Apidog MCP مواصفات API الخاصة بك لأدوات برمجة الذكاء الاصطناعي عبر بروتوكول سياق النموذج، حتى يتمكن الوكيل من قراءة مخططك أثناء البرمجة. ويقوم Apidog CLI مع مهارات Claude بتجميع سير عمل CLI في مهارة قابلة لإعادة الاستخدام، بحيث تصبح خطوة تشغيل الاختبار شيئًا يصل إليه Claude بنفسه. يبني كلاهما على نفس apidog-cli المثبت الذي قمت بإعداده للتو.
من التثبيت الموكل إلى حلقة تم اختبارها
هذا هو المسار بأكمله. أنت تؤكد Node، يقوم الوكيل بتثبيت apidog-cli بأمر npm واحد، تتحقق باستخدام apidog --version، تصادق باستخدام رمز مميز تحتفظ به في يديك، ويقوم الوكيل بتشغيل أول apidog run بينما تتحقق من رمز الخروج. بضع دقائق من التفويض ثم التحقق، ويمكن لوكيلك الآن تشغيل اختبارات API الخاصة بك بنفسه.
السبب في أهمية هذا هو نفس السبب الذي يجعل أي بوابة اختبار مهمة، مع إضافة واحدة. الاختبارات المحاصرة خلف واجهة المستخدم الرسومية لا تعمل إلا عندما ينقر عليها إنسان. أمر من سطر واحد يعمل في كل عملية دفع. وبمجرد أن يصبح هذا الأمر في متناول وكيل البرمجة الخاص بك، فإنه يعمل داخل حلقة تحرير-اختبار-إصلاح الخاصة بالوكيل، على التغييرات التي لم تراجعها بعد. تستمر في تأليف السيناريوهات بصريًا في Apidog، ويقوم كل من مسار التنفيذ الخاص بك ووكيلك بتشغيلها حيث لا يراقبها أي إنسان.
من هنا، وجه نفس الأمر إلى CI في Apidog CLI في GitHub Actions، أو اقرأ المرجع الكامل للأعلام في دليل Apidog CLI الكامل.
