Personal Agent Protocol: هل يصبح OAuth لغة الوكلاء مع الشركات؟

في 6 أكتوبر 2026 أعلنت شركة Sierra، بالتعاون مع Meta، عن «بروتوكول الوكيل الشخصي» (Personal Agent Protocol أو PAP)، وهو معيار مفتوح يحدد كيف تتعامل وكلاء الذكاء الاصطناعي الشخصية مع الشركات. يشارك في تطويره كل من Genesys وInstinct وRocket وShopify وStripe وWalmart. الفكرة بسيطة في ظاهرها: بدل أن يخترع كل متجر وكل وكيل طريقته الخاصة في تسجيل الدخول وتنفيذ الطلبات، يتفق الجميع على لغة مشتركة.

لكن الأهمية الحقيقية للخبر في السؤال الذي يطرحه: حين يصبح لكل مستخدم وكيل يتصرف نيابةً عنه، كيف تعرف الشركة من هذا الوكيل، وماذا يحق له أن يفعل؟

ما هو بروتوكول الوكيل الشخصي؟

PAP معيار مفتوح يعرّف طريقة تواصل وكيل المستخدم الشخصي مع الشركة. يتعامل مع المصادقة، ويعطي المستخدم تحكماً بما يُسمح لوكيله بفعله، ويمنح الشركة رؤية واضحة لما يجري عبر موقعها أو واجهاتها البرمجية أو وكيلها الخاص. ويمكن لأي طرف تنفيذه.

أبرز ما أُعلن عنه:

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

كيف يعمل عملياً؟

جلسة واحدة عبر القنوات

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

ثلاث طرق للوصول

يتعامل الوكيل مع الشركة عبر موقعها، أو واجهاتها البرمجية (MCP وOpenAPI)، أو عبر وكيلها الخاص. هذا يعني أن الشركات الصغيرة التي لديها واجهة برمجية فقط تستطيع المشاركة دون بناء وكيل كامل.

ما الذي لم يدخل بعد؟

المدفوعات ليست جزءاً من الإصدار الأول. تضعها Sierra ضمن امتدادات مستقبلية، مع صلاحيات أدق وإشعارات الدفع (Push). ومن المقرر إصدار المواصفة v0.1 مع ورش تصميم ونموذج مرجعي في وقت لاحق من أكتوبر.

حين يتكلم الوكلاء مع الشركات، لا يكفي أن يفهموا بعضهم؛ يجب أن يعرف كل طرف من الذي يتكلم باسم من.

لماذا يهمّ المطورين؟

لمن يبني متاجر وخدمات

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

لمن يبني وكلاء

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

لمن يهتم بالأمان

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

ما الذي ينقص الصورة؟

تشير تقارير إلى أن Amazon وOpenAI وAnthropic ليست ضمن قائمة الشركاء المؤسسين حتى الآن، وأن Stripe وShopify انضمتا أيضاً إلى بروتوكول مختلف هو Trusted Agent Protocol من Visa. كما لم تحدد المصادر رخصة المعيار أو جهة حوكمته. لذلك يبقى الحكم على نجاحه مرهوناً بمدى انتشاره فعلاً، لا بقائمة الأسماء وحدها.

أسئلة شائعة

هل PAP هو نفسه MCP؟

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

هل يمكن للوكيل الدفع نيابةً عني عبره؟

ليس في الإصدار الأول، فالمدفوعات مدرجة ضمن الامتدادات المستقبلية وفق ما أعلنته Sierra.

هل المعيار متاح الآن للتنفيذ؟

الإعلان صدر، لكن المواصفة v0.1 ونموذج التنفيذ المرجعي مقرران لاحقاً في أكتوبر، فالأفضل متابعة المواصفة قبل بناء أي شيء عليها.

الخلاصة

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

المصادر: Sierra، The Paypers، YourStory