أعلنت Microsoft في 28 أكتوبر 2026 إتاحة البنية التي تشغّل تجارب Copilot، والمعروفة باسم Copilot harness، عبر منصة Microsoft Foundry. وتستهدف الخطوة المطورين والشركات الراغبين في بناء وكلاء ذكاء اصطناعي قادرين على استخدام الأدوات وتنفيذ مهام طويلة ومعقدة من دون بناء طبقة التنسيق وإدارتها من الصفر.
الإعلان منشور على المدونة الرسمية لمايكروسوفت. والمقصود هنا ليس إطلاق نموذج ذكاء اصطناعي جديد، بل إتاحة جزء من البنية البرمجية التي تنظم طريقة عمل النموذج داخل التطبيق.
ما المقصود بـ Copilot harness؟
النموذج اللغوي يقدم قدرات الفهم والاستدلال، لكن تحويل هذه القدرات إلى وكيل ينفذ مهمة فعلية يحتاج إلى طبقة إضافية تضبط التعليمات والسياق والأدوات وبيئة التنفيذ والضوابط الأمنية. هذه الطبقة هي ما تسميه Microsoft بـ«الـharness»؛ أي الإطار الذي يدير دورة عمل الوكيل ويحدد كيفية تفاعله مع الأنظمة المحيطة.
بحسب الشركة، تُستخدم هذه البنية في منتجات منها Copilot Studio وتطبيق GitHub Copilot وواجهة سطر الأوامر وبيئة Visual Studio Code. وتقول Microsoft إنها تتيحها الآن عبر Foundry كخدمة مُدارة لبناء الوكلاء وتشغيلهم.
دعم أكثر من 20 نموذجًا
تقول Microsoft إن الإطار يدعم أكثر من 20 نموذجًا متقدمًا، مع إمكانية استخدام مفاتيح النماذج الخاصة بالعميل. الفكرة هي اختيار النموذج الأنسب للمهمة من دون إعادة بناء بقية التطبيق كلما تغير النموذج أو ظهر خيار جديد.
وقد يفيد هذا النهج فرق التطوير التي تحتاج إلى الموازنة بين جودة النتائج وسرعة الاستجابة وتكلفة التشغيل. لكن الإعلان لا يثبت أن استخدام الإطار سيخفض التكلفة في كل حالة؛ فالنتيجة تعتمد على النماذج المختارة وطبيعة المهمة وحجم الاستخدام وطريقة إعداد الوكيل.
التكامل مع الأدوات ومعايير الوكلاء
تشير Microsoft إلى دعم معايير وأدوات مثل Model Context Protocol (MCP)، ومهارات الوكلاء، والإضافات. ويسمح ذلك بربط الوكيل بمصادر بيانات وأدوات خارجية وفق الإعدادات والصلاحيات التي يحددها المطور.
وتوضح الشركة أن بيئة Foundry تتولى إدارة دورة عمل الوكيل وصندوق التنفيذ والحوكمة والتحسين، بينما يحدد المطور التعليمات والمهارات والأدوات واختيار النموذج. كما تقول إنها نقلت بيئة تشغيل الإطار إلى لغة Rust، وإن ذلك خفّض زمن بدء الجلسة ووقت الوصول إلى أول رمز؛ وهي تصريحات من الشركة لم تُرفق في الإعلان بقياسات مستقلة مفصلة يمكن تعميمها على جميع التطبيقات.
ما الذي ينبغي أن يضعه المطورون في الحسبان؟
إتاحة طبقة التنسيق قد تقلل العمل اللازم لبناء وكلاء متعددَي النماذج، لكنها لا تلغي الحاجة إلى تصميم الصلاحيات وحدود الوصول ومراقبة استخدام الأدوات. يجب اختبار الوكيل في بيئة محدودة، وتسجيل العمليات التي ينفذها، والتحقق من البيانات التي يرسلها إلى النماذج والخدمات المتصلة، خصوصًا عندما يتعامل مع معلومات حساسة أو أنظمة إنتاجية.
كما أن الاعتماد على إطار مُدار يعني دراسة التكامل مع المنصة وتكاليفها وحدود نقل التطبيقات إلى بيئات أخرى. وتشير Microsoft إلى أن المنصة تظل قابلة للتكامل مع أطر عمل أخرى، لكن تفاصيل التوافق الفعلي ستعتمد على الأدوات والنماذج المستخدمة في كل مشروع.
الخلاصة
توسّع Microsoft نطاق Foundry من استضافة النماذج إلى توفير البنية المحيطة التي تساعد على تحويلها إلى وكلاء قادرين على تنفيذ مهام متعددة الخطوات. وتكمن أهمية الإعلان في فصل اختيار النموذج عن طبقة إدارة الوكيل، مع بقاء الأداء والتكلفة والأمان أمورًا يجب تقييمها عمليًا لكل تطبيق.
المصدر الأصلي
Microsoft Official Blog — Introducing the Microsoft Copilot harness، 28 أكتوبر 2026
اكتشاف المزيد من lightweb2
اشترك للحصول على أحدث التدوينات المرسلة إلى بريدك الإلكتروني.
