Maven Apps: وكلاؤكم يحتاجون إلى مشغّلين، لا إلى لوحات مفاتيح

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

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

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

اليوم، يعمل على إطار عملنا آلاف التطبيقات. نعم، من بينها تطبيقات لأنظمة خارجية كبرى مثل Salesforce وZendesk وNotion، لكنها تشمل أيضًا مئات التطبيقات المخصصة العاملة في بيئة الإنتاج على وكلاء فعليين.

لماذا لا تكفي التكاملات الأساسية

اسألوا 10 موردين عمّا تعنيه عبارة «يتكامل مع Salesforce» بالنسبة لمنتجاتهم، وستحصلون على 10 إجابات مختلفة، لأن نظامًا مثل Salesforce أو Zendesk أو Front ليس شيئًا واحدًا أبدًا. فقد يكون:

• مكانًا يحتاج وكيلكم إلى الرجوع إليه للعثور على المعلومات (قاعدة معرفة، سجل الحالات)
• مكانًا يحتاج وكيلكم إلى الوصول إليه لاتخاذ إجراء (إنشاء تذكرة، تحديث سجل، إصدار استرداد)
• واجهة يحتاج وكيلكم إلى الظهور فيها (مساعد آلي لدعم الموظفين داخل وحدة التحكم التي يعمل فيها فريق الدعم لديكم أصلًا)

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

إنها مشكلة آلة البيع: قائمة ثابتة تعمل تمامًا كما هو معلن، إلى أن يكون ما تحتاجونه غير مدرج فيها، وعندها تكونون قد التزمتم بالفعل. لم نرد أن تعمل Maven Apps بهذه الطريقة، لذا بنينا إطار العمل حول السؤال الفعلي المطروح (معرفة أم قدرة أم قناة) بدلًا من «موصّل» عام.

Maven Apps: أكثر من مجرد تكاملات

يمكن أن تتخذ Maven Apps أشكالًا عديدة، لكن معظمها يقوم على بضعة أنماط شائعة. إليكم أمثلة على ما يمكن للتطبيقات فعله:

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

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

لا توجد فئة منفصلة «بمستوى المؤسسات» من إطار العمل يستخدمها مهندسونا وحدهم؛ فـApp Studio، منصتنا للمطورين لبناء التطبيقات، تعمل على البنية نفسها تمامًا. إنها TypeScript حقيقية، وSDK حقيقية (@mavenagi/mavenagi)، ومسار نشر حقيقي، لا لغة برمجة نصية مملوكة عليكم تعلّمها من أجلنا فقط.

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

كيف صُممت التطبيقات لتكون قوية

Maven App تطبيق بلا خوادم (serverless) يعمل داخل بيئة آمنة ومعزولة، ويتواصل مع منصة Maven عبر SDK محددة. وبشكل ملموس:

متعدد المستأجرين. يُبنى التطبيق الواحد مرة واحدة ويُثبَّت مرات عديدة، عبر مؤسسات ووكلاء مختلفين. تحصل كل عملية تثبيت على سياقها الخاص المحدد النطاق (معرّف المؤسسة ومعرّف الوكيل وإعدادات التشغيل الخاصة بها)، لكنها تتشارك الشيفرة الأساسية نفسها. وهذا يعني أنه حين نطرح تحسينًا لتطبيق Salesforce، يستفيد منه كل عميل يستخدمه، ولا يبقى أحد عالقًا مع نسخة قديمة مصنوعة يدويًا من تكامله «الخاص».

معزول، لا مُلحَق. يعمل كل تطبيق كدالة مستقلة في بيئة آمنة، منفصلة عن الواجهة الخلفية الأساسية لـMaven وعن تطبيقات العملاء الآخرين. لا يعمل منطقكم المخصص أبدًا داخل نظام موحّد مشترك بجوار منطق غيركم. ويمكن أن تتم الاتصالات الصادرة إلى أنظمة السجلات لديكم عبر VPN أو VPC peering أو OIDC أو HTTPS عادي مع قوائم السماح لعناوين IP، والخيار لكم لا لنا.

يستجيب لأحداث فعلية، لا لجداول استطلاع دورية. بدلًا من مهمة مزامنة ليلية، يمكن للتطبيق تنفيذ خطافات أحداث تُسمى المشغّلات (triggers): إنشاء محادثة، أو ورود ملاحظات، أو تحديث قاعدة معرفة، فتُبلغ المنصة التطبيق لحظة وقوع الحدث. وهذا شكل مختلف عن أدوات الأتمتة التي ربما تعرفونها. فالمشغّل في Maven سلبي: المنصة نفسها هي التي ترصد تغيّرات الحالة وتدفعها إلى أي تطبيق معني، دون أي ارتباط بين التطبيق الذي تسبّب في الحدث والتطبيق الذي يستجيب له. وعمليًا، يعني ذلك أن تطبيقًا للرد على البريد الإلكتروني وتطبيقًا منفصلًا تمامًا لمزامنة Salesforce يمكنهما الاستجابة للحدث نفسه «تحديث المحادثة» باستقلالية، كلٌّ يؤدي مهمته، دون أن يعلم أيٌّ منهما بوجود الآخر.

إنها آلية التنسيق نفسها التي تعتمدها مستعمرة النمل. لا توجد نملة واحدة تخطط لسلوك المستعمرة، ولا تراسل نملةٌ أخرى مباشرة؛ بل تغيّر النملة شيئًا في البيئة المشتركة (أثر الفيرومون)، فتستجيب كل نملة أخرى لهذا التغيير باستقلالية، متبعةً قاعدتها البسيطة. ومن ذلك ينبثق ذكاء المستعمرة ككل (مسارات مُحسّنة للبحث عن الغذاء، وتوزيع الأحمال، بل وقرارات جماعية مثل نقل العش)، دون منسّق مركزي ودون أن تدرك أي نملة الخطة. وتتنسق Maven Apps بالطريقة نفسها: يغيّر الحدث الحالة المشتركة، فيستجيب كل تطبيق معني من تلقاء نفسه.

له دورة حياة حقيقية. ينفّذ كل تطبيق مجموعة صغيرة من خطافات دورة الحياة:

• preInstall: يتحقق من بيانات الاعتماد والإعدادات قبل تفعيل أي شيء. إذا كان مفتاح API لديكم خاطئًا، يفشل التثبيت هنا بوضوح بدلًا من أن يفشل بصمت بعد 3 أسابيع.
• postInstall: يسجّل إجراءات التطبيق ويهيّئ ما يحتاجه من موارد بعد نجاح التثبيت.
• executeAction: ينفّذ العمل الفعلي الذي يطلبه الوكيل، ويُعرض للعملاء كقدرة: البحث عن طلب، أو إنشاء حالة، أو إصدار استرداد، أو التحقق من رصيد حساب.

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

التطبيقات مقابل التكاملات

يجيب التكامل النموذجي عن سؤال واحد محدود، عادةً «هل يمكن نقل البيانات من A إلى B»، ويعدّه خط النهاية. أما Maven App فمبني للإجابة عن سؤال أصعب وأكثر فائدة: هل يستطيع وكيل الذكاء الاصطناعي أن يعرف بموثوقية ما هو صحيح في أنظمتكم الآن، وهل يمكن الوثوق به للتصرف نيابةً عنكم عند الحاجة؟

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

ولهذا أيضًا تُصر البنية على أمور لا يضطر خطاف ويب (webhook) بسيط إلى القلق بشأنها أبدًا:

• استجابات منظمة ومحدودة الحجم. يُرجع كل إجراء ينفّذه التطبيق استجابة واضحة مع بيانات منظمة يمكن للوكيل الاستدلال بها، لا كتلة بيانات خام غير محدودة عليه أن يخمّن محتواها.
• مصادقة موقّعة ومتبادلة. توقّع المنصة كل طلب يُرسل إلى التطبيق ليتمكن التطبيق من التحقق من أن Maven هو المتصل فعلًا، ويصادق التطبيق بدوره على المنصة ببيانات اعتماده الخاصة. فلا يضطر أي طرف إلى الاعتماد على الشبكة وحدها.
• التحقق من الإعدادات قبل وصولها إلى الإنتاج. لأن preInstall يعمل قبل تفعيل التطبيق، تُكتشف بيانات الاعتماد المعطوبة أو الإعدادات الناقصة وقت التثبيت، لا في أول مرة يعتمد فيها عميل عليها.
• بنية تحتية حقيقية في الأساس، لا مجرد استدعاء دالة. لأن التطبيقات تطبيقات كاملة، فيمكنها الاحتفاظ بحالة حقيقية: ذاكرة تخزين مؤقت، أو عدّاد للمعدّلات، أو قاعدة بيانات صغيرة، لا مجرد طلب واستجابة بلا حالة. وهذا ما يتيح، على سبيل المثال، تتبّع ما إذا كان معدل الحل لمجال معيّن قد انخفض بأكثر من 10% خلال آخر 24 ساعة، وتنبيه فريقكم عند حدوث ذلك. استدعاء API مجرد لا يمكنه الاحتفاظ بهذا النوع من الذاكرة. أما التطبيق الحقيقي فيمكنه ذلك، تمامًا كما تحتفظ مستعمرة النمل بذاكرة لمكان الغذاء رغم أن أي نملة بمفردها لا تحتفظ بها.
• إبعاد البيانات الحساسة عن النموذج. بعض الخطوات لا ينبغي أن تمر عبر الذكاء الاصطناعي إطلاقًا. فحين يكون العميل مستعدًا لشراء ما في سلته، يُطلق الوكيل عملية الدفع في التطبيق، ويجمع التطبيق بيانات الدفع والبيانات الشخصية مباشرة من العميل عبر واجهته الآمنة الخاصة. يتولى الوكيل تنسيق التدفق، لكن أرقام البطاقات وغيرها من المعلومات الحساسة لا تدخل أبدًا في المحادثة مع الذكاء الاصطناعي.
• قاعدة شيفرة واحدة لجميع العملاء، مع نطاق تأثير معزول. يعني تعدد المستأجرين أن الإصلاحات والتحسينات تُطرح مرة واحدة وتصل إلى الجميع، بينما يعني العزل أن المنطق المخصص لعميل ما لا يمكن أن يؤثر أبدًا في عميل آخر.

ماذا يعني ذلك لكم

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

بنينا Maven Apps لأننا نؤمن بأن هذا ما كان ينبغي أن تعنيه كلمة «تكامل» منذ البداية.