Docker Agent: هل يصبح YAML هو «Compose» الخاص بوكلاء الذكاء الاصطناعي؟
أعلنت Docker عن docker-agent، إطار مفتوح لتعريف وكلاء الذكاء الاصطناعي بملف YAML ونشرهم عبر OCI. ما الجديد فيه، وما حدوده، ومتى يناسب فريقك؟
حين ظهر Docker Compose قبل سنوات، لم يضف قدرة جديدة إلى الحاويات، لكنه جعل وصف تطبيق كامل في ملف واحد أمراً عادياً. هذا بالضبط ما تحاول Docker فعله اليوم مع وكلاء الذكاء الاصطناعي عبر docker-agent، وهو أداة مفتوحة المصدر (كانت تُعرف باسم cagent) تتيح تعريف وكيل أو فريق وكلاء بملف YAML، ثم تشغيله ومشاركته كأنه صورة حاوية. المشروع حظي بنقاش واسع على Hacker News هذا الأسبوع، وفيه أسئلة مشروعة تستحق التوقف عندها قبل أن تدمجه في سير عملك.
ما هو docker-agent بالضبط؟
docker-agent إضافة لسطر الأوامر (CLI plugin) تسمح لك بتعريف وكلاء الذكاء الاصطناعي وتشغيلهم وتوزيعهم دون كتابة شيفرة. تصف في ملف YAML النموذج الذي يستخدمه الوكيل، ووصفه، وتعليماته، والأدوات المتاحة له. وبحسب تغطية الإطلاق، تأتي الأداة مثبّتة مسبقاً في Docker Desktop بدءاً من الإصدار 4.63، ويمكن تثبيتها أيضاً عبر Homebrew أو من صفحة الإصدارات على GitHub.
أحد القائمين على المشروع قال في نقاش Hacker News إن الفكرة بدأت قبل نحو عام ونصف كـ«Compose للوكلاء»، وإن الأداة ملف تنفيذي مستقل يعمل جيداً داخل الحاويات و«sandboxes»، وخارجها أيضاً.
مثال مبسّط على الفكرة
بدل كتابة برنامج يستدعي واجهة نموذج ويدير الأدوات والذاكرة، تصف المطلوب في ملف تعريفي. ملف الوكيل يحدد النموذج والتعليمات ومجموعة الأدوات، ويصبح قابلاً للإصدار والمراجعة والمشاركة مثل شيفرة البنية التحتية. هذه النقطة بالذات هي ما يجذب فرق DevOps، لأنها تحوّل الوكيل من سكربت غامض إلى أصل مُدار في مستودع الشيفرة.
أهم القدرات المعلنة
| القدرة | التفاصيل |
|---|---|
| التعريف التصريحي | وكلاء معرّفون بملفات YAML قابلة للإصدار والمراجعة |
| تعدد الوكلاء | وكيل جذري يفوّض المهام إلى وكلاء فرعيين، لكل منهم نموذجه وأدواته وتعليماته |
| تعدد المزوّدين | OpenAI وAnthropic وGoogle Gemini وAWS Bedrock وMistral وxAI، إضافة إلى Docker Model Runner للنماذج المحلية |
| الأدوات | خوادم MCP محلية أو بعيدة أو مبنية على Docker، مع أدوات مدمجة للتفكير وتتبّع المهام والذاكرة |
| الاسترجاع (RAG) | دعم BM25 والتضمينات والبحث الهجين وإعادة الترتيب |
| التوزيع | دفع الوكلاء إلى أي سجل OCI وسحبهم وتشغيلهم في أي مكان |
التوزيع عبر OCI هو الجزء الأذكى في التصميم. فالشركات تملك أصلاً سجلات صور وسياسات صلاحيات وفحص أمني، وبذلك يرث الوكيل البنية نفسها بدل أن يحتاج إلى منصة جديدة.
قيمة الأداة ليست في أنها تجعل الوكلاء أذكى، بل في أنها تجعلهم قابلين للإدارة: ملف واحد، وإصدار واحد، وسجل واحد.
لماذا يهمّ هذا فرق المطورين؟
1. إنهاء فوضى السكربتات الفردية
في كثير من الفرق يبني كل مطور وكيله الخاص بسكربت بايثون مختلف، ولا أحد يعرف ما يملكه من صلاحيات. التعريف التصريحي يجعل المراجعة ممكنة: يرى الزميل في طلب الدمج أي أدوات مُنحت للوكيل وأي نموذج يتصل به.
2. تبديل المزوّد دون إعادة كتابة
بما أن الأداة تدعم عدة مزوّدين وتسمح بتبديلهم عبر متغيرات البيئة، يقل ارتباطك بمزوّد واحد. وهذا مفيد في زمن تتغير فيه الأسعار والنماذج بوتيرة أسبوعية، كما رأينا في خفض أسعار النماذج الصغيرة مؤخراً.
3. ربط طبيعي مع MCP
دعم خوادم MCP يعني أن الوكيل يصل إلى الأدوات الموجودة أصلاً، من قواعد البيانات إلى أنظمة التذاكر، بدل بناء موصلات خاصة لكل وكيل.
الانتقادات المشروعة
لم يمرّ الإعلان دون أسئلة. أبرزها تعليق متسائل: لماذا تُعدّ عبارة «بلا شيفرة» ميزة، ما دامت وكلاء البرمجة قادرة على توليد الشيفرة بسرعة؟ ردّ أحد المشرفين بأن هناك واجهة Go للحالات المخصصة، وأن كثيراً من الاستخدامات تكفيها تعديلات على ملف YAML. وقال معلّق آخر إنه لا يرى الفرق الواضح بين هذه الأداة وأخرى مثل kagent وبيئات العزل في Kubernetes وLangChain وCloudflare.
عملياً، تشير هذه الملاحظات إلى ثلاث نقاط ضعف محتملة:
- حدود التعبير: ملف YAML ممتاز للحالات الشائعة، لكنه يصبح مرهقاً حين تتعقد المنطق الشرطية.
- ازدحام السوق: أدوات تنسيق الوكلاء كثيرة، والتميّز يحتاج إلى نظام بيئي لا إلى فكرة فقط.
- الأمان: توزيع وكيل جاهز عبر سجل يعني أنك تشغّل تعليمات وأدوات كتبها غيرك، فلا بد من مراجعتها كما تراجع أي صورة حاوية.
أين يتقاطع مع أدوات الوكلاء الأخرى؟
تتنوع أدوات الوكلاء اليوم بين وكلاء البرمجة في الطرفية، وأطر بناء السلاسل البرمجية، ومنصات التنسيق على Kubernetes. موقع docker-agent بينها هو «طبقة التعريف والتوزيع»: لا يحاول أن يكون بيئة تطوير ولا منصة سحابية، بل صيغة موحدة لوصف الوكيل وتغليفه. هذا يشبه ما فعلته الحاويات مع التطبيقات، إذ لم تستبدل لغات البرمجة لكنها وحّدت طريقة تسليمها.
أسئلة يجب أن يطرحها فريقك قبل الاعتماد
- هل نحتاج فعلاً إلى فريق وكلاء، أم يكفي وكيل واحد بأدوات جيدة؟
- من يملك صلاحية دفع وكيل جديد إلى السجل الداخلي، ومن يراجعه؟
- كيف نختبر سلوك الوكيل عند تغيير النموذج أو التعليمات؟
- أين تُحفظ سجلات التنفيذ، ولمن تتاح؟
الإجابة عن هذه الأسئلة أهم من اختيار الأداة نفسها، لأن أغلب إخفاقات الوكلاء في الشركات سببها غياب الملكية والمراجعة لا ضعف النموذج. وإذا كانت لديك أصلاً سياسات لفحص الصور وتوقيعها، فيمكنك تطبيقها على ملفات الوكلاء بجهد قليل، وهذه ميزة حقيقية للفرق المعتادة على بيئات الحاويات.
كيف تبدأ بحذر؟
- جرّب وكيلاً واحداً لمهمة محدودة مثل تلخيص سجلات الأخطاء، قبل بناء فريق وكلاء.
- قيّد الأدوات: امنح الوكيل أقل مجموعة أدوات يحتاجها، وتجنب مفاتيح الإنتاج في البداية.
- شغّله في بيئة معزولة، واحتفظ بسجل لكل ما ينفّذه.
- أدرج ملفات الوكلاء في المراجعة كما تفعل مع ملفات Compose وTerraform.
- ثبّت الإصدارات: لا تسحب وكيلاً من سجل خارجي بوسم متحرك مثل latest.
أسئلة شائعة
هل docker-agent يعني أنني لن أحتاج إلى كتابة شيفرة؟
للحالات الشائعة نعم، فالتعريف يتم بملف YAML. وللحالات المعقدة تتوفر واجهة Go لبناء سلوك مخصص، لذلك لا تتوقع أن يلغي البرمجة تماماً.
هل يعمل مع نماذج غير مملوكة لـ Docker؟
نعم، فهو يدعم عدة مزوّدين سحابيين، إضافة إلى Docker Model Runner لتشغيل النماذج محلياً.
ما العلاقة بين cagent وdocker-agent؟
هو المشروع نفسه بعد إعادة التسمية، وفق ما ذكره أحد القائمين عليه في النقاش العام.
الخلاصة
docker-agent محاولة جادة لجعل وكلاء الذكاء الاصطناعي أصولاً هندسية عادية: تُعرَّف في ملف، وتُراجَع في مستودع، وتُوزَّع عبر سجل. نجاحه لن يتحدد بذكاء الوكلاء، بل بمدى نضج الأدوات حولهم وبقدرة الفرق على تطبيق انضباط الحاويات نفسه على الوكلاء. إن كان فريقك يملك أصلاً خبرة في Docker وسجل صور، فهو تجربة منخفضة الكلفة تستحق وقتاً قصيراً، لكن ابدأ بمهمة صغيرة وصلاحيات ضيقة.
