عندما يعطيك نظام ذكاء اصطناعي نتيجة ضعيفة، لا تفترض مباشرة أن المشكلة في النموذج.
قد يكون النموذج ممتازًا، لكن المنظومة المحيطة به لم تجمع السياق الصحيح، أو فقدت تفاصيل مهمة من الذاكرة، أو استخدمت الأداة بطريقة سيئة، أو توقفت قبل التحقق من النتيجة.
هذه المنظومة هي ما يُسمى AI Harness.
وفهمها لم يعد موضوعًا تقنيًا يخص المطورين فقط. إذا كنت تستخدم وكلاء الذكاء الاصطناعي، أو تطلب من نظام أن يقرأ ملفات ويبحث في البريد وينفذ مهام متعددة الخطوات، فأنت لا تتعامل مع نموذج منفرد. أنت تتعامل مع نظام كامل يعمل خلف الواجهة.
شاهد الشرح الكامل لـ AI Harness على YouTube
النموذج هو الدماغ، لكنه لا يستطيع العمل وحده
أسهل طريقة لفهم الفكرة هي تشبيه النموذج بالدماغ، وAI Harness بالجسد.
الدماغ قادر على التفكير، لكنه لا يستطيع وحده أن يفتح كتابًا، أو يرسل رسالة، أو يتنقل داخل بيئة عمل، أو يعرف ما المسموح والممنوع. يحتاج إلى أنظمة تمنحه الحواس والأدوات والذاكرة وآليات الحركة والتحكم.
الأمر نفسه ينطبق على نموذج الذكاء الاصطناعي.
النموذج في جوهره يستقبل مدخلات ويولد مخرجات. أما تذكّر تاريخ المحادثة، وقراءة الملفات، وتشغيل الأدوات، وإدارة الصلاحيات، وتنظيم المهام والتحقق من النتيجة، فكلها مسؤوليات تتولاها الأنظمة المحيطة به.
لهذا يمكن وضع النموذج نفسه داخل هارنسين مختلفين والحصول على تجربتين تبدوان وكأنهما صادرتان عن نموذجين مختلفين: أحدهما منظم وموثوق، والآخر مشتت وينسى التفاصيل ويتوقف في الوقت الخطأ.
المغزى العملي: مقارنة المنتجات اعتمادًا على اسم النموذج وحده لم تعد كافية. عليك أن تسأل أيضًا كيف يدير المنتج النموذج.
الجودة الحقيقية تبدأ قبل وصول طلبك إلى النموذج
عندما تكتب أمرًا، قد يبدو لك أنه ينتقل مباشرة إلى النموذج. لكن في الأنظمة المتقدمة، تحدث سلسلة من الخطوات قبل ذلك.
يحتاج النظام أولًا إلى فهم هوية المستخدم، والجلسة الحالية، والمهمة المطلوبة، والبيئة المتاحة، والأدوات التي يمكن استخدامها، والصلاحيات المرتبطة بها. ثم يجمع هذه المعلومات في سياق منظم يمكن للنموذج قراءته.
هذه المرحلة تحدد إلى حد كبير جودة كل ما سيحدث بعدها.
طبقة الاتصال بالنموذج
كل نموذج له طريقة محددة للتواصل مع النظام المحيط به، بما في ذلك الصيغ والتعليمات والإشارات الخاصة باستدعاء الأدوات.
تعمل طبقة Model Adapter كمترجم بين النموذج والعالم الخارجي. تستقبل ما يولده النموذج وتحوله إلى صيغة يستطيع الهارنس تنفيذها، ثم تعيد نتائج التنفيذ إلى النموذج بطريقة يفهمها.
إذا كانت هذه الطبقة غير منضبطة، فقد يُفهم طلب النموذج بصورة خاطئة حتى لو كان تفكيره الأساسي صحيحًا.
إدارة الجلسات وعمليات التنفيذ
المحادثة الطويلة ليست كتلة واحدة. قد تحتوي الجلسة نفسها على أكثر من مهمة، وكل مهمة قد تتضمن عدة عمليات تنفيذ أو محاولات.
يتولى Session and Run Manager تنظيم هذه العلاقات: ما الجلسة الحالية؟ ما المهمة النشطة؟ أي عملية انتهت؟ وأي نتيجة تنتمي إلى أي طلب؟
من دون هذا التنظيم، قد يخلط النظام بين نتائج قديمة ومهمة جديدة، أو يتعامل مع خطوة انتهت وكأنها ما زالت قيد التنفيذ.
استقبال المهمة وبناء السياق
طلب المستخدم وحده لا يحتوي دائمًا على كل ما يحتاجه النموذج. لذلك تعمل طبقة Task Intake and Interface على تفسير المهمة وجمع المعلومات المرتبطة بها.
بعد ذلك يأتي دور Context Builder and Prompt Assembly لتركيب الطلب الحالي مع التعليمات السابقة، وتاريخ الجلسة، وحالة المهمة، ونتائج الأدوات، والقيود التي يجب احترامها.
في النهاية لا يرى النموذج واجهة التطبيق كما تراها أنت. يرى حزمة من المعلومات جُمعت ورتبت له في لحظة محددة.
المغزى العملي: إذا أخطأ النظام في فهم طلبك، فقد تكون المشكلة في استقبال المهمة أو بناء السياق، لا في قدرة النموذج على الاستدلال.
الوكيل ليس نموذجًا يعمل وحده
الفرق الأساسي بين الرد التقليدي والوكيل هو أن الوكيل لا يولد إجابة واحدة ثم يتوقف. بل يدخل في دورة تنفيذ هدفها إنجاز مهمة.
قد يفكر، ويطلب استخدام أداة، ويقرأ النتيجة، ثم يقرر أنه يحتاج إلى أداة أخرى. وقد يعيد المحاولة أو يطلب موافقة قبل متابعة خطوة حساسة.
هذه الدورة هي AI Agent Loop، لكنها تحتاج إلى نظام يتحكم بها.
من يقرر متى تستمر الدورة؟
يتولى Agent Loop and Turn Controller تنظيم أدوار الوكيل ومحاولاته. فهو يحدد متى يبدأ الدور، وما الذي يستطيع الوكيل فعله، ومتى يعيد المحاولة، ومتى يرجع إلى المستخدم.
تخيل وكيلًا يحاول معالجة ملف معطوب. من دون شروط واضحة قد يكرر المحاولة بلا نهاية، أو يتوقف بعد أول فشل رغم وجود مسار بديل.
لذلك تحتاج الدورة إلى حدود: عدد للمحاولات، وتعريف واضح للهدف، وشروط للنجاح أو الفشل، وقواعد تحدد متى يجب طلب معلومات إضافية.
تنسيق الخطوات المتوازية والمتتابعة
بعض المهام تتطلب خطوات يمكن تشغيلها في الوقت نفسه، وخطوات أخرى لا يمكن أن تبدأ قبل انتهاء ما يسبقها.
هنا يأتي دور Orchestrator. فهو ينسق حركة العمل داخل الهارنس حتى تصل المعلومات إلى النموذج بالتسلسل المناسب، بدل إغراقه بنتائج متداخلة وغير منظمة.
المغزى العملي: الوكيل الجيد ليس الوكيل الذي يستمر في العمل أطول فترة، بل الذي يعرف ما الخطوة التالية ولماذا، ومتى أصبحت المهمة مكتملة.
الأدوات لا تصبح مفيدة بمجرد إضافتها
منح النظام إمكانية الوصول إلى البريد أو المتصفح أو الملفات لا يعني أنه أصبح قادرًا على استخدامها بصورة صحيحة.
الهارنس يحتاج إلى معرفة الأدوات الموجودة، وطريقة استدعاء كل أداة، والمدخلات التي تقبلها، وشكل النتائج التي تعيدها.
سجل الأدوات وتعريفاتها
يعمل Tool Registry and Schema كدفتر منظم للأدوات المتاحة. يوضح ما وظيفة كل أداة، وما المعطيات المطلوبة لتشغيلها، وما نوع المخرجات المتوقع.
هذا يمنع النموذج من محاولة استدعاء أداة غير موجودة أو إرسال مدخلات بصيغة لا تستطيع الأداة فهمها.
مسار تنفيذ الأدوات
بعد اختيار الأداة، تبدأ مسؤولية Tool Execution Pipeline.
قد يحتاج النظام إلى الحصول على بيانات دخول آمنة، والتحقق من الصلاحيات، وتنفيذ الطلب، ومعالجة الأخطاء، ثم تحويل النتيجة الخام إلى صيغة يستطيع النموذج قراءتها.
على سبيل المثال، الوصول إلى البريد لا يعني فقط تشغيل أمر «اقرأ الرسائل». هناك طريقة للاتصال، وسياسة وصول، وصيغة لنتائج البحث، وآلية لجلب محتوى الرسائل وإعادته إلى النموذج.
المغزى العملي: عدد الأدوات ليس مؤشرًا كافيًا على جودة النظام. الأهم هو مدى جودة تعريفها وتنفيذها وإعادة نتائجها.
الصلاحيات وSandbox جزء من جودة النتيجة
قد ننظر إلى الصلاحيات باعتبارها قيدًا أمنيًا فقط، لكنها تؤثر أيضًا في طريقة تخطيط النموذج للمهمة.
إذا عرف النموذج أنه يستطيع قراءة البريد دون الإرسال، فسيبني خطة مختلفة عن خطة نظام يملك صلاحية إرسال الرسائل. وإذا كانت خطوة معينة تحتاج إلى موافقة المستخدم، فيجب أن يعرف ذلك قبل محاولة تنفيذها.
إدارة البيئة وSandbox
تحدد Environment and Sandbox Management البيئة التي يعمل داخلها الوكيل والحدود التي لا يستطيع تجاوزها.
قد يعمل الوكيل داخل مشروع محدد، أو مجلد معين، أو بيئة معزولة لا تسمح له بالوصول إلى بقية الجهاز. هذه الحدود ليست تفاصيل جانبية؛ بل جزء من تعريف الواقع الذي يستطيع الوكيل العمل داخله.
الموافقات قبل الأفعال الحساسة
تحدد منظومة Permissions and Approvals الأفعال المسموحة مباشرة، والأفعال التي تتطلب موافقة، والأفعال الممنوعة بالكامل.
إذا احتاج إرسال رسالة إلى موافقة، يمكن للنموذج إعداد المسودة ثم إيقاف الدورة وطلب الإذن. وبعد الموافقة يستأنف الهارنس التنفيذ من الحالة الصحيحة بدل إعادة المهمة من البداية.
المغزى العملي: عندما تطلب من وكيل تنفيذ مهمة، وضّح ليس فقط ما تريده، بل أيضًا ما يستطيع فعله دون الرجوع إليك وما يحتاج إلى موافقة.
إدارة السياق هي المكان الذي تضيع فيه المشاريع الطويلة
كلما طالت الجلسة، زادت كمية المحادثات والملفات ونتائج الأدوات والقرارات التي يجب الاحتفاظ بها. لكن مساحة السياق ليست بلا حدود، ولا يمكن عرض كل شيء للنموذج في كل مرة.
لهذا يحتاج الهارنس إلى ضغط المعلومات واسترجاع ما يلزم منها.
ضغط السياق دون فقدان المهم
تعمل منظومة Context Compaction and Retrieval على تلخيص أجزاء من السياق، بحيث تتحول مئات الأسطر إلى خلاصة أصغر تترك مساحة لخطوات جديدة.
المشكلة أن التلخيص ليس عملية محايدة. إذا حذف النظام قرارًا مهمًا أو قيدًا اتُّفق عليه سابقًا، سيبدأ النموذج بالتصرف وكأن تلك المعلومة لم تكن موجودة.
وهذا يفسر نمطًا مألوفًا: يعمل النظام جيدًا في بداية المشروع، ثم يبدأ بعد مدة في نسيان تفاصيل واضحة أو مخالفة تعليمات قديمة.
قد لا يكون النموذج قد أصبح أقل ذكاء. ربما حدثت دورة ضغط للسياق فُقدت خلالها معلومات أساسية.
الحالة والذاكرة ليستا الشيء نفسه
يحتاج الهارنس إلى معرفة حالة النظام الآن: ما المهام المفتوحة؟ ما العمليات الجارية؟ ما الذي انتهى؟ وما النتائج المحفوظة؟
ويحتاج أيضًا إلى ذاكرة يمكن استرجاعها لاحقًا، سواء كانت قصيرة الأمد داخل الجلسة أو طويلة الأمد تمتد عبر جلسات متعددة.
التحدي ليس حفظ أكبر كمية ممكنة، بل استرجاع المعلومة المناسبة في الوقت المناسب. فالذاكرة التي لا تصل إلى النموذج عندما يحتاجها لا تقدم قيمة عملية.
المغزى العملي: في المشاريع الطويلة، ثبّت القرارات والقيود المهمة بوضوح، ولا تفترض أن كل تفصيل ورد سابقًا سيظل حاضرًا تلقائيًا.
النظام الجيد يعرف متى يتوقف
قد يبدو استمرار الوكيل في العمل علامة على الاجتهاد، لكنه قد يتحول إلى تكلفة بلا فائدة إذا لم تكن هناك شروط واضحة للتوقف.
يحتاج الهارنس إلى التحكم في الميزانية والوقت وعدد المحاولات، مع امتلاك آليات للتعافي من الأخطاء والتحقق من النتيجة.
الميزانيات والتوقف والتعافي
تحدد منظومة Budgets, Stopping and Recovery الحدود التي يعمل ضمنها الوكيل.
متى يتوقف لأنه نجح؟ متى يتوقف لأنه فشل؟ متى يجرب مسارًا آخر؟ ومتى يعرض أفضل ما وصل إليه بدل الاستمرار في استهلاك الوقت والموارد؟
إذا كانت هذه المنظومة ضعيفة، قد يعمل الوكيل لساعات أو يكرر الخطوات نفسها ثم يعيد نتيجة لا تبرر التكلفة.
التحقق قبل إعلان النجاح
لا يكفي أن ينتج النظام جوابًا يبدو مقنعًا. يجب أن يقارن ما وصل إليه بمعايير المهمة الأصلية.
هل غطى جميع العناصر المطلوبة؟ هل استند إلى الأدلة التي جلبتها الأدوات؟ هل التزم بشكل المخرجات؟ هل توجد رسالة أو ملف لم تتم معالجته؟
إذا فشل التحقق، تعود الدورة إلى النموذج مع توضيح النقص. وإذا تحققت الشروط، ينتقل الهارنس إلى إعداد الرد النهائي.
المغزى العملي: حسّن طلبك بإضافة معيار نجاح قابل للفحص، مثل «تأكد من تغطية جميع الرسائل» أو «لا تعتبر المهمة مكتملة قبل مطابقة النتائج مع القائمة الأصلية».
المراقبة تجعل النظام قادرًا على فهم نفسه
خلال تنفيذ مهمة واحدة قد تقع عشرات الأحداث: تشغيل أداة، وصول نتيجة، فشل محاولة، طلب موافقة، تحديث للذاكرة أو إنهاء لعملية.
تجمع منظومة Observability, Tracing and Event Bus هذه الأحداث وتربطها ببعضها.
تسمح هذه الطبقة للنظام بمعرفة ما حدث، كما تساعد على تشخيص سبب الفشل. هل المشكلة في استدعاء الأداة؟ أم في الصلاحيات؟ أم في بناء السياق؟ أم في قرار اتخذه النموذج بعد قراءة النتيجة؟
من دون التتبع، يصبح النظام صندوقًا أسود حتى بالنسبة إلى من بناه.
المغزى العملي: في المهام المهمة، لا تكتفِ بالنتيجة النهائية. ابحث عن نظام يوضح ما الأدوات التي استخدمها وما الخطوات التي نفذها وأين توقف.
ماذا يحدث خلف طلب بسيط لقراءة البريد؟
لنفترض أنك طلبت من النظام مراجعة رسائل الموردين، واستخراج المهام التي تحتاج إلى تدخل منك، ثم تلخيص بقية الرسائل في سطرين.
يبدو هذا طلبًا واحدًا، لكنه قد يطلق سلسلة تنفيذ كاملة.
أولًا، يجمع الهارنس معلومات الجلسة وهوية المستخدم وصندوق البريد وسياسة الوصول. ثم ينشئ المهمة وعملية التنفيذ، ويحمل الحالة والذاكرة المرتبطة بالجلسة.
بعد ذلك يبني السياق الذي سيصل إلى النموذج، ويضيف إليه الهدف وشكل المخرجات والقيود. وقد يحدد مثلًا أن قراءة البريد والبحث فيه مسموحان، بينما إرسال الرسائل غير مسموح.
عندها فقط يصل الطلب المركب إلى النموذج.
يقرر النموذج البحث عن رسائل الموردين، فيتحقق الهارنس من صلاحية الأداة ومدخلاتها، ثم ينفذ البحث ويعيد النتائج. قد يطلب النموذج قراءة مجموعة من الرسائل، فتتكرر الدورة.
بعد جمع المحتوى، يستخرج النموذج المهام والملخصات. لكن الهارنس لا يفترض أن النتيجة مكتملة؛ بل يمررها إلى مرحلة التحقق.
إذا اكتشف أن رسالة لم تُغطَّ أو أن الملخص تجاوز الشكل المطلوب، تعود المهمة إلى دورة جديدة. وعندما تتحقق الشروط، يجهز النظام الرد النهائي، ويسجل النتائج والتكلفة، ويحدّث الحالة والذاكرة.
أنت ترى في النهاية قائمة مهام وملخصات قصيرة. أما خلف الواجهة، فقد عملت طبقات متعددة لتنظيم كل خطوة.
إطار من 14 نظامًا لفهم AI Harness
لا يوجد سبب لاعتبار كل هارنس مقسمًا بالطريقة نفسها. قد تدمج بعض المنتجات عدة مسؤوليات في مكوّن واحد، وقد تفصلها منتجات أخرى إلى عدد أكبر من الخدمات.
لكن يمكن استخدام الإطار التالي لفهم المسؤوليات الأساسية:
Model Adapter
Session and Run Manager
Context Builder and Prompt Assembly
Task Intake and Interface
Environment and Sandbox Management
Permissions and Approvals
Agent Loop and Turn Controller
Orchestrator
Tool Registry and Schema
Tool Execution Pipeline
Context Compaction and Retrieval
State and Memory Management
Budgets, Stopping, Recovery and Verification
Observability, Tracing and Event Bus
القيمة هنا ليست في حفظ الأسماء. القيمة في إدراك أن الرد الذي تراه هو نتيجة تعاون هذه المسؤوليات، وليس نتاج النموذج وحده.
كيف يغيّر هذا الفهم طريقة استخدامك للذكاء الاصطناعي؟
فهم AI Harness يجعلك تكتب أوامر أقرب إلى طريقة عمل النظام الفعلية.
بدل إعطاء طلب عام، تبدأ بتحديد خمسة أمور: الهدف، والمصادر المتاحة، والقيود، والصلاحيات، ومعيار النجاح.
حدّد الهدف النهائي
لا تقل فقط «راجع البريد». وضّح ما القرار أو المخرج الذي تحتاج إليه: قائمة مهام، أو تصنيف للرسائل، أو ملخصات قصيرة.
عرّف نطاق الأدوات والمصادر
حدد صندوق البريد أو المجلد أو الفترة أو نوع الملفات التي يجب استخدامها. كلما كان النطاق أوضح، قل احتمال أن يعمل الوكيل في اتجاه غير مفيد.
افصل بين القراءة والتنفيذ
وضح ما إذا كان النظام يستطيع القراءة والتحليل فقط، أم يمكنه أيضًا تعديل الملفات أو إرسال الرسائل. وإذا كانت بعض الأفعال تحتاج إلى موافقة، اذكر ذلك.
أضف شروط التوقف
حدد متى تعتبر المهمة مكتملة، وماذا يجب أن يفعل النظام إذا لم يجد المعلومات المطلوبة أو واجه خطأ.
اطلب تحققًا نهائيًا
اطلب من النظام مراجعة النتيجة مقارنة بالطلب قبل تقديمها. هذه الخطوة مفيدة خصوصًا في المهام التي تتضمن عدة ملفات أو رسائل أو مصادر.
بهذه الطريقة، أنت لا تحاول كتابة «برومت سحري». أنت تمنح الهارنس تعريفًا أفضل للمهمة التي سيديرها.
السؤال لم يعد: ما أذكى نموذج؟
النموذج سيظل عنصرًا أساسيًا. لا يستطيع الهارنس تحويل نموذج محدود إلى نموذج خارق.
لكن قدرات النموذج لا تتحول تلقائيًا إلى قيمة للمستخدم. تحتاج إلى سياق منظم، وأدوات معرفة جيدًا، وذاكرة قابلة للاسترجاع، وصلاحيات واضحة، ودورات تنفيذ منضبطة، وآليات تحقق وتوقف.
لهذا أصبح السؤال الأكثر فائدة عند تقييم أي نظام ذكاء اصطناعي هو: كيف يدير هذا النظام النموذج أثناء العمل؟
هل يحتفظ بتفاصيل المشروع؟ هل تعرف أدواته حدودها؟ هل يطلب الموافقة في اللحظة المناسبة؟ هل يستطيع تفسير ما نفذه؟ وهل يتحقق من اكتمال المهمة قبل إعلان النجاح؟
الإجابة عن هذه الأسئلة تكشف لك جودة المنتج أكثر مما يكشفه اسم النموذج وحده.
برأيك، أين يظهر أكبر فرق بين أنظمة الذكاء الاصطناعي التي تستخدمها اليوم: في بناء السياق، أم الذاكرة، أم الأدوات والصلاحيات؟ شاركني المثال الذي جعلك تشعر أن النظام ذكي فعلًا، أو أن الهارنس خذل النموذج.
