ما بعد تجارب روبوتات المحادثة: بناء أنظمة ذكاء اصطناعي مؤسسية قابلة للتدقيق

ما بعد تجارب روبوتات المحادثة: بناء أنظمة ذكاء اصطناعي مؤسسية قابلة للتدقيق

فخ المساعد المعزول

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

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

الجزء الصعب ليس المحادثة. الجزء الصعب هو الفعل المضبوط.

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

ما الذي تتطلبه مؤسسة وكلاء فعلا

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

ثلاث قدرات هي الأهم.

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

ثانيا، الهوية والتحكم في الوصول. تربط Microsoft تحديدا حوكمة الوكلاء المؤسسية بأسس الهوية والوصول والامتثال والأمن مثل Entra وPurview وDefender وAgent 365 ومنظومة Microsoft Security الأوسع. يجب على المشغلين التعامل مع الوكلاء بوصفهم كيانات تشغيل غير بشرية، لا جلسات موظفين مستعارة.

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

البنية التحتية واختيار النموذج

Claude Opus 4.8 في Microsoft Foundry

تذكر Microsoft Tech Community أن Claude Opus 4.8 متاح في Microsoft Foundry. بالنسبة إلى المشغلين، ليست النقطة المهمة أن يوجه كل طلب إلى أقوى نموذج متاح. بل أن يكون اختيار النموذج صريحا ومختبرا ومرتبطا بمخاطر المهمة.

النمط الأفضل هو التوجيه الطبقي. في سير عمل مشتريات، قد يصنف نموذج أصغر رسائل الموردين الواردة ويستخرج التواريخ وSKUs والأسعار المعروضة. وقد يخصص Claude Opus 4.8 للحالات التي يجب فيها على النظام مقارنة عروض الموردين، أو حل لغة تعاقدية، أو التعامل مع بنود مفقودة، أو إنتاج حمولة منظمة لبوابة ERP. يستخدم النموذج الأثقل حيث يحمل خطأ الاستدلال مخاطر تجارية أو امتثالية أعلى.

Azure Cobalt 200 VMs لأعمال الوكلاء الخلفية

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

تقول مدونة Azure لدى Microsoft إن Azure Cobalt 200 VMs القائمة على Arm مصممة لأحمال عمل الذكاء الاصطناعي الوكيلية السحابية الأصلية، القائمة على Linux، والقابلة للتوسع الأفقي، وتوفر أداء جيليا أفضل بنسبة تصل إلى 50% مقارنة مع Cobalt 100. بالنسبة إلى المشغلين، السؤال العملي هو أين تمنح الحوسبة الثابتة تحكما أكبر من التنفيذ الخادمي الصرف. قد تستفيد وكلاء المطابقة طويلة التشغيل، وخدمات التنسيق المحلية، وآلات الحالة عالية التزامن من بنية تحتية متوقعة وقرب شديد من البيانات المخزنة مؤقتا. ومع ذلك يجب التحقق من ذلك مقابل بيانات الكمون والاستخدام والتكلفة الخاصة بكل حمل عمل.

إطار EAG: الهوية والصلاحيات والحوكمة

حوكمة الوكلاء المؤسسية

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

إطار Optijara لحوكمة الوكلاء المؤسسية (EAG) هو إطار تشغيلي مقترح للتعامل مع كل وكيل باعتباره كيانا تشغيليا له هويته الخاصة، ومجموعة صلاحياته، وفحوصات البوابة، وسجل الأثر الخاص به.

mermaid graph TD A[طلب العميل] --> B[بوابة التنسيق والتحقق OVG] B --> C{تحقق من هوية الوكيل عبر IPL}

D --> F[محرك تنفيذ الأدوات] F --> G[كتابة نظام / واجهة API لقاعدة البيانات] F --> H[خزنة قابلية التدقيق والتتبع ATV] G --> H

يتكون الإطار من أربع طبقات.

1. طبقة تهيئة الهوية (IPL): تخصص هويات فريدة غير بشرية للوكلاء الفرديين، باستخدام مزود الهوية المؤسسي حيثما ينطبق ذلك.
2. حواجز التحكم في الوصول والامتيازات (ACPG): تحدد نطاقات ضيقة وتمنع توسيع الامتيازات.
3. بوابة التنسيق والتحقق (OVG): تتحقق من استدعاءات الأدوات التي ينشئها الوكيل قبل تنفيذها.
4. خزنة قابلية التدقيق والتتبع (ATV): تسجل آثار المطالبات، ومعلمات النموذج، واستدعاءات الأدوات، ونتائج التحقق، والأفعال النهائية.

قد يبدو ملف تعريف افتراضي لوكيل مشتريات كما يلي.

json { "agentId": "agent-procure-prod-08", "class": "EAG-Finance-Tier1", "identityPrincipal": "spn:agent-procure-prod-08@example.internal", "authorizedTools": [ "read_vendor_contracts", "generate_purchase_order_draft", "submit_to_erp_gateway" ], "approvalPolicy": { "requireHumanVerificationForSensitiveActions": true, "requireSecondCheckForSystemWrites": true }, "runtimeGuardrails": { "preventPrivilegeEscalation": true, "enforceStructuredOutput": "json_schema" } }

هوية الوكيل مقابل هوية الإنسان

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

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

صلاحيات الأدوات وحدود المعاملات

قد يكون التحكم في الوصول القائم على الأدوار حادا أكثر من اللازم للعمل الوكيلي. قد يحتاج الوكيل إلى حقل قاعدة بيانات فقط في ظروف معينة، أو إلى أداة كتابة فقط بعد فحص موافقة. يجب أن تفرض طبقة الأدوات ذلك الحد.

خذ أداة باسم modify_shipping_address. يجب أن تتحقق OVG من معرف العميل، وقائمة المناطق المقبولة، وصيغة الرمز البريدي، وحالة التفويض، ومخطط الحمولة قبل تنفيذ استدعاء API. يجب أن ترفض محاولات تمرير أجزاء SQL، أو تعليمات مخفية، أو حقول غير متوقعة. بالنسبة إلى الأفعال الحساسة، يجب أن تطلب البوابة تحققا بشريا أو فحصا آليا ثانيا من خدمة منفصلة.

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

الاكتشاف وقابلية المراقبة والاسترجاع

Microsoft Discovery

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

أعلنت مدونة Azure لدى Microsoft في يونيو 2026 عن التوافر العام لـ Microsoft Discovery وعن معاينة تطبيق Microsoft Discovery. يقدم المنتج أساسا حول مسارات عمل البحث والتطوير العلمية والهندسية، مع قدرات لبناء وحوكمة سير عمل الذكاء الاصطناعي الوكيلية عبر البيانات والأدوات ودورات المراجعة والأدلة. يجب على المشغلين خارج البحث والتطوير التعامل معه بوصفه إشارة إلى الاتجاه الذي تأخذ إليه Microsoft أنماط قابلية مراقبة الوكلاء وحوكمتهم، لا بديلا شاملا لمراقبة التطبيقات.

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

التتبع وتدقيق القرارات

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

Foundry IQ ومشكلة السياق

تعتمد جودة الوكيل بدرجة كبيرة على الاسترجاع. تفشل كثير من أنظمة RAG لأن الإجابة ذات الصلة مدفونة في ملحق PDF، أو قاعدة بيانات قديمة، أو مكتبة مستندات ذات بيانات وصفية غير متسقة. تقول Microsoft Tech Community إن Foundry IQ يمكنه تحسين استدعاء قواعد المعرفة بنسبة تصل إلى 54%.

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

أخطاء شائعة في برامج الوكلاء الإنتاجية

الوثوق بالنموذج ليحكم نفسه

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

تجاهل تكلفة التكرار والكمون

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

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

التعامل مع مخططات المخرجات كصياغة مطالبة

تتوقع الأنظمة المؤسسية بيانات منظمة. تنتج النماذج اللغة بطبيعتها. طلب "JSON فقط" ليس كافيا. يحتاج النظام إلى تحقق JSON Schema أو ضوابط مخرجات منظمة، يتبعها إعادة محاولة، أو عزل، أو مراجعة بشرية عندما يفشل التحقق. يجب ألا تتلقى APIs اللاحقة أي مخرج نموذج غير مفحوص.

قائمة تنفيذية

المرحلة 1: البنية والتهيئة للهويات

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

المرحلة 2: التقييم والاختبار الهجومي

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

المرحلة 3: النشر والمراقبة واكتشاف الانحراف

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

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

التحفظات والارتباط بالمورد

الاقتران بمنظومة Microsoft

تمنح حزمة Microsoft في يونيو 2026 المشغلين مسارا متكاملا عبر Azure AI Foundry وMicrosoft Foundry وMicrosoft Discovery وFoundry IQ وAzure Cobalt 200 VMs. المقابل هو الاقتران بالمنصة. قد تصبح هويات الوكلاء، ومخازن السياق، وخرائط قابلية المراقبة، وتكاملات سير العمل أصعب نقلا لاحقا.

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

التكلفة والكمون والموافقة البشرية

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

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

يتطلب الانتقال من تجارب روبوتات المحادثة إلى أنظمة وكلاء إنتاجية نموذجا تشغيليا جديدا للبنية التحتية والهوية والاسترجاع والحوكمة والتحسين المستمر. يمكن لكل من Azure Cobalt 200 VMs وClaude Opus 4.8 في Microsoft Foundry وMicrosoft Discovery وFoundry IQ أن يؤدي دورا مفيدا. ولا يلغي أي منها الحاجة إلى حدود صلاحيات صارمة، وفحوصات مخطط، وآثار تدقيق، وتحقق بشري حيث تكون مخاطر العمل عالية.

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

الأسئلة الشائعة

ما الفرق الأساسي بين روبوت محادثة قياسي ونظام وكلاء؟

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

كيف يتكامل Claude Opus 4.8 مع Microsoft Foundry؟

تذكر Microsoft Tech Community أن Claude Opus 4.8 متاح في Microsoft Foundry، مما يمنح المشغلين خيار نموذج آخر لمهام الاستدلال الأعلى.

ما الوظيفة الأساسية لـ Microsoft Discovery؟

Microsoft Discovery هي منصة من Microsoft لبناء وحوكمة سير عمل الذكاء الاصطناعي الوكيلية، مع تركيز إعلان يونيو 2026 على حالات استخدام البحث والتطوير العلمية والهندسية ومعاينة تطبيق Discovery.

كيف تدعم Azure Cobalt 200 VMs أحمال عمل الوكلاء؟

Azure Cobalt 200 VMs هي آلات افتراضية من Azure قائمة على Arm ومصممة لأحمال عمل الذكاء الاصطناعي الوكيلية السحابية الأصلية، القائمة على Linux، والقابلة للتوسع الأفقي، مع إشارة Microsoft إلى أداء جيلي أفضل بنسبة تصل إلى 50% مقارنة مع Cobalt 100.

كيف يحسن Foundry IQ استرجاع المؤسسة؟

تقول Microsoft إن Foundry IQ يمكنه تحسين استدعاء قواعد المعرفة بنسبة تصل إلى 54%، مما يساعد الأنظمة على استرجاع سياق أكثر صلة من قواعد المعرفة المؤسسية.