لما بنتكلم عن الـ AI Agents، الفكرة غالبًا بتتباع لنا بشكل بسيط جدًا: ادّي للـ Agent هدف، وهو يخطط، يستخدم الأدوات، ينفّذ، ويرجعلك بالنتيجة.

لكن في الواقع العملي، خصوصًا داخل الأنظمة الحقيقية في الشركات، الموضوع مش بيكون بالبساطة دي.

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

لما بنتكلم عن AI Agent قوي زي Claude Fable 5، السؤال الطبيعي بيبقى:
هل القوة كلها جوه الموديل؟ ولا في النظام اللي حوالين الموديل؟ وهنا بيظهر دور الـ Harness!

الـ Harness هو الطبقة اللي بتتحط حوالين الـ Agent علشان تخليه قابل للاستخدام في نظام حقيقي، مش مجرد Demo لطيف .. تقدر تتخيله كأنه Wrapper حوالين الـ Agent، فهو مش العقل نفسه، ولكنه البيئة اللي بتنظّم شغله، وتحدد له الأدوات، وتتابع حالته، وتراقب نتائجه.

فببساطة هو “الإطار” أو “النظام” اللي بيشغّل الـ Agent ويسيطر على طريقة شغله. مش شرط يكون جزء من الموديل نفسه، لكنه كل حاجة بتخلي الموديل يشتغل في اتجاه واضح بدل ما يفضل مجرد عقل ذكي بيرد على prompts.

ممكن تتخيله زي البيئة اللي بتحاوط موظف جديد في شركة. الموظف ممكن يكون شاطر جدًا، بس من غير access واضح، rules، review process، tools، logs، وحدود صلاحيات… هيغلط، أو هيشتغل بعشوائية، أو ياخد قرارات أكبر من حجمه.

مكونات الـ Harness

1. Instructions و System Prompts
دي القواعد الأساسية: أنت مين؟ شغلك إيه؟ متعملش إيه؟ إمتى تسأل؟ وإمتى ترفض؟

2. Tools
زي إن الـ Agent يعرف يقرأ ملفات، يشغّل tests، يفتح issue، يعمل search، يكتب كود، أو يتعامل مع API. من غير tools، الموديل ذكي بس محبوس في الكلام بس.

3. Memory و Context
الـ Agent محتاج يعرف هو شغال على إيه، المشروع شكله إيه، القرارات القديمة كانت إيه، وإيه اللي اتجرب قبل كده. بس هنا لازم نفرّق بين context مفيد و context زيادة يخليه يتوه ويحصله Hallucination.

4. Permissions و Boundaries
مينفعش كل Agent يبقى معاه كل الصلاحيات. في فرق بين Agent يقترح كود، وAgent يعمل merge، وAgent يعدل production config. كل مستوى بيحتاج حدود واضحة من الصلاحيات.

5. Feedback Loop
الـ Agent لازم يراجع نفسه أو يتراجع من أدوات تانية: tests، linters، static analysis، human review، أو حتى Agent تاني ناقد. من غير feedback loop، احنا هنكون بنثق في أول إجابة بترجعلنا وخلاص.

6. Observability
وده جزء مهم جدًا غالبًا الناس بتنساه .. لازم تعرف الـ Agent عمل إيه، استخدم أنهي tool، قرر بناءً على إيه، فشل فين، وهل النتيجة اتحسنت ولا لأ ، لإن من غير logs وmetrics، مفيش طريقة نعرف هل فعلاً بيساعد ولا بيعمل noise.

والنقطة الجميلة في الموضوع هنا إن الناس مش متفقة 100٪ على ماهية الـ Harness لسه:
هل الـ Harness ده جزء من الـ Agent نفسه؟ ولا هو النظام اللي المستخدمين والشركة بيبنوه حوالين الـ Agent؟

الاختلاف ده طبيعي جدًا لأن كلمة Agent نفسها بقت مطاطة شوية .. فيه ناس بتشوف إن الـ Agent هو الموديل + الأدوات + الذاكرة + طريقة التخطيط وده معناه إن الـ Harness داخل في تعريف الـ Agent.

وناس تانية بتفصل بينهم: الموديل هو “العقل”، والـ Harness هو “البيئة التشغيلية” اللي بتحط العقل ده في سياق آمن ومنظم .. والفصل ده مفيد أكتر للمطورين.

لأنك لو قلت إن كل حاجة اسمها Agent، هتنسى إن فيه شغل هندسي كبير جدًا خارج الموديل: تصميم الصلاحيات، بناء الأدوات، إدارة الـ context، قياس الجودة، التعامل مع الفشل، وتحديد إمتى الإنسان يدخل في القرار.

عشان كده مع موديلات أقوى زي Fable 5، قيمة الـ Harness بتزيد مش بتقل ، لأن كل ما الموديل بقى أقوى وعنده إمكانيات أعلى، الغلطة بتاعته بقت تأثيرها أكبر .. والموضوع مبقاش: “هل الموديل يقدر يعمل المهمة؟” بقى: “هل إحنا بنشغّله جوه نظام يخليه يعمل المهمة صح، بأمان، وبشكل قابل للمراجعة؟”