هندسة الأطر التشغيلية تتحول إلى وظيفة حقيقية... فماذا تتضمن فعليًا؟

على مدى العامين الماضيين، كانت النصيحة المهنية المتعلقة بوكلاء الذكاء الاصطناعي تدور في الغالب حول تعلّم كتابة الأوامر (البرومبت) لها بشكل جيد. لم تعد هذه هي المهارة النادرة. المهارة النادرة اليوم هي بناء البنية الداعمة التي يعمل الوكيل داخلها — وهو الشيء الذي يُطلق عليه بشكل متزايد اسم harness — وهي مهارة محددة وصعبة بما يكفي لتتحول إلى وصف وظيفي قائم بذاته، بدلاً من كونها مسؤولية جانبية يتولاها "شخص الذكاء الاصطناعي" في الفريق.

أوضح شرح علني لما يعنيه هذا الأمر فعليًا جاء من نشرة Lenny's Newsletter، التي توثّق كيف قامت أداة إدارة المنتجات ChatPRD ببناء harness لتصحيح أخطاء Sentry تلقائيًا. يستحق المقال قراءة كاملة إذا كنت تفكر في التخصص في هذا المجال، لأنه يطرح نقطة يسهل إغفالها: النموذج لم يكن يومًا هو نقطة الاختناق. استخدم الفريق حزمة Claude Agent SDK كأساس، ثم أنفق معظم جهده الهندسي على واجهة طرفية (terminal UI) مخصصة، ومجموعة من المحوّلات (adapters) التي تربط الوكيل بـ Sentry وLinear وGitHub وVercel. هذه هي الوظيفة، بصورة مصغّرة: أربعة أنظمة، وأربعة مخططات مصادقة مختلفة، وأربعة أشكال بيانات مختلفة، وواجهة تتيح لإنسان أن يراقب ويتدخل دون الحاجة لمراقبة كل خطوة بخطوة.

ما الذي يتكوّن منه "harness" فعليًا

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

• تصميم الصلاحيات. تحديد ما يُسمح للوكيل بفعله دون إشراف (قراءة تذكرة، صياغة طلب سحب) مقابل ما يتطلب وجود إنسان ضمن الحلقة (الدمج، النشر، الحذف، إنفاق المال) — وترميز ذلك كسياسة فعلية داخل الكود، لا كتعليمة في البرومبت قد يتجاهلها النموذج تحت الضغط. هذا أقرب إلى هندسة التحكم في الوصول منه إلى كتابة البرومبت.
• محوّلات الأدوات. أغلفة رقيقة ومختبرة جيدًا حول كل نظام خارجي (Sentry، Linear، GitHub، Vercel، أو أيًا كانت حزمة أدوات شركتك) تترجم نيّة الوكيل إلى استدعاء API آمن ومتحقَّق منه، وتترجم الاستجابة مرة أخرى إلى شيء يمكن للنموذج التفكير فيه. هذه هندسة برمجيات عادية — معالجة الأخطاء، وإعادة المحاولة، والتحقق من صحة المخططات — تُطبَّق على مستهلك جديد.
• واجهة طرفية أو وحدة تحكم. وسيلة تتيح للإنسان رؤية ما يفعله الوكيل، والموافقة على الإجراءات أو رفضها، والتدخل عندما يتوقف. بنت ChatPRD واحدة مخصصة؛ ستستخدم فرق كثيرة بدلًا من ذلك وحدات تحكم جاهزة للوكلاء، لكن يظل على شخص ما أن يقرر ما يُعرض، وما يُخفى، وما يتطلب نقرة قبل حدوثه.
• اختيار الأدوات على نطاق واسع. يشير مقال من Machine Learning Mastery إلى أمر يستحق معرفته إذا كنت تبني أي شيء يتجاوز مجرد عرض توضيحي: تميل دقة الوكيل في استدعاء الأدوات إلى التراجع بمجرد أن يتجاوز كتالوج الأدوات نحو اثني عشر خيارًا تقريبًا — إذ يبدأ النموذج في استدعاء الأدوات الخاطئة، أو اختلاق معاملات وهمية، أو التعثر عند استدعاءات فاشلة. وسائل التخفيف التي يسردها المقال (تقييد الأدوات المرئية أصلًا في سياق معين، والبحث عن الأدوات بالاسترجاع، والتوجيه إلى وكلاء فرعيين متخصصين، وخطوات تخطيط صريحة، ومنطق احتياطي، وأطر اختبار مرجعية لرصد التراجع) هي في حد ذاتها قائمة مهام يحتاج مهندس الـharness إلى معرفة كيفية تنفيذها، لا مجرد معرفتها نظريًا.
• هندسة السياق والذاكرة. يرسم المصدر نفسه تمييزًا يستحق الاستيعاب: هندسة السياق (ما يُدرج في استدعاء استدلال واحد، وأين) وهندسة الذاكرة (ما يبقى عبر الجلسات، وكيف يُخزَّن، وكيف يُسترجَع) تخصصان مختلفان بأنماط فشل مختلفة. وتزعم المقالة أن معظم الأعطال في الوكلاء طويلي الأمد ومتعددي الجلسات تعود جذورها إلى الخلط بين الاثنين — معاملة ذاكرة الجلسة وكأنها مجرد سياق إضافي، أو العكس — خصوصًا عند النقطة التي يقرر فيها النظام ما الذي يجب استرجاعه.

الدليل على أن هذا دور حقيقي وقابل للتمويل — وليس مجرد تخصص للهواة

من المعقول أن يتساءل المتشككون عما إذا كانت "هندسة الـharness" وظيفة قائمة بذاتها أم مجرد مهمة ضمن وظيفة شخص آخر. تشير نقطتا بيانات من الملخص إلى أنها تتجه نحو الاحتمال الأول. أولًا، استخدم فريق Aspire التابع لمايكروسوفت — وهو مجموعة من عشرة أشخاص — أدوات GitHub's Agentic Workflows لأتمتة طلبات سحب التوثيق عبر المستودعات المتعددة، وخلال إصدارين، دمجوا 82 طلب سحب بمتوسط زمني قدره 44.8 ساعة بعد إطلاق طلب سحب المنتج المقابل، دون زيادة في عدد الموظفين أو إعادة تدريب على العمليات. هذا مثال على فريق صغير يحقق نفوذًا غير متناسب تحديدًا لأن أحدًا استثمر في البنية الداعمة (تعريفات سير العمل، وتوجيه المراجعة، ومنطق المشغّلات) بدلًا من ترك المهندسين يكتبون طلبات سحب التوثيق يدويًا. ثانيًا، يتعامل مشروع SkillOpt التابع لـMicrosoft Research مع ملفات "المهارة" الخاصة بالوكلاء — التعليمات والقيود التي تشكّل سلوك الوكيل داخل الـharness الخاص به — بوصفها شيئًا ينبغي تحسينه بشكل منهجي بدلًا من تعديله يدويًا، ويفيد التقرير بأنه كان الأفضل أو متعادلًا مع الأفضل في جميع الخانات الاثنتين والخمسين لشبكة اختبار مرجعية (ستة اختبارات مرجعية، وسبعة نماذج، وثلاثة أنماط تنفيذ)، مع قابلية نقل المهارات المحسَّنة عبر نماذج مختلفة وharnesses مختلفة. وبصرف النظر عمّا إذا كانت هذه الأداة بعينها ستصبح معيارًا قياسيًا أم لا، فإنها تشير إلى أن القطاع بدأ يتعامل مع إعداد الـharness كمُنتَج هندسي له أدواته ومقاييسه المرجعية الخاصة — وهو المسار نفسه الذي حوّل "DevOps" من مجموعة سكربتات ارتجالية إلى تخصص قائم بذاته.

هناك أيضًا بنية تحتية تُبنى الآن خصيصًا لهذه الطبقة. تُعدّ قدرات "Managed Agents" التي أعلنت عنها جوجل مؤخرًا ضمن Gemini API — التنفيذ في الخلفية وغير المتزامن، والتكامل مع خوادم MCP عن بُعد، واستدعاء الدوال المخصصة، وتجديد بيانات الاعتماد عبر التفاعلات — بمثابة بنية جاهزة مسبقًا لنفس المشكلات التي حلّها فريق ChatPRD يدويًا. هذا نمط معتاد: ما يبنيه فريق واحد بشكل مخصص هذا العام، يحوّله مزوّد منصة إلى منتج جاهز في العام المقبل. هذا لا يُلغي دور هندسة الـharness؛ بل يرفع الحد الأدنى المطلوب وينقل الوظيفة نحو دمج وتهيئة عناصر أولية مُدارة بدلًا من كتابة كل محوّل من الصفر، على غرار كيف أن البنية التحتية السحابية لم تُلغِ مهندسي العمليات، بل غيّرت ما يقضون وقتهم في فعله.

ماذا يعني هذا إذا كنت تستهدف هذا الدور

هناك بضعة أمور ملموسة وقابلة للتحقق يمكن إضافتها إلى ملف أعمالك أو سيرتك الذاتية إذا أردت أن تكون موثوقًا في هذا المجال: ابنِ محوّلًا واحدًا من طرف إلى طرف مقابل API حقيقي لا تتحكم فيه (بما يشمل المصادقة، ومعالجة الأخطاء، وحدود معدل الاستخدام، وليس مجرد عرض توضيحي للمسار السعيد)؛ صمّم ووثّق نموذج صلاحيات لوكيل يميّز بين إجراءات القراءة/الاقتراح/التنفيذ ويوضّح لماذا يقع كل حد فاصل حيث يقع؛ وابنِ أو هيّئ واجهة مراجعة يوافق فيها إنسان على إجراءات الوكيل قبل تنفيذها، لأن هذا هو الجزء الذي ستُصرّ عليه معظم الشركات قبل السماح لوكيل بلمس بيئة الإنتاج. وإذا كنت تقيّم عرض عمل في هندسة الـharness أو تحدد نطاق مسؤولياتك الخاصة، اسأل تحديدًا مَن يملك نموذج الصلاحيات، ومَن يملك المحوّلات، ومَن يملك واجهة المراجعة البشرية — ففي كثير من الفرق حاليًا، لا يوجد مالك واضح لهذه الأمور الثلاثة، وهذه بالضبط هي الفجوة التي يتشكّل هذا الدور لسدّها.

تحفظ واحد يستحق ذكره بوضوح: لا يُثبت أيٌّ من المصادر أعلاه رقمًا في سوق التوظيف لهذا المسمى الوظيفي تحديدًا، و"مهندس harness" ليس مسمى وظيفيًا سترونه بعد في إعلانات التوظيف — بل يظهر ضمن مسميات مثل "مهندس بنية تحتية للذكاء الاصطناعي"، أو "مهندس منصة وكلاء"، أو ببساطة "مهندس خلفية أول، أنظمة الذكاء الاصطناعي". تعامل مع هذا بوصفه مجموعة مهارات ينبغي بناؤها ووصفها بدقة، لا مسمى وظيفي تبحث عنه على LinkedIn.