تناولت المقالات الأربع السابقة في هذه السلسلة القراءة. وهذه المقالة تتناول الفعل — وكيل يحجز، يشتري، يرسل نموذجًا أو يجلب بيانًا. فحصتُ حالة المعايير على أرض الواقع، والصورة حادّة: WebMCP مسوّدة مجموعة مجتمعية في W3C، في تجربة أصل ضمن كروم وإيدج، وآبل سجّلت اعتراضًا رسميًا. وبروتوكول التجارة من OpenAI وStripe يتطلّب من التاجر تنفيذ خمس نقاط نهاية وهو في بيتا — وفي موقعه الرسمي مكتوب أن آليات الاكتشاف ما زالت قيد التطوير. ومجموعة عمل IETF لهوية الوكلاء اعتُمدت، لكن لا وثيقة متبنّاة فيها بعد. وفي أبرز مقياس مستقل لتنفيذ مهام مكتبية، بلغت أفضل نتيجة موثّقة 42.9% من المهام.
الطبقات الثلاث التي يجب أن تتحقّق
كي ينفّذ وكيل مهمة في موقعكم يجب أن تتحقّق ثلاثة أمور في آن: أن يعرف ما هو مسموح له فعله، وأن تتوفّر له واجهة للتنفيذ، وأن تعرفوا أنه هو فعلًا لا منتحل. يلخّص الجدول موقع كل طبقة اليوم.
| الطبقة | الآلية الرائدة | الحالة الفعلية |
|---|---|---|
| إعلان القدرات | WebMCP | مسوّدة مجموعة مجتمعية؛ تجربة أصل في كروم وإيدج؛ WebKit اعترضت |
| تنفيذ الشراء | ACP | بيتا؛ خمس نقاط نهاية للتاجر؛ بلا آلية اكتشاف |
| إذن الدفع | AP2 | الإصدار 0.2؛ مُتبرَّع به لـFIDO Alliance؛ لا يتطلّب تغييرًا في الموقع |
| وكيل مقابل وكيل | A2A | الإصدار 1.0.1؛ مستقر، لكنه يحلّ مشكلة أخرى |
| هوية الوكيل | Web Bot Auth | مجموعة العمل اعتُمدت في IETF؛ لا وثيقة متبنّاة بعد؛ Cloudflare نفّذت |
| تمييز المتصفّح الوكيلي | — | لا يوجد user-agent موثّق لأي متصفّح وكيلي |
WebMCP: أين يقف فعلًا
WebMCP هو فكرة أن يعلن الموقع داخل الصفحة نفسها ما يقدّمه من إجراءات للوكيل — بدل أن يخمّن الوكيل أين يضغط. هذه هي المقاربة الصحيحة، ولذلك تحظى بعناوين كثيرة. لكن من المهم معرفة وضعها الرسمي.
تنشر الوثيقة مجموعة Web Machine Learning Community Group في W3C، وفي مقدّمتها مكتوب صراحةً أنها ليست معيار W3C وليست على مسار التقييس. ومحرّروها من مايكروسوفت وجوجل. ونسخة المسوّدة التي قرأتها تحمل تاريخ 26 أغسطس 2026.
أما التنفيذات: فتحت كروم تجربة أصل في الإصدار 149، وفق إعلان في مدوّنة المطوّرين نُشر في 9 يونيو 2026. وفتحت إيدج تجربة أصل في الإصدار 150، وتشغّله Brave تجريبيًا في Leo، ويدعمه تطبيق ChatGPT لسطح المكتب. في المقابل سجّلت WebKit موقف اعتراض مع قائمة تحفّظات تشمل اختيار المنتدى نفسه، وسجّلت موزيلا موقفًا محايدًا.
خطآن يتكرّران في كل دليل: الواجهة ليست navigator.modelContext — كلمة Navigator لا ترد في نص المواصفة ولو مرة واحدة. وكروم لم تدمجه في الإصدار 146 في فبراير 2026؛ المدوّنة الرسمية تتحدّث عن تجربة أصل في الإصدار 149. وإن أخبركم دليل بغير ذلك فهو لم يقرأ المصدر.
كيف يبدو ذلك في الشيفرة
الواجهة الحقيقية هي document.modelContext.registerTool. والفكرة بسيطة: تسجّل الصفحة أداةً لها اسم ووصف ومخطّط مدخلات ودالّة تنفّذ. فيرى الوكيل الذي يشغّل الصفحة الأداة دون أن يخمّن وظيفة كل زر.
document.modelContext.registerTool({
name “book_appointment”,
description “Book an appointment on a given date”,
inputSchema {
type “object”,
properties { date { type “string” } },
required [“date”]
},
async execute({ date }) {
const result = await bookOnServer(date);
return { content [{ type “text”, text result.confirmation }] };
}
});
المهم ليس الصياغة بل ما يترتّب عليها: الفعل يمرّ عبر شيفرتكم أنتم. أنتم تقرّرون ما يُكشف، وأنتم تتحقّقون من المدخلات، وأنتم تتحكّمون في الآثار الجانبية. وهذا يختلف جوهريًا عن وكيل يحاول الضغط على الواجهة المرئية ويأمل. في هذه المرحلة، كل تنفيذ من هذا النوع تجربة — لا بنية إنتاج.
التجارة الوكيلية: ثلاثة بروتوكولات، ثلاث مشكلات مختلفة
من السهل الخلط لأن الأسماء الثلاثة تظهر في التقارير نفسها، لكنها تحلّ أمورًا مختلفة تمامًا.
- ACP — Agentic Commerce Protocol، تتولّاه OpenAI وStripe ويُعرّف نفسه بأنه في بيتا، برخصة Apache-2.0. وآخر نسخة مواصفة رأيتها تحمل تاريخ 17 أبريل 2026. ومن منظور التاجر فالمطلب ملموس: تنفيذ خمس نقاط نهاية من نوع REST لإدارة جلسة الدفع — إنشاء وتحديث وإتمام وإلغاء وجلب — إضافة إلى webhooks لأحداث الطلب. وفي الموقع الرسمي مكتوب أنهم ما زالوا يعملون على إنشاء آليات اكتشاف تتيح لمنصّات الذكاء الاصطناعي التعرّف على الأنشطة التجارية. أي حتى لو نفّذتم كل شيء، لا سبيل معياريًا اليوم للإعلان عن ذلك — وهي بالضبط الفجوة التي وصفتها في مقالة طبقة الاكتشاف.
- AP2 — Agent Payments Protocol من جوجل، في الإصدار 0.2، أُعلن في سبتمبر 2025 وتُبرِّع به منذئذ لـFIDO Alliance لمواصلة التقييس. وهو مبني كامتداد لـA2A، ويعالج إذن الدفع: اعتمادات موثّقة تُثبت أن المستخدم سمح فعلًا للوكيل بالدفع. ولا يتطلّب أي تغيير في HTML موقعكم، ولذلك فهو ليس بديلًا لـACP بل طبقة تحته.
- UCP — Universal Commerce Protocol، الذي يُطوَّر وفق إعلان من Shopify بتاريخ 24 مارس 2026 بالتعاون مع جوجل وبدعم من Walmart وTarget وEtsy وAmerican Express وMastercard وStripe وVisa. لم أفتح المواصفة نفسها، ولذلك لن أذكر رقم إصدار.
ملاحظة تمنع خيبة الأمل: في إعلان Shopify نفسه يوصَف أن تكاملها مع ChatGPT يعمل عبر متصفّح داخلي، وأنه على سطح المكتب يحيل مباشرة إلى متجر التاجر. أي إن «الشراء داخل ChatGPT» ليس بالضرورة صفحة دفع أصلية وفق ACP. وفي توثيق OpenAI مكتوب أن Instant Checkout متاح لشركاء معتمدين — لا لكل تاجر.
A2A يحلّ مشكلة أخرى
وصل A2A إلى الإصدار 1.0.0 في مارس 2026 وإلى 1.0.1 في مايو 2026، وهو الأنضج في المجموعة. يعرّف بطاقة وكيل — مستند JSON يصف الهوية والقدرات والمهارات وعنوان الخدمة ومتطلّبات المصادقة لخادم وكيل — وينشرها في المسار /.well-known/agent-card.json. وهي أيضًا المدخل الوحيد من عالم الوكلاء المسجّل في سجلّ IANA.
ولهذا بالذات يجب التدقيق: مجاله هو الاتصال بين منظومات وكلاء مستقلة، لا بين موقع ووكيل. ونشر هذا الملف على موقع تعريفي لا يفعل شيئًا، إلا إن كنتم تشغّلون فعلًا خادم A2A خلفه. وقد رأيتُ توصيات كثيرة تُفوّت هذا التمييز.
كيف يُميَّز الوكيل أصلًا
هذه أكثر الطبقات نقصًا، وأحدّ نتيجة في هذا البحث نتيجة سلبية: لا يوجد user-agent موثّق لأي متصفّح وكيلي. صفحة الروبوتات لدى OpenAI تُفصّل OAI-SearchBot وOAI-AdsBot وGPTBot وChatGPT-User — ولا مدخل فيها لـChatGPT Atlas. وصفحة الروبوتات لدى Anthropic تُفصّل ClaudeBot وClaude-User وClaude-SearchBot — ولا مدخل فيها لـClaude in Chrome. وإن رأيتم في السجلّات سلسلة تبدو كمتصفّح وكيلي، فهي غير موثّقة وقد تتغيّر دون إشعار.
والاستجابة الآخذة في التبلور هي Web Bot Auth: توقيع تعمية على الطلب نفسه. اعتُمدت مجموعة عمل بهذا الاسم في IETF، لكن لا وثيقة متبنّاة فيها حتى اليوم — وكل المسوّدات ذات الصلة ما زالت بصفة فردية. وقد حُدّثت مسوّدة البروتوكول المركزية في 19 أغسطس 2026.
وقد نفّذت Cloudflare الآلية بالفعل: دليل مفاتيح في المسار /.well-known/http-message-signatures-directory وترويسات Signature-Agent وSignature-Input وSignature في الطلب. ويذكر توثيقها أيضًا أنه منذ 1 يوليو 2026 يوجد حقل بيانات وصفية جديد يميّز بين وكيل مباشر ووسيط، وأن فئات السلوك تشمل صراحةً تنفيذ معاملات نيابة عن مستخدم. وتحفّظ يجدر معرفته: تنفّذ Cloudflare نسخ مسوّدة أقدم من الأحدث، ولذلك فعدم التطابق بين التنفيذات متوقّع في هذه المرحلة.
ما مدى جودة تنفيذ الوكلاء للمهام فعلًا
هنا يهمّني إعطاء رقم حقيقي بدل انطباع. أجدى مقياس مستقل وجدته هو TheAgentCompany، الذي طُوّر في جامعة كارنيغي ميلون بدقة، ويضمّ 175 مهمة تحاكي العمل في شركة برمجيات. والنتائج في لوحة النتائج موسومة بأنها موثّقة باستقلالية.
- أفضل نتيجة في اللوحة: 42.9% من المهام أُنجزت، وهي قيمة سُجّلت في 10 نوفمبر 2025.
- تركيبة OpenHands-Versa مع Claude Sonnet 4 أنجزت 33.1% في يونيو 2025.
- OpenHands مع GPT-4o أنجز 8.6% في ديسمبر 2024.
تحفّظ لا بدّ من ذكره: أحدث قيمة في اللوحة من نوفمبر 2025، ولا تتضمّن نماذج 2026 الأمامية. لذلك لا تقدّموا 42.9% بوصفها «حالة المعرفة في 2026» بل أفضل نتيجة موثّقة باستقلالية في هذا المقياس. وما يقوله الرقم فعلًا، حتى مع افتراض تحسّن كبير، هو أنه لا يوجد بعد واقع تُسلَّم فيه للوكيل مهمة معقّدة ويُتوقّع أن تكتمل.
ما الذي يُفعل اليوم فعلًا
التوصية الصادقة ألّا تسارعوا إلى تنفيذ مسوّدات. ترتيبي، وفق ما هو موثّق ومستقر: أولًا التأكد من أن الموقع قابل للقراءة أصلًا — أذونات صحيحة، ومحتوى في HTML الأوّلي، وصفحات قابلة للاقتباس. ثم التحقّق من أن حجوباتكم لا تُسقط وكلاء شرعيين يعملون نيابة عن مستخدم: هذا خطأ شائع، والآلية الوحيدة الموثّقة للإذن الصريح التي وجدتها هي آلية Cloudflare، التي تتيح لمزوّدي الروبوتات تقديم طلب ولأصحاب المواقع تفعيل إعدادات بحسب الفئة.
وبعد ذلك فقط، إن كان نموذجكم التجاري يربح من ذلك حقًا، فكّروا في تجربة رائدة: تجربة أصل لـWebMCP لإجراء واحد محدَّد جيدًا، أو تنفيذ ACP إن كنتم تبيعون منتجات ولديكم موارد تطوير. وفي الحالتين تعاملوا مع الأمر كتجربة، لأنه كذلك.
والفجوة التي تبقى مفتوحة هي بالضبط التي وصفتها على امتداد هذه السلسلة: لا سبيل معياريًا لموقع كي يعلن ما يقدّمه لوكيل. ACP يعترف بذلك بنفسه، وMCP لا يغطّيه، وA2A يحلّ مشكلة أخرى. ولهذا أعمل على مواصفة AX. لكن إلى أن يوجد معيار متّفق عليه، توصيتي ألّا تخترعوا مسارًا خاصًا وتأملوا — بل أن تبنوا ما يعمل بالفعل.
هل يُستحسن تنفيذ WebMCP في موقعي اليوم؟
كتجربة فقط. الوثيقة مسوّدة مجموعة مجتمعية في W3C، ومكتوب فيها صراحةً أنها ليست معيارًا وليست على مسار التقييس. فتحت كروم وإيدج تجربة أصل، وسجّلت WebKit اعتراضًا وموزيلا موقفًا محايدًا. هذه ليست حالة تُبنى عليها بنية إنتاج.
ما اسم واجهة WebMCP الحقيقي؟
document.modelContext.registerTool. أما الاسم navigator.modelContext الذي يظهر في أدلة كثيرة فخاطئ — كلمة Navigator لا ترد في نص المواصفة إطلاقًا.
ما الذي يجب تنفيذه بالضبط لدعم التجارة الوكيلية لدى OpenAI؟
وفق مواصفة ACP، على التاجر تنفيذ خمس نقاط نهاية من نوع REST لإدارة جلسة الدفع — إنشاء وتحديث وإتمام وإلغاء وجلب — إضافة إلى webhooks لأحداث الطلب. والبروتوكول معرَّف بأنه في بيتا، وInstant Checkout موثّق بأنه متاح لشركاء معتمدين.
هل يُستحسن نشر agent-card.json في الموقع؟
فقط إن كنتم تشغّلون خادم A2A فعلًا. تصف البطاقة الهوية والقدرات وعنوان الخدمة ومتطلّبات المصادقة لخادم وكيل، وA2A يعالج الاتصال بين منظومات الوكلاء — لا بين موقع ووكيل. وعلى موقع تعريفي لا يفعل الملف شيئًا.
كيف أميّز حركة متصفّح وكيلي في السجلّات؟
حتى اليوم، لا سبيل موثّقًا. صفحتا الروبوتات لدى OpenAI وAnthropic لا تتضمّنان مدخلًا لمتصفّحيهما الوكيليين. والآلية الآخذة في التبلور هي Web Bot Auth القائمة على توقيع الطلب؛ اعتُمدت مجموعة عمل بشأنها في IETF لكن لا وثيقة متبنّاة فيها بعد، وقد نفّذت Cloudflare نسخ مسوّدة منها.