أدوات RPA مفتوحة المصدر التي تستحق النظر فيها، وأين يمكنك تشغيلها

لا تستطيع عدة أدوات في قائمة مختصرة نموذجية لأدوات RPA مفتوحة المصدر العمل على خادم Linux مجرد من البيئة الرسومية. فهي تؤتمت واجهات تطبيقات سطح المكتب وتعتمد على جلسة رسومية، بينما لا يوفر الخادم المجرد جلسة سطح مكتب للتحكم فيها. هذه الخاصية وحدها تقسم الفئة إلى قسمين، وتحدد المكان الذي يمكن أن يعمل فيه روبوتك.

تراخيص RPA التجارية هي ما يدفع معظم عمليات البحث عن أفضل أدوات RPA مفتوحة المصدر. راجعت سجلات الترخيص والنشاط والحزم أدناه مجددًا في 5 أكتوبر 2026، وكل ادعاء بشأن حالة مشروع مرتبط بالسجل الذي استند إليه.

أبرز النقاط

• ابدأ بمتطلبات الجلسة، لا بقائمة الميزات. تعتمد Oculix وOpenRPA وtaskt أساسًا على الواجهة الرسومية وتحتاج إلى جلسة رسومية للعمل على تطبيقات سطح المكتب المحلية. أما RPA Framework فلا يحتاج إليها للعمل على المتصفح والملفات والبيانات. ويعتمد الأمر مع TagUI وUI.Vision على وضع التشغيل الذي تستخدمه.
• أصدر RPA Framework إصدارات في فبراير ومارس ومايو ويونيو وأغسطس وأكتوبر من عام 2026، وهو سجل الإصدارات الأكثر انتظامًا مما جرى التحقق منه هنا.
• يستخدم TagUI ترخيص Apache-2.0 وما زال يقبل المساهمات، لكن AI Singapore أوقفت صيانته ودعمه. ولم يصدر إصدار جديد من غلافه البرمجي بلغة Python منذ يوليو 2023.
• لا مكان لـAutomagica وOpenBots في قائمة مختصرة حديثة. توقف Automagica عن استخدام AGPL3 عندما استحوذت Netcall على الشركة في أكتوبر 2020، وليس لدى OpenBots مستودع عام تتم صيانته لمنتج RPA.
• إذا كانت الأنظمة التي تربطها توفر أصلًا واجهات API أو webhooks، فأنت تحتاج إلى أتمتة سير العمل، لا RPA. فئة مختلفة، وأدوات مختلفة، ومدة تطوير أقصر بكثير.

ما لا يغطّيه هذا المقال

ثلاثة أسئلة مجاورة تقع خارج نطاق المقالة، ولكل منها سبب مختلف.

• المنصات التجارية التي تقدم مستويات مجانية. يُعد اختيار UiPath Community Edition أو الخطة المجانية من Power Automate قرارًا منفصلًا عن القرار المطروح هنا.
• التثبيت والإعداد. لا يمثل أي شيء أدناه دليل إعداد، ولا نقدم أمرًا لسطر الأوامر لأي أداة هنا.
• وكلاء الذكاء الاصطناعي لاستخدام الكمبيوتر. توفر إحدى أدوات القائمة تكاملًا مع أحد هؤلاء الوكلاء، ونخصص له جملة واحدة، لا مقارنة.

أدوات RPA مفتوحة المصدر التي ما زالت تتم صيانتها

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

rpaframework مجموعة مكتبات، لا تطبيق. تكتب بلغة Python أو باستخدام Robot Framework وتستورد الأجزاء التي تحتاج إليها، ما يجعل البداية أصعب من تسجيل ماكرو، لكنه أسهل بكثير في الصيانة. يصف مستودعه المشروع بأنه مُحسّن للعمل مع Control Room، منتج التنسيق التجاري الذي بنته Robocorp حوله. يصف أحد أعضاء فريق Sema4.ai في نقاش على r/rpa شركة Robocorp بأنها أصبحت جزءًا من Sema4.ai، ويحدد الحد الفاصل بوضوح. المكتبة مرخصة بموجب Apache-2.0، أما المنصة فلا. تغيرت الملكية ولم يتغير هذا الحد. كذلك يستخدم Robot Framework الذي تقوم عليه المكتبة ترخيص Apache-2.0، ولا يمثل خيارًا منفصلًا لإضافته إلى القائمة المختصرة.

