Open Interpreter

أداة Open Interpreter هي أداة سطر أوامر مجانية ومفتوحة المصدر أنشأها Killian Lucas، وتمنح النماذج اللغوية الكبيرة واجهة لغة طبيعية للتحكم في حاسوبك المحلي. أُصدرت الأداة في أغسطس 2023 بموجب ترخيص AGPL-3.0، وتعمل من خلال تزويد أي نموذج لغوي كبير (LLM) تتصل به بوظيفة exec(): حيث يكتب النموذج الكود، ويعرضه عليك للموافقة، ثم يُشغله على جهازك، ويتلقى المخرجات، ويكرر العملية حتى تكتمل المهمة. لا يوجد وسيط سحابي، ولا حدود للرفع، ولا قيود على وقت التشغيل.

يغطي سير العمل الأساسي أوامر Python وJavaScript وshell. يمكنك الاتصال بالنموذج اللغوي المفضل لديك: GPT-4o من OpenAI (الافتراضي)، أو Anthropic Claude، أو نموذج يعمل محلياً عبر Ollama أو LiteLLM. يضيف وضع interpreter --os الذي تم تقديمه في الإصدار v0.4.0 إمكانية قراءة الشاشة والتحكم في الماوس/لوحة المفاتيح بدعم من واجهة برمجة تطبيقات استخدام الكمبيوتر من Anthropic، مما يوسع قدرات الوكيل من مهام كتابة السكربتات إلى الأتمتة الرسومية الكاملة لسطح المكتب. يتم التثبيت بأمر pip واحد؛ وتبدأ المحادثة بكتابة interpreter في سطر الأوامر (terminal).

ما الذي تفعله أداة Open Interpreter فعلياً في أبريل 2026

الإصدار المستقر الحالي هو 0.4.3، والذي تم إصداره في أكتوبر 2024. يتم تثبيت المشروع عبر pip install open-interpreter أو uv tool install open-interpreter وقد حصد أكثر من 63,000 نجمة على GitHub، مما يجعله أحد أكثر مشاريع وكلاء الذكاء الاصطناعي مفتوحة المصدر حصولاً على النجوم.

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

بيئات التعليمات البرمجية المدعومة افتراضياً هي: Python وJavaScript وShell (سواء bash أو PowerShell حسب نظام التشغيل) وHTML. يتم إعلام النموذج اللغوي بنظام التشغيل المضيف، لذلك يكتب AppleScript على macOS، وPowerShell على Windows، وbash على Linux دون الحاجة إلى تكوين من المستخدم. الوصول إلى الملفات غير مقيد: يمكن للوكيل قراءة وكتابة ونقل وحذف الملفات في أي مكان على نظامك يمكن لحساب المستخدم الخاص بك الوصول إليه.

يمثل وضع التحكم في الكمبيوتر --os التوسع الأكثر أهمية في القدرات منذ الإطلاق. في هذا الوضع، يمكن لأداة Open Interpreter التقاط لقطات شاشة، وتحريك الماوس، وكتابة ضغطات المفاتيح، والتفاعل مع أي تطبيق مرئي على الشاشة. يتيح ذلك أتمتة برامج سطح المكتب بشكل يشبه الأوامر الصوتية دون الحاجة إلى واجهة برمجة تطبيقات (API) للبرمجة النصية.

مرونة الواجهة الخلفية (Backend) هي نقطة قوة حقيقية. يقوم المستخدمون الذين يتعاملون مع أعباء عمل حساسة للخصوصية بتوجيه كل شيء عبر Ollama، مما يحافظ على كل رمز (token) على أجهزتهم الخاصة. ويستخدم آخرون LiteLLM للاتصال بأي نقطة نهاية متوافقة مع OpenAI. تعتمد جودة المخرجات بشكل كبير على اختيار النموذج: ينتج GPT-4o وClaude أكواداً موثوقة مع دورات تصحيح أخطاء قليلة؛ بينما تتطلب النماذج المحلية الأصغر غالباً المزيد من التكرارات والتدخل اليدوي.

"إنها في الأساس تنفيذ محلي ومفتوح المصدر لأداة Code Interpreter من OpenAI، ولكن بدون قيود على حجم الملف، أو مهلات وقت التشغيل، أو الوصول إلى الويب." - killianlucas (Killian Lucas)، Hacker News Show HN، 30 أغسطس 2023

موقع Open Interpreter مقارنةً بـ Cline وAider

تعالج أدوات Open Interpreter وCline وAider مشكلات متقاربة باستخدام نماذج تنفيذ مختلفة جوهرياً. إن فهم الآلية التي تعمل بها كل أداة يحدد الأداة التي تناسب سير عملك.

Open Interpreter مقابل Cline: تعيش أداة Cline داخل VS Code كإضافة. حلقتها الأساسية هي القراءة-المقارنة-التعديل-الاعتماد (read-diff-edit-commit): فهي تفهم بنية ملفات مشروعك، وتقترح التغييرات كفروقات (diffs)، وتكتب مباشرة في ملفات المصدر الحالية. ليس لدى Open Interpreter أي اعتماد على بيئة التطوير المتكاملة (IDE) ولا وعي بقاعدة التعليمات البرمجية على مستوى المشروع. إنها تعمل من أي سطر أوامر (terminal) على أي دليل وحلقتها الأساسية هي كتابة الكود-التنفيذ-المراقبة. Cline هو وكيل لتحرير الأكواد. بينما Open Interpreter هو وكيل لتنفيذ الأكواد. أطلقت Cline وكلاء فرعيين أصليين في فبراير 2026 مع نوافذ سياق متوازية لسير العمل متعدد الخيوط؛ بينما تعمل Open Interpreter بخيط واحد. إذا كانت مهمتك هي تعديل قاعدة تعليمات برمجية حالية، فإن Cline تتفوق في السياق. أما إذا كانت مهمتك هي تشغيل مسار بيانات أو أتمتة عملية نظام، فإن Open Interpreter هي الأداة المباشرة.

Open Interpreter مقابل Aider: أداة Aider هي أيضاً واجهة سطر أوامر (CLI)، مما يجعل المقارنة أقرب ظاهرياً. يكمن الاختلاف في التركيز المعماري. تم بناء Aider حول git: فهي تتعامل مع كل تعديل للذكاء الاصطناعي كعملية اعتماد (commit)، وتُنشئ فروقات منظمة (diffs) للملفات الحالية، وتبني خريطة مستودع (repo-map) لقاعدة التعليمات البرمجية بأكملها لمنح النموذج اللغوي سياقاً عميقاً. لا تفعل Open Interpreter أياً من هذا. فهي لا ترسم خرائط للمستودعات، ولا تُنشئ فروقات، ولا تقوم بعمليات اعتماد. تم تصميم Aider خصيصاً لإعادة الهيكلة (refactoring)، وتنفيذ الميزات في المشاريع الحالية، والعمل على الأكواد بمستوى طلبات السحب (PR). بينما تم تصميم Open Interpreter خصيصاً للسكربتات لمرة واحدة، وتحليل البيانات، وأتمتة الملفات، وبرمجة النظام حيث لا توجد حاجة لفهم قاعدة تعليمات برمجية حالية.

Open Interpreter مقابل Devin: تعمل أداة Devin من Cognition في بيئة سحابية معزولة بالكامل (sandboxed) مع متصفحها الخاص وبيئة التطوير المتكاملة (IDE) وسطر الأوامر. وهي تعمل بشكل مستقل على مستوى المهمة: التفكيك، والتنفيذ، والتحقق، دون الحاجة إلى موافقة على كل خطوة. تعمل Open Interpreter على جهازك، وتتطلب موافقتك قبل كل كتلة كود، ولا تحتوي على بيئة معزولة. انخفض سعر Devin من 500 دولار/شهرياً إلى حوالي 20 دولاراً/شهرياً للخطة الأساسية بالإضافة إلى وحدات الحوسبة، مما يجعلها في المتناول ولكنها تظل خدمة برمجيات كخدمة (SaaS) احتكارية. بينما Open Interpreter مرخصة بموجب AGPL ومجانية. يعتمد الاختيار الصحيح على احتياجات العزل: Devin أكثر أماناً بحكم تصميمها؛ بينما Open Interpreter أرخص وأكثر شفافية.

كيف يبدو واقع حلقة الوكيل

الاستخدام اليومي لأداة Open Interpreter هو عملية تكرارية تستفيد من فهم إيقاعها. عادةً ما يكتمل الطلب المحدد جيداً ("تحميل sales.csv، التجميع حسب الشهر، حساب متوسط قيمة الطلب، حفظ مخطط شريطي باسم chart.png") في كتلتين إلى أربع كتل برمجية. تستورد الكتلة الأولى المكتبات وتحمل البيانات. إذا كان هناك خطأ في الاستيراد، يراه النموذج اللغوي ويكتب كتلة تصحيحية. تستمر الحلقة حتى يتم تأكيد المخرجات. بالنسبة لمعظم مهام تحليل البيانات، يبدو هذا مباشراً بشكل مثير للإعجاب.

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

تكاليف الرموز (Tokens) حقيقية ومتغيرة. قد تستهلك عملية ملف بسيطة بضع مئات من الرموز. بينما يمكن أن تتضخم حلقة تصحيح الأخطاء التكرارية لسكربت فاشل إلى عشرات الآلاف، خاصة مع نموذج مسهب. أبلغ المستخدمون الذين يقومون بتشغيل GPT-4o في مهام معقدة عن فواتير غير متوقعة لواجهة برمجة التطبيقات (API) بسبب تصحيح الأخطاء التكراري. يتضمن المشروع أمراً تجريبياً %tokens لتقدير التكلفة قبل التشغيل.

يغير توجيه النماذج المحلية من الجانب الاقتصادي ولكنه ليس مجانياً بالكامل. فالتوجيه عبر Ollama على وحدة معالجة رسومات (GPU) استهلاكية يلغي تكاليف واجهة برمجة التطبيقات ولكنه يُحدث تبايناً في الجودة. غالباً ما تنتج النماذج الأصغر (7B-13B معلمة) أكواداً صحيحة نحوياً ولكنها معيبة منطقياً، مما يؤدي إلى دورات تصحيح أخطاء أطول تستهلك المزيد من انتباه المستخدم.

"نظراً لأن الكود يتم تشغيله مباشرة على جهازك، فهناك العديد من الطرق التي قد تسير بها الأمور بشكل خاطئ إذا لم تقم بمراجعة الكود المُنشأ بعناية." - Simon Willison، موقع simonwillison.net، 24 نوفمبر 2024

نموذج الأمان هو نقطة نقاش حقيقية. تحمي مطالبة التأكيد الافتراضية معظم المستخدمين في معظم الأوقات. يستخدم "الوضع الآمن" التجريبي التحليل الثابت semgrep للإبلاغ عن الأنماط التي يحتمل أن تكون خطرة قبل التنفيذ. قام Simon Willison، عند مراجعته للأداة في نوفمبر 2024، بتقييم هذا النهج بشك، مجادلاً بأن العزل الحقيقي القائم على Docker سيكون أكثر قوة. بالنسبة للمستخدمين المستعدين للوثوق بنموذج لغوي يتمتع بوصول محلي كامل، تعمل الأداة بسلاسة. أما بالنسبة للمستخدمين الذين يريدون عزلاً تم التحقق منه، فإن وضع Docker موجود كخيار تجريبي ولكنه ليس الافتراضي.

تم الإعلان عن منتج الأجهزة 01 Light، وهو جهاز صوتي ESP32 مدعوم من Kickstarter مصمم ليكون وحدة تحكم فعلية بالذكاء الاصطناعي، في أوائل عام 2024 ومثل محاولة Open Interpreter لتصبح منصة أجهزة. في 9 سبتمبر 2024، نشر Killian Lucas مقالاً بعنوان "كان يجب أن يكون تطبيقاً"، معلناً أنه تم استرداد جميع طلبات 01 Light وإلغاء التصنيع. خلص الفريق إلى أن تطبيق الهاتف الذكي يقدم أداءً أفضل على الأجهزة التي يمتلكها المستخدمون بالفعل. تم إطلاق تطبيق 01 App المجاني في وقت واحد لأنظمة iOS وAndroid، مما يوفر نفس الواجهة الصوتية (اضغط للتحدث) للتحكم في أجهزة سطح المكتب. أوضح هذا التحول كلاً من قدرة المشروع على التكيف والتحدي الأساسي المتمثل في فريق صغير (خمسة أشخاص في ذلك الوقت) يمتد عبر مجالات البرمجيات والأجهزة.

لمن تم بناء Open Interpreter

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

لدى المستخدمين الذين يضعون الخصوصية في المقام الأول سبب وجيه لاختيار Open Interpreter بدلاً من البدائل المستضافة. مع توجيه النماذج المحلية، لا يغادر وصف المهمة، والكود المُنشأ، والبيانات المعالجة جهاز المستخدم أبداً. هذا يهم أي شخص يعمل مع ملفات حساسة، أو بيانات ملكية، أو في الصناعات الخاضعة للتنظيم حيث يتم تقييد النقل السحابي.

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

ما لا تقدمه Open Interpreter

أداة Open Interpreter ليست وكيلاً لتحرير الأكواد على دراية بقاعدة التعليمات البرمجية. إذا كنت بحاجة إلى إعادة هيكلة مشروع حالي، أو تنفيذ ميزة عبر ملفات متعددة، أو العمل ضمن بنية برمجية محددة، فإن Aider أو Cline تلبي هذه الاحتياجات بآليات سياق أفضل. لا تحتوي Open Interpreter على خريطة مستودع، ولا إنشاء فروقات، ولا تكامل تلقائي مع git. يتطلب استخدامها على قاعدة تعليمات برمجية حالية إدخال محتويات الملفات ذات الصلة يدوياً في المحادثة.

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

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

واعتباراً من أبريل 2026، أصبح مسار الصيانة مصدر قلق عملي. كان آخر إصدار مستقر على PyPI في أكتوبر 2024. تم إغلاق مشكلة GitHub رقم 1627، التي فُتحت في مايو 2025 بعنوان "هل هذا المشروع ميت؟"، كـ "غير مخطط له" دون رد عام. يستمر نشاط الاعتماد (Commit) ولكن وتيرة الإصدار تباطأت بشكل كبير عن فترة 2023-2024 السريعة. يجب على المستخدمين الذين يبنون سير عمل يعتمد على Open Interpreter أن يأخذوا في الاعتبار أن صيانة التبعيات قد تتطلب تصحيحاً ذاتياً.