لا تحتاج إلى أدوات أكثر. تحتاج إلى AI Harness

كيف يتحول النموذج من محادثة تجيب عن الأسئلة إلى جزء من عمل يمكن تنفيذه وفحصه واستكماله؟ شرح لبنية AI Harness، وحدودها، وطريقة اختبار فائدتها.

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

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

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

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

ما الذي يضيفه AI Harness إلى النموذج؟

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

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

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

وتوضح تجربة هندسية نشرتها Anthropic للمهام الطويلة أهمية هذه الاستمرارية: احتاجت الجلسات المتعاقبة إلى سجل تقدم ونتائج يمكن استكمالها، ولم يكن اختصار المحادثة وحده كافيا. هذه ملاحظة من تجربة محددة، وليست دليلا على أن Harness واحدا يناسب كل الأعمال. المصدر: Effective harnesses for long-running agents.

أداة، وWorkflow، وHarness: أين يختلف دور كل منها؟

الأداة تنجز فعلا محددا: قراءة ملف، أو الاستعلام من قاعدة بيانات، أو تشغيل فحص. ويمكن أن تكون وظيفة Python قصيرة. أما Workflow فيربط خطوات وفق ترتيب وشروط محددة، مثل جلب البيانات ثم فحصها ثم إصدار التقرير.

يضيف Harness إدارة ما يحتاجه النموذج أثناء هذا العمل: ما المعلومات التي يراها؟ كيف يختار الخطوة التالية؟ متى يسمح باستدعاء أداة؟ وكيف يستأنف المهمة بعد انقطاعها؟ ويمكن أن يجمع Workflow ثابتا في بعض المراحل مع قرار يتخذه النموذج في مراحل تحتاج إلى تفسير أو تحقيق.

لهذا قد يكون Workflow بسيط هو الاختيار الأنسب لعملية مستقرة ومحددة. أما إذا كانت المهمة تتطلب فحص حالات غير متوقعة، والرجوع إلى مصادر مختلفة، والعمل عبر جلسات متعددة، فتصبح إدارة السياق والحالة والقرارات أكثر أهمية. زيادة الاستقلالية قد تزيد التكلفة ووقت التنفيذ أيضا؛ وهذا من المفاضلات التي تناقشها Anthropic في إرشادات بناء هذه الأنظمة. المصدر: Building effective agents.

كيف تمر مهمة داخل Harness؟

تبدأ المهمة بهدف يمكن فحصه. عبارة «حلل البيانات» تترك معنى الإنجاز مفتوحا. أما «افحص الملف وفق Data Contract المحدد، وأخرج المخالفات مع أرقام السجلات، ولا تعدل المصدر» فتحدد المدخلات والمخرج وحدود التصرف. وData Contract هو وصف متفق عليه لشكل البيانات ومعناها والشروط التي يجب أن تحققها.

بعد ذلك تحدد هوية المستخدم ومساحة العمل، ويجهز Context من المصادر المسموحة وإصداراتها الحالية. يجب فصل التعليمات المعتمدة عن المحتوى الذي يستخدم كدليل. وجود أمر داخل ملف مستورد لا يمنحه حق تغيير التعليمات أو توسيع الصلاحيات.

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

ويجب حفظ الحالة عند نقاط معروفة: ما الذي قرئ؟ ما الذي تغير؟ ما الفحص الذي نجح؟ وما الذي ينتظر قرارا؟ إذا انقطع الاتصال بعد إرسال تعديل، يحتاج الاستئناف إلى معرفة هل وقع التعديل بالفعل. تساعد مفاتيح Idempotency، حيث يدعمها النظام، على منع تكرار أثر الطلب نفسه عند إعادة إرساله.

مثال قابل للفحص: طبقة Data Quality

لنفترض أن فريقا يجمع بيانات تشغيلية من API وملف دوري. تختلف أسماء الحقول بين المصدرين، وقد تتكرر سجلات أو تصل قيم ناقصة. الهدف إعداد بيانات صالحة لتحليل محدد، مع تقرير بما تعذر اعتماده.

يمكن تقسيم المهمة بين مرجع للقواعد، وكود للفحص، ونموذج للتفسير. يصف Data Contract الحقول المطلوبة وشروطها. توحد خطوة Mapping الأسماء والقيم وفق قواعد معلومة. ثم تنفذ Python الفحوص الحسابية والمنطقية، ويشرح النموذج المخالفات أو يقترح أسئلة للتحقيق فيها.

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

def check_rows(rows):    issues, seen = [], set()    for index, row in enumerate(rows):        record_id = row.get("id")        if record_id is None:            issues.append((index, "missing_id"))        elif record_id in seen:            issues.append((index, "duplicate_id"))        else:            seen.add(record_id)        if type(row.get("amount")) not in (int, float):            issues.append((index, "invalid_amount"))    return issues

يفترض الكود أن المعرفات قابلة للإضافة إلى set. ولا يفحص العملة أو نطاق القيم أو القيم العددية غير المنتهية أو علاقة السجلات بعضها ببعض. تحدد هذه الشروط بحسب المهمة، ثم تضاف لها فحوص صريحة. هذا أدق من مطالبة النموذج بأن «يتأكد أن كل شيء صحيح».

إذا ظهرت قيمة ناقصة، يحفظ Harness المخالفة ومصدرها وما اتخذ بشأنها. وقد يقترح النموذج تفسيرا أو إصلاحا، لكن نشر الإصلاح يحتاج إلى القواعد والصلاحيات المناسبة. وكتابة Data Contract لا تنشئ فحوصه تلقائيا؛ يجب تنفيذها واختبارها.

الذاكرة: ماذا يحفظ النظام، وبأي صفة؟

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

لذلك يفيد فصل أربعة أنواع من السجلات. المصدر هو الوثيقة أو المحتوى الأصلي. والمعلومة المستخرجة ترتبط بدليل وإصدار. وطريقة العمل المعتمدة تحدد خطوات وشروطا يمكن إعادة استخدامها. أما سجل التنفيذ فيصف ما حدث في مهمة بعينها، بما فيه الفشل والتصحيح.

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

إذا تغير الأصل، يجب أن تظهر صلة التغيير بما اشتق منه. ولا يكفي أن تبقى نتيجة قديمة في البحث لأنها تشبه سؤال المستخدم. الاسترجاع الجيد يجمع الصلة بالسؤال مع صلاحية الدليل وإذن الوصول إليه.

التعلم المستمر له مساران، ولا يعني تدريب النموذج

المسار الأول تحديث ما يعرفه النظام عن العمل. يصل إصدار جديد من مصدر، فيحفظ ويربط بمهمة المعالجة. تعاد مراجعة المعلومات التي اعتمدت على الإصدار السابق، ثم تستخرج المعلومات المناسبة من الجديد. يجب التحقق من الإصدار والصلاحيات عند حفظ النتيجة أيضا، فقد تتغير أثناء المعالجة.

المسار الثاني تحسين طريقة العمل. ينفذ النظام مهمة، ويسجل الخطوات والفحوص والتصحيحات. إذا كشف التقرير طريقة مفيدة، يمكن إعداد Skill، أي تعليمات قابلة لإعادة الاستخدام ضمن شروط محددة. تراجع المسودة ويعتمدها من يملك حق النشر قبل أن تصبح مرجعا للمهام التالية.

بهذا يمكن أن يصل تصحيح في Mapping إلى مهام لاحقة، مع إبقاء استثناء يخص ملفا واحدا مرتبطا بذلك الملف. ولا ينبغي أن يتحول كل تكرار إلى قاعدة؛ أحيانا يتكرر الخطأ لأن المصدر نفسه معيب، أو لأن المستخدم اضطر إلى حل مؤقت.

هذا تعلم في حالة النظام ومراجعه وطرقه. لا يتطلب بالضرورة Fine-tuning، أي تعديل أوزان النموذج بالتدريب. ويتوقف نجاحه على وصول التحديثات، وجودة الأدلة، والمراجعة، واختبار أثر الطريقة الجديدة. كثرة السجلات وحدها لا تثبت تحسن الأداء.

نواة مشتركة، وصلاحيات مختلفة لكل مستخدم

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

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

كذلك تختلف صلاحية القراءة عن التنفيذ وعن النشر. يستطيع مستخدم المساهمة بملاحظة من دون اعتمادها قاعدة، وقد تستطيع أداة قراءة نظام من دون تحديثه. تحتاج الإجراءات ذات الأثر إلى تفويض يمكن للبرمجيات التحقق منه؛ كتابة «لا تفعل» في Prompt لا تعوض هذا الضبط.

وهذه الحدود تتعلق بالاتصال كله. إذا امتلك التطبيق طريقا مستقلا واسع الصلاحيات إلى الملفات أو الخدمات، فلا تحميه قيود النواة وحدها. يجب ضبط صلاحيات الأداة والنظام الخارجي أيضا.

التكامل المباشر: ما دور API وMCP وPython؟

لا يشترط ربط Harness بأنظمة العمل شراء منصة أتمتة وسيطة. إذا أتاح النظام API مناسبا، يمكن كتابة Adapter في Python يقرأ البيانات المسموحة ويحولها إلى صيغة واضحة. ويمكن استخدام MCP لتقديم أدوات وموارد بواجهة موحدة للتطبيقات التي تدعمه.

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

تؤثر طريقة تصميم الأداة في سلوك النموذج. الاسم الواضح، والمدخلات المحددة، والنتيجة المختصرة المفيدة، تساعده على اختيار الاستدعاء المناسب وفهم ما حدث. وتناقش إرشادات Anthropic لتصميم الأدوات أهمية اختبارها على مهام فعلية وتحسين نتائجها لتقليل السياق غير المفيد. المصدر: Writing effective tools for agents.

محلي أم سحابي؟ افصل مكان الذاكرة عن مكان المعالجة

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

والتشغيل المحلي لا يثبت وحده أن البيانات لا تغادر الجهاز. قد تتصل أداة بخدمة خارجية، أو يرسل جزء من السياق إلى نموذج سحابي، أو تستخدم معالجة خارجية لاستخراج محتوى. يلزم تتبع مسار البيانات فعليا: أين تحفظ، وأين تعالج، وما الذي يرسل، ولمن؟

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

Atmet Brain مثال على جزء من هذه البنية

يمكن توضيح هذا الفصل بنواة Atmet Brain. النواة المكتوبة بـPython وتستخدم SQLite تدير المصادر والذاكرة وطرق العمل وإصداراتها وصلاحيات الوصول. وتصل واجهات CLI وPython وREST وMCP إلى منطق النواة نفسه. أما استخدام النموذج وتشغيل الأدوات فيبقيان من مسؤولية التطبيق المتصل.

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

context = brain.get_context(    actor=actor,    space_id=workspace_id,    query="Prepare data quality checks for this source",    task_path="engineering/data_pipeline",    max_chars=12000,)

تفصل النتيجة التعليمات المعتمدة عن الأدلة المرجعية وتوضح الموارد المستخدمة. ويقيس max_chars هنا الحجم بالحروف، لا عدد Tokens لدى مزود النموذج. وإذا تعذر توفير التعليمات المطلوبة ضمن القيود، تعيد النواة incomplete_context بدلا من إسقاطها بصمت.

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

أين يمكن أن يوفر الوقت وTokens؟

قد يأتي التوفير من إرسال ما تحتاجه المهمة بدلا من تكرار ملفات طويلة، ومن إعادة استخدام طريقة سبق فحصها، ومن إبقاء الحسابات المستقرة في الكود. وقد تقل إعادة جمع المعلومات إذا احتفظ النظام بحالة العمل ومراجعها بصورة صالحة للاستكمال.

لكن الذاكرة والاسترجاع والفحوص نفسها لها تكلفة. وقد تحتاج مراجعة طريقة جديدة إلى وقت أطول من كتابة سكربت لمرة واحدة. لذلك لا يصح استنتاج التوفير من عدد Tokens في طلب واحد أو من نجاح عرض تجريبي.

المقياس الأجدى هو تكلفة نتيجة مقبولة: استخدام النماذج، ووقت تشغيل الأدوات، وجهد الإعداد والمراجعة، والمحاولات الفاشلة وإعادة العمل. وقد تقل Tokens وتزداد هذه التكلفة، أو تزيد الاستدعاءات بينما يتحسن الإنجاز بما يبررها. الحكم يحتاج إلى قياس على المهام التي سيستخدم فيها النظام.

كيف تختبر الفكرة بدلا من الاكتفاء بالمخطط؟

اختر مجموعة مهام تمثل العمل المعتاد وحالاته الصعبة. احتفظ بحالات لم تستخدم في تعديل التعليمات، وحدد مسبقا ما الذي يعد نتيجة مقبولة: مخالفات تكتشف، وقيم تنتج، وأفعال يجب ألا تقع. في مهام البيانات، يمكن مقارنتها بنتائج مرجعية وفحوص مستقلة.

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

اختبر الاستمرار أيضا: أوقف المهمة بعد خطوة معروفة، ثم استأنفها. حدث مصدرا أثناء المعالجة. اسحب إذن مستخدم. أعد إرسال طلب سبق تنفيذه. بهذه الحالات يتضح هل يحفظ النظام حالة مفيدة، أم يعيد التخمين أو يكرر الأثر أو يستخدم مرجعا انتهت صلاحيته.

ولقياس التعلم، أضف تصحيحا بعد الجولة الأولى، وراجعه وفق المسار المحدد، ثم اختبر مهام جديدة ينطبق عليها. يجب أن يتحسن التعامل مع الحالة المقصودة من دون نشر الاستثناء على حالات أخرى. هذا اقتراح لبروتوكول اختبار، وليس نتائج مقاسة لـAtmet أو لأي منتج آخر.

متى يكفي سكربت، ومتى تحتاج إلى Harness؟

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

تصبح فكرة Harness أكثر وجاهة حين يتكرر العمل عبر جلسات، وتتغير مصادره، ويحتاج إلى أدوات وصلاحيات مختلفة، وتهمك معرفة سبب القرار واستكمال ما توقف. يمكن البدء بمهمة واحدة: مرجع واضح، وأدوات قليلة، وحالة محفوظة، وفحص مستقل، وحد للمراجعة البشرية.

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