إضافة المتصفح الخاصة بـUI.Vision هي النواة مفتوحة المصدر. أتمتة سطح المكتب تتطلب تنزيلًا منفصلًا، هو تطبيق محلي يسمى XModules يمنح الإضافة القدرة على التعرف على الصور والنصوص لتتمكن من النقر على عناصر خارج المتصفح. الترخيص مزدوج (AGPLv3 أو اتفاقية تجارية). إذا عدّلت النواة مفتوحة المصدر ولا تريد الالتزام بشروط AGPLv3 الخاصة بمشاركة المصدر، فالترخيص التجاري هو البديل.

taskt هو الخيار الذي يصعب تصنيفه. تلقى فرع التطوير فيه commit في يوليو 2025، بينما نُشر آخر إصدار موسوم له، v3.5.0.0، في مايو 2020. عمليات commit والإصدارات إشارتان مختلفتان، ومرور كل هذه المدة دون نسخة مبنية ذات رقم إصدار لا يعني أن النسخة الموجودة توقفت عن العمل.

يحتاج SikuliX إلى ملاحظة خاصة به، لأن الاسم أصبح فعليًا يشير إلى خط التطوير القديم. أُرشف مستودعه الأصلي في مارس 2026، وتوجه مرآة oculix-org المستخدمين الحاليين إلى Oculix، الامتداد النشط المرخص بموجب MIT. لذلك فإن Oculix هو المشروع الذي يستحق الدخول في القائمة المختصرة الآن؛ أما SikuliX1 فيفيد في فهم أصل المشروع والتوافق، لا بوصفه الخيار الذي تتم صيانته.

هناك خياران يواصلان الظهور في القوائم المختصرة ولا ينبغي أن يكونا فيها. يعلن README الخاص بـAutomagica أن Netcall استحوذت على الشركة في 13 أكتوبر 2020 وأن الروبوت لم يعد متاحًا بموجب AGPL3، بينما تضم مؤسسة OpenBots العامة على GitHub مستودعًا لموقع ثابت ومكتبة لمحاكاة الطرفية، دون نواة RPA.

الاعتماد على الواجهة الرسومية أم التشغيل بلا واجهة: الفارق الذي يحدد خادمك

تحتاج أداة RPA مفتوحة المصدر إلى جلسة سطح مكتب عندما يعتمد سير العمل على أتمتة واجهة تطبيقات سطح المكتب. يمكن تشغيل أتمتة واجهات API والملفات والبيانات بلا واجهة رسومية، وكذلك أتمتة المتصفح إذا كان المتصفح يعمل في الوضع بلا واجهة. تحتاج أدوات التعرف على الصور أيضًا إلى بكسلات تفحصها، لكن أتمتة سطح المكتب قد تظل معتمدة على جلسة رسومية حتى عندما تتعرف على عناصر التحكم باستخدام المحددات بدلًا من الصور.

جلسة سطح المكتب هي البيئة الرسومية التي يحصل عليها المستخدم بعد تسجيل الدخول: شاشة، ومدير نوافذ، ومؤشر فأرة له إحداثيات. أما التشغيل بلا واجهة رسومية فيعني العكس: جهاز يعمل دون شاشة متصلة. معظم خوادم Linux التي تستأجرها تأتي بلا واجهة رسومية افتراضيًا.

ينبع هذا التقسيم مما تعتمد عليه الأتمتة. تستخدم Oculix، مثل SikuliX قبلها، الرؤية الحاسوبية للعثور على زر عبر مطابقة صورة محفوظة مع البكسلات الحالية على الشاشة، ولذلك تحتاج إلى سطح رسومي تفحصه. يمكن لمتصفح يُقاد عبر واجهة API للأتمتة أن يعمل بلا واجهة رسومية دون عرض سطح مكتب. وتختلف أتمتة تطبيقات سطح المكتب المعتمدة على المحددات مرة أخرى: فقد تتعرف على عناصر التحكم بدلًا من البكسلات، لكنها قد تظل معتمدة على بيئة سطح مكتب رسومية. عند تشغيل RPA مفتوحة المصدر على خادم، فالسؤال العملي هو ما إذا كان سير العمل يحتاج إلى جلسة رسومية.

تقع TagUI وUI.Vision على جانبي هذا التقسيم، ويعتمد الجانب على الوضع الذي تستخدمه. تنص الوثائق المرجعية الخاصة بـTagUI على أن الخيار -headless يشغل تدفقًا باستخدام متصفح Chrome غير مرئي، وأنه لا يعمل للأتمتة المرئية. تعمل مهام المتصفح في UI.Vision داخل إضافة، بينما تعمل مهام سطح المكتب عبر XModules، الذي يتعرف على الصور على الشاشة، ولذلك يحتاج إلى شاشة ليتعرف عليها.

تسد الشاشة الافتراضية جزءًا من الفجوة. Xvfb طريقة معتادة لمنح جهاز Linux يعمل بلا شاشة عرضًا في الذاكرة يمكن للبرامج الرسومية الرسم فيه دون أن يشاهدها أحد، ما يجعل الأتمتة المعتمدة على الشاشة ممكنة على خادم لا يملك شاشة فعلية. لكنه لن يجعل أداة مخصصة لـWindows فقط تعمل على Linux، ويضيف طبقة أخرى يجب أن تستمر في العمل عند الثالثة صباحًا.

يخبرك الترخيص وتاريخ commit بما إذا كانت الأداة ستظل موجودة العام المقبل. وتخبرك متطلبات الجلسة بما إذا كنت تستطيع تشغيلها أصلًا.

أين تعمل كل أداة

يحتاج الروبوت الذي يتحكم في الشاشة إلى جلسة رسومية يستطيع التحكم فيها، سواء كانت سطح مكتب فعليًا أو جلسة بعيدة أو شاشة افتراضية. أما الروبوت الذي يعمل بلا واجهة رسومية فلا يحتاج إليها. يبدو الأمران بديهيين إلى أن يُطلب من الروبوت العمل في 3 صباحًا دون وجود أحد أمام لوحة المفاتيح.

تفرض RPA ذاتية الاستضافة متطلبًا تشغيليًا واحدًا يبقى قائمًا مهما اخترت من أدوات: يجب أن يكون الجهاز في الحالة الصحيحة عند حلول موعد التشغيل. هذه الحالة محددة في Windows، وتوثقها Microsoft بدقة لمنتجها. تقول إرشادات Microsoft الخاصة بتدفقات سطح المكتب غير المراقبة في Power Automate إن المنتج ينشئ جلسة سطح مكتب بعيد على الجهاز الهدف لتشغيل التدفق، وإن الاتصال بجلسة وحدة التحكم الخاصة بالجهاز غير متاح للتشغيل غير المراقب، وإن جهاز Windows 10 أو Windows 11 لا يستطيع تشغيل التدفق إذا كانت هناك جلسة مستخدم، حتى لو كانت مقفلة. أما في Windows Server، فإن وجود جلسة مقفلة مفتوحة باسم المستخدم نفسه الذي يُستخدم للاتصال يؤدي بدلًا من ذلك إلى خطأ.

هذه طريقة تنفيذ تخص شركة واحدة، لا قاعدة عامة في Windows، لكنها خريطة مفيدة لأنماط الفشل، لأن كل روبوت يتحكم في الشاشة يجب أن يحل المشكلة نفسها. لا بد من جهة تتحكم في جلسة تفاعلية، وعادة ما يكون سطح المكتب الذي سجلت الدخول إليه بنفسك هو العائق. في Linux، المشكلة المكافئة أصغر لكنها موجودة: المهمة التي تستمر بعد إغلاق جلسة SSH تحتاج إلى مجدول ومدير خدمات، لا إلى طرفية تركتها مفتوحة.

يتعامل Windows Server مع الجلسات بشكل مختلف عن إصدارات سطح المكتب. دور RD Session Host فيه يشغل أسطح مكتب قائمة على الجلسات على جهاز واحد لتحقيق الكفاءة في تعدد الجلسات، ولذلك يمكن لجلسة الروبوت وجلستك الشخصية أن تتعايشا. إذا استخدمت RD Session Host لتشغيل عدة جلسات، يحتاج كل مستخدم أو جهاز متصل إلى RDS CAL، وهي تكلفة ينبغي احتسابها مبكرًا، لا تفصيلًا تكتشفه متأخرًا.

متطلبات الموارد متواضعة. لن أخصص أكثر من 1 vCPU و2 GB من RAM لروبوت ينقر عبر نموذج ويكتب ملفًا. وسأخصص لأي شيء يقود متصفحًا كاملًا 2 vCPU و4 GB أو أكثر، خصوصًا مع عدة علامات تبويب، لأن Chrome هو الجزء المكلف من ذلك الحمل، لا أداة الأتمتة التي تعمل فوقه.

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

إذا كان استئجار الجهاز أفضل من صيانته، فإن هذا التقسيم يتوافق بوضوح كافٍ مع منتجين. يمنح Windows VPS الذي يعمل بصورة Desktop أو Server الروبوت المتحكم في الشاشة بيئة Windows مخصصة، ويغطي Linux VPS جانب التشغيل بلا واجهة رسومية، ويعمل كلاهما سواء كان حاسوبك المحمول مفتوحًا أم لا.

أي أداة تختار

إذا كانت المهمة تتم داخل المتصفح أو على الملفات وكنت تستطيع كتابة Python، فاختر RPA Framework، وما تبقى من هذا القسم حالات خاصة. تتغير الإجابة بمجرد أن تتعامل المهمة مع تطبيق سطح مكتب لا يوفر API، لأنك عندئذ تحتاج إلى أداة تستطيع التفاعل مع سطح مكتب رسومي، وتصبح القائمة المختصرة أقصر وأقدم.

للعمل على المتصفح والملفات والبيانات على خادم Linux، اختر RPA Framework. فهو يعمل بلا واجهة رسومية، ويمكن وضعه على جهاز بلا شاشة دون تجهيزات إضافية، وأصدر نسخة جديدة في وقت حديث هو أكتوبر 2026. المقابل هو أن تكتب Python أو Robot Framework بدلًا من تسجيل ماكرو، ما يكلفك في اليوم الأول ويعود عليك بالفائدة كلما تغير التطبيق الهدف.

لتطبيق Windows قديم لا يوفر API، عندما تريد أتمتة مرئية بدلًا من كتابة قاعدة شيفرة كاملة للأتمتة، اختر UI.Vision، مع مراعاة الشرط المرتبط به. يتلقى المشروع عمليات commit هذا العام، وهو ما لا ينطبق على جميع الخيارات القادرة على أتمتة سطح المكتب هنا، ويحمل جانب AGPLv3 من ترخيصه المزدوج التزامات مشاركة المصدر إذا عدلت البرنامج مفتوح المصدر ووزعته. taskt هو الخيار الثاني هنا. فرع تطويره نشط، وآخر إصدار موسوم له نُشر في مايو 2020، والفجوة بين مشروع يتلقى عمليات commit ومشروع يصدر نسخًا هي ما ينبغي تقييمه.

للأتمتة المرئية متعددة المنصات لأي شيء يظهر على الشاشة، اختر Oculix، الامتداد النشط لـSikuliX. ما زال يعتمد على الصور أولًا لا على المحددات، لكن المشروع يمتلك الآن IDE وإصدارات نشطة بدلًا من أن يكون مجرد مجموعة بدائيات لمطابقة الصور. استخدمه عندما يكون الهدف بكسلات، لا DOM أو شجرة إمكانية الوصول، وتعامل مع مستودع SikuliX1 المؤرشف بوصفه خط التطوير القديم، لا المنتج الذي تتم صيانته.

تستمر التوصيات بـTagUI لسبب وجيه. تبدو لغة نصوصه البرمجية قريبة من الإنجليزية العادية، ومنحنى تعلمه هو الأسهل بين الأدوات الست. أما الجانب المقابل فيرد في README الخاص به، الذي ينص على أن AI Singapore أوقفت الصيانة والدعم لـTagUI، بينما يستمر المشروع بمساهمي البرمجيات مفتوحة المصدر والمجتمع. هذا لا يعني التخلي عنه. ما زال المساهمون يضيفون إصلاحات إلى الفرع الافتراضي، والمستودع ليس مؤرشفًا. لكنه لا يعني وجود زخم أيضًا، كما أن الغلاف البرمجي بلغة Python rpa على PyPI يتأخر بسنوات عن سجل commit. اختر TagUI لمهمة يمكنك تحمل إبقائها ثابتة، لا لمنصة تخطط لتوسيعها طوال ثلاث سنوات.

OpenRPA خيار أصعب. لديه ميزات تنسيق حقيقية تحت MPL-2.0، لكن آخر commit للشيفرة وأحدث إصدار موسوم له يعودان كلاهما إلى يونيو 2025، والنشاط الوحيد في المستودع منذ ذلك الحين هو فروع آلية لتحديث التبعيات. هذا ليس تخليًا عن المشروع، إذ لم تتم أرشفة أي شيء، لكن لم يُطرح أي إصدار جديد أيضًا. وازن هذه الفجوة مع المدة التي تحتاج إلى استمرار عمل الروبوتات خلالها.

متى تكون أداة RPA مخصصة هي الإجابة الخاطئة

جاءت أقوى حجة ضد كل ما سبق من شخص يمارس هذا العمل. في نقاش على r/selfhosted بدأه مشغل يحاول التخلص من عقد RPA تجاري، يدعو أحد الردود إلى استخدام Python مع إطار أتمتة مثل Selenium بدلًا منه. جهد أكبر في التطوير، وأعطال أقل بعد بنائه، وتكلفة ملكية مستمرة أقل من برنامج RPA الذي استخدمه صاحب التعليق. ويوافقه معلّق آخر في النقاش نفسه بشكل مستقل.

المعيار الفاصل هو الصيانة. إذا كانت المهمة ستعمل سنوات، وكان حجم العمل كبيرًا، وكنت أنت أو أحد أفراد فريقك تستطيعون الحفاظ على قاعدة شيفرة صغيرة، فاكتب الشيفرة. يكلف Selenium وPlaywright أكثر في اليوم الأول وأقل في اليوم الأربعمائة، لأن النص البرمجي الذي كتبته يتعطل بطرق تستطيع فهمها. إذا كان أفق المهمة أشهرًا، أو لم يكن أحد في الفريق يكتب الشيفرة، فإن مسار أداة RPA الأقصر للوصول إلى روبوت يعمل يستحق هشاشتها.

ناتج تسجيل الإجراءات هو الجزء الذي يتقادم بأسوأ شكل. يرتبط النص البرمجي المولد من مراقبة نقراتك بتخطيط الواجهة الذي سُجل عليه، ولذلك تتسبب صفحة أعيد تصميمها أو زر نُقل من مكانه في تعطله بطريقة نادرًا ما تشرحها رسالة الخطأ. ويذهب التشكيك في هذه الفئة أبعد من ذلك في بعض المواضع: يصف أحد المعلقين في نقاش على r/rpa عن الخيارات مفتوحة المصدر تقنية RPA بأنها نصوص برمجية معاد تغليفها وتباع لمديرين غير تقنيين، وهو وصف لا يفتقر إلى الإنصاف إذا كانت المهمة ضيقة بما يكفي.

هناك أيضًا خطأ في اختيار الفئة يستحق اكتشافه مبكرًا. إذا كانت الأنظمة التي تربطها توفر API أو webhooks، فأنت لا تحتاج إلى RPA أصلًا. تقود RPA واجهة مستخدم لعدم وجود مدخل آخر، بينما تستدعي أتمتة سير العمل المدخل مباشرة، ما يجعل تطويرها أسرع وأقل هشاشة بكثير. تلك مجموعة أدوات أخرى لها منحنى تكلفة خاص بها، وأول ما ينبغي حسمه هو ترخيص n8n وتكلفة استضافته ذاتيًا. تتوفر n8n وNode-RED وApache Airflow وKestra وDagu كلها كتطبيقات تثبت بنقرة واحدة في متجرنا إذا أردت تشغيل أحدها اليوم.

يعلن موقع UI.Vision الحالي عن تكامل مع Anthropic Computer Use، لذا بدأت هذه الفئة بالفعل تستوعب وكلاء يقودون الشاشة بالاستدلال بشأنها، لا بمطابقة صور محفوظة.

الأسئلة الشائعة