هذه سلسلة من 10 أجزاء تشارك كيف طوّرت Apidog Apidog CLI، وهي أداة سطر أوامر لاختبار واجهات برمجة التطبيقات وإدارة دورة حياة واجهات برمجة التطبيقات. اقرأ بالترتيب أو انتقل إلى أي منشور يثير اهتمامك:
| العنوان | التركيز | |
|---|---|---|
| 1 | بنينا 126 أداة MCP. لكنها ليست الحل الأفضل للوكيل | اكتشاف المشكلة |
| 2 | لماذا طورنا Apidog CLI الجديد تمامًا | تطوير البنية |
| 3 | القاعدة الذهبية: CLI ينتج الحقائق، النموذج يعمل على الحقائق | الفلسفة الأساسية |
| 4 | agentHints: تعليم واجهات سطر الأوامر (CLIs) للتحدث مع الوكلاء |
مخرجات منظمة |
| 5 | المهارة (SKILL): شحن الخبرة التشغيلية ككود | الخبرة التشغيلية |
| 6 | الأرقام لا تكذب: 30% مكالمات أدوات أقل، 25% رموز مميزة أقل | نتائج كمية |
| 7 | من PRD إلى حلقة الاختبار: سير عمل وكيل كامل مع Apidog CLI | برنامج تعليمي عملي |
| 8 | لماذا لا يمكن المساومة على توافق CI/CD لأدوات الوكيل | منظور DevOps |
| 9 | فرع الذكاء الاصطناعي: تغييرات مشروع أكثر أمانًا مع وكلاء الذكاء الاصطناعي | طبقة الأمان |
| 10 | Spec-First كان بالأمس. مرحبًا بك في Skill-First. | الرؤية والمستقبل |
لقد بنينا CLI + SKILL للتعامل مع ما لا يحسّنه MCP: مسارات العمل المعقدة مع بوابات التحقق والتنفيذ المنظم.
MCP يواصل خدمة غرضه
قبل أن نتعمق في CLI + SKILL، دعنا نوضح: Apidog MCP لا يزال متاحًا ويتم صيانته.
يوفر MCP اتصالات أدوات موحدة تتبع البروتوكول – وهذا قيم لـ:
- العمليات البسيطة والمحددة جيدًا
- المستخدمين الذين يفضلون مسارات العمل المستندة إلى MCP
- تكامل النظام البيئي مع العملاء المتوافقين مع MCP
لم نستبدل MCP. لقد بنينا CLI + SKILL لتكميله.
ما اكتشفناه هو أن MCP يتفوق في ربط الأدوات، ولكن بالنسبة لمسارات عمل البحث والتطوير المعقدة – العمليات متعددة الخطوات مع التحقق، والقراءة العكسية، والتحقق – يستفيد الوكلاء من العمليات الهندسية القابلة للتنفيذ. هذا هو المكان الذي يتناسب فيه CLI + SKILL.
فكر في الأمر بهذه الطريقة:
| نوع المهمة | النهج الموصى به |
|---|---|
| استدعاء أداة بسيط (مثل الحصول على نقطة نهاية) | MCP أو CLI—كلاهما يعمل |
| مسار عمل متعدد الخطوات (مثل إنشاء اختبار، التحقق، التشغيل) | CLI + SKILL—تجربة أفضل |
| تكامل CI/CD | CLI—مناسب بشكل طبيعي |
| تكامل نظام MCP البيئي | MCP—معيار البروتوكول |
واجهة سطر الأوامر القديمة: تشغيل الاختبارات في النهاية
لطالما كانت Apidog CLI نقطة الدخول في سطر الأوامر لتشغيل اختبارات واجهة برمجة التطبيقات.
apidog run --project <projectId> --test-scenario <scenarioId> --environment <environmentId>هذا الأساس لا يزال مهمًا. تحتاج الفرق إلى طريقة موثوقة لـ:
- تشغيل اختبارات واجهة برمجة التطبيقات من الطرفية
- توليد التقارير في مسارات CI
- الحفاظ على بوابات الجودة داخل مسارات عمل الأتمتة
لكن واجهة سطر الأوامر القديمة ركزت بشكل أساسي على تنفيذ الاختبارات. وظهرت قرب نهاية مسار العمل:
التصميم → التوثيق → المحاكاة → التصحيح → الاختبار → [CLI يشغل الاختبارات]كانت واجهة سطر الأوامر هي الخطوة الأخيرة – بعد الانتهاء من كل شيء آخر.
المتطلبات الجديدة: الوكلاء يحتاجون المزيد
تطوير واجهات برمجة التطبيقات يتغير.
يشارك وكلاء الذكاء الاصطناعي الآن في:
| المرحلة | نشاط الوكيل |
|---|---|
| تصميم واجهة برمجة التطبيقات | توليد تعريفات نقطة النهاية من PRD |
| توليد الاختبار | إنشاء حالات اختبار من مواصفات واجهة برمجة التطبيقات |
| التصحيح | تحليل الإخفاقات، اقتراح الإصلاحات |
| الترحيل | نقل واجهات برمجة التطبيقات بين المشاريع |
| الصيانة | تحديث الاختبارات عند تغيير واجهات برمجة التطبيقات |
بالنسبة لمسارات العمل هذه، لا يمكن أن تكون واجهة سطر الأوامر مجرد الخطوة الأخيرة التي تشغل الاختبارات الموجودة.
يجب أن توفر للوكلاء أيضًا طريقة مستقرة من أجل:
- قراءة أصول واجهة برمجة التطبيقات (نقاط النهاية، المخططات، البيئات)
- إنشاء أو تحديث أصول الاختبار (حالات الاختبار، سيناريوهات الاختبار)
- التحقق من التغييرات المنظمة قبل الكتابة
- إعادتها إلى المشروع
- التحقق من النتيجة
توسع منهجي، وليس إضافة تدريجية
Apidog CLI الجديد ليس مجرد إضافة بعض الأوامر إلى CLI القديم.
إنه يقدم قدرات Apidog الأساسية بشكل منهجي إلى CLI، مما يجعله طبقة سير عمل للمطورين، والسكريبتات، ووكلاء الذكاء الاصطناعي.
| سؤال CLI القديم | سؤال CLI الجديد |
|---|---|
| "كيف أقوم بتشغيل اختبارات Apidog خارجيًا؟" | "كيف يمكن لوكلاء الذكاء الاصطناعي استخدام Apidog بثبات؟" |
تغيرت الحدود المعمارية وراء ذلك بشكل كبير.
مقارنة سلسلة التنفيذ بين MCP و CLI
دعونا نقارن سلاسل التنفيذ النموذجية لمسارات العمل المعقدة.
مسار MCP (جيد لربط الأدوات)
تهيئة جلسة MCP
↓
تحميل قائمة الأدوات + أوصاف الأدوات
↓
الوكيل يختار الأداة
↓
البحث عن المزيد من الأدوات (listOpenApiEndpoints)
↓
الحصول على المخطط (getOpenApiDetails)
↓
تنفيذ مكالمة HTTP (executeOpenApi)قوة MCP: بروتوكول موحد لربط الأدوات بالوكلاء.
موضع التعقيد: يكمن معظم التعقيد في سياق النموذج ومرحلة اختيار الأداة. يحتاج الوكيل إلى فهم:
- قوائم الأدوات
- أوصاف الأدوات
- مخططات الإدخال
- تتابعات المكالمات
- هياكل الإرجاع
متى يعمل بشكل جيد: العمليات البسيطة ذات التعيين الواضح للأداة إلى المهمة.
متى يصبح تحديًا: مسارات العمل المعقدة حيث يجب على الوكيل تنسيق أدوات متعددة، وفهم دلالات المنتج، والتعامل مع التحقق.
مسار CLI + SKILL (أفضل لمسارات العمل المعقدة)
SKILL يحكم نوع المهمة
↓
CLI ينفذ أوامر ذات دلالة للمنتج
↓
cli-schema يتحقق من البنية
↓
agentHints يعطي اقتراحات للخطوة التالية
↓
حلقة التحقق (الحصول على قراءة عكسية أو apidog run)قوة CLI + SKILL: توزيع التعقيد في النظام الهندسي.
موضع التعقيد:
- SKILL: المنهجية وإرشادات سير العمل
- CLI: التنفيذ ذو الدلالة للمنتج
- cli-schema: التحقق قبل الكتابة
- agentHints: التنقل بعد التنفيذ
متى يعمل بشكل جيد: مسارات العمل متعددة الخطوات، العمليات الثقيلة بالتحقق، الاختبار المعتمد على الوكيل.
الاختلاف الرئيسي: أين يكمن التعقيد
الفرق بين هذين النهجين هو أين يوضع التعقيد.
| النهج | أين يكمن التعقيد | الأفضل لـ |
|---|---|---|
| MCP | سياق النموذج + مرحلة اختيار الأداة | استدعاءات الأدوات البسيطة، نظام MCP البيئي |
| CLI + SKILL | النظام الهندسي (SKILL، CLI، التحقق، التلميحات) | مسارات العمل المعقدة، العمليات متعددة الخطوات |
في MCP، يجب على النموذج أن يحمل:
- أي أداة تستخدم
- ماذا يقول وصف الأداة
- ما هي الحقول المطلوبة
- ما هو التسلسل الذي يجب اتباعه
- ماذا تعني بنية الإرجاع
يعمل هذا عندما يكون التعيين من المهمة إلى الأداة مباشرًا.
في CLI + SKILL، يحمل النظام الهندسي:
- ما هو نوع هذه المهمة (SKILL)
- ما هو الأمر الذي يجب تنفيذه (CLI)
- ما هي البنية الصالحة (cli-schema)
- ماذا يجب فعله بعد ذلك (agentHints)
يعمل هذا بشكل أفضل عندما تحتوي مسارات العمل على بوابات تحقق، ومتطلبات قراءة عكسية، وحلقات تحقق.
مثال على سير عمل نموذجي
فيما يلي مثال ملموس لسير عمل CLI + SKILL:
# الخطوة 1: قراءة الحقائق
apidog endpoint get <endpointId> --project <projectId>
# الخطوة 2: التحقق قبل الكتابة
apidog cli-schema validate test-case-create --file ./test-case-create.json
# الخطوة 3: تنفيذ التحقق
apidog run --project <projectId> --out-dir ./apidog-reportsتمثل هذه الأوامر الثلاثة ثلاثة إجراءات هندسية:
| الأمر | الإجراء |
|---|---|
endpoint get |
قراءة الحقائق من المشروع |
cli-schema validate |
التحقق من البنية قبل الكتابة |
apidog run |
تنفيذ التحقق |
مسار الوكيل لمسارات العمل المعقدة
بالنسبة لمسارات العمل المعقدة ومتعددة الخطوات، يستفيد مسار الوكيل من بنية CLI + SKILL.
مسار MCP لمسارات العمل المعقدة
"اختر الأدوات ← افهم المخططات ← نسق التسلسل ← تعامل مع الأخطاء"يقوم الوكيل بـ:
- اختيار الأدوات المناسبة من بين العديد من الخيارات
- فهم أوصاف الأدوات ومخططاتها
- تنسيق التسلسل الصحيح
- التعامل مع الأخطاء من خلال إعادة المحاولة
يمكن أن يعمل هذا، ولكنه يتطلب قدرًا كبيرًا من التفكير النموذجي لكل نقطة قرار.
مسار CLI + SKILL لمسارات العمل المعقدة
"اقرأ الحقائق ← توليد التغييرات ← تحقق من البنية ← اكتب ← تشغيل التحقق"يقوم الوكيل بـ:
- قراءة الحقائق الموجودة أولاً (بتوجيه من SKILL)
- توليد التغييرات بناءً على الحقائق
- التحقق من البنية محليًا (cli-schema)
- الكتابة إلى المشروع
- تشغيل التحقق (agentHints يوجه الخطوة التالية)
يتعامل النظام الهندسي مع التحقق، والتوجيه، والتأكيد – مما يقلل من عبء التفكير النموذجي.
يمكن لكلا المسارين إكمال المهمة. CLI + SKILL يقلل التعقيد في مرحلة سياق النموذج.
ما تغطيه واجهة سطر الأوامر الآن
مع الترقية، تغطي واجهة سطر الأوامر الآن المزيد من موارد Apidog الأساسية:
| المورد | قدرة CLI |
|---|---|
| المشاريع والبيانات الوصفية | القائمة، القراءة |
| واجهات برمجة التطبيقات وتعريفات واجهات برمجة التطبيقات | الحصول، الإنشاء، التحديث |
| البيئات والمتغيرات | القائمة، الإدارة |
| حالات الاختبار | الإنشاء، التحديث، التحقق |
| سيناريوهات الاختبار | الإنشاء، التحديث، استيراد الخطوات، الحصول بالتفصيل |
| مجموعات الاختبار | الإدارة |
| التقارير | التوليد من apidog run |
| الاستيراد/التصدير | تصدير المشروع، استيراد الملفات |
هذا يغير دور Apidog CLI.
لم تعد مجرد وسيلة لتنفيذ الاختبارات بعد الانتهاء من كل شيء آخر.
يمكنها الآن المشاركة مبكرًا في حلقة التطوير – حيث يحتاج الوكيل إلى:
- فهم المشروع
- توليد أو تحديث أصول الاختبار
- التحقق من التغييرات
- تشغيل التحقق
ملخص البنية
| البعد | MCP | CLI + SKILL |
|---|---|---|
| القوة الأساسية | ربط الأدوات | تنفيذ سير العمل |
| موقع التعقيد | سياق النموذج | النظام الهندسي |
| مسار الوكيل للمهام المعقدة | اختيار، تنسيق، إعادة المحاولة | قراءة، تحقق، كتابة، تأكيد |
| التغطية | 126 أداة تم إنشاؤها + أدوات أصلية | إدارة الموارد الكاملة + التحقق |
| أفضل ملاءمة | عمليات بسيطة، نظام MCP البيئي | مسارات عمل معقدة، CI/CD |
كلاهما متاح. اختر بناءً على مهمتك.
ماذا بعد؟
الآن بعد أن أوضحنا كيف يكمل CLI + SKILL نظام MCP، السؤال التالي هو:
ما هو المبدأ الأساسي الذي يجعل CLI + SKILL فعالًا لمسارات العمل المعقدة؟
في الجزء الثالث، القاعدة الذهبية: CLI ينتج الحقائق، النموذج يعمل على الحقائق، سنستكشف فلسفة التصميم التي توجه كل قرار في CLI + SKILL – بدءًا من cli-schema validate، وهي بوابة الجودة التي تكتشف الأخطاء قبل أن تصبح كتابات فاشلة.
النقاط الرئيسية
- يستمر MCP في العمل – استخدمه للعمليات البسيطة وتكامل نظام MCP البيئي
- يكمل CLI + SKILL نظام MCP – وهو أفضل لمسارات العمل المعقدة مع التحقق
- الفرق الرئيسي هو أين يكمن التعقيد: سياق النموذج مقابل النظام الهندسي
- يقلل CLI + SKILL من عبء التفكير النموذجي من خلال التحقق، التوجيه، التأكيد
- يغطي CLI الآن المشاريع، واجهات برمجة التطبيقات، البيئات، حالات الاختبار، السيناريوهات، والمزيد
- كلا النهجين متاحان – اختر بناءً على تعقيد المهمة
قم بتنزيل Apidog من أجل تصميم، محاكاة، اختبار، و توثيق واجهات برمجة التطبيقات في مساحة عمل واحدة. تعرف على المزيد حول Apidog CLI لاختبار واجهات برمجة التطبيقات عبر سطر الأوامر، وأتمتة CI، وسير عمل وكلاء الذكاء الاصطناعي.