🤖 AI

Terminal Agents Suffice for Enterprise Automation

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

المؤلفون الأصليون: Patrice Bechard, Orlando Marquez Ayala, Emily Chen, Jordan Skelton, Sagar Davasam, Srinivas Sunkara, Vikas Yadav, Sai Rajeswar

نُشر 2026-04-02

📖 4 دقيقة قراءة☕ قراءة في استراحة قهوة

CC BY 4.0

المؤلفون الأصليون: Patrice Bechard, Orlando Marquez Ayala, Emily Chen, Jordan Skelton, Sagar Davasam, Srinivas Sunkara, Vikas Yadav, Sai Rajeswar

البحث الأصلي مرخَّص بموجب CC BY 4.0 (http://creativecommons.org/licenses/by/4.0/). ✨ هذا شرح مولَّده بالذكاء الاصطناعي للبحث أدناه. لم يكتبه المؤلفون ولم يصادقوا عليه. وللتحقق من الدقة التقنية، يرجى الرجوع إلى البحث الأصلي. اقرأ إخلاء المسؤولية الكامل

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

اختبر الباحثون ثلاث طرق مختلفة لإعطاء التعليمات للمساعد:

1. نهج "السائح" (وكلاء واجهة المستخدم الرسومية/الويب - GUI/Web Agents)

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

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

2. نههج "القائمة" (الوكلاء المعززون بالأدوات/MCP Agents)

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

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

3. نهج "المفتاح الرئيسي" (وكلاء الطرفية - Terminal Agents)

الاستعارة: هذا هو نجم العرض. تخيل إعطاء المساعد مفتاحًا رئيسيًا ومخططًا (Blueprint) لسباكة وكهرباء المبنى. بدلاً من التجول والضغط على الأبواب، يذهب مباشرة إلى الأنابيب والأسلاك.

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

الاكتشاف الكبير

أجرى الباحثون آلاف الاختبارات عبر ثلاثة أنظمة مؤسسية كبرى (ServiceNow وGitLab وERPNext). وإليك ما وجدوه:

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

الخلاصة

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

يقول هذا البحث: لا، لست بحاجة إلى الأشياء الفخمة.

إذا أعطيت ذكاءً اصطناعيًا ذكيًا خطًا مباشرًا إلى "محرك" النظام (API) وطرفية (Terminal) لكتابة الأوامر، فيمكنه القيام بالمهمة بشكل أسرع، وأرخص، وأكثر موثوقية من البدائل المرئية والمقيدة بالقوائم والمعقدة.

باختة القول: لا تبنِ روبوتًا يتجول في المكتب وينقر على الأزرار. أعطِ الروبوت خط هاتف مباشر إلى المدير واتركه يبدأ العمل مباشرة.

إليك ملخص تقني مفصل لورقة البحث بعنوان "الوكلاء الطرفيون يكفون لأتمتة المؤسسات" (Terminal Agents Suffice for Enterprise Automation).

1. بيان المشكلة

تتناول الورقة التوجه المتزايد لاستخدام وكلاء النماذج اللغوية الكبيرة (LLM) لأتمتة المؤسسات. تندرج النهج الحالية عموماً تحت فئتين:

الوكلاء المعتمدون على واجهة المستخدم الرسومية (GUI-driven Agents): وهم الوكلاء الذين يتفاعلون مع واجهات الويب عبر لقطات الشاشة وعناصر الـ DOM (مثل النقر على الأزرار، والتنقل في القوائم).
الوكلاء المعززون بالأدوات (Tool-Augmented Agents): وهم الوكلاء الذين يتفاعلون مع مخططات واجهة برمجة تطبيقات (API) منسقة عبر أطر عمل مثل بروتوكول سياق النموذج (MCP).

يجادل المؤلفون بأن هذه النهج تفرض تعقيداً غير ضروري، وأعباء تشغيلية، وتكاليف مرتفعة. فالوكلاء المعتمدون على واجهة المستخدم الرسومية يعانون من الهشاشة بسبب تغيرات الواجهة والتكلفة العالية للرموز (tokens) لمعالجة البيانات المرئية. أما الوكلاء المعززون بالأدوات، فغالباً ما يتقيدون بمدى تعبيرية سجلات الأدوات المحددة مسبقاً، مما يقيدهم بعمليات معينة ويمنعهم من الاستكشاف الديناميكي. السؤال البحثي الجوهري هو: هل طبقات التجريد المعقدة (واجهة المستخدم الرسومية أو الأدوات المنسقة) ضرورية لأتمتة المؤسسات، أم أن وكيل برمجي بسيط يعتمد على الطرفية (Terminal) ويتفاعل مباشرة مع واجهات برمجة التطبيقات (APIs) قد يكون كافياً؟

2. المنهجية

2.1 الحل المقترح: StarShell

يقدم المؤلفون StarShell، وهو وكيل برمجي بسيط يعتمد على الطرفية.

نمط التفاعل: يعمل الوكيل عبر طرفية (Terminal) ونظام ملفات. لا يستخدم مخططات أدوات محددة مسبقاً أو تفاعلات واجهة مستخدم رسومية.
الآلية: يقوم بكتابة وتنفيذ الكود (بشكل أساسي أوامر curl وسكريبتات Python) للتفاعل مباشرة مع واجهات برمجة تطبيقات المنصات (REST APIs).
القدرات: يمكنه اكتشاف نقاط نهاية الـ API ديناميكياً، وفحص الوثائق، ومعالجة البيانات، وإنشاء "مهارات" قابلة لإعادة الاستخدام (سكريبتات أو ملاحظات) تُخزن في نظام الملفات للحفاظ على المعرفة عبر المهام.
البنية: يعمل الوكيل في حلقة نمط REPL: استدلال $\leftarrow$ تنفيذ $\leftarrow$ ملاحظة $\leftarrow$ تصحيح.

2.2 الإعداد التجريبي

لاختبار الفرضية، أنشأ المؤلفون معياراً موحداً عبر ثلاث منصات مؤسسية متنوعة وذات مستوى إنتاجي:

ServiceNow: إدارة خدمات تكنولوجيا المعلومات (330 مهمة).
GitLab: دورة حياة تطوير البرمجيات (192 مهمة).
ERPNext: تخطيط موارد المؤسسات (207 مهام).

نماذج المقارنة:
تقارن الدراسة ثلاثة أنواع من الوكلاء باستخدام نفس النماذج اللغوية الأساسية (Claude Sonnet 4.6, Claude Opus 4.6, GPT-5.4 Thinking, Gemini 3.1 Pro):

وكلاء الويب (Web Agents): يتفاعلون عبر Playwright (أتمتة المتصفح).
وكلاء MCP: يتفاعلون عبر سجلات أدوات منسقة (خوادم MCP الخاصة بـ ServiceNow، وGitLab، وERPNext).
الوكلاء الطرفيون (StarShell): يتفاعلون مباشرة عبر استدعاءات الـ API.

المقاييس:

معدل النجاح (SR): النسبة المئوية للمهام المكتملة بنجاح بناءً على التحقق من الحالة.
التكلفة: تكلفة الاستدلال (استخدام الرموز/tokens) كمعيار رئيسي للكفاءة.
مقاييس إضافية: عدد استدعاءات الأدوات ووقت التنفيذ (wall-clock time).

3. المساهمات الرئيسية

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

4. النتائج الرئيسية

4.1 مقارنة الأداء

الطرفي مقابل الويب: حقق الوكلاء الطرفيون معدلات نجاح مماثلة أو أعلى من وكلاء الويب (مثلاً: 73.6% مقابل 72.4% في ServiceNow باستخدام Claude Sonnet) ولكن بتكلفة أقل بكfold. كانت تكلفة وكلاء الويب أعلى بمقدار 4 إلى 9 أضعاف بسبب العبء الناتج عن معالجة لقطات الشاشة وأشجار الـ DOM.
الطرفي مقابل MCP: تفوق الوكلاء الطرفيون بشكل كبير على وكلاء MCP.
- ServiceNow: الطرفي (73.6%) مقابل MCP (11.5%). فشل وكلاء MCP لأن العديد من المهام تطلبت عمليات غير معروضة في سجل الأدوات المنسق.
- GitLab: الطرفي (76.5%) مقابل MCP (45.2%).
- ERPNext: الطرفي (67.6%) مقابل MCP (55.6%).
- رؤية: حتى عندما توجد أدوات MCP، فإن واجهاتها غالباً ما تكون جامدة للغاية (على سبيل المثال، تفتقر إلى حقول محددة)، بينما يمكن للوكلاء الطرفيين بناء حمولات (payloads) عشوائية.

4.2 كفاءة التكلفة

كان الوكلاء الطرفيون هم الأكثر كفاءة في التكلفة باستمرار. على سبيل المثال، في ServiceNow باستخدام Gemini 3.1 Pro، بلغت تكلفة الوكيل الطرفي 0.09 دولار لكل مهمة، مقارنة بـ 0.68 دولار لوكلاء الويب و 0.10 دولار لوكلاء MCP (رغم أن تكلفة MCP كانت منخفضة، إلا أن معدل نجاحها كان ضئيلاً جداً).
ينبع التفوق في التكلفة من تجنب معالجة البيانات المرئية كثيفة الرموز وتقليل عدد خطوات التفاعل المطلوبة لتكوين استدعاءات API معقدة.

4.3 تأثير الوثائق والمهارات

الوثائق: لم تؤدِ إمكانية الوصول إلى الوثائق الرسمية إلى تحسين الأداء بشكل عام. في ServiceNow، أدت الوثائق أحياناً إلى تراجع الأداء لأنها كانت تركز على واجهة المستخدم وقادت الوكلاء إلى مسارات API معقدة ومتعددة الخطوات (مثل add_to_cart ثم checkout) في حين وجد مسار API مباشر أبسط (order_now).
المهارات (الذاكرة): أدى السماح للوكلاء بتخزين واسترجاع "المهارات" (الإجراءات) إلى تحسين الأداء بشكل كبير، خاصة في المنصات الأقل شهرة مثل ERPNext (زيادة بنسبة 5.8% في معدل النجاح) وقلل التكاليف بنسبة ~43% في ServiceNow. وهذا يؤكد أن الذاكرة المستمرة تساعد في تقليل تكلفة استكشاف الـ API.

5. الأهمية والخاتمة

الاستنتاج الرئيسي:
تتحدى الورقة الافتراض السائد بأن أتمتة المؤسسات تتطلب مجموعات أدوات (stacks) أكثر تطوراً (واجهات مستخدم رسومية أو تنسيق أدوات معقد). بدلاً من ذلك، تجادل الورقة بأن النماذج التأسيسية القوية المدمجة مع الواجهات البرمجية المباشرة (طرفية + API) كافية لفئة واسعة من مهام المؤسسات الواقعية.

الآثار المترتبة:

البساطة فوق التجريد: يجب على المؤسسات إعطاء الأولوية لعرض واجهات برمجة تطبيقات (APIs) مستقرة وتعبيرية، بدلاً من بناء طبقات تجريد معقدة (مثل سجلات MCP) التي قد تحد من مرونة الوكيل.
خفض التكاليف: يمكن أن يؤدي الانتقال من الوكلاء المعتمدين على واجهة المستخدم الرسومية أو المعززين بالأدوات بكثافة إلى وكلاء برمجيين طرفيين إلى تقليل تكاليف الأتمتة بمقدار رتبة عشرية كاملة دون التضحភាព بالموثوقية.
الاتجاه المستقبلي: بينما يعد الوكلاء الطرفيون فعالين للغاية، تشير الورقة إلى قيود في المهام التي تتطلب تفاعلات خاصة بالمتصفح (مثل انتحال الشخصية أو قراءة الرسوم البيانية المُصيرة). ويُقترح نهج هجين (طرفي + متصفح) للحالات الاستثنائية، لكن الطرفية تظل هي الواجهة الأساسية والأكثر كفاءة.

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

باختصار، تقدم الورقة دليلاً قوياً على أنه بالنسبة لأتمتة المؤسسات، فإن "الأقل هو الأكثر": فوكيل برمجي بسيط مع وصول مباشر إلى الـ API يتفوق على الأنظمة المعقدة والمجردة في كل من الفعالية والكفاءة.