ساعدني في بناء سير عملي: عقدة Agent مع Gemini + أداة Perplexity + أداة HTTP تتعطل قبل محلل الإخراج. الخطأ يتناوب بين a.ok(nodeExists وout-of-memory

[Camila_Andrea]

مرحبا، أنا جديد في n8n. بدأت بإنشاء سير عمل لتطبيق copilot على بعض الوظائف التي تتطابق مع ملفي الشخصي، لكنني لا أستطيع جعل سير العمل يعمل. هل هذه مشكلة في البنية المعمارية أم أنني أفعل شيئًا آخر خاطئًا؟ هل هذا شيء قابل للتنفيذ أم أنني طموح جدًا؟ إذا لم يكن ممكنًا، ماذا يمكنني أن أفعل لجعله قابلًا للاستخدام على الأقل؟ - على سبيل المثال، مجرد الحصول على سير العمل لوضع جميع الروابط والمعلومات في جدول بيانات حتى أتمكن من التقديم بسهولة أكبر. هل يجب أن أبدأ من جديد؟

يجب أن تقوم هذه الأتمتة بـ:

• التشغيل يوميًا في الساعة 9 صباحًا.

• البحث في لوحات وظائف متعددة يوميًا عن الشواغر التي تتطابق مع خبرة المرشح (مرشح واحد).

• الكشف عن كلمات مفاتيح نظام التتبع (ATS) وعناوين URL والشركة ومعلومات الوظيفة والدور والكشف عن حقن التعليمات والأدلة.

• استخراج المعلومات إلى جدول.

يجب أن يقوم محفز ثانٍ بإنشاء نسخ مخصصة من السيرة الذاتية وخطاب التغطية لكل مرشح وحفظ هذه الملفات في مجلد Drive. يجب أيضًا أن يملأ النماذج تلقائيًا حتى يتمكن المرشح من تحديد ما إذا كان يريد التقديم أم لا. يجب أن يرفع وثائق السيرة الذاتية إلى كل موقع ويب.

إذا لم يكن هذا ممكنًا أو كان له حدود، أخبرني وسنفعل شيئًا أبسط. لدي إمكانية الوصول إلى Perplexity و Google Studio.

[nguyenthieutoan]

أهلا وسهلا بك @Camila_Andrea!

خطأ a.ok(nodeExists) عادة ما يعني أن عقدة في سلسلة أدوات الوكيل مرجعية لكن غير متصلة بشكل صحيح - تأكد مضاعف من أن كل عقدة أداة (Perplexity و HTTP) لها اتصال مناسب بمدخل “Tool” الخاص بعقدة وكيل الذكاء الاصطناعي، وليس فقط مع التدفق الرئيسي. مشكلة OOM هي مشكلة منفصلة: مع Gemini وأدوات متعددة، يمكن للوكيل أن يكرر عدة مرات ويتراكم نافذة السياق الكبيرة، مما يستنزف الذاكرة. عيّن حد أقصى لحدود التكرار على عقدة الوكيل (ضمن الإعدادات) - ابدأ بـ 5-10 وانظر إذا كملت.

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

[north1314520-dot]

مرحباً كاميلا،

هذا مشروع رائع جداً بصراحة، وبالفعل يمكن تنفيذه في n8n — لكن البنية المعمارية تحتاج إلى إعادة تفكير.

الأعطال التي تراها على الأغلب تأتي من عقدة Agent التي تحاول التعامل مع الكثير في نفس الوقت. عندما تدمج عدة استدعاءات للأدوات (بحث Perplexity + حذف بيانات لوحات الوظائف + ملء النماذج) داخل عقدة Agent واحدة، قد تتجاوز حدود الذاكرة، خاصة مع Gemini.

إليك ما أقترحه:

1. قسّمها إلى مسارات عمل منفصلة. لا تحاول فعل كل شيء في عقدة Agent واحدة. اقسمها:
   المسار A: Cron يومي → البحث في لوحات الوظائف → تصفية المطابقات → حفظ في قاعدة البيانات
   المسار B: يُشغّل لكل مطابقة → Perplexity لتحليل كلمات المفاتيح في ATS → تنسيق في جدول البيانات
   المسار C: تشغيل يدوي → توليد سيرة ذاتية/رسالة تغطية مخصصة لكل وظيفة محددة

2. عقدة Agent تعمل بشكل أفضل في صنع القرارات، وليس لربط طلبات HTTP متعددة ثقيلة. استخدم Agent لتقرير أي الوظائف سيتم التقدم إليها، وليس لحذف الوظائف بنفسك.

3. بخصوص جزء ملء النماذج تلقائياً — هذا هو الجزء الأصعب. معظم لوحات الوظائف تستخدم بنى نماذج فريدة. النهج الأكثر عملية هو جعل المسار يُحضّر كل شيء (السيرة الذاتية، رسالة التغطية، الإجابات) ويُنبهك للتقدم يدوياً. وجدت أن هذا النهج 80/20 يوفر وقتاً ضخماً في التطوير.

أنا أبني مسارات n8n مثل هذه احترافياً — هذا النوع من أتمتة الذكاء الاصطناعي متعدد الخطوات هو تخصصي بالفعل. إذا كنت تريد مني أن أساعدك في البنية المعمارية أو بنائها، أرسل لي رسالة مباشرة. أنا سعيد بالقيام بمكالمة سريعة ورسم خريطة البنية المعمارية لك.

على أي حال، فكرة مشروع رائعة — لا تتخلَّ عنها، فقط أعد هيكلتها.

[dima_automation]

خطآن مختلفان يتناوبان عادة ما يعنيان مشكلتين حقيقيتين متراكمتين، والرد أعلاه فصلهما بشكل صحيح. يستحق التعامل معهما بهذا الترتيب.

خطأ a.ok(nodeExists) هو مشكلة توصيل: عقدة أداة (Perplexity، أداة HTTP) يتم الإشارة إليها بواسطة الوكيل لكنها لم تُوصّل بشكل صحيح إلى مدخل أداة عقدة وكيل الذكاء الاصطناعي. يجب توصيل كل أداة بمدخل ai_tool الخاص بالوكيل، وليس في السطر الرئيسي للتنفيذ. افتح عقدة الوكيل وتأكد من ظهور كل أداة في قائمة الأدوات الخاصة به، إذا كانت إحدى الأدوات موصولة بالتدفق الرئيسي بدلاً من مدخل الأداة، فستحصل على هذا الخطأ بالضبط.

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

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

[Krunal_Salvi]

يحدث هذا الخطأ المتناوب عندما يكون تخصيص ذاكرة Node.js (max-old-space-size) مرهقًا تماماً بسبب بيانات التنفيذ المتزامنة التي تتدفق عبر نوافذ السياق الخاصة بـ Gemini و Perplexity. عندما يختنق الحاوية، فإنها إما تسقط تتبع حالة العقدة (a.ok(nodeExists) أو تتعطل بشكل كامل مع خطأ نفاد الذاكرة.

لمنع هذا من إسقاط مثيلك، تحتاج إلى فرض n8n على حذف سجلات التنفيذ السابقة وتوسيع بصمة ذاكرة Node.js داخل متغيرات بيئة Docker الخاصة بك.

أضف هذه إلى إعداد الحاوية الآن:
NODE_OPTIONS=–max-old-space-size=4096
EXECUTIONS_DATA_PRUNE=true
EXECUTIONS_DATA_MAX_AGE=24

إذا كنت تقوم بتشغيل حلقات ذكاء اصطناعي معقدة جداً لمشروع عميل وتحتاج إلى إعداد خادم محكم لن يتعطل تحت الحمل قبل صباح يوم الاثنين، فلننتقل. أنا مهندس بنية تحتية في الواجهة الخلفية؛ يمكنني القفز على مشاركة شاشة سريعة معك اليوم، وتحسين طبقات Docker compose الخاصة بك، واستقرار محركات تحليل الذكاء الاصطناعي الخاصة بك مقابل 250 دولار فقط. أرسل لي رسالة مباشرة إذا كنت تريد إصلاح هذا في غضون 30 دقيقة!