استبدل GPT-5 بـ Claude داخل وكيل يعمل، وفي معظم الأحيان، لن يتغير الأمر تقريباً. غيّر طريقة التعامل مع إعادة المحاولات، أو ما تُدخله في نافذة السياق، أو متى يقرر التوقف، وسيتصرف الوكيل بأكمله بشكل مختلف. تلك الفجوة هي الدليل: النموذج هو الجزء الأصغر والأكثر قابلية للاستبدال في الوكيل العامل. الهندسة المثيرة للاهتمام تكمن في كل ما يحيط به.
هذا الـ wrapper أصبح له اسم الآن. استقر المختصون على مصطلح "harness" للطبقة التي تحول مولد النصوص إلى شيء يتخذ إجراءات عبر الزمن بدلاً من تشغيل نص برمجي ثابت. انتشر المصطلح بسرعة عبر Twitter والمدونات الهندسية في مطلع 2026، مما يعني أنه استُخدم أيضاً بشكل فضفاض، مع نفس الكلمة تؤدي عملاً مختلفاً قليلاً في كل منشور تقرأه. هذا المقال يحدد المعنى بدقة: ما هو الـ harness، ما الذي يتكون منه، كيف يختلف عن "framework" و"scaffold"، ولماذا معظم جودة وكيلك مختبئة في الـ harness وليس في النموذج.
النسخة المختصرة
- الـ agent harness هو البرنامج المحيط بـ LLM الذي يدير حلقة التنفيذ والأدوات والذاكرة والسياق والحالة ومعالجة الأخطاء وضوابط الأمان. النموذج يولّد النصوص؛ الـ harness يقرر ما يراه النموذج، وما يمكنه فعله، ومتى يتوقف، وما يحدث حين ينكسر شيء ما.
- في بيئة الإنتاج، استدعاء النموذج غالباً ما يكون أصغر الأجزاء المرئية من سطح النظام. نموذج أضعف في harness مبني بشكل جيد يمكنه التغلب على نموذج أقوى في harness مهمل، خاصة في المهام الطويلة التي تعتمد على كثير من الأدوات.
- يحتوي الـ harness على ما يقارب من تسعة إلى أحد عشر مكوناً متكرراً. معظمها أشياء لا يلمسها النموذج مباشرةً أبداً.
- "Harness" ليس مرادفاً لـ "framework". الـ framework (LangGraph، agents SDK) هو المكتبة التي تبني بها؛ الـ harness هو الطبقة التشغيلية التي تساعدك تلك المكتبة على تجميعها.
ما هو الـ Agent Harness؟
الـ agent harness هو البنية التحتية البرمجية المحيطة بنموذج اللغة التي تدير حلقة التنفيذ والوصول إلى الأدوات والذاكرة والسياق واستمرارية الحالة ومعالجة الأخطاء وضوابط الأمان. النموذج يولّد النصوص. الـ harness يقرر ما يراه النموذج في كل دور، وما الإجراءات التي يمكنه اتخاذها، ومتى يتوقف، وما يحدث حين تفشل خطوة ما.
أوضح صياغة جاءت من LangChain، الذي اختزله في معادلة: Agent = Model + Harness. النموذج يوفر الذكاء. الإطار التنفيذي هو ما يجعل هذا الذكاء يفعل أي شيء في العالم.
"الـ harness هو كل قطعة من الكود والإعدادات ومنطق التنفيذ التي ليست النموذج نفسه."
— LangChain, تشريح harness الوكيل
أجد أن الحدود أسهل ما يمكن إدراكها من خلال سؤال واحد: عندما يفعل وكيلك الشيء الخاطئ، هل كان استدلال النموذج نفسه خاطئاً، أم أن النظام المحيط به أعطى النموذج السياق الخاطئ أو الأدوات الخاطئة أو لم يمنحه طريقة للتعافي؟ في معظم الأحيان، في النظام الحقيقي، يكون السبب هو الثاني. النموذج استدل بشكل صحيح على مدخلات غير صالحة. الـ harness هو ما يتحكم في المدخلات.
الفكرة الرئيسية: النموذج يولّد؛ والـ harness يحكم. هذا التقسيم هو المفهوم بأكمله.
ما هي مكونات harness الوكيل؟
كل harness إنتاجي يجمع نفس الأجزاء المتكررة: حلقة تنفيذ تقود النموذج دوراً بدور، والوصول إلى الأدوات للسماح له بالتصرف، والذاكرة عبر الأدوار، وإدارة السياق لما يراه الآن، واستمرارية الحالة حتى يبقى العمل عبر الجلسات، ومعالجة الأخطاء للخطوات الفاشلة، والحواجز التي تقيد ما يمكنه فعله. تضيف أنظمة الإنتاج حلقات التحقق وتنسيق الوكلاء الفرعيين.
جرد مفيد، مستمد من كيفية وصف الممارسين للأنظمة الحقيقية:
- حلقة التنفيذ / التحكم: ما يقود الوكيل خطوة بخطوة. استدعاء النموذج، قراءة مخرجاته، تشغيل أي أداة طلبها، إعادة النتيجة، تكرار ذلك حتى تتحقق شرط التوقف.
- الوصول إلى الأدوات: الدوال، وAPI، وتنفيذ الكود، ونظام الملفات التي يمكن للنموذج الوصول إليها.
- الذاكرة: ما يحتفظ به الوكيل عبر الأدوار والجلسات.
- إدارة السياق: ما يُحشى في نافذة النموذج في كل دور، وما يُضغط خارجها عند الفيضان.
- استمرارية الحالة / نقاط التحقق: حفظ حالة الوكيل حتى يمكن استئناف تشغيل متعطل أو متوقف.
- معالجة الأخطاء: إعادة المحاولة، والبدائل، والاسترداد عند فشل استدعاء أداة أو نموذج.
- الضوابط والقيود: قيود على ما يمكن للوكيل فعله، مثل الأدوات المسموح بها وحدود الخطوات والتحقق من المخرجات.
- حلقات التحقق: جعل الوكيل (أو الإطار) يتحقق من عمله الخاص قبل اعتباره منتهياً.
- تنسيق الوكلاء الفرعيين: إنشاء وكلاء فرعيين والتفويض إليهم وجمع النتائج منهم في المهام الأكبر.
ليست كل هذه العناصر عالمية. تظهر حلقة التنفيذ والأدوات ومعالجة السياق ومعالجة الأخطاء حتى في نموذج أولي لعطلة نهاية الأسبوع. استمرارية الحالة والتحقق وتنسيق الوكلاء الفرعيين هي المكان الذي تنقسم فيه النماذج الأولية وأنظمة الإنتاج. يمكن للنموذج الأولي تجاهلها؛ أما وكيل الإنتاج طويل الأمد فلا يستطيع. ما كتبته Anthropic حول الوكلاء طويلو الأمد هو جولة في الأجزاء الخاصة بالإنتاج فقط: كيف يعيد الوكيل بناء فهمه من ملف التقدم بعد إعادة تعيين نافذة السياق، وكيف يتم دمج الاختبار في الحلقة.
لمن يريد الجسر الأكاديمي، استعراض حديث استعراض لبنيات الوكلاء يدمج هذه الآلية نفسها في مجموعة شكلية أصغر من المكونات الأساسية. قائمة الممارس وإطار الاستعراض هما مستويان من التكبير على نفس البنية: الاستعراض يضغط، والمخزون أعلاه يوسع. تعامل مع العدد من تسعة إلى أحد عشر باعتباره المكونات التي تشترك فيها معظم أطر الإنتاج، وليس معياراً مُصادقاً عليه؛ لم يُصادق الحقل على أي شيء بعد.
الفكرة الرئيسية: معظم الأجزاء المتحركة في الوكيل تقع في الإطار، وليس في النموذج. النموذج هو مجرد مكون من بين مكونات كثيرة.
لماذا يهم الهارنس أكثر من النموذج؟
نموذج أضعف داخل harness مُصمَّم بشكل جيد كثيرًا ما يتفوق على نموذج أقوى في harness رديء التصميم. السبب ميكانيكي لا سحري: موثوقية الوكيل من البداية إلى النهاية هي حاصل ضرب موثوقية كل خطوة، ومعظم تلك الخطوات (اختيار الأداة، تجميع السياق، التعافي من الأخطاء) هي مهمة الهارنس لا النموذج. حسِّنها وستصبح السلسلة بأكملها أكثر موثوقية، بصرف النظر عن النموذج المستخدم.
الحساب يجعل الأمر ملموسًا. لنفترض أن كل خطوة في مهمة مكونة من عشر خطوات تنجح 99% من الوقت. النجاح من البداية إلى النهاية ليس 99%، بل هو 0.99 مرفوعًا للقوة العاشرة، أي نحو 90%. ادفع كل خطوة إلى 99.9% وسيقفز معدل النجاح الكلي إلى نحو 99%. موثوقية كل خطوة تتضاعف، وهي في معظمها خاصية للهارنس. لهذا السبب، تحسين معالجة الأخطاء وإدارة السياق يُجدي أكثر من استبدال نموذج أفضل بنصف نقطة على مؤشر أداء ما.
ثمة إشارة من بيئة الإنتاج تشير إلى الاتجاه ذاته. MongoDB، مستشهدًا بدراسة حالة Vercel, يُفيد بأن Vercel قلّصت الجزء الأكبر من أدوات وكيلها وشاهدت معدل نجاحه يرتفع بشكل حاد على النموذج ذاته، مع harness أصغر وأنظف. اقرأه بوصفه دليلًا متقاربًا لا دليلًا قاطعًا: إنه حالة إنتاج واحدة لا تجربة خاضعة للضبط، لكنه يشير إلى الاتجاه ذاته الذي تشير إليه الحسابات التراكمية والأعمال البحثية أعلاه.
هذا هو المبدأ التوجيهي الذي أعود إليه باستمرار بوصفي مهندس منصة: السياق هو عنق الزجاجة، لا قدرة النموذج الخام، والسقالات المبنية لتغطية ثغرات النماذج الحالية تميل إلى أن تُبتلع مع تحسّن النماذج. ابنِ الأجزاء الدائمة من الهارنس (الحلقة، والحالة، والتعافي) واترك النموذج الأساسي يتحسن وفق جدوله الخاص.
الفكرة الرئيسية: حين يخفق وكيلك، اشكك في الهارنس قبل النموذج. الاحتمالات تدعم ذلك.
ما الفرق بين الهارنس والسقالة والإطار؟
يُستخدم هؤلاء الثلاثة بالتبادل، وهذا خطأ. A framework هي المكتبة أو SDK التي تبني بها، مثل LangGraph أو agents SDK. A harness هي طبقة التنفيذ والحوكمة التي تعمل حول النموذج، ويساعدك إطار العمل على تجميعها. A scaffold هو الأكثر مرونة من بين الثلاثة: أحياناً يكاد يكون مرادفاً للـ harness، وأحياناً نسخة النموذج الأولي منه، وأحياناً طبقة prompt وأوصاف الأدوات تحديداً.
المصطلحات غير مستقرة فعلاً، والأمر الأوضح هو رسم خريطة للاستخدامات بدلاً من فرض واحد. مصدر HuggingFace مسرد الوكلاء تقول ذلك مباشرة:
"كثير من هذه المصطلحات لا تزال تفتقر إلى تعريفات مقبولة عالمياً، وتستخدم أطر العمل المختلفة الكلمة ذاتها بطرق مختلفة."
— HuggingFace, مسرد الوكلاء
| المصطلح | ما يشير إليه | علاقة |
|---|---|---|
| Framework | المكتبة أو SDK التي تبني بها (LangGraph، SDK للوكلاء) | أداة لتجميع harness |
| Harness | طبقة التشغيل حول النموذج: الحلقة، الأدوات، السياق، الحالة، الضوابط | ما تُسلِّمه وتشغِّله |
| Scaffold | يُستخدم بشكل فضفاض: شبه مرادف لـ harness، أو نسخة مستوى النموذج الأولي / طبقة الـ prompt | يتداخل مع harness؛ أقل دقة |
| حلقة | دورة التنفيذ داخل harness | مكوّن من مكوّنات الharness |
الخلاصة العملية للتفكير في نظامك الخاص: حين يقول أحدهم "framework"، اسأل هل يقصد المكتبة أم الشيء الذي يعمل فعلاً. وحين يقول "scaffold"، اسأل هل يقصد الharness بأكمله أم مجرد طبقة الprompt والأدوات. القيمة هنا هي إزالة الغموض، لا ادعاء امتلاك الكلمة الفصل.
كيف يُطبّق LangGraph نمط الharness؟
LangGraph هو تطبيق Python مفتوح المصدر شائع لنمط الharness. يُنمذج تنفيذ الوكيل باعتباره رسماً بيانياً موجهاً من العقد والحواف، مع تدفق حالة مكتوبة بينها وإمكانية عمل checkpoint لكل انتقال. إذا كانت المكوّنات المجردة المذكورة أعلاه تبدو غير واضحة، فإن LangGraph هو المكان الذي يمكنك فيه رؤيتها تأخذ شكلاً ملموساً في أداة حقيقية.
التعيين قريب من واحد إلى واحد. العقد والحواف هي حلقة التنفيذ: كل عقدة تؤدي عملاً، وكل حافة تقرر إلى أين يذهب التحكم بعد ذلك. كائن الحالة المكتوب الممرر بين العقد هو مكوّن السياق والحالة المُوضَّح صراحةً. الcheckpointing (LangGraph يحفظ الحالة عبر savers مثل تطبيقه المدعوم بـ Postgres) هو مكوّن استمرارية الحالة. حد الخطوات القابل للتهيئة هو guardrail لشرط الإيقاف، يمنع الوكيل المعطوب من الدوران إلى الأبد. نفس المكوّنات، مُسمّاة ومُوصَّلة بواسطة مكتبة محددة.
إذا كنت تريد تشغيل LangGraph agent على خادمك الخاص على مدار الساعة، فهذا سؤال نشر لا سؤال مفاهيمي. انظر دليل Linux VPS الخاص بنا لذلك المسار. هنا، LangGraph هو مجرد المثال العملي: دليل على أن «حلقة التنفيذ» و«استمرارية الحالة» و«guardrail» ليست تجريدات، بل أشياء يمكنك الإشارة إليها في كود حقيقي.
الأسئلة الشائعة
ما هو الـ Agent Harness؟
agent harness هو البرنامج المحيط بنموذج اللغة الذي يحوّله إلى وكيل. يدير حلقة التنفيذ، والوصول إلى الأدوات، والذاكرة، والسياق، واستمرارية الحالة، ومعالجة الأخطاء، والguardrails. النموذج يولّد النص؛ الharness يقرر ما يراه النموذج، وما يمكنه فعله، ومتى يتوقف، وما يحدث عند الفشل.
هل إطار تنفيذ العميل هو نفسه إطار عمل العميل؟
لا. الإطار هو المكتبة أو SDK الذي تبني به، مثل LangGraph أو SDK للعملاء. الإطار التنفيذي هو طبقة التشغيل والحوكمة النشطة حول النموذج (الحلقة والأدوات والسياق والحالة وضوابط الأمان) التي يساعدك الإطار على تجميعها. تستخدم الإطار لبناء إطار تنفيذي.
ما المكونات التي يمتلكها كل إطار تنفيذي للعميل؟
تشترك معظم أطر التنفيذ في نواة متكررة: حلقة تنفيذ، والوصول إلى الأدوات، والذاكرة، وإدارة السياق، وثبات الحالة، ومعالجة الأخطاء، وضوابط الأمان. تضيف أطر التنفيذ الإنتاجية حلقات التحقق وتنسيق العملاء الفرعيين. يمكن للنماذج الأولية تخطي الأجزاء المخصصة للإنتاج فقط، لكن الحلقة والأدوات ومعالجة السياق ومعالجة الأخطاء تظهر في كل مكان تقريبا.
ماذا يعني «LLM هو الجزء الأصغر من نظام العميل الخاص بك»؟
يعني ذلك أن معظم سلوك العميل وموثوقيته يأتيان من الإطار التنفيذي، وليس من النموذج. الموثوقية الشاملة هي حاصل ضرب معدل نجاح كل خطوة، ومعظم الخطوات هي عمل الإطار التنفيذي. تُفيد MongoDB، مستشهدةً بدراسة حالة Vercel، بارتفاع في معدل النجاح من تغييرات الإطار التنفيذي وحده، على نفس النموذج. هذا دليل على أن إصلاح الإطار التنفيذي يتفوق على إصلاح النموذج.
أين تعيش جودة عميلك
الإطار التنفيذي هو المكان الذي تعيش فيه معظم جودة العميل، والآن لديك المفردات اللازمة لتحديد المشكلات في نظامك الخاص. يمكنك تعريف إطار تنفيذي وتسمية مكوناته وتمييزه عن إطار عمل وسقالة، والتفكير فيما إذا كان الفشل المعطى مشكلة نموذج أم مشكلة إطار تنفيذي.
لذا في المرة القادمة التي يتصرف فيها عميلك بشكل سيء، افحص طبقة الإطار التنفيذي أولا: السياق الذي تغذيه به، والأدوات التي عرضتها، وشروط الإيقاف التي حددتها، والطريقة التي يتعافى بها من خطوة فاشلة. ابحث عن نموذج أكبر فقط بعد التحقق من تلك الطبقة. في معظم الأوقات، لن تحتاج إلى ذلك.
