لا تسمح لميزة Agentic Management في Zapier بتطبيق الإصلاحات تلقائيًا إلا في سير العمل الذي يبقى فيه أثر الإصلاح الخاطئ داخل فريقك. أما كل سير عمل يراسل عميلًا، أو يحرّك مالًا، أو يسجّل ما وُعِد به، أو يرسل بيانات إلى وجهة جديدة، فاضبط الوكيل فيه على طلب موافقتك أولًا. تسأل قاعدة الموافقة لدى Zapier: هل يغيّر الإصلاح ما يستطيع سير العمل فعله، أو يغيّر أحد الأصول أو المصادقة، أو هل ثقة الوكيل به منخفضة؟ لكنها لا تسأل عمّا يمسّه سير العمل في نشاطك التجاري، وهذا سؤال ثانٍ عليك أنت أن تجيب عنه.
ينطبق هذا على Next Gen Zaps، لا على كل Zap. أعلنت عنها Zapier في 23 سبتمبر 2026، وهي متاحة في مرحلة وصول مبكر لمن يطلبها، على خطط Professional، Team، Enterprise فقط. وهي مجانية إلى أن تبدأ الفوترة في 1 ديسمبر 2026. إذا بدأت استخدام Next Gen Zaps الآن، فستعمل بالإعدادات الافتراضية التي وضعتها Zapier ما لم تغيّرها.
ما الذي يسأل عنه الوكيل، وما الذي لا يسأل عنه
تسمّي Zapier هذه الميزة Agentic Management. وبحسب صفحة المساعدة التي تشرح Agentic Management في Next Gen Zaps، تضم الميزة ثلاث قدرات، والثلاث كلها مفعّلة افتراضيًا:
- Heal: تصلح سير العمل عندما يفشل تشغيله.
- Optimize: تقترح تحسينات بعد تشغيل ناجح.
- Automatically apply fixes: تتيح للوكيل أن يطبّق الإصلاح بنفسه عندما لا يغيّر الإصلاح ما يستطيع سير العمل فعله.
إذا كان خيار Automatically apply fixes معطّلًا، يُعِدّ الوكيل الإصلاح ويطلب موافقتك عليه. وإذا كان مفعّلًا، يطبّق الوكيل الإصلاح ثم يخبرك بعد ذلك. وتقول Zapier إن الوكيل يختبر سير العمل أولًا، ثم ينشر التغيير في إصدار جديد من سير عملك.
وحتى مع تفعيل التطبيق التلقائي، هناك ثلاثة أنواع من الإصلاحات تنتظر موافقتك دائمًا:
- أن يغيّر الإصلاح ما يستطيع سير العمل فعله، كإضافة استدعاء أداة أو إجراء أو فرع.
- أن يغيّر الإصلاح أحد الأصول أو المصادقة، وهو ما تعدّه Zapier عالي الخطورة.
- أن تكون ثقة الوكيل بالإصلاح منخفضة.
أما ما يقع خارج هذه الثلاثة فيمكن نشره دونك. وتلخّص Zapier ذلك بعبارة قصيرة مفادها أن التغيير الصغير في الشيفرة يمضي وحده. ولا تضع حدًّا لحجم ما تعدّه صغيرًا؛ فالمعيار هو الشروط الثلاثة السابقة، لا عدد الأسطر التي تغيّرت.
هذه القاعدة حماية حقيقية. فالوكيل الذي يحتاج إلى موافقتك ليضيف إجراءً أو يغيّر المصادقة، وينتظرك حين لا يكون واثقًا، يختلف كثيرًا عن وكيل مطلق اليد. السؤال هو: هل تتطابق هذه الشروط الثلاثة مع المواضع التي تكمن فيها مخاطرك؟
تصنّف Zapier الإصلاحات بحسب ما يستطيع سير العمل فعله، ومخاطرك تتحدّد بحسب العواقب
تصف شروط Zapier شكل سير العمل ومدى يقين الوكيل: إجراءاته وفروعه وأصوله وعمليات المصادقة فيه، ثم ثقة الوكيل. أما ما تتعرّض له أنت فيتوقف على شيء آخر: ما تفعله الخطوة بعميل، أو برصيد حساب، أو بسجلّ، أو بحدود بياناتك.
هذان محوران مختلفان. فقد يترك الإصلاح شكل سير العمل كما هو، ومع ذلك يغيّر العواقب. تغيير الحقل الذي يغذّي خطوة موجودة لا يضيف إجراءً ولا فرعًا، ولا يغيّر أي مصادقة. وبحسب القاعدة كما تنصّ عليها Zapier، يمكن لإصلاح كهذا أن يمضي وحده. هذه قراءة للقاعدة المنشورة، وليست شيئًا قالته Zapier عن حالة بعينها.
وحتى Zapier لا تقدّم قاعدتها على أنها تغطي المخاطر كلها. ففي صفحة البدء باستخدام Next Gen Zaps تنصحك بأن تبدأ بسير عمل واتصالات تطبيقات منخفضة المخاطر. وتطلب منك صفحة Agentic Management أن تراجع اعتبارات الأمان قبل أن تفعّل Automatically apply fixes في سير العمل الذي يتعامل مع بيانات حساسة. أي أن Zapier نفسها تطلب منك أن تصنّف سير العمل لديك، والإعداد الافتراضي لا يقوم بذلك نيابة عنك.
العطل الذي تذكره Zapier، أي الحقل الذي تغيّر اسمه، هو الذي ينبغي أن يقلقك
تضرب Zapier مثالين على ما يُفشل التشغيل: حقل تغيّر اسمه، واتصال انتهت صلاحيته. الاتصال الذي انتهت صلاحيته يبدو مشكلة مصادقة، فإذا كان إصلاحه يغيّر المصادقة، فإن قاعدة Zapier تجعله ينتظر الموافقة. أما الحقل الذي تغيّر اسمه فحالته مختلفة.
لنأخذ مثالًا افتراضيًا: تأكيد حجز. يقرأ Zap موعدًا جديدًا من أداة الجدولة لديك، ثم يرسل إلى العميل بريدًا إلكترونيًا فيه التاريخ والوقت والمكان. تغيّر أداة الجدولة اسم أحد حقولها، فيفشل التشغيل، ويصلح الوكيل ربط الحقول لتحصل خطوة البريد على قيمة من جديد. لم يُضَف أي إجراء، ولم يتغيّر أي اتصال. فإذا كان الوكيل واثقًا، وما لم تعدّ Zapier ربط الحقول أحد الأصول، فلا شيء في القاعدة المعلنة يمنع نشر هذا الإصلاح.
افترض الآن أن الحقل الذي اختاره قريب من الصحيح لكنه ليس هو: وقت إنشاء الحجز بدلًا من وقت الموعد، أو الفرع الرئيسي بدلًا من الفرع الذي اختاره العميل. ينجح التشغيل، ويُرسَل البريد، ويصل العميل في الوقت الخطأ، وأول علامة على المشكلة شكوى.
لا تقدّم صفحات المساعدة لدى Zapier أي أرقام عن عدد المرات التي يخطئ فيها وكيلها خطأً كهذا. أما المقصود هنا فأضيق من ذلك: هذا النوع من الإصلاحات يمكن أن يُطبَّق تلقائيًا بحسب قاعدة Zapier، والخطوة التي يغيّرها تتعامل مع العميل.
الاختبار قبل النشر لا يخبرك بما فُحص
تقول Zapier إن الوكيل يختبر سير العمل قبل النشر. لكن صفحات المساعدة لديها لا توضح ما الذي يفحصه هذا الاختبار، ولا إن كان يقارن الناتج الجديد بما كان سير العمل يُخرجه من قبل. فلا تفترض أنه يفعل ذلك.
التشغيل الناجح يثبت أن الخطوات نُفّذت، لكنه لا يثبت أن البريد حمل الوقت الصحيح أو أن الفاتورة حملت المبلغ الصحيح. وتَظهر الفجوة نفسها في الأبحاث عن الإصلاح الآلي لشيفرات البرمجيات: فقد تناولت دراسة عن الهلوسة في الإصلاح الآلي للبرامج نماذج لغة كبيرة تصلح أخطاء في برامج Java، وأبلغت عن إصلاحات ناتجة عن الهلوسة، من بينها تعديلات برمجية تجتاز كل الاختبارات المتاحة. هذا إصلاح للشيفرة على مجموعة اختبار معيارية، لا أتمتة لسير العمل ولا وكيل Zapier، فتعامل معه على أنه تشبيه. أما ما ينطبق هنا فهو الآلية: اجتياز الفحص المتاح شيء، وكون الإصلاح صحيحًا شيء آخر.
وقد طرحنا الفكرة نفسها عن سير العمل الذي يُبلغ عن النجاح ولا يغيّر شيئًا (مقال بالإنجليزية). فقد يعمل Zap مُصلَح وتظهر حالته خضراء، ومع ذلك يفعل شيئًا مختلفًا.
صنّف كل سير عمل بحسب الخطوة الأبعد أثرًا فيه
يُضبط خيار Automatically apply fixes لكل سير عمل على حدة، لذا يُتخذ القرار لكل سير عمل على حدة أيضًا. انظر في كل خطوة، ودع الخطوة ذات الأثر الأسوأ تحدّد إعداد Zap بأكمله.
| إذا كان سير العمل… | Automatically apply fixes | السبب |
|---|---|---|
| يرسل تنبيهات أو إشعارات داخلية إلى فريقك | مفعّل | الإصلاح الخاطئ يراه الأشخاص القادرون على اكتشافه، قبل أن يتأثر أي أحد من خارج الفريق. |
| يكتب سجلات داخلية أو صفوفًا في التقارير | مفعّل | يمكن تدارك الأخطاء، وتظهر عند المراجعة التالية. انقله إلى الموافقة أولًا إذا كان أحد يتصرف بناءً على الأرقام دون أن يتحقق منها. |
| يراسل عميلًا: رسائل التأكيد والمتابعة والتذكير | الموافقة أولًا | تصل القيمة الخاطئة إلى شخص لا يمكنك استرجاع الرسالة منه. |
| ينشئ معاملات مالية أو يغيّرها: الفواتير وطلبات الدفع والمبالغ المستردة | الموافقة أولًا | المبلغ الخاطئ أو المستلم الخاطئ يكلّف مالًا، والتراجع عنه ليس سهلًا. |
| يسجّل ما وُعِد به: الحجوزات وشروط الصفقات وتفاصيل طلبات الشراء | الموافقة أولًا | يصبح السجلّ هو النسخة التي يتصرف الناس بناءً عليها لاحقًا. |
| يرسل بيانات إلى وجهة لم يرسل إليها من قبل | الموافقة أولًا | خروج البيانات إلى وجهة جديدة قرار يخص حدود البيانات، وليس إصلاحًا. |
حين يكون التطبيق التلقائي غير مفعّل، يظل الوكيل يحدد سبب العطل ويُعدّ الإصلاح. وتقرأ أنت تغييرًا واحدًا مقترحًا وتضغط زر الموافقة. الثمن انتظار إلى أن يوافق أحد، في سير عمل فشل بالفعل. والمكسب أن إنسانًا ينظر في التغيير الذي يطرأ على خطوة تتعامل مع العملاء قبل أن يدخل حيز التشغيل.
وإذا أردت ألا يغيّر الوكيل شيئًا على الإطلاق في سير عمل ما، فإن Zapier توثّق مفتاحًا يشغّل الميزة كلها ويوقفها لسير عمل واحد. ولا تصف صفحات المساعدة لديها أي مفتاح على مستوى الحساب كله. ويمكن للفرق التي تدير عددًا كبيرًا من سير العمل أن تضبط الخيار نفسه لكل سير عمل عبر Agentic Management API. وحين تُضبط قيمة الخيار auto_approve على true، تُطبَّق الإصلاحات دون أن يُطلب من المالك الموافقة على كل واحد منها.
بعد أي إصلاح تلقائي: حالة واحدة معروفة، وشخص واحد محدد بالاسم
حتى سير العمل الذي تُبقي فيه التطبيق التلقائي مفعّلًا يحتاج إلى فحص بعد كل إصلاح، وللفحص جزءان.
قارن حالة واحدة معروفة. تقول Zapier إنك تستطيع أن تراجع في سجل الإصدارات ما تغيّر بالضبط. افتح الإصدار الجديد، وحدّد الخطوة التي تغيّرت، ثم شغّل أو قارن حالة واحدة تعرف نتيجتها مسبقًا: حجزًا تجريبيًا، أو عميلًا محتملًا تعرفه، أو صفًّا من تقرير الأسبوع الماضي. وطابق الناتج قيمةً قيمةً مع ما أخرجه الإصدار السابق. فإن كان ربط الحقول قد تغيّر، فهنا ستراه.
تأكد أن شخصًا محددًا بالاسم يقرأ الإشعارات. في مرحلة الوصول المبكر، تُخطرك Zapier بالبريد الإلكتروني حين يطبّق الوكيل إصلاحًا. لكن صفحاتها لا تذكر من يتلقى هذا البريد: مالك الحساب، أم أحد المشرفين، أم شخص تختاره أنت. تحقّق من ذلك في حسابك. فإذا وصل الإشعار إلى صندوق بريد مشترك لا يتابعه أحد، فالإصلاح التلقائي صامت عمليًا.
وتحقّق من شيء آخر قبل أن تعتمد على هذا الإعداد. صفحة Agentic Management وصفحة البدء باستخدام Next Gen Zaps لدى Zapier تصفان مراجعة الإصلاح في سجل الإصدارات، لكنهما لا تصفان استعادة إصدار سابق. تحقّق إن كان بإمكانك إرجاع Next Gen Zap إلى إصدار سابق في حسابك، وكيف، قبل أن يعتمد سير عمل يتعامل مع العملاء على هذه الإجابة.
رُوجعت هذه المعلومات في 6 نوفمبر 2026 على صفحات المساعدة لدى Zapier وإعلانها في منتدى مجتمعها ووثائق API الخاصة بها. ولأن Next Gen Zaps قيد التطوير النشط، فقد تتغير الإعدادات الافتراضية والحدود.
الأسئلة الشائعة
هل تنطبق Agentic Management على Zaps الكلاسيكية أو على الخطة المجانية؟
لا. تنتمي Agentic Management إلى Next Gen Zaps، وهي في مرحلة وصول مبكر لمن يطلبها على خطط Professional، Team، Enterprise. وفي خطة Team، يجب أن يأتي الطلب من مالك الحساب أو أحد المشرفين.
هل التطبيق التلقائي مفعّل افتراضيًا؟
نعم. تقول صفحة المساعدة لدى Zapier إن Agentic Management وقدراتها الثلاث كلها، ومنها Automatically apply fixes، مفعّلة افتراضيًا في Next Gen Zaps.
هل توثّق Zapier مفتاح إيقاف على مستوى الحساب كله؟
لا. تصف صفحات المساعدة لديها مفتاحًا يشغّل الميزة كلها أو يوقفها في كل سير عمل على حدة، وإعدادًا منفصلًا للتطبيق التلقائي في كل سير عمل. وتتيح API التحكم نفسه لكل سير عمل.
ما الذي تفعله Optimize؟
تصف Zapier قدرة Optimize بأنها تقترح تحسينات بعد تشغيل ناجح. أما Heal فهي القدرة التي تصلح عمليات التشغيل الفاشلة، فيما يحدد خيار Automatically apply fixes ما إذا كانت هذه الإصلاحات تُنشر دون موافقتك.
كم ستكلّف Next Gen Zaps؟
تقول Zapier إن Next Gen Zaps مجانية خلال مرحلة الوصول المبكر إلى أن تبدأ الفوترة في 1 ديسمبر 2026. ولا تذكر صفحة البدء لديها شكل الفوترة بعد هذا التاريخ.
لست متأكدًا من أين تبدأ؟
فحص ملاءمة الأنظمة المجاني: تسعة أسئلة في نحو 5 دقائق تقترح نظامًا واحدًا تبدأ به، مع خطوة تالية مجانية.
ابدأ فحص الملاءمة المجانيإشارات أوضح. قرارات أذكى.
انضمّ إلى قائمتنا البريدية واحصل على أفضل ما نكتبه عن الذكاء الاصطناعي والأنظمة مباشرةً في بريدك — دون ضجيج.
