أحاول فهم كيفية تشغيل مسارات عمل n8n التي تتضمن وكلاء ذكاء اصطناعي بأمان.
بالتحديد، أنا فضولي حول إجراءات مثل إرسال رسائل بريد إلكترونية خارجية، وتحديث سجلات العملاء، والوصول إلى Drive/Notion، وإصدار المبالغ المستردة، أو استدعاء واجهات برمجية خارجية.
ما الإجراءات التي لا تسمح لخطوة ذكاء اصطناعي بتنفيذها تلقائياً؟
أين تستخدم حالياً عقد Wait، أو موافقات Slack، أو فحوصات يدوية، أو كود مخصص؟
هل حدث أن قام مسار عمل بفعل شيء غير متوقع لأن خطوة ذكاء اصطناعي فسرت البيانات بشكل غير صحيح؟
هل من الصعب إجراء تدقيق “لماذا حدث هذا الإجراء” في إعدادك الحالي؟
أنا في مراحل البحث الأولية وأقدّر الأمثلة الحقيقية أكثر من الآراء العامة.
مثال واقعي بدلاً من رأي عام، لأن هذا ما طلبته: كنت أختبر سير عمل الوكيل هذا الأسبوع حيث يتم حظر إرسال بريد إلكتروني خلف فحص سياسة مع قاعدة قائمة بيضاء على نطاق المستقبل. في أول اختبار، تم رفض بريد إلكتروني كان يجب أن يمر. اتضح أن قاعدتي سياسة متداخلتين كانتا تراقبان نفس الإجراء، وكانت إحداهما تحتوي على مسافة واحدة شاردة مكتوبة في القيمة المسموحة. لم يتعطل شيء، لم يحدث خطأ، فقط عاد بصمت إلى الرفض — ومعرفة السبب تطلبت حفرًا حقيقيًا في سجل التدقيق، والذي كان لديه خطأ عرض صغير خاص به أفسد أي قاعدة تسببت فيه بالفعل.
هذا هو الجواب الصادق على سؤالك الأخير — التدقيق في “لماذا حدث هذا” ليس صعبًا لأن المفهوم صعب، بل لأن هذه الأنظمة تفشل بصمت، وأدواتك يجب أن تكون موثوقة بما يكفي بحيث تؤمن حقًا بما تخبرك به حول ما حدث.
حول ما لا أسمح له أبدًا بالتشغيل التلقائي: أي شيء لا رجوع فيه يتعلق بالمال أو رسائل البريد الإلكتروني الخارجية أو سجلات شخص آخر. يتم فحصها مقابل القواعد أولاً — السماح أو الرفض أو الانتظار لمراجعة بشرية — قبل تنفيذها، وليس عقدة انتظار تجلس في المنطقة الأعلى تأمل في أن استدعاء أداة الوكيل قد يحترمها.
كنت أبني طبقة السياسة والتدقيق كشيء خاص بها بدلاً من توصيل منطق الموافقة في كل سير عمل بشكل منفصل — يصبح فوضويًا بسرعة بعد 10-15 سير عمل. إنها عقدة مجتمع n8n، مبكرة، حواف خشنة مضمونة. إذا كنت تريد أن ترى تشغيلاً حقيقيًا لها أو تحاول كسرها بنفسك، فأنا سعيد بإظهار ذلك لك.
لا يمكنني التحدث إلا عن جانب المال — أنا مؤسس في Sequence (getsequence.io)، نحن نوفر البنية التحتية للدفع التي تعمل عليها الكثير من وكلاء الذكاء الاصطناعي — لكن بما أن المبالغ المستردة/الدفعات على قائمتك، إليك حيث يرسم مستخدمونا الخط بالفعل:
أبداً تلقائياً: الدفعة الأولى لطرف مقابل جديد أو حساب بنكي مضاف حديثاً. لا يهم ما إذا كان صغيراً جداً. عادة ما يتم أتمتة الدفعات المتكررة للأطراف المعروفة بعد بضعة أسابيع بمجرد أن يثق الناس بسير العملية.
حدود، وليس موافقات شاملة: النمط الشائع هو تحت $X بالكامل تلقائي، $X–$Y موافقة Slack، فوق $Y موافق اثنان. “الموافقة على كل شيء” الشاملة تختفي بسرعة لأن البشر يبدأون في التوقيع الروتيني في غضون أسبوع — مما يهزم بهدوء الهدف كله.
السلوك غير المتوقع: نعم. الحالة الكلاسيكية هي أن الوكيل يسيء قراءة مبلغ الفاتورة (التباس عشري أو عملة) ويبدأ تحويلاً بمقدار 100 ضعف النية. تمسك خطوات الموافقة بالمعاملات التي يقرأها الإنسان فعلياً؛ الحدود الصعبة المفروضة خارج سير العمل تمسك بالمعاملات التي يوقعون عليها روتينياً. تريد كليهما.
التدقيق: مؤلم إذا كان السجل الوحيد لديك هو سجلات تنفيذ n8n. يجب أن يعيش “السبب” متصلاً بالإجراء نفسه، وليس في تشغيل سير عمل يجب عليك التنقيب عنه لاحقاً.
أنا سعيد بمشاركة المزيد من التفاصيل إذا كان ذلك مفيداً لبحثك.
نمط ملموس استخدمته: وكيل الذكاء الاصطناعي لا يحصل أبداً على أداة تنفذ الإجراء الحساس بشكل مباشر (استرجاع، بريد إلكتروني خارجي، تحديث السجل). يحصل فقط على أداة “اقتراح إجراء” التي تكتب حمولة منظمة — نوع الإجراء، الهدف، المعاملات، والمنطق الخاص بالوكيل — في قائمة الانتظار (Sheets/Postgres).
فرع منفصل يختار تلك الصف، يرسل رسالة Slack مع أزرار الموافقة/الرفض، وينتظر في عقدة الانتظار التي تستأنف بواسطة webhook — وليس بمهلة زمنية. لذا لا يحدث شيء فقط لأن أحداً لم ينظر إليه في الوقت المناسب. فقط بعد الموافقة يعمل عقدة الإجراء الفعلي (Gmail، HTTP Request، إلخ)، مستخدماً المعاملات الدقيقة التي رآها الإنسان — وليس أياً كان قد ينتجه الوكيل في استدعاء ثانٍ. هذا هو الجزء الذي يوقف “وافقت على X، نفذت Y”.
بخصوص “لماذا حدث هذا” — تسجيل نص المنطق الخام الخاص بالوكيل جنباً إلى جنب مع قرار الموافقة، في نفس الصف، هو ما جعل الإجابة عن هذا ممكنة لاحقاً. معاملات استدعاء الأداة وحدها لم تكن كافية.
نمط فشل يستحق الإشارة إليه: عند إعادة محاولات webhook، استدعى الوكيل أحياناً أداة الاقتراح مرتين لنفس الحدث، مما أنشأ طلبات موافقة مكررة. تم إصلاح هذا بمساعدة دالة hash لحمولة المشغل كمفتاح القدرة على التكرار في صف قائمة الانتظار.
نمط الاقتراح والإجراء من @nathan3 هو العمارة الصحيحة. شيء واحد أود أن أضيفه على جانب التدقيق: قم بتخزين نص التفكير الخام للوكيل جنباً إلى جنب مع الإجراء المقترح في نفس صف الطابور، وليس فقط معاملات استدعاء الأداة. عندما يحدث خطأ ما لاحقاً، “قرر الوكيل إرسال بريد إلى X لأنه تطابق مع القاعدة Y” أكثر فائدة بـ 10 مرات من مجرد “تمت الموافقة على البريد إلى X.”.
بخصوص مشكلة التكرار - يعمل تجزئة حمل بيانات المشغل، لكن إذا كنت تعمل في وضع الطابور يمكنك أيضاً استخدام معرف التنفيذ المدمج في n8n كمفتاح التكرار على صف الطابور. بهذه الطريقة، حتى لو تمت إعادة محاولة webhook، فإن INSERT ... ON CONFLICT DO NOTHING يمنع النسخة المكررة على مستوى قاعدة البيانات قبل أن تصل إلى خطوة الموافقة.
إضافة جيدة، معرّف التنفيذ + ON CONFLICT DO NOTHING أنظف مما كنت أفعله. كنت أقوم بتجزئة حمولة المشغل يدويًا والتحقق منها قبل الإدراج، لكن هذه خطوة قراءة-ثم-كتابة إضافية مع نافذة سباق بين الفحص والإدراج. دفع قيد التفرد إلى قاعدة البيانات يزيل تلك النافذة تماما. جاري التبديل إلى هذا.
درس إنتاجي واحد يجب إضافته إلى نمط الاقتراح ثم التنفيذ الذي وصفه @nathan3: الموافقات تحتاج إلى TTL. زر الموافقة في Slack الذي تم النقر عليه بعد ثلاثة أيام من تنفيذ الطلب مقابل عالم قد يكون قد تغير - تم دفع الفاتورة بالفعل، وتم تحديث تفاصيل الطرف الآخر، والسعر تحرك. كانت الموافقة مشروعة عند طلبها وخاطئة بحلول الوقت الذي تم تنفيذها.
إنها إصلاح رخيص في تصميم صف الطابور الذي تقاربتم عليه: قم بتخزين approved_at + expires_at، واجعل فرع التنفيذ يتحقق من كليهما. انتهاء صلاحية الموافقة يعني إعادة الاقتراح، لا تنفذ أبداً. يختلف TTL حسب فئة الإجراء — دقائق للمدفوعات، ساعات للرسائل الإلكترونية هو الافتراضي المعقول.
اكتشاف جيد، لم أكن قد أخذت في الاعتبار الموافقات القديمة. إضافة approved_at + expires_at على صف الطابور، والبوابة على فرع التنفيذ على كليهما، هو بالضبط نوع الإصلاح الرخيص الذي من السهل تجاهله حتى يعضك.
ربما كنت سأذهب خطوة أبعد حتى داخل نافذة TTL: إعادة فحص الحالة الأساسية مباشرة قبل التنفيذ (الفاتورة لم تُدفع بعد، السعر لم يتغير)، وليس فقط فحص طزاجة الموافقة. يمسك TTL بالقدم الواضحة، لكن بالنسبة للدفع على وجه التحديد، يمكن للعالم أن يتحرك في دقائق، وليس أيام فقط - كون الموافقة “طازجة” لا يعني أن الحالة التي تمت الموافقة عليها لا تزال قائمة.
زاوية مختلفة عن الإجابات أعلاه، لأن الجميع حتى الآن يضعون قيودًا على عمليات الكتابة: المال والرسائل والسجلات. الإجراء الذي كان علي تعلم وضع قيود عليه هو الإجراء الذي لا يكتب شيئًا، وهو الذكاء الاصطناعي يرد مباشرة على العميل.
رد برنامج الدردشة على شخص حقيقي هو أيضًا إجراء خارجي لا رجعة فيه. بمجرد أن يقول شيئًا خاطئًا، لا يمكنك التراجع عنه. لكن لا تشتعل أي من الغرائز المعتادة، لأنه لم يتم إدراج شيء، ولم يصل شيء إلى واجهة برمجية تطبيق خارجية، ولم يتغير أي صف. لا يبدو أنه من الفئة الخطرة من الإجراءات، لذلك عادة لا يحصل على أي قيد على الإطلاق.
ما أستخدمه بدلاً من خطوة موافقة بشرية، لأنك لا تستطيع وضع إنسان أمام رد دردشة مباشر دون قتل المنتج: بوابة الثقة بين الاسترجاع والإجابة. إذا كانت الأدلة المسترجعة ضعيفة جدًا أو كان التشابه ضعيفًا جدًا، فلا يُسمح للنموذج بالإجابة. يقول إنه لا يملك هذه المعلومات وينقل الأمر إلى إنسان. الرفض هو الافتراضي والإجابة هي الشيء الذي يجب أن يُكتسب. نفس الشكل مثل قائمة السماح، فقط تم تطبيقها على ما إذا كان يُسمح للنموذج بالتحدث بدلاً من ما إذا كان يُسمح له بالتصرف.
شيئان أخطأت فيهما ربما يستحقان النقل.
بخصوص سؤال التدقيق: أقوم بتسجيل الأجزاء المسترجعة ودرجات التشابه الخاصة بها بجانب كل إجابة، وليس فقط النص النهائي. بدون ذلك، السؤال “لماذا قال ذلك” غير قابل للإجابة، لأن نص الإجابة وحده لا يخبرك بأي شيء عما كان النموذج ينظر إليه بالفعل. إنه نسخة الجانب الثابت من ما قاله nathan3 حول تخزين استدلال الوكيل بجانب القرار.
ثانيًا، وهذا هو الذي علق بي قبل يومين: البوابة نفسها يمكن أن تفشل بصمت، وتفشل في الاتجاه الآمن. كان شرط قديم في عقدة مرشح في اتجاه مصب الاسترجاع يسقط كل صف، لذلك رأت البوابة دليلاً صفريًا ورفضت بشكل صحيح. كل تنفيذ أخضر، لم يتم رفع أي خطأ. أخبر البوت الأشخاص بأدب أنه لا يعرف الأشياء التي تعرفها مستندات المصدر بوضوح، وكان سيستمر في فعل ذلك إلى الأبد، لأن الرفض لا يبدو أبدًا مثل الفشل. وجدته فقط بسؤال سؤال كنت أعرف بالفعل أن مستندات المصدر ترد عليه.
إذن الشيء الذي أود إضافته إلى نمط “الاقتراح ثم التنفيذ” الموصوف أعلاه: أي مكون يقرر “عدم المتابعة”، راقب عدد المرات التي ينطلق فيها. مسار الرفض الذي ينقل بهدوء من إطلاق 5 بالمائة من الوقت إلى 100 بالمائة من الوقت هو نظام مكسور يبدو تمامًا مثل نظام حذر.