البنية المرجعية لمنصة وكلاء المؤسسات

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

كل فريق يبدأ بنفس الحماس. وكل فريق يبني بطريقته الخاصة. فريق المالية ينشئ تسجيلاً بسيطاً في جدول بيانات. فريق المشتريات يختار بوابة نماذج (Model Gateway) مختلفة. فريق خدمة العملاء يخزن السياق في ملفات محلية. فريق عمليات تقنية المعلومات يصنع آلية موافقة خاصة به.

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

هنا تبدأ الشركة بالتساؤل: هل نبني عدة تطبيقات وكلاء، أم نبني منصة مؤسسية لتشغيل الوكلاء بأمان وقابلية للتوسع؟

لماذا يبدأ نمط "كل فريق يبني بنفسه" في أن يصبح مشكلة

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

لفهم لماذا تصبح هذه مشكلة، نحتاج إلى التمييز بين شيئين غالباً ما يتم الخلط بينهما.

تطبيق الوكيل (Agent Application) هو حل لحالة استخدام محددة. على سبيل المثال، وكيل لمعالجة استثناءات الحسابات الدائنة، أو وكيل لسير عمل المشتريات "من الطلب إلى أمر الشراء"، أو وكيل لحل شكاوى العملاء. يحتوي كل منها على سير عمل، واستدعاءات (Prompts)، وأدوات، وسياق، وواجهة مستخدم خاصة بهذا المجال. هذه هي الطبقة التي يراها مستخدم الأعمال مباشرة.

منصة وكلاء المؤسسات (Enterprise Agent Platform) هي الطبقة المشتركة التي تستخدمها العديد من تطبيقات الوكلاء. هذه المنصة لا تحل عملية تجارية معينة بشكل مباشر. إنها توفر قدرات (Capabilities) قياسية مثل التحكم في الهوية والوصول (Identity and Access Control)، وبوابة النماذج (Model Gateway)، وسجل الأدوات (Tool Registry)، واسترجاع السياق (Context Retrieval)، وقابلية المراقبة (Observability)، ومنصة تقييم (Evaluation Harness)، والنشر والتراجع (Deployment and Rollback)، وتطبيق السياسات (Policy Enforcement)، بالإضافة إلى إدارة دورة الحياة والسجل (Registry and Lifecycle Governance).

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

تصبح المنصة المشتركة مهمة بسبب ثلاث مشاكل تظهر عند التوسع. أولاً، قابلية إعادة الاستخدام (Reusability): القدرات مثل توجيه النماذج، والاسترجاع المراعي للأذونات، وتسجيل التدقيق، وتنسيق الموافقات لا تحتاج إلى إعادة بناء لكل وكيل. ثانياً، اتساق التحكم (Control Consistency): إذا مرت جميع الوكلاء عبر نفس أنماط تطبيق السياسات، وقابلية المراقبة، والهوية، تصبح الحوكمة (Governance) أقوى بكثير. ثالثاً، قوة التشغيل (Operating Leverage): يمكن لفريق المنصة إدارة التكلفة، وزمن الاستجابة، والحوادث، ودورة الحياة بشكل مركزي، بينما يركز فريق المجال على المنطق التجاري.

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

زمن التشغيل (Runtime): حيث يعمل الوكيل حقاً

الطبقة الأولى في البنية المرجعية هي المكان الذي يتلقى فيه الوكيل المحفز (Trigger)، ويستنتج، ويجلب السياق، ويستدعي الأدوات، ويولد الإجراءات. هنا يكمن منطق التنفيذ.

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

بوابة النماذج (Model Gateway) هي مكون غالباً ما يتم الاستهانة به، على الرغم من أهميته البالغة. وظيفتها ليست مجرد الاتصال بالنموذج، بل اختيار النموذج المناسب لمهمة محددة، وإدارة آلية الاحتياط (Fallback) إذا فشل النموذج الرئيسي، وتطبيق تسجيل قياسي، والتحكم في التكلفة وزمن الاستجابة، والحفاظ على اتساق سياسات استخدام النموذج. بدون بوابة نماذج، يميل كل وكيل إلى استدعاء النموذج مباشرة بأنماط مختلفة. ونتيجة لذلك، تفقد الشركة السيطرة على التكلفة والجودة وقابلية التدقيق. بوابة النماذج مهمة أيضاً لاستراتيجية النماذج المتعددة. مهمة تصنيف بسيطة قد تكون كافية بنموذج أخف، بينما الاستدلال المعقد أو التوليف عبر المستندات قد يتطلب نموذجاً أقوى.

الأدوات (Tools) في منصة وكلاء المؤسسات لا ينبغي التعامل معها كقائمة واجهات برمجة تطبيقات (APIs) حرة الاستخدام. هناك حاجة لطبقتين مختلفتين. سجل الأدوات (Tool Registry) هو كتالوج للأدوات المتاحة، يحتوي على البيانات الوصفية، والمالك، والأذونات، ومستوى المخاطرة، وعقد الاستخدام. خدمة تنفيذ الأدوات (Tool Execution Service) هي طبقة زمن التشغيل التي تنفذ استدعاء الأداة فعلياً بعد التحقق من الصحة. يجب أن يمر كل إجراء للوكيل عبر التحقق من صحة المعاملات، والتحقق من الأذونات، وتقييم السياسات، وتسجيل التدقيق، وإذا لزم الأمر، سير عمل الموافقة. هذا يمنع الوكيل من التصرف مباشرة في أنظمة ERP، CRM، HRIS، أو ITSM دون ضوابط كافية. وكيل المشتريات قد يُسمح له باستدعاء أداة لإنشاء مسودة طلب شراء، ولكن خدمة تنفيذ الأدوات يمكنها رفض التنفيذ إذا لم يكن المورد معتمداً. وكيل عمليات العملاء قد يعد رد أموال، ولكن التنفيذ يتوقف إذا تجاوزت القيمة حد السياسة.

نادراً ما يعمل وكيل المؤسسة في تفاعل واحد منفرد. إنه يحتاج إلى تخزين حالة سير العمل، ونتائج الخطوات السابقة، والقرارات المؤقتة، وأحياناً الذاكرة ذات الصلة للتفاعلات اللاحقة. لذلك، تحتاج البنية إلى التمييز بين مخزن الحالة (State Store) لحالة سير العمل التشغيلية الحتمية، وخدمة الذاكرة (Memory Service) للسياق الإضافي الذي يمكن للوكيل استخدامه عبر الجلسات أو الخطوات. العديد من التطبيقات تخلط بينهما تحت مسمى ذاكرة، لكن احتياجات الحوكمة مختلفة. حالة سير العمل يجب أن تكون أكثر صرامة، ومنظمة، وسهلة التدقيق. الذاكرة يمكن أن تكون أكثر مرونة، ولكن يجب أن تخضع لأذونات وسياسات الاحتفاظ.

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

السياق والمعرفة: جودة الوكيل تتحدد هنا

العديد من حالات فشل الوكيل لا تكون بسبب رداءة النموذج، ولكن بسبب أن السياق المقدم خاطئ، أو غير كامل، أو منتهي الصلاحية، أو ينتهك حدود الأذونات. طبقة السياق (Context Layer) ليست مكملاً. إنها الاعتماد الرئيسي لجودة الوكيل.

تحتاج المنصة إلى خط أنابيب إدخال (Ingestion Pipeline) لجلب المستندات، ومقالات المعرفة، والسياسات، وإجراءات التشغيل القياسية (SOPs)، والنصوص، والبيانات المرجعية إلى طبقة السياق بشكل مُدار. يتعامل هذا الخط مع الاستخراج، والتقطيع (Chunking) أو التقسيم، وإثراء البيانات الوصفية، وتصنيف الحساسية، وإدارة الإصدارات، ومزامنة التحديثات. بدون إدخال منضبط، سيقوم الاسترجاع بجلب مستندات غير ذات صلة أو قديمة.

ثلاثة مكونات تخزين لها أدوار مختلفة. مخزن المتجهات (Vector Store) يساعد في البحث الدلالي عن المحتوى غير المنظم. كتالوج البيانات الوصفية (Metadata Catalog) يوفر البنية: مصدر المستند، المالك، تاريخ الصلاحية، التصنيف، المجال، وحقوق الوصول. رسم المعرفة (Knowledge Graph) مفيد عندما تحتاج الشركة إلى فهم العلاقات بين الكيانات: الموردون، العقود، المنتجات، العملاء، الحسابات، الحوادث، المواقع، أو السياسات. ليست كل حالات الاستخدام تحتاج إلى رسم معرفة منذ البداية. بالنسبة لمساعد المعرفة البسيط، قد يكون الاسترجاع المتجهي بالإضافة إلى البيانات الوصفية كافياً. ولكن بالنسبة لحالات الاستخدام المؤسسي التي تتضمن علاقات معقدة - مثل اضطراب سلسلة التوريد، أو استحقاقات العملاء، أو استثناءات مالية عبر الكيانات - يمكن للرسم أن يحسن جودة الاستدلال والتنقل في السياق.

الاسترجاع المراعي للأذونات (Permission-aware Retrieval) هو أحد أهم القدرات. لا ينبغي للوكيل جلب السياق فقط لأن المستند مشابه دلالياً. يجب أن يكون الاسترجاع واعياً للأذونات: من هو المستخدم أو المدير الأصلي، أي وكيل يطلب، ما هو المجال الذي تتم معالجته، وما هي البيانات المسموح بالوصول إليها في هذا السياق. وكيل الموارد البشرية لا ينبغي له سحب مستندات تعويض غير ذات صلة بالقضية. وكيل خدمة العملاء لا ينبغي له جلب تاريخ عميل آخر. وكيل المالية لا ينبغي له خلط الإرشادات عبر الكيانات دون حقوق الوصول المناسبة.

الوكيل المؤسسي الجيد يحتاج دائماً تقريباً إلى الجمع بين نوعين من السياق: البيانات المنظمة (Structured Data) من أنظمة ERP، CRM، HRIS، مستودع البيانات، أو تدفق الأحداث، والبيانات غير المنظمة (Unstructured Data) من المستندات، البريد الإلكتروني، إجراءات التشغيل القياسية، العقود، قاعدة المعرفة، أو النصوص. من الأفضل أن تحتوي المنصة على خدمة سياق (Context Service) يمكنها دمج الاثنين معاً بأمان. في معالجة استثناءات الحسابات الدائنة، يحتاج الوكيل إلى الفاتورة، وأمر الشراء، وإيصال استلام البضائع من الأنظمة المنظمة، بالإضافة إلى السياسة وتاريخ القضية من المستندات. في عمليات العملاء، يحتاج الوكيل إلى الاستحقاق وتاريخ الطلب من CRM/OMS، بالإضافة إلى مقال المعرفة ونص التفاعل. إذا كانت خدمة السياق ضعيفة، سيبدو الوكيل ذكياً ولكنه سيتصرف على أساس هش.

الحوكمة والعمليات: لجعل الوكيل قابلاً للتشغيل في الإنتاج

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

سجل الوكلاء (Agent Registry) هو الكتالوج الرسمي لجميع الوكلاء النشطين في المؤسسة. يحتوي كحد أدنى على اسم الوكيل والغرض منه، والمالك التجاري والتقني، ومستوى المخاطرة، والأدوات ومصادر البيانات، ومستوى الاستقلالية، وحالة دورة الحياة، والتبعيات الرئيسية. سجل السياسات (Policy Registry) يخزن القواعد المستخدمة عبر الوكلاء: حدود المعاملات، قواعد الموافقة، قيود الأدوات، تصنيف المخاطر، وسياسات المجال المحددة. بدون سجل، لا تملك الشركة جرداً مناسباً للحوكمة.

ليست كل الوكلاء تحتاج إلى نفس التحكم. يجب أن تدعم المنصة تصنيف المخاطر (Risk Tiering). وكيل المعرفة الداخلي بوضع المساعدة يختلف بالتأكيد عن وكيل يمكنه تنفيذ إجراءات في نظام ERP. وكيل صياغة التعليقات يختلف عن وكيل يمكنه تحفيز رد الأموال أو معالجة الإنتاج. يجب أن يكون تصنيف المخاطر هذا مرتبطاً بسير عمل الموافقة، وعمق قابلية المراقبة، وصرامة الاختبار، والتحكم في الإصدار.

جميع الآثار المهمة - استدعاء الأداة، قرار السياسة، الموافقة، استرجاع السياق، النتيجة - تحتاج إلى الدخول إلى مخزن تدقيق (Audit Storage) آمن وقابل للتتبع. إلى جانب ذلك، تحتاج المنصة إلى منصة تقييم (Evaluation Harness): بيئة وأدوات لاختبار الوكيل قبل وبعد الإصدار. يشمل ذلك مجموعة بيانات ذهبية، واختبار سيناريو، واختبار الامتثال للسياسات، واختبار الانحدار عند تغيير النموذج أو الاستدعاء أو الأداة، وأخذ عينات تقييم ما بعد الإنتاج. بدون منصة تقييم، تعرف الشركة فقط أن الوكيل يعمل، لكنها لا تعرف ما إذا كانت جودته تتحسن أم تتدهور.

من ناحية العمليات، تحتاج المنصة إلى توفير لوحة معلومات صحة زمن التشغيل (Runtime Health Dashboard)، ولوحة معلومات الجودة والنتائج (Quality and Outcome Dashboard)، وتنبيهات للحوادث التقنية، وانتهاكات السياسات، وارتفاع التكاليف، وآلية للتراجع أو التعطيل السريع، بالإضافة إلى إدارة التكاليف (Cost Management) للنماذج والاسترجاع واستخدام الأدوات. الأنظمة الوكيلة (Agentic Systems) لا يمكن أن تفشل تقنياً فقط. يمكنها أيضاً أن تصبح باهظة الثمن، أو بطيئة جداً، أو كثيرة التصعيد، أو تخفض جودة القرارات بصمت.

ترتيب بناء معقول

الخطأ الكلاسيكي في استراتيجية المنصة هو محاولة بناء بنية كاملة من اليوم الأول. هذا ينتهي دائماً تقريباً بطيئاً ومكلفاً وبعيداً عن احتياجات العمل. النهج الأكثر صحة هو بناء الحد الأدنى من المنصة القابلة للتطبيق (Minimum Viable Platform) الذي ينبثق من أول حالة استخدام جاهزة للإنتاج.

الترتيب العملي الذي عادة ما يكون الأكثر منطقية يبدأ بـ بوابة النماذج (Model Gateway). ابدأ من هنا حتى يكون لجميع الوكلاء الأوائل مسار قياسي للوصول إلى النماذج، والتسجيل، والاحتياط، والتحكم في التكاليف. بعد ذلك، سجل الأدوات وتنفيذها (Tool Registry and Execution). بمجرد أن يبدأ الوكيل في لمس الأنظمة المؤسسية، تصبح هذه القدرة إلزامية. بدونها، سيكون التكامل فوضوياً ويصعب تدقيقه. بعد ذلك، التسجيل والتتبع وقابلية المراقبة الأساسية (Logging, Tracing, and Basic Observability). قبل التوسع، يجب أن تكون الشركة قادرة على رؤية ما يفعله الوكيل وكم تكلفته وزمن استجابته. تطبيق الأذونات والتحقق من السياسات (Permission Enforcement and Policy Check) يأتي بعد ذلك عندما يبدأ الوكيل في قراءة بيانات حساسة أو تنفيذ إجراءات. منصة التقييم (Evaluation Harness) ضرورية بمجرد أن تصبح تغييرات النموذج أو الاستدعاء أو الأداة متكررة. خدمة الذاكرة وسجل الوكلاء الأكثر نضجاً (Memory Service and More Mature Agent Registry) يمكن بناؤها لاحقاً، إلا إذا كانت حالة الاستخدام تتطلب ذلك منذ البداية.

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

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

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

إذا كانت الإجابة لا، فإن الأولوية التالية ليست إضافة المزيد من الوكلاء، بل تعزيز المنصة.