منصة تشغيل الوكلاء مقابل إطار عمل الوكلاء: ما الفرق الحقيقي؟

Built for Speed: ~10ms Latency, Even Under Load
Blazingly fast way to build, track and deploy your models!
- Handles 350+ RPS on just 1 vCPU — no tuning needed
- Production-ready with full enterprise support
ما هو إطار عمل الوكيل؟
يمنحك إطار عمل الوكيل اللبنات الأساسية لتجميع الوكيل. فهو يوفر الهيكل والتجريدات، بينما توفر أنت المنطق الذي يربطها ببعضها البعض.
عادةً ما يوفر لك إطار العمل ما يلي:
- طريقة لتحديد الخطوات. عُقد في رسم بياني، أو أدوار في فريق، أو وظائف في سلسلة.
- طريقة لربطها ببعضها. حواف، وشروط، وعمليات تسليم، وتسلسلات.
- نموذج حالة. عادةً ما يكون مخططاً مكتوباً تقوم بتعريفه، ويتم تمريره عبر كل خطوة.
- ارتباطات النماذج. محولات برمجية ليعمل الكود نفسه مع مزودين مختلفين.
- التنفيذ. مشغل يتتبع هيكلك البرمجي حتى يصل إلى نهايته.
يُعد LangGraph أوضح مثال على ذلك؛ حيث تقوم بتعريف العُقد والحواف ومخطط الحالة المشترك، ويقوم هو بالتنفيذ حتى تُرجع إحدى العُقد قيمة END. يتخذ CrewAI شكلاً مختلفاً مع نفس الفكرة: تعريف الوكلاء بأدوار ومهام، ثم تشغيلهم بشكل تسلسلي أو هرمي. ويقوم إطار عمل وكيل مايكروسوفت (Microsoft Agent Framework)، الذي دمج AutoGen وSemantic Kernel في إصدار 1.0 في أبريل 2026، بنفس الشيء لكل من .NET وPython.
يعمل إطار العمل بشكل أفضل عندما:
- يكون لسير عملك شكل محدد، ويُعد الانحراف عنه مشكلة في صحة التنفيذ.
- تحتاج إلى تفرع شرطي، أو توزيع مهام متوازٍ، أو حلقات تكرارية تعود إلى مراحل سابقة.
- تتطلب الخطوات المختلفة نماذج أو مطالبات أو مجموعات أدوات مختلفة.
- أنت تريد أن يكون مسار التنفيذ واضحاً في الكود، لا أن يتم استنتاجه من الأوامر النصية
- يجب أن يوافق الإنسان على خطوة محددة في سير العمل
ما هو إطار عمل الوكيل (Agent Harness)؟
إن إطار عمل الوكيل هو طبقة وقت التشغيل المحيطة بنموذج لغوي ضخم (LLM) والتي تحوله إلى وكيل موثوق يعمل لفترات طويلة. إنه ليس مجرد أدوات أولية لبناء حلقة عمل، بل هو الحلقة نفسها، جاهزة ومبنية مسبقاً.
النموذج بمفرده قادر على التفكير لكنه لا يستطيع التنفيذ. إذا أعطيته مهمة، ستحصل على خطة لا أكثر. فهو لا يستطيع فتح ملف، أو استدعاء واجهة برمجة تطبيقات (API)، أو تشغيل الكود الذي كتبه للتو، أو تذكر القرارات التي اتخذها قبل ثلاث خطوات. يعمل إطار العمل على سد هذه الفجوة باستمرار طوال فترة التشغيل.
يتولى إطار العمل النموذجي المهام التالية:
- حلقة التنفيذ. التخطيط، استدعاء الأداة، قراءة النتيجة، تحديد الخطوة التالية، ثم التكرار.
- إدارة السياق. الضغط، التحميل المؤجل للأدوات، وتفريغ استجابات الأدوات الضخمة، لضمان عدم تجاوز نافذة السياق أو الميزانية أثناء التشغيل الطويل.
- البيئة المعزولة (Sandboxing). تنفيذ معزول للكود والملفات وأوامر النظام.
- الموافقات. الإيقاف المؤقت قبل استدعاء الأدوات ذات التأثير التدميري وانتظار تدخل بشري.
- حالة الجلسة. الاستمرارية عبر إعادة الاتصال، وإعادة التشغيل، والمحادثات متعددة الجولات.
تعد TrueForge وClaude Agent SDK وopencode وPi وOpenHands كلها أمثلة على أطر عمل الوكلاء. أنت توفر الأدوات والتعليمات، ولا تحتاج لبناء حلقة العمل بنفسك.
يعمل إطار العمل بأفضل كفاءة عندما:
- المسار يُكتشف ولا يُصمم، والخطوة التالية تعتمد على ما كشفت عنه الخطوة السابقة.
- أنت بحاجة إلى وكيل يعمل هذا الأسبوع، لا إلى بنية سير عمل.
- تستغرق عمليات التشغيل وقتاً طويلاً لدرجة أن إدارة السياق تصبح هي نقطة الفشل.
- ينفذ الوكيل تعليمات برمجية أو يصل إلى نظام ملفات، لذا فهو يحتاج إلى العزل.
- تفضل ضبط المطالبات والأدوات على صيانة آلة الحالة.
الاختلافات الجوهرية
كلاهما يوصلك إلى وكيل يعمل، لكنهما يختلفان في ما تتحمل أنت مسؤوليته.
سؤالان يوضحان الفرق بينهما
صفحات المنتجات لن تحسم هذا الأمر، لذا استخدم هذين السؤالين بدلاً منها.
هل تكتب حلقة العمل بنفسك؟
إذا كنت تحدد المسارات أو الشروط أو تسلسل الخطوات، فهذا إطار عمل. أما إذا كنت توفر الأدوات والتعليمات وتضغط على زر البدء، فهذا نظام تشغيل (Harness).
هل يتولى النظام إدارة السياق نيابة عنك؟
تمنحك أطر العمل عادةً مخطط الحالة وتترك لك حرية تحديد ما يدخل في نافذة السياق. أما أنظمة التشغيل (Harnesses) فيجب أن تتولى إدارته بنفسها، لأنها هي من تتحكم في حلقة العمل، وبدون ذلك ستمتلئ النافذة في العمليات الطويلة وتتوقف عن الاستجابة. إذا لم تشر الوثائق إلى تقنيات الضغط أو التفريغ أو التحميل المؤجل للأدوات، فأنت على الأرجح تتعامل مع إطار عمل.
لماذا يحدث خلط بين هذه المصطلحات؟
ثلاثة أسباب، وأولها هو الأهم.
بعض المنتجات تجمع بين الأمرين فعلياً. deepagents هو نظام تشغيل من LangChain مبني فوق LangGraph، وهو إطار عمل. يوفر النظام حلقة عمل متكاملة تتضمن التخطيط، ونظام ملفات افتراضي، ووكلاء فرعيين، وذاكرة، لذا فهو يعمل كنظام تشغيل. أما في جوهره، فهو عبارة عن رسم بياني. ويقوم Microsoft Agent Framework بشيء مشابه، حيث يوفر كلاً من أدوات التنسيق وطبقة نظام تشغيل ذات رؤية محددة فوقها.
تتبع جهود التسويق حجم عمليات البحث. ظل مصطلح "إطار العمل" (Framework) هو المصطلح السائد لسنوات ويحظى بحجم بحث أكبر. أما مصطلح "المُسخِّر" (Harness) فلم يبدأ في الظهور إلا في عام 2026. ولا تزال العديد من أدوات "المُسخِّر" تطلق على نفسها اسم "إطارات عمل" لأن هذه هي الكلمة التي يستخدمها المشترون في عمليات البحث.
تتغير الحدود الفاصلة بين هذه المصطلحات مع نضوج المنتجات. تضيف إطارات العمل إعدادات افتراضية محددة مسبقاً وتبدأ في محاكاة أداء "المُسخِّرات". بينما توفر "المُسخِّرات" نقاط ربط (hooks) وتبدأ في محاكاة أداء إطارات العمل. إن قيام مايكروسوفت بطرح طبقة "مُسخِّر الوكلاء" (Agent Harness) داخل "إطار عمل الوكلاء" (Agent Framework) هو تجسيد دقيق لهذا التداخل، وسنشهد المزيد من ذلك مستقبلاً.
لا يعني هذا أن التمييز بينهما عديم الفائدة، بل يعني ببساطة أنه يجب عليك التحقق من السلوك الفعلي بدلاً من الاكتفاء بالمسمى.
هما ليسا متنافيين
الخطأ الذي يقع فيه الكثير من الفرق هو التعامل مع الأمر كخيار بين بديلين. فمعظم أنظمة الإنتاج تستخدم كليهما في طبقات مختلفة.
يتولى "المُسخِّر" إدارة حلقة عمل الوكيل وكل ما يجب تنفيذه في كل دورة. بينما يتولى إطار العمل إدارة التنسيق بين الوكلاء، أو سير العمل الحتمي الذي يعمل ضمنه الوكيل المعتمد على "المُسخِّر". على سبيل المثال: توزيع المهام على خمسة وكلاء، وانتظار اكتمالها جميعاً، ثم تشغيل خطوة التحقق، وبعدها الانتقال للمرحلة التالية. هذه هي وظيفة إطار العمل، ويمكن أن يكون المكون الموجود في كل عقدة عبارة عن "مُسخِّر".
الخطأ يكمن في استخدام إطار عمل لإعادة بناء حلقة عمل موجودة بالفعل. فكتابة مخطط لوكيل مساره مفتوح بطبيعته تعني بناء نسخة أسوأ مما يوفره لك "المُسخِّر" جاهزاً، مع دفع ثمن ذلك في تكاليف الصيانة للأبد. والخطأ المعاكس حقيقي أيضاً: وهو إجبار "المُسخِّر" على اتباع سير عمل امتثال صارم من خلال وصف التسلسل في "موجه" (prompt) وانتظار النتائج.
TrueForge: أفضل "مُسخِّر" للوكلاء لفرق الإنتاج

TrueForge هو "المُسخِّر" المرخص برخصة MIT الذي أطلقناه كمصدر مفتوح في أغسطس 2026، وهو نفس وقت التشغيل الذي يدعم وكيلنا الخاص AskTFY. لقد بنيناه لأننا أردنا سهولة استخدام الوكلاء المدارين دون التنازل عن قرار النموذج لمورد خارجي، ولم يكن هناك أي حل مفتوح المصدر يغطي كافة الجوانب.
يأتي النظام في ثلاثة أجزاء بدلاً من جزء واحد. خادم أساسي يدير الحلقة: البث، وبوابات الموافقة على الإجراءات الحساسة، وتفويض الوكلاء الفرعيين، والضغط، والجلسات التي تستمر بعد إعادة الاتصال. واجهة برمجة تطبيقات HTTP مع حزمة تطوير برمجيات (SDK) بلغة TypeScript (@truefoundry/trueforge-sdk) تمنح كودك البرمجي كل ما يمكن لواجهة المستخدم القيام به. وواجهة مستخدم للدردشة مع حزمة تطوير برمجيات خاصة بها (@truefoundry/trueforge-ui) متاحة للاستخدام كما هي، أو لتعديل مظهرها، أو لتضمينها. هذا الجزء الثالث هو ما يميزه عن معظم الأدوات في هذه القائمة، التي تكتفي بالعمل عبر واجهة الأوامر (terminal).
خيار التصميم الذي يؤثر على فاتورتك أكثر من غيره: يتعامل TrueForge مع بيئة الاختبار (sandbox) كأداة. فهو لا يشغلها إلا عندما يحتاج الوكيل فعلياً إلى تشغيل كود، بدلاً من تغليف الجلسة بأكملها داخل حاوية. خادم واحد يدير العديد من الوكلاء في وقت واحد، وتظل الدورات التي لا تتضمن تشغيل كود منخفضة التكلفة.
ما يضيفه فوق حلقة العمل هو إدارة السياق، لأن هذا هو العامل الحاسم في بقاء التكاليف معقولة خلال فترات التشغيل الطويلة. يعني التحميل المؤجل للأدوات أن مخططات أدوات MCP يتم تحميلها عند الطلب بدلاً من ملء نافذة السياق مسبقاً. يتيح "وضع الكود" للوكيل ربط عدة استدعاءات للأدوات داخل نص برمجي واحد في بيئة الاختبار، بحيث لا يدخل في السياق سوى الملخص المطبوع. يتم كتابة استجابات الأدوات الكبيرة في ملف داخل بيئة الاختبار واستبدالها بمسار ومعاينة. يتم تفعيل الضغط عند وصول طول سياق النموذج إلى 80%، حيث يتم استبدال السجل القديم بملخص منظم. وتعمل الوكلاء الفرعيون بسياق نظيف خاص بهم ولا يعيدون سوى النتيجة.
في اختبار Enterprise-Bench الخاص بـ DevRev، والذي يتضمن 14 مهمة عبر أنظمة مختلفة باستخدام ثلاثة خوادم MCP مع جلسة جديدة في كل مرة وتقييم من نموذج لغوي أعمى، تمكن TrueForge على Opus 4.8 من حل نفس المهام التي حلتها وكلاء Claude المدارة بتكلفة 8.5 دولار لكل تشغيل مقابل 11.8 دولار، وبـ 3.8 مليون رمز (token) مقابل 10 ملايين. عند التبديل إلى GLM-5.2، انخفضت التكلفة إلى 2.9 دولار لكل تشغيل. ومقارنة بـ deepagents على نفس النموذج، فقد استهلك أقل من ربع عدد الرموز.

إنه مرخص برخصة MIT، ونحن نتولى صيانته، ويتم تطويره بشكل مفتوح. تكمن نقاط قوته في تلك الأسطح الثلاثة، والبيئة المعزولة (sandboxing) عند الطلب، والمسار الموثق من npx وصولاً إلى Helm مع Postgres وRedis ونسخ متماثلة وOIDC، بالإضافة إلى أرقام قياسية منشورة يمكنك التحقق منها. نقطة الضعف الواضحة هي حداثة العهد؛ فهو أحدث مشروع هنا، لذا فإن نظام الإضافات التابع لجهات خارجية محدود مقارنة بما يمتلكه opencode.
جربه في 60 ثانية: npx @truefoundry/trueforge أو امنحه نجمة على GitHub.
الأسئلة الشائعة
س: ما هو إطار عمل الوكيل (agent harness)؟
ج: إطار عمل الوكيل هو طبقة وقت التشغيل المحيطة بالنموذج اللغوي الكبير (LLM) التي تحوله إلى وكيل موثوق يعمل لفترات طويلة. يتولى الإطار إدارة حلقة التنفيذ، والتعامل مع إدارة السياق، والبيئة المعزولة، والموافقات، وحالة الجلسة، لأن النموذج بمفرده يمكنه التفكير ولكنه لا يستطيع التصرف أو التنفيذ أو التذكر عبر الجلسات المتتالية.
س: ما الفرق بين بيئة تشغيل الوكيل (agent harness) وإطار عمل الوكيل (agent framework)؟
ج: يوفر لك إطار العمل الأدوات الأساسية لبناء وكيل ويتوقع منك كتابة تدفق التحكم بنفسك. أما بيئة التشغيل فهي نظام جاهز يتضمن حلقة العمل (loop) مكتوبة مسبقاً، لذا تكتفي أنت بتزويدها بالأدوات والتعليمات. إطارات العمل مخصصة لبناء الوكلاء، بينما بيئات التشغيل مخصصة لتشغيلهم.
س: هل LangGraph يعتبر بيئة تشغيل وكيل أم إطار عمل؟
ج: LangGraph هو إطار عمل. أنت تقوم بتعريف العُقد (nodes) والحواف (edges) ومخطط الحالة (state schema)، وهو يتولى تنفيذ الرسم البياني الخاص بك. أما deepagents، المبني على LangGraph، فهو بيئة تشغيل لأنه يوفر حلقة عمل كاملة لا تحتاج لكتابتها. يمكن للمنتج الواحد أن يحتوي على كلا الطبقتين.
س: هل أحتاج إلى كليهما؟
ج: غالباً نعم، ولكن على مستويات مختلفة. استخدم بيئة التشغيل لحلقة عمل الوكيل، وإطار العمل للتنسيق بين الوكلاء أو لسير عمل حتمي يقع الوكيل ضمنه. ما لا يجب عليك فعله هو استخدام إطار عمل لبناء حلقة عمل يدوياً بينما توفرها لك بيئة التشغيل جاهزة.
س: هل يمكنني تشغيل بيئة تشغيل الوكيل في سحابة VPC الخاصة بي أو محلياً (on-prem)؟
ج: نعم، إذا كانت مفتوحة المصدر. يعمل TrueForge من خلال أمر npx محلياً، أو عبر Docker Compose وHelm لعمليات النشر الجماعي مع دعم Postgres وRedis والنسخ المتماثل وتسجيل الدخول عبر OIDC. كما تتوفر نسخة TrueFoundry المُدارة للتشغيل الذاتي، أو محلياً، أو في بيئات معزولة (air-gapped)، أو هجينة، لضمان عدم خروج أي بيانات من نطاقك الخاص.
س: كيف يمكنني إدارة النماذج وخوادم MCP عبر العديد من الوكلاء؟
ج: من خلال طبقة بوابة (gateway). تضع بوابة الذكاء الاصطناعي AI Gateway من TrueFoundry أكثر من 1000 نموذج لغوي كبير خلف واجهة برمجة تطبيقات واحدة متوافقة مع OpenAI، مع زمن انتقال إضافي يبلغ حوالي 3-4 مللي ثانية وقدرة على معالجة أكثر من 350 طلباً في الثانية على وحدة معالجة مركزية افتراضية واحدة، بالإضافة إلى التحكم في الوصول القائم على الأدوار (RBAC)، والميزانيات، وحواجز الحماية، وتدوير بيانات الاعتماد، إلى جانب بوابة MCP للتحكم في الوصول على مستوى الأدوات، وتتبع OpenTelemetry في Grafana أو Datadog أو Prometheus.
قراءات ذات صلة
- أفضل منصات تشغيل الوكلاء (Agent Harness) في عام 2026: مقارنة بين أفضل 5 خيارات: المجال، بمجرد أن تقرر حاجتك إلى منصة تشغيل (harness)
- نقدم لكم TrueForge: منصة تشغيل الوكلاء مفتوحة المصدر التي نعتمد عليها في بيئة الإنتاج: قرارات الهندسة والتصميم
- TrueForge مقابل وكلاء Claude المدارة: تكلفة أقل بنسبة تصل إلى 75%: تأثير طبقة التشغيل على التكلفة
- لماذا يجب أن تكون منصات تشغيل الوكلاء مفتوحة المصدر: الحجج ضد استئجار هذه الطبقة
- كيف يعمل AskTFY الخاص بـ TrueFoundry على TrueForge: وكيل إنتاجي مبني على منصة تشغيل
الخلاصة
باختصار: إطار العمل مخصص لبناء الوكيل، بينما منصة التشغيل مخصصة لتشغيله. إذا وجدت نفسك تكتب حلقة العمل (loop) بنفسك، فقد اخترت إطار عمل. أما إذا كانت الحلقة جاهزة ضمن الأداة، فقد اخترت منصة تشغيل. تحتاج العديد من الفرق إلى كليهما في مستويات مختلفة، والخطأ المكلف هو استخدام أحدهما لإعادة بناء ما يوفره الآخر بالفعل.
إذا كنت تريد حلقة العمل دون الحاجة لكتابتها، TrueForge متاح على GitHub و npx @truefoundry/trueforge يستغرق الأمر حوالي دقيقة. إذا كنت ترغب في رؤية كيف تعمل نفس المنصة في بيئة خاضعة للحوكمة، مع ميزانيات، وتحكم في الوصول (RBAC)، وتتبعات موحدة، فهذا هو TrueFoundry Agent Harness.
TrueFoundry AI Gateway delivers ~3–4 ms latency, handles 350+ RPS on 1 vCPU, scales horizontally with ease, and is production-ready, while LiteLLM suffers from high latency, struggles beyond moderate RPS, lacks built-in scaling, and is best for light or prototype workloads.












.png)
.png)
.png)
.png)
.png)
.png)
.png)

.png)
.png)
.png)
.png)


.png)





