مدخل إلى هندسة الهارنس: كيف يعمل وكلاء البرمجة فعلًا

بقلم Ariful Islam التاريخ: ٢٤ سبتمبر ٢٠٢٦ النوع: مقالة التصنيف: الذكاء الاصطناعي الوسوم: ai-agents, harness-engineering, context-engineering, claude-code, codex, coding-agents, linux

ما هو هارنس الوكيل؟

هارنس الوكيل هو كل البرمجيات التي تحيط بالنموذج اللغوي وتجعل منه وكيلًا يعمل. لخّصت Birgitta Böckeler من Thoughtworks الفكرة في معادلة قصيرة، في مقال على موقع Martin Fowler: الوكيل = النموذج + الهارنس.

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

دورة واحدة من الحلقة لكل خطوة. النموذج والعالم الحقيقي وحدهما خارج الهارنس، فكل ما يراه النموذج وكل ما يُسمح له بلمسه يمر عبر جزء بناه أحدهم. وما يعود في كل دورة هو تغذية راجعة: المخرجات، ورمز الخروج، وما تبلّغ عنه الخطافات. أما تشغيل الاختبارات نفسها فغالبًا ما يقرره النموذج بنفسه، أو يفرضه عليه خطاف.

كثيرًا ما يُخلط بين الهارنس وإطار العمل، وهما شيئان مختلفان. LangChain وMicrosoft Agent Framework وOpenAI Agents SDK أطر عمل، أي مجموعات من القطع تبني منها وكيلًا. أما الهارنس فهو بيئة التشغيل المكتملة التي تنتج عن تركيب هذه القطع. Claude Code هارنس، وكذلك Codex CLI. والخط الفاصل بينهما بدأ يبهت، لأن عددًا من أطر العمل صار يأتي بهارنس جاهز خاص به.

لماذا يهم الهارنس

هذه تجربة أتمنى لو سمع بها عدد أكبر من الناس. خذ نموذجًا واحدًا وأعطه 169 مهمة حقيقية لإصلاح الأخطاء من SWE-bench Verified. لا تلمس أوزان النموذج ولا المهام ولا نافذة السياق، وغيّر الكود الذي يعمل حول النموذج فقط. سيقفز عدد المهام المحلولة بالكامل من 43 إلى 72.

النتيجة من ورقة بحثية نُشرت على arXiv في أغسطس، وهي أقصر جواب عندي عن موضوع هذا المقال. النموذج لم يتغير بين التجربتين. الذي تغيّر هو الهارنس (agent harness).

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

التعليمات، ثم السياق، ثم الهارنس

وصل المجال إلى هنا على ثلاث مراحل، وكل مرحلة احتوت التي سبقتها.

لم يُستبدل شيء. التعليمات والسياق ما زالا مهمين، لكنهما صارا جزأين من الهارنس يعيشان داخله.

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

الحلقة كلها في ثلاثين سطرًا

أسهل طريقة لفهم الهارنس أن تكتب واحدًا. وإليك جوهر وكيل برمجة مكتوبًا بشبه الكود (pseudocode). هو مبسّط، لكن كل هارنس حقيقي قرأت كوده يأخذ هذا الشكل.

def run_agent(task, model, tools, limits):
    context = [system_prompt(), project_memory(), task]

    for step in range(limits.max_steps):
        if count_tokens(context) > limits.window * 0.8:
            context = compact(context)          # summarize old turns

        reply = model.generate(context, tools=tools.schemas())

        if reply.is_done:
            report = verify(reply)              # run tests, linters, a reviewer
            if report.passed:
                return reply
            context.append(report.as_feedback())
            continue

        for call in reply.tool_calls:
            if not policy.allows(call):
                result = ask_human(call) or "denied by policy"
            else:
                result = tools.run(call)        # most of the time: a shell command
            context.append(trim(result))        # keep the lines that matter

        if same_command_failed(context, times=3):
            context.append("That failed three times. Try a different approach.")

    return stop_and_report(context)

عُدّ الأسطر التي تتعامل مع النموذج. ستجد سطرًا واحدًا: model.generate. كل ما عداه هارنس، وكل سطر منه قرار اضطر أحدهم إلى اتخاذه. متى تضغط السياق؟ كم يرى النموذج من سجل اختبارات طوله 4000 سطر؟ ماذا يقول policy.allows عن git push --force؟ غيّر أي إجابة من هذه، وسيتصرف النموذج نفسه كأنه وكيل آخر.

الأجزاء واحدًا واحدًا

الحلقة

خطّط، نفّذ، راقب، كرّر. والنواة صغيرة فعلًا: وكيل Pi الذي كتبه Mario Zechner يُبقي تعليمات النظام وتعريفات الأدوات كلها دون 1000 توكن. الصعوبة كلها فيما يحيط بالحلقة: متى تتوقف، ومتى تسأل إنسانًا، وماذا تفعل حين يشغّل الوكيل الأمر الفاشل نفسه للمرة الخامسة. ولهذه الحالة بالذات وُضع سطر same_command_failed في الكود أعلاه.

الأدوات

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

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

السياق

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

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

ورقة أغسطس التي ذكرتها سابقًا، «Same Model, Different Harness»، هي أوضح دليل رأيته على هذا. التجربتان استخدمتا أوزان النموذج نفسها، والمهام الـ169 نفسها من SWE-bench Verified، وسعة السياق نفسها، وطريقة التشغيل نفسها. واختلف الهارنس الجديد في أمرين فقط: كان يقصّر نتائج الأدوات القديمة على مراحل كلما امتلأت النافذة، وإذا وجد الوكيل يعيد أوامر سبق أن فشلت، طلب منه أن يجرب طريقًا آخر.

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

التقنيات المعتادة:

التقنية	ما تفعله
الضغط (compaction)	تلخّص الجولات القديمة حين يرتفع عدد التوكنات
القص (truncation)	تقلّص مخرجات الأدوات القديمة وتُبقي الحديثة كاملة
ملفات الذاكرة	ملاحظات تُحمَّل في بداية كل جلسة، مثل ملف CLAUDE.md أو AGENTS.md في المشروع
الوكلاء الفرعيون	تعطي المهمة الجانبية سياقًا جديدًا خاصًا بها، ولا يعود منها إلا الجواب
إعادة ضبط السياق	تمسح النافذة بالكامل وتبدأ جلسة جديدة من ملف تسليم مكتوب

الصف الأخير أحدث من البقية، ووراءه سبب لن يخطر لك. وجد فريق Anthropic الذي يبني تطبيقات تعمل لساعات طويلة أن «الضغط وحده لم يكن كافيًا». فمع امتلاء النافذة بدأت النماذج تُظهر ما يسمونه قلق السياق (context anxiety)، أي أنها تستعجل إنهاء العمل لأنها تشعر باقتراب الحد. فالبدء بنافذة نظيفة وملف تسليم منظّم أعطى نتائج أفضل من ملخص يعرف النموذج أنه لم يُكتب إلا لأن المساحة توشك أن تنفد.

حواجز الحماية

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

• اسأل قبل كل شيء. وهو السلوك الافتراضي في Cline: كل إجراء ينتظر موافقتك.
• دع مصنِّفًا يقرر. الوضع التلقائي في Claude Code (وهو الوضع الذي تبدأ به خطط Pro وMax وTeam) وخاصية Auto-review في Cursor يكلّفان نموذجًا ثانيًا بمراجعة الإجراءات بدل أن يسألاك في كل مرة.
• اعزله. يعمل Codex CLI افتراضيًا داخل بيئة معزولة على مستوى نظام التشغيل، محصورًا في مساحة العمل والشبكة مقطوعة عنه.
• ثق بالمستخدم. لا عزل في Pi ولا طلبات إذن. مطوّره يسميه «وضع YOLO الكامل»، وينصح بتشغيله داخل حاوية.

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

التحقق

هذه الطبقة هي ما يسمح لك بأن تثق بالوكيل دون أن تقرأ كل سطر يكتبه. تقسمها Böckeler إلى نوعين من الضبط. الموجِّهات (guides) تقود الوكيل قبل أن يتصرف: تعليمات، وأعراف، وأمثلة. والمستشعرات (sensors) تراقب النتيجة بعد ذلك وتساعده على تصحيح نفسه: اختبارات، وأدوات lint، ومدققات أنواع، ووكلاء مراجعة. في شبه الكود أعلاه، project_memory() موجِّه وverify() مستشعر.

مقال OpenAI «Harness engineering: leveraging Codex in an agent-first world» يقف عند أقصى هذا الطرف. فريق بدأ بثلاثة مهندسين أطلق نسخة تجريبية داخلية دون سطر واحد مكتوب باليد، وكان قد دمج حتى ذلك الحين نحو 1500 طلب سحب (pull request). كتب Codex التطبيق والاختبارات وإعدادات CI والتوثيق، وبنى البشر الهارنس: الفحوص، والبنية، وحلقات التغذية الراجعة التي أبقت الوكيل على المسار.

المشكلة أن الوكيل لا يُحسن الحكم على عمله. ومقال Anthropic نفسه يقولها بلا مواربة: إذا طُلب من الوكلاء تقييم ما أنتجوه، فإنهم «يميلون إلى الرد بمديح العمل بثقة»، حتى حين يرى الإنسان بوضوح أنه متوسط المستوى. وكان حلّهم أن يوزعوا المهمة على ثلاثة وكلاء: مخطِّط يكتب المواصفات، ومنفِّذ يبني، ومقيِّم مستقل يختبر التطبيق وهو يعمل باستخدام Playwright، وفق معايير اتُّفق عليها قبل كتابة أي كود. الوكيل المنفرد استغرق 20 دقيقة وكلّف 9 دولارات. والهارنس الكامل استغرق ست ساعات وكلّف 200 دولار، لكن النتيجة كانت أفضل بكثير. التحقق لا يحدث من تلقاء نفسه، ولا بد أن يبنيه أحد داخل الهارنس، وأحيانًا في صورة وكيل ثانٍ كامل لا عمل له إلا أن يكون صعب الإرضاء.

قابلية التوسعة

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

هذا خطاف حقيقي من النوع الذي أضيفه في اليوم الأول. بعد كل تعديل على ملف، يشغّل أداة التنسيق على الملف الذي تغيّر:

{
  "hooks": {
    "PostToolUse": [
      {
        "matcher": "Edit|Write",
        "hooks": [
          {
            "type": "command",
            "command": "jq -r '.tool_input.file_path' | xargs npx prettier --write"
          }
        ]
      }
    ]
  }
}

انظر إلى الأمر. يمرر الهارنس الحدث بصيغة JSON على المدخل القياسي، فيستخرج jq حقلًا واحدًا، ويسلّمه xargs إلى برنامج آخر. هذا خط أنابيب يونكس (pipeline)، وهذا ليس مصادفة.

لماذا يقوم الشِل بمعظم العمل

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

grep "Failed password" /var/log/auth.log | awk '{print $(NF-3)}' | sort | uniq -c | sort -rn | head

يعطيك هذا السطر كل عنوان IP حاول اقتحام SSH على الخادم بتخمين كلمات المرور، معدودًا ومرتبًا، من خمسة برامج لا يعرف أحدها شيئًا عن الآخر. والإحساس نفسه يعود إليّ كلما شاهدت وكيل برمجة يعمل: يمد يده إلى الأدوات ذاتها، وبالترتيب الذي كنت سأتبعه تقريبًا:

$ rg -n "InvoiceTotal" src/
$ sed -n '118,160p' src/billing/invoice.ts
$ npm test -- invoice
$ git diff --stat

رأيي أن معظم قدرة وكيل البرمجة على الفعل تأتي من هنا. أعطِ النموذج أداة واحدة، هي الشِل، فيحصل معها على كل برنامج موجود على الجهاز. لم يضطر أحد إلى بناء أداة search_code أو أداة run_tests، فـrg وnpm test موجودان أصلًا، ووراءهما عقود من التوثيق.

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

أظن أن أربعة أشياء تجعل الشِل مناسبًا للنموذج اللغوي إلى هذا الحد.

أولها أن لغته النص. دوّن Doug McIlroy القاعدة في Bell System Technical Journal عام 1978: «توقّع أن تصير مخرجات كل برنامج مدخلات لبرنامج آخر لم يُعرف بعد». لم يكن أحد في مختبرات بِل يفكر في النماذج اللغوية طبعًا، لكن «برنامج مجهول يقرأ مخرجاتك» وصف منصف لها.

وثانيها أن النماذج تعرفه مسبقًا. خمسون عامًا من صفحات man وسكربتات الشِل وملفات README وإجابات المنتديات موجودة في بيانات التدريب. وقالها Zechner صراحة حين شرح لماذا لا يأتي Pi إلا بأربع أدوات (read وwrite وedit وbash): «النماذج تعرف كيف تستخدم bash».

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

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

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

ووصلت الشركات المزوّدة إلى الاستنتاج ذاته من الجهة المقابلة. تصف Anthropic المبدأ الذي صممت عليه Claude Agent SDK بأنه منح «وكلائك حاسوبًا، ليعملوا كما يعمل البشر». وقال Boris Cherny، مبتكر Claude Code، إن النسخ الأولى اعتمدت على RAG مع قاعدة بيانات متجهات محلية، ثم انتقل الفريق إلى البحث الوكيلي البسيط (النموذج يشغّل grep وأخواته) لأن نتائجه كانت أفضل. وهو يعترف بأن ذلك كان في الغالب انطباعًا داخليًا لا نتيجة قياس، لكنه ما أطلقوه فعلًا. أما Vercel فقلّصت وكيل بيانات داخليًا حتى لم يبقَ منه تقريبًا إلا أداة bash واحدة، وذكرت أنه صار أسرع بـ3.5 مرة باستهلاك توكنات أقل بنسبة 37%. لكن ذلك كان على خمسة استعلامات اختبارية فقط، فخذه مؤشرًا على الاتجاه لا قياسًا.

وللشِل حدود أيضًا، ومن المفيد أن تعرفها. فهو لا يستطيع النقر داخل تطبيق ويب، لذا ما زال العمل على الواجهات الرسومية يحتاج إلى أدوات تتحكم بالمتصفح أو بالحاسوب. ومنتج SaaS لا يملك واجهة سطر أوامر تصل إليه عبر واجهة برمجية أو خادم MCP. ثم إن الشِل الذي يشغّل npm test يستطيع أن يشغّل rm -rf أيضًا، ولهذا يوجد قسم حواجز الحماية أصلًا.

مقارنة بين وكلاء البرمجة

هذه وكلاء البرمجة التي يسألني الناس عنها أكثر من غيرها، كما هي في سبتمبر 2026. الإعدادات الافتراضية تتغير بسرعة، فراجع التوثيق قبل أن تعتمد على أي خانة.

الوكيل	مفتوح المصدر	النماذج	الأمان الافتراضي	الأدوات المدمجة
Claude Code	لا	Claude فقط	مصنِّف في Pro وMax وTeam، وإلا فيسأل	أكثر من 40، أساسها Read وEdit وGrep وGlob وBash
Codex CLI	Apache 2.0	OpenAI افتراضيًا، وغيرها عبر الإعدادات	عزل على مستوى النظام، مساحة العمل فقط، بلا شبكة	الشِل غالبًا، ومعه apply_patch
Gemini CLI	Apache 2.0	Gemini فقط	بلا عزل، يطلب التأكيد قبل أوامر الشِل والكتابة	نحو 20، منها الشِل وgrep
Cursor	لا	مزودون كثيرون	شِل معزول، ومصنِّف يراجع الباقي	البحث والقراءة والتعديل والشِل والمتصفح
OpenHands	MIT	أي نموذج تقريبًا، عبر LiteLLM	عزل Docker في تطبيق الويب، ويسأل أولًا في نسخة سطر الأوامر	الطرفية ومحرر الملفات ومتتبع المهام
Aider	Apache 2.0	أي نموذج تقريبًا، والمحلية أيضًا	بلا عزل، ينشئ commit في git لكل تعديل، ويسأل قبل الأوامر	بلا حلقة أدوات: صيغ تعديل وخريطة للمستودع
Cline	Apache 2.0	كثيرة، والمحلية أيضًا	يسأل قبل كل إجراء	7، ومعها ripgrep للبحث
Pi	MIT	أكثر من 15 مزودًا	بلا عزل، بلا طلبات إذن	4: read وwrite وedit وbash

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

خارج البرمجة

لا شيء في المخطط الأول خاص بالبرمجيات. وصل Microsoft Agent Framework إلى الإصدار 1.0 في أبريل 2026، وفي مؤتمر Build في يونيو صار يأتي بهارنس مدمج فيه وصول إلى الشِل والملفات، وموافقة على استدعاء الأدوات، وذاكرة تعتمد على الملفات، وضغط تلقائي للسياق. ويقدّم LangChain Deep Agents وOpenAI Agents SDK قطعًا مشابهة.

ما يتغير حين تغادر عالم الكود هو صف واحد في الغالب:

	وكيل برمجة	وكيل عام
الحلقة	هي نفسها	هي نفسها
الأدوات	الشِل، git، الملفات	واجهات برمجية، متصفح، بريد، CRM
السياق	المستودع، الفروق	المستندات، التذاكر، سجل المحادثات
حواجز الحماية	بيئة معزولة	موافقة قبل الإرسال والدفع والحذف
التحقق	الاختبارات، جاهزة سلفًا	تقييمات، ومعايير، ومراجعة بشرية

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

كيف تحكم على هارنس

سواء كنت تختار هارنسًا جاهزًا أو تبني هارنسك الخاص، قِس المنظومة كلها لا النموذج وحده:

1. التكلفة لكل مهمة مكتملة، لا لكل توكن.
2. نسبة النجاح على مهامك أنت، لا على لوحة ترتيب عامة.
3. المهام الطويلة: هل يكملها، أم يتعثر في منتصفها؟
4. منطق الأمان: ماذا يستطيع أن يكسر، ومن يوافق؟
5. الملاءمة: هل ينسجم مع أدواتك وأعرافك؟

التكلفة هي البند الذي يستهين به الناس. حين أطلقت Artificial Analysis مؤشر Coding Agent Index في مايو 2026، كانت تكلفة المهمة الواحدة، عبر أزواج النموذج والهارنس التي اختبرها، تتراوح بين 0.07 و2.26 دولار. معظم هذا التفاوت سببه النموذج، لكن الهارنس هو ما يحدد كم توكنًا يحرق النموذج في طريقه إلى الحل.

حتى الجهاز الذي يعمل عليه كل هذا يحرّك الأرقام. شغّل فريق الهندسة في Anthropic نموذج Claude نفسه عبر الهارنس نفسه على مهام Terminal-Bench 2.0 نفسها، فظهر فارق قدره 6 نقاط مئوية بين أضيق موارد للحاوية وأسخاها. لذا أجرِ مقارنتك على البنية التحتية التي ستستخدمها فعلًا.

إلى أين يتجه كل هذا

بدأت تظهر طبقة جديدة فوق الهارنس نفسه. في يونيو 2026 طرحت Databricks مشروع Omnigent مفتوح المصدر، وتسميه «هارنس فوقي» (meta-harness): يعمل فوق Claude Code أو Codex أو Pi أو وكيلك الخاص، ويتيح لك أن تجمع بينها وتتحكم فيها من مكان واحد. وإن ترسّخت الفكرة، صار الهارنس مكوّنًا تبدّله كما تبدّل قاعدة بيانات بأخرى.

بعض ما في هارنس اليوم سينتقل إلى داخل النموذج. أفضل ما قرأته في هذا جملة من مقال Anthropic نفسه: «كل مكوّن في الهارنس يجسّد افتراضًا عمّا لا يستطيع النموذج فعله وحده». فحص same_command_failed في شبه الكود يفترض أن النموذج لن ينتبه إلى أنه يدور في حلقة مفرغة. والضغط يفترض أنه لا يستطيع حمل مهمة طويلة في نافذة واحدة. ومع تحسّن النماذج تسقط بعض هذه الافتراضات، ويمكن عندها التخلي عن الأجزاء المبنية عليها.

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

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

المصادر

• Birgitta Böckeler، Harness engineering for coding agent users، موقع martinfowler.com، أبريل 2026
• Sydney Lewis، Same Model, Different Harness: Different Coding-Agent Results، arXiv، أغسطس 2026
• OpenAI، Harness engineering: leveraging Codex in an agent-first world
• Anthropic، Building agents with the Claude Agent SDK
• M. D. McIlroy وE. N. Pinson وB. A. Tague، UNIX Time-Sharing System: Foreword، Bell System Technical Journal، عام 1978
• Mario Zechner، What I learned building an opinionated and minimal coding agent، نوفمبر 2025
• Boris Cherny عن agentic search replacing RAG in Claude Code، فبراير 2026
• Vercel، We removed 80% of our agent's tools، ديسمبر 2025
• Artificial Analysis، Coding Agent Index ومنشور إطلاقه في مايو 2026
• Anthropic، Quantifying infrastructure noise in agentic coding evals
• Anthropic، Harness design for long-running application development، مارس 2026
• LangChain، The anatomy of an agent harness، مارس 2026
• Microsoft، Microsoft Agent Framework at BUILD 2026
• Databricks، Introducing Omnigent
• توثيق الأدوات المستخدم في جدول المقارنة: Claude Code tools وpermission modes وhooks؛ Codex وapprovals and security؛ Gemini CLI tools؛ Cursor run modes؛ OpenHands؛ Aider؛ Cline tools؛ Pi