IETF تدرس وضع معيار لبروتوكول وكلاء AI في عام 2026

في سطر واحد: في اجتماع IETF 126 في فيينا هذا الأسبوع، تساءلت جلسة Birds-of-a-Feather تسمى agentproto عما إذا كان ينبغي للهيئة المسؤولة عن معايير الإنترنت تحديد كيفية تواصل وكلاء الذكاء الاصطناعي (AI agents) مع بعضهم البعض عبر المؤسسات — وهي الفجوة التي تتركها البروتوكولات المهيمنة حالياً، MCP و A2A، مفتوحة.¹

ملخص: لأكثر من عام، طرح الموردون بروتوكولات متنافسة لوكلاء الذكاء الاصطناعي — MCP من Anthropic، و A2A من Google، والعديد غيرها — ولم يتجاوز أي منها الحاجز الوحيد الذي يجعل البروتوكول قابلاً للتشغيل البيني عبر حدود المؤسسات: وهو الحصول على RFC من IETF. في يوم الخميس 23 يوليو، نقلت جلسة agentproto Birds-of-a-Feather (BoF) في IETF 126 في فيينا هذا السؤال إلى قوة مهام هندسة الإنترنت (Internet Engineering Task Force)، بهدف تأسيس مجموعة عمل (Working Group).¹ هذا ليس تصويتاً وليس إطلاقاً لمنتج؛ فمنظمة IETF تعمل بنظام "التوافق التقريبي" (rough consensus)، وأي معيار ينتج عن ذلك سيستغرق سنوات.² الشيء الجديد حقاً هو أن التواصل من وكيل إلى وكيل يتم التعامل معه الآن كمشكلة في البنية التحتية للإنترنت، وليس مجرد ميزة يقدمها مورد معين.

ما ستتعلمه

• ماذا حدث في جلسة agentproto BoF في IETF 126، وما الذي تقرره جلسة "Birds-of-a-Feather" فعلياً
• لماذا تعمل IETF بنظام التوافق التقريبي بدلاً من التصويت — ولماذا يهم هذا الإطار هنا
• كيف يختلف MCP عن A2A، وفجوة التشغيل البيني التي لم يغلقها أي منهما
• المشكلات المحددة التي تقول مسودة الإطار الأساسي إنها لا تزال بحاجة إلى معيار
• لماذا يعد "حقن الأوامر" (prompt injection) هو الاختبار الأمني الذي يجب أن يجتازه أي معيار لبروتوكول الوكلاء
• الجدول الزمني الواقعي من جلسة BoF إلى نشر RFC، وما الذي يجب مراقبته تالياً

ماذا حدث في جلسة agentproto BoF

انعقد اجتماع IETF 126 في الفترة من 18 إلى 24 يوليو 2026 في فيينا، ومن بين جلسات مجموعات العمل القائمة، حددت المنظمة خمس جلسات Birds-of-a-Feather — وهي مناقشات مبكرة على مستوى المجتمع حول أعمال قد تكون جاهزة لتتولاها IETF.¹ ثلاث من هذه الجلسات الخمس تناولت وكلاء الذكاء الاصطناعي بشكل مباشر. وكانت الجلسة الأكثر أهمية لأي شخص يبني أنظمة متعددة الوكلاء هي agentproto (بروتوكولات اتصال الوكلاء)، التي عُقدت يوم الخميس 23 يوليو، من الساعة 09:00 إلى 11:00 بتوقيت وسط أوروبا.¹

صياغة IETF نفسها دقيقة: فقد أنتج العام الماضي "اندفاعاً من البروتوكولات المتنافسة والمتداخلة لربط وكلاء الذكاء الاصطناعي ببعضهم البعض وبالأدوات التي يستخدمونها — Model Context Protocol (MCP)، و Agent2Agent (A2A)، و Agent Communication Protocol (ACP)، و Agent Network Protocol (ANP)، وغيرها". وتقول إن جلسة agentproto "تنقل هذه المحادثة إلى IETF"، بناءً على اجتماع جانبي شهد حضوراً كبيراً في IETF 124، وعلى عمل في الإطار والمتطلبات بقيادة Jonathan Rosenberg و Cullen Jennings، "بهدف تأسيس مجموعة عمل للمضي قدماً في هذا العمل".¹

هذه العبارة — تأسيس مجموعة عمل — هي الهدف الفعلي من الاجتماع. فجلسة BoF ليست المكان الذي يُكتب فيه المعيار، بل هي المكان الذي يقرر فيه المجتمع ما إذا كان هناك توافق وطاقة كافيتان، ونطاق محدد بما يكفي لتبرير بدء العملية التي تستغرق سنوات وتؤدي في النهاية إلى إنتاج معيار.²

لماذا هو توافق تقريبي وليس تصويتاً

من المغري وصف جلسة يوم الخميس بأنها تصويت على معيار بروتوكول وكلاء AI الخاص بـ IETF. لكن هذا النموذج الذهني خاطئ، والتمييز هنا ليس مجرد تدقيق لغوي. فمنظمة IETF لا تقرر عن طريق عد الأصوات، بل تقرر بناءً على "التوافق التقريبي والكود الذي يعمل" — وهو اتفاق عمل داخل القاعة وفي القائمة البريدية، مدعوم بتنفيذات تعمل بالفعل.² إن أي BoF يهدف إلى "تكوين مجموعة عمل"، كما يطمح agentproto، ينجح عندما يثبت وجود مشكلة متماسكة ومجتمع راغب في الحل؛ ويمكنه ببساطة إعادة العمل إلى القائمة البريدية إذا كشفت المناقشات عن خلاف كبير حول النطاق.²

هذا هو السبب في أن نتيجة IETF تحمل ثقلاً لا تحمله إعلانات الشركات الموردة. إن وثائق RFC التي نتجت عن هذه العملية هي التي تحدد TLS و DNS والنقل الذي يرتكز عليه مرور الويب الحديث، وهي مستمرة تحديداً لأنها لم تُفرض من قبل شركة واحدة. إذا قامت IETF في النهاية بتكليف مجموعة عمل لبروتوكول الوكلاء، فإنها تؤكد أن معيار بروتوكول وكلاء AI الخاص بـ IETF ينتمي إلى نفس فئة تلك المواصفات التأسيسية — أي أنه شأن يتعلق بطبقة الإنترنت وليس بطبقة المنتج. وحتى لحظة كتابة هذه السطور، فإن النتيجة الرسمية لجلسة الخميس — سواء تم تكليف مجموعة عمل أم لا — تتبع عملية التوافق تلك؛ ويتم نشر مواد الجلسة والمحاضر على IETF Datatracker بمجرد نهائيتها، وهذا هو المكان المعتمد لتأكيد النتيجة بدلاً من الملخصات الصحفية المبكرة.

MCP مقابل A2A: طبقتان، وقطعة واحدة مفقودة

لكي تفهم سبب اهتمام IETF من الأساس، يجب أن ترى ما تغطيه البروتوكولات الحالية وما لا تغطيه. فهي ليست منافسة بقدر ما هي جيران يحلون أنصافاً مختلفة من المشكلة.

MCP (Model Context Protocol) هو بروتوكول خادم-عميل (client-server): حيث يتواصل الوكيل مع أداة أو قاعدة بيانات أو API ويطلب بيانات أو إجراءً معيناً. تبرعت Anthropic بـ MCP إلى Agentic AI Foundation — وهو صندوق موجه تحت مظلة Linux Foundation — في 9 ديسمبر 2025، وبحلول ذلك الوقت سجل البروتوكول "أكثر من 97 مليون عملية تحميل شهري لـ SDK، و10,000 خادم نشط"، مع دعم ممتاز للعملاء عبر ChatGPT و Claude و Cursor و Gemini و Microsoft Copilot و Visual Studio Code.³ المراجعة التالية، مواصفات 2026-07-28، هي الأكبر منذ الإطلاق، وتقوم من بين أمور أخرى بإعادة مواءمة التفويض مع OAuth 2.1؛ وقد غطينا هذا التغيير بعمق في مقالنا عن مواصفات MCP عديمة الحالة (stateless) بتاريخ 2026-07-28.⁴

A2A (Agent2Agent) هو بروتوكول نظير-إلى-نظير (peer-to-peer): حيث يكتشف وكيلان قدرات بعضهما البعض ويفوضان المهام. تبرعت Google بـ A2A إلى Linux Foundation في 23 يونيو 2025 في Open Source Summit North America، وكان من بين الأعضاء المؤسسين Amazon Web Services و Cisco و Microsoft و Salesforce و SAP و ServiceNow؛ ومنذ ذلك الحين نمت هذه المجموعة لتشمل أكثر من 100 شركة تكنولوجيا.⁵⁶ إذا كنت تريد نسخة عملية حول كيفية إعلان الوكلاء عن قدراتهم وتسليم العمل، فإن درس بروتوكول A2A التعليمي يشرح ذلك بالتفصيل.

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

المشكلات التي يرى الإطار أنها لا تزال بحاجة إلى معيار

الأساس الفكري لـ agentproto هو إطار عمل ووثيقة متطلبات ألفها جوناثان روزنبرغ من Five9، وكولين جينينجز من Cisco.⁷ مشاركة روزنبرغ هي إشارة في حد ذاتها: فهو مؤلف رئيسي لـ RFC 3261، وهو بروتوكول بدء الجلسة (SIP) الذي يحكم الكثير من الصوت والفيديو في الوقت الفعلي على الإنترنت. هناك تحذير إجرائي واحد يستحق ذكره بوضوح: مسودة الإنترنت (Internet-Draft) هي مقترح وليست معياراً. يرفق متتبع البيانات إخلاء مسؤولية صريح بأن هذه المسودات "غير معتمدة من قبل IETF" و"ليس لها مكانة رسمية في عملية معايير IETF"، وقد تم استبدال مسودة الإطار الأولية بالفعل — الوثيقة الحالية هي draft-rosenberg-agentproto-usecases.⁷⁸

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

لماذا يعتبر حقن الأوامر (prompt injection) هو اختبار الأمان

أكثر الحجج التقنية ملموسة لتوحيد هذا الأمر على مستوى البروتوكول هي حجة أمنية، وتتمحور حول حقن الأوامر.

في نظام العميل الواحد، يعني حقن الأوامر أن يقوم المستخدم بصياغة مدخلات تتجاوز تعليمات العميل. وتصنفها OWASP على أنها LLM01 — الخطر رقم واحد في قائمة أهم 10 مخاطر لتطبيقات LLM.⁹ أما النسخة متعددة العملاء فهي أسوأ هيكلياً. يمكن لمستخدم خبيث صياغة مدخلات للعميل A تكون موجهة في الواقع إلى العميل B، وهو العميل الذي يستدعيه A تالياً. ولأن A ينقل محتوى المستخدم إلى B كجزء من التشغيل العادي، ولأن B يثق في A، فإن التعليمات المحقونة يمكن أن تستغل علاقة الثقة هذه لتتجاوز دفاعات A مباشرة.⁷ موقف الإطار هنا صريح: حقن الأوامر يصعب منعه بشكل معروف، لذا فإن الحل على مستوى البروتوكول ليس المنع بل الإسناد — آليات للتسجيل والتشخيص وإعادة بناء أي عميل فعل ماذا عند وقوع حادث.⁷

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

الجدول الزمني الواقعي — وما يجب مراقبته

ضع التوقعات وفقاً لذلك. عملية IETF بطيئة عمداً: فعادةً ما ينتقل المقترح من جلسة BoF، إلى مجموعة عمل معتمدة، مروراً بمراجعات وتعديلات متعددة لمسودات الإنترنت (Internet-Draft)، وصولاً إلى RFC منشور — وهو مسار يستغرق عادةً ما بين سنتين إلى أربع سنوات.¹⁰ لم يتم إطلاق أي شيء في فيينا هذا الأسبوع. ما يمكن أن ينتج عن الاجتماع هو قرار بـ البدء، وهذا القرار هو الذي سيشكل شكل مسار RFC في عامي 2027 و 2028.

السؤال الاستراتيجي الكامن هو ما إذا كان معيار بروتوكول وكلاء AI مفتوح من IETF هو الذي سيحدد اتصالات الوكلاء بين المجالات، أو ما إذا كانت البروتوكولات المهيمنة على السوق ستتحول إلى معايير واقعية (de facto) بفعل زخم الانتشار وحده. إن تبني MCP بمعدل 97 مليون تحميل شهرياً يمثل قوة جذب حقيقية، ومن الممكن تماماً أن يتم تحديد الأساس العملي بناءً على ما هو منتشر بالفعل بدلاً من ما ستباركه IETF في النهاية.³ التوتر بين هاتين النتيجتين هو القصة التي تستحق المتابعة. وهو أيضاً نفس التوتر بين التوافق التشغيلي والارتباط بمورد واحد (lock-in) الذي يضغط عليه المنظمون من اتجاه مختلف، كما غطينا في سعي الاتحاد الأوروبي لتحقيق التوافق التشغيلي لوكلاء AI بموجب قانون الأسواق الرقمية (DMA).

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