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

في APC و APX، اخترنا مساراً مختلفاً. الصوت ليس قناة، بل هو نمط (mode). إنه يوضع فوق الواجهة بدلاً من استبدالها. إن إدراك هذا الفرق هو ما يمنع النظام من التفكك.

التجريد الخاطئ

عندما تتعامل مع الصوت كقناة مستقلة، فإنك تفترض ضمنياً أن التحدث إلى الوكيل هو محادثة مختلفة جوهرياً عن الكتابة إليه. تستجيب الفرق الهندسية لذلك عن طريق تقسيم قاعدة الكود (codebase). فجأة، تصبح هناك قناة CLI وقناة صوتية منفصلة لـ CLI. وتصبح هناك قناة ويب وقناة ويب صوتية موازية. تتطلب كل واحدة منها تنويعات خاصة في البرومبت (prompt)، وقواعد تنسيق، ومنطقاً خاصاً للتعامل مع السياق.

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

فصل السياق عن وقت التشغيل

لمنع حدوث ذلك، قمنا بفصل المسؤوليات بين طبقتين تظلان منفصلتين تماماً.

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

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

هذا الفصل يعني أن المشروع المحدد في APC يظل سليماً بغض النظر عن عدد الواجهات التي تعرضها APX. العقد لا يتغير، بل طبقة العرض فقط هي التي تتغير.

كيف تعمل الأنماط فعلياً

في تنفيذنا، تُعد الواجهات مثل تلغرام و CLI وتطبيق الويب قنوات. تخبرك القناة بمكان حدوث التفاعل. أما الصوت، فيتم وضعه كنمط (mode) من خلال البيانات الوصفية (metadata) للقناة. يخبرك النمط بكيفية تصرف الرد.

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

النتيجة هي شجرة برومبت واحدة لكل واجهة. لا يوجد فرع منفصل لـ voice-desktop، ولا يوجد متغير whisper-web. يتم تطبيق المعدل فقط عندما يطلبه وقت التشغيل، وفقط في آخر لحظة مسؤولة. يظل البرومبت الأساسي ثابتاً.

ما الذي ستجنيه

تحقق هذه البنية نتائج ملموسة بثلاث طرق.

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

تسجيل دقيق للسجلات. تسجل القنوات مكان حدوث التفاعل، بينما تسجل الأنماط كيفية تقديم الرد. يظل تفاعل سطح المكتب تفاعلاً عبر سطح المكتب سواء قرأه المستخدم أو سمعه. عندما يقوم فريقك بتتبع خطأ برمجِي أو مراجعة التحليلات، فلن يضطروا للمطابقة بين "desktop-voice" و "desktop-text" كما لو كانا واجهتين مختلفتين للمنتج. يظل معرف القناة نظيفاً، ويستقر علم النمط (mode flag) بجانبه بدقة في البيانات الوصفية. تظل سجلاتك صادقة، وتظل عملية تصحيح الأخطاء مباشرة لأن الموقع والسلوك غير متشابكين.

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

الإثبات على سطح المكتب

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

الخلاصة الحقيقية

الفكرة الجوهرية بسيطة. يصف APC معنى المشروع المستقر، بينما يصف APX التنفيذ في وقت التشغيل. الصوت هو مُعدِّل للواجهة وليس بديلاً عنها. تعامل معه بهذه الطريقة، وستظل أوامرك صغيرة. وستظل سجلاتك واضحة. و...