مصنع الوكلاء: كيف يبني Claude Code وكلاء OpenAI على نطاق واسع

في هذه الهندسة وكيلان، وواحد منهما فقط يُشحن.

الأول هو Claude Code. لا يصل إلى عميل أبداً. مهمته أن يبني الثاني — أن يجهّز هيكله، ويوصّل أدواته، ويكتب تقييماته، ويضعه في حاوية، ويسلّمه إلى Kubernetes، وهي منصة تنسيق الحاويات التي تتولى النشر والتوسّع. والثاني تطبيق مبني على OpenAI Agents SDK يفعل شيئاً واحداً بالضبط لعميل واحد بالضبط، ولا يعرف شيئاً عن كيفية صناعته.

هذا الفصل هو الفكرة كلها وراء H5، جولة مصنع الوكلاء من سلسلة Panaversity. معظم من يبنون بالوكلاء إنما يبنون وكيلاً. أما سؤال المصنع فمختلف: كيف تبدو الآلة التي تُنتج الوكلاء، وما الوحدة التي تصكّها؟

والجواب الذي استقررتُ عليه هو: ملف. وتحديداً ملف SKILL.md.

الطبقتان، ولماذا تستخدمان أدوات مختلفة

استخدام أدوات من مزوّدَين مختلفين هنا قرار متعمَّد، لا تردداً في الاختيار.

Claude Code وكيل زمن تطوير. يملك نظام ملفات، وصدفة أوامر، والاستعداد للطحن عبر إعادة هيكلة من أربعين خطوة. إنه المقاول العام. تريد منه الاتساع، والوصول إلى الأدوات، والاستدلال بعيد المدى، ولا يهمّك كثيراً أن الجلسة تكلّف مالاً حقيقياً، لأنها تجري مرة واحدة وتُنتج أثراً دائماً.

أما تطبيق OpenAI Agents SDK فهو بيئة تشغيل إنتاجية. يعمل آلاف المرات يومياً على مهمة ضيقة واحدة. وتريد منه الخصائص المعاكسة: نطاقاً محدوداً، وزمن استجابة قابلاً للتنبؤ، وتكلفة منخفضة لكل استدعاء، ومُخرَجاً مُهيكلاً يمكنك التحقق منه. الاتساع هنا عبء — فالوكيل الإنتاجي الذي يستطيع فعل أي شيء هو وكيل سيفعل في نهاية المطاف شيئاً لم تقصده، في الثالثة فجراً، لعميل يدفع.

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

ملف SKILL.md هو الوحدة التي يصكّها المصنع

الأثر المثير للاهتمام ليس الوكيل، بل الشيء الذي يصنع الوكيل.

ملف SKILL.md هو ملف Markdown عادي يحزم قدرة واحدة: ما هي القدرة، ومتى ينبغي أن تنطلق، والإجراء الواجب اتباعه، والقيود المفروضة عليها، وكيف تعرف أنها نجحت. وهو مُعَدّ ليقرأه وكيل، لا ليُترجَم إلى لغة آلة.

ثلاث خصائص تجعله الوحدة الصحيحة:

قابل للنقل. Markdown بلا بيئة تشغيل. الملف نفسه يمكن أن يوجّه Claude Code أثناء البناء، وأن يُدمَج في تعليمات وكيل إنتاجي. وتنقله بين المشاريع بنسخه.

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

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

والانضباط الذي يجعلها تعمل هو المُحفِّزات الضيقة. المهارة التي تقول «استخدم هذه لأسئلة العملاء» عديمة الفائدة — فكل شيء سؤال عميل. أما المهارة التي تقول «استخدم هذه حين يكون العميل قد دُفع عليه بالفعل ويطلب استرداداً، والطلب أقل من 30 يوماً» فهي مهارة يستطيع الوكيل توجيه الطلب إليها بشكل صحيح. اكتب المُحفِّز كما لو كنت تكتب قاعدة توجيه، لأنك تفعل ذلك فعلاً.

MCP للأدوات، وA2A للوكلاء

بروتوكولان يظهران باستمرار في هذا المجال، وهما يحلّان مشكلتين مختلفتين. وتوضيح الفرق بينهما أهم مما قد يبدو.

بروتوكول MCP — أي Model Context Protocol — يوحّد الطريقة التي يصل بها الوكيل إلى أداة. فبدل كتابة تكامل HTTP مفصّل لكل قدرة، تعرض القدرة كخادم MCP، وعندها يستطيع أي عميل يتحدث MCP أن يكتشفها ويستدعيها. والمصافحة هي الجوهر: خادم MCP الحقيقي يتفاوض على القدرات عند initialize، ويعلن أدواته عبر tools/list، وينفّذها عبر tools/call.

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

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

أما A2A — أي Agent-to-Agent — فهو المحور الآخر: كيف يفوّض وكيل إلى وكيل آخر، بوصفه نِدّاً لا أداة. MCP يجيب عن سؤال «ما الذي أستطيع استدعاءه؟»، وA2A يجيب عن سؤال «إلى مَن أستطيع تسليم هذا؟».

وفي نموذج المصنع يكون هذا التمييز بنيوياً. فالطبقة 1 والطبقة 2 لا تتحدثان إلى بعضهما في وقت التشغيل إطلاقاً — العلاقة بينهما علاقة صانع بمنتَج، وتنتهي عند النشر. لكن ما إن يصير لديك وكلاء كثيرون من الطبقة 2 في الإنتاج، حتى يصبح سؤال ما إذا كان وكيل الاستردادات يستطيع التفويض إلى وكيل فحص الاحتيال سؤال A2A بالضبط.

الفخ الذي يكلّف بعد ظهيرة كاملة

تفصيلة محددة ومكتسبة بشق الأنفس لكل من يتبنى OpenAI Agents SDK.

حزمة التثبيت تضع وحدة عليا اسمها agents. فإن كان تطبيقك يعمل ومجلده الخاص أول ما في sys.path — وهي الحالة الطبيعية لخدمة تُشغَّل من مجلدها — فإن إنشاء حزمة في yourapp/agents/ يحجب حزمة التطوير بالكامل. وعندها يستورد السطر from agents import Agent حزمتك أنت، ويظهر الفشل على هيئة خطأ استيراد أو خاصية مفقودة لا تشبه تضارب التسميات في شيء.

سمِّ المجلد باسم آخر. اسم orchestration/ يفي بالغرض. هذه ثلاثون ثانية من الوقاية في مقابل بعد ظهيرة كامل من الحيرة، وهي من النوع الذي لا يظهر في ملاحظات أحد إلا بعد أن يكون قد وقع له فعلاً.

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

الموظف الرقمي: تسعير المُخرَج لا الرموز

هنا تتحول الهندسة إلى نموذج عمل، وجذور ذلك أبعد من H5 — فتأطير الموظف الرقمي (Digital FTE) كان موجوداً منذ H1، في رفيق مساق بُني بوصفه موظفاً بدوام كامل لا بوصفه ميزة.

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

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

وأمران يجعلان هذا التأطير مشروعاً لا حيلة تسعيرية:

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

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

وهذا بالضبط سبب استخدام الطبقة 2 لبيئة تشغيل مقيّدة. فالموظف الرقمي المُسعَّر في مقابل راتب لا ينجح إلا إذا كانت تكلفته لكل مهمة قابلة للتنبؤ، وقابلية التنبؤ بالتكلفة تأتي من ضيق النطاق ومن المُخرَج المُهيكل.

النشر: Kubernetes وDapr

مُخرَج المصنع يُشحن إلى Kubernetes، ومعه Dapr في المقدمة يتولى الاهتمامات العابرة للخدمات.

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

أما Dapr فيستحق مكانه لأنه يُبقي كود الوكيل جاهلاً ببنيته التحتية. فمخازن الحالة، والنشر والاشتراك، واستدعاء الخدمات، كلها يُوصَل إليها عبر خدمة جانبية، فيستدعي الوكيل نقطة نهاية محلية وتقرر المنصة ما إذا كان ذلك Redis أم Postgres، وKafka أم غيرها. وهذا الفصل غير المباشر مهم في المصنع أكثر منه في تطبيق مفرد: فالوكلاء يُنتَجون باستمرار، ولا تريد أن يثبّت كل واحد منهم اختيار وسيط رسائل يضطر فريق المنصة لاحقاً إلى ترحيله عبر أربعين خدمة.

وحزمة المراقبة — Prometheus وGrafana وJaeger — ليست اختيارية هنا لسبب خاص بالوكلاء. فحين تكون خدمة عادية بطيئة، تحلّل أداءها. أما حين يكون الوكيل بطيئاً، أو مخطئاً، فالسبب عادةً قرار: استدعى أربع أدوات حيث تكفي واحدة، أو وجّه الطلب إلى المهارة الخطأ، أو دار في حلقة. والتتبع الموزّع هو كيف ترى تسلسل القرارات. وبدونه تقرأ المُخرَجات النهائية وتخمّن الاستدلال الذي أنتجها.

التوزيع هو الجزء الذي يتخطاه المهندسون

استهدف H5 منظومة OpenAI Apps كقناة توزيع، على أساس أن لقاء المستخدمين داخل مساعد يستخدمونه أصلاً أفضل من مطالبتهم بتبنّي وجهة أخرى.

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

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

أين يتوتر هذا النموذج

ثلاثة حدود بصراحة.

المصنع لا يفوق جودة مواصفاته. ملف SKILL.md مكتوب بغموض يُنتج وكيلاً غامضاً، وبسرعة أكبر من ذي قبل. سرعة التوليد تضاعف أي جودة تحملها مُدخلاتك، بما في ذلك النوع السيئ منها. وعنق الزجاجة ينتقل من كتابة الكود إلى كتابة أوصاف دقيقة للعمل — وهي مهارة حقيقية، موزّعة بتفاوت، وليست أسهل بشكل بديهي.

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

مزوّدان يعنيان دائرتَي انفجار. الطبقة 1 والطبقة 2 تعتمدان على أسعار شركتين مختلفتين وإتاحتهما وشروطهما. وهذه تكلفة تشغيلية حقيقية، قُبلت هنا لأن كل أداة أفضل فعلاً في نصفها. لكنها ليست مجانية، ولا ينبغي أن تتظاهر بغير ذلك أمام مشترٍ.

الخلاصات

• افصل الوكيل الذي يبني عن الوكيل الذي يُشحن. أعمار مختلفة، ونطاقات مختلفة، وأهداف تحسين مختلفة. لا تشحن المقاول العام.
• اجعل وحدة قدرتك ملفاً، لا صنفاً برمجياً. قابلة للنقل، وقابلة لمراجعة خبراء المجال، وقابلة للتسعير.
• اكتب مُحفِّزات ضيقة. المهارة التي قد تنطبق على أي شيء يُوجَّه إليها الطلب عشوائياً.
• اعرف الفرق بين MCP وA2A. الوصول إلى الأدوات مقابل التفويض بين الأنداد. ولا تسمِّ نقطة نهاية HTTP خادم MCP — فالمصافحة هي الجوهر.
• سعّر في مقابل الرواتب، واجعل اقتصاديات الوحدة تُغلق عند الذيل.
• تتبّع القرارات، لا المُخرَجات وحدها. الإجابة الطليقة التي تخطّت أداتها هي الإخفاق الذي سيفوته تقييمك.