وكيل n8n يكتب حالات الاختبار: يأخذ حالة الاستخدام من «Pachka» والمتطلبات من «ياندكس ويكي»

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

ماذا نبني وعلى أي أساس

n8n أداة لبناء الوكلاء تربط النماذج بالشيفرة وأنظمة تتبع المهام وCI وبقية البنية التحتية. كل إجراء عقدة مستقلة، وتُركَّب العقد في سير عمل كما تُركَّب قطع الليغو. ويمكن تصدير سير العمل بصيغة JSON. الشيفرة المصدرية مفتوحة: في سحابة n8n تدفع ثمن الاستضافة وكل عملية تشغيل، أما على بنيتك التحتية فالأمر مجاني. التكاملات تزيد على 2600، ولذلك يمكن بناء وكيل يناسب معظم البيئات التقنية. مثلًا: توليد حالات اختبار من تذاكر Jira والوثائق في GitHub مع البحث عبر Pinecone.

السيناريو في المقال أبسط. المتطلب موجود في «ياندكس ويكي»، وحالة الاستخدام في دردشة «Pachka». المنطق من أربع خطوات:

• ينتظر الوكيل حالة الاستخدام من المستخدم في الدردشة؛
• يطلب عبر نموذج (فورم) عنوان URL لصفحة المتطلب، كتعليق على الرسالة؛
• يمرّر إلى النموذج حالة الاستخدام والمتطلب؛
• يعيد الرد إلى خيط حالة الاستخدام.

كيف نربط «Pachka» و«ويكي»

من جهة «Pachka» يجب إنشاء بوت وتفعيل webhook صادر له. يذكر المؤلف ثلاثة خيارات: تجاهل رسائله الخاصة (كي لا يستفز البوت نفسه)، والاستماع إلى أي رسائل، والاستجابة للنقر على الأزرار. يعرض النظام الرمز مرة واحدة فقط، لذا يجب حفظه فورًا. الصلاحيات: messages:read وmessages:create وthreads:read وthreads:create وviews:write، والأخيرة لازمة كي يمرّر المستخدم عنوان URL للمتطلب عبر النموذج. يُلصق عنوان webhook ومفتاح التوقيع في مشغّل n8n.

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

مع «ياندكس ويكي» الأمر أصعب: لا توجد عقدة جاهزة، لكن خادم MCP يعمل. يلزم تطبيق OAuth بصلاحية wiki:read، ورمز يُحصل عليه عبر رابط التفويض مع ClientID الخاص بك، ومعرّف المؤسسة. وهو X-Org-ID لـ«ياندكس 360 للأعمال»، وX-Cloud-Org-ID لـ Yandex Cloud Organization. في Credentials داخل n8n يُنشأ سجل من نوع Multiple Headers Auth بترويستين: Authorization وترويسة المؤسسة.

بعد ذلك خياران. العقدة المربعة MCP Client تستدعي الأداة مباشرة. أما العقدة الدائرية MCP Client Tool فتُوصَل بعقدة النموذج، ويقرر النموذج نفسه ما يطلبه. اختار المؤلف الاستدعاء المباشر: HTTP Streamable، ونقطة النهاية mcp.wiki.yandex.net، والأداة GetPageById. العقبة في معرّف الصفحة: لا يمكن الحصول عليه إلا عبر API «ويكي» بطلب بحسب الـ slug، مثلًا بأمر curl مع الرمز وترويسة المؤسسة.

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

تنتقل البيانات بين العقد بصيغة JSON، ويُوصَل إلى مخرجات العقدة السابقة عبر $json.اسم_المتغير. وأسهل طريقة لمعرفة أسماء المتغيرات هي النظر في تبويب Executions بعد أي تشغيل، حتى الفاشل. النتيجة: يتلقى البوت حالة الاستخدام، ويسأل عن رابط المتطلب، ثم يعيد حالة الاختبار إلى الخيط. نشر المؤلف سير العمل الجاهز على GitHub بصيغة JSON.

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

ماذا نفعل عمليًا. إذا كان لدى الفريق «Pachka» و«ويكي» فيمكن تكرار سير العمل في أمسية واحدة. في أول تجربة يكفي الاستدعاء المباشر لـ MCP: فهو أكثر قابلية للتنبؤ من ترك اختيار الأداة للنموذج (هذا رأي منا، ولا توجد مثل هذه المقارنة في المقال). احتفظ ببيانات الاعتماد في Credentials لا في العقد نفسها. افحص النتيجة على 5–10 حالات استخدام حقيقية وقارنها بما كان سيكتبه مختبِر. وبعد ذلك فقط قرّر ما إذا كان هذا الوكيل ضروريًا في العملية.