كيف يشتري وكلاء الذكاء الاصطناعي دومينات من غير تدخل بشري (2026)

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

في 15 أبريل 2026، الفلتر ده ما بقاش شاملًا. أطلقت Cloudflare واجهة Registrar API في نسخة تجريبية عامة، ووصفت تغطية القطاع عرضها بوضوح: Cloudflare "نقلت المعاملة إلى طبقة الوكلاء"؛ أي الطبقة المعمارية اللي فيها البرنامج، مش شخص بينقر في نموذج، هو اللي يبدأ الشراء. تسجيل الدومين وDNS وعدد من المهام الأخرى اللي قاومت الأتمتة الكاملة لأنها كانت بتفترض وجود إنسان أمام لوحة المفاتيح، بطلت تفترض ده بهدوء.

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

إيه اللي اتغير تقنيًا؟

صناعة الدومينات ما أعادتش كتابة قواعدها في أبريل 2026. كان عند المُسجِّلين واجهات API برمجية منذ عقود قبلها؛ اللي اتغير هو مين يقدر يفهم الواجهات دي ويستخدمها بسهولة.

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

ثلاثة أشياء حلت محل النموذج ده، وهي بتتراكم فوق بعض بدل ما تتنافس:

• واجهات REST API تتطلب المصادقة، بحيث يكتمل الشراء كاستدعاء HTTP بدل صفحة دفع معروضة. نسخة Cloudflare التجريبية بتغطي البحث والتوافر والتسجيل بالطريقة دي، وتفيد تقارير الإطلاق إن التسجيل بيكتمل «بصورة متزامنة خلال ثوانٍ للدومينات القياسية».
• MCP (بروتوكول سياق النموذج)، وهو معيار مفتوح تصفه وثائقه بأنه "معيار مفتوح المصدر لربط تطبيقات الذكاء الاصطناعي بالأنظمة الخارجية". الفرق هنا بين وكيل استلم كود تكامل مخصص ووكيل يقدر يكتشف أدوات المُسجِّل، مثل search وregister وset_dns_record، ويستدعيها مباشرة من داخل Claude أو Cursor أو أي عميل متوافق آخر. ربطت Cloudflare واجهة Registrar API بالطبقة دي بحيث، حسب وصفها، «يقدر وكيل يعمل داخل Cursor أو Claude Code أو أي بيئة متوافقة مع MCP أن يكتشف نقاط نهاية Registrar ويستدعيها» من غير خطوة تكامل منفصلة.
• اكتشاف llms.txt، وهو اصطلاح نصي بسيط، «اقتراح لتوحيد استخدام ملف /llms.txt لتقديم معلومات تساعد نماذج اللغة الكبيرة على استخدام موقع ويب وقت الاستدلال»، وبيخلي الوكيل اللي ما شافش مُسجِّلًا معينًا قبل كده يعرف هو يقدر يعمل إيه من غير ما إنسان يلصق وثائق API في المحادثة أولًا.

ولا واحدة من القطع الثلاث دي جديدة لوحدها؛ MCP ظهر أواخر 2024 وllms.txt اقتُرح في السنة نفسها. الجديد إن مُسجِّلًا كبيرًا وضع الثلاثة وراء مسار شراء شغّال، وده اللي خلّى عبارة «وكلاء الذكاء الاصطناعي يسجلون دومينات» عنوانًا خبريًا بدل تجربة لهواة.

إيه اللي بيعمله الوكيل فعلًا؟

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

1. البحث. الوكيل يستدعي نقطة بحث المُسجِّل، أو أداة MCP المكافئة، باسم مرشح أو بوصف لما هو مطلوب، ويرجع له قائمة ببدائل متاحة ومحجوزة.
2. فحص التوافر والسعر. لاسم محدد، الوكيل يستعلم عن التوافر اللحظي والسعر الدقيق: رسوم التسجيل، وأي علاوة على السعر، ورسوم معاملة ICANN إن وُجدت. هنا قائمة منتقاة من TLD مهمة: عدة نسخ تجريبية مصممة للوكلاء، ومنها Cloudflare، بتغطي جزءًا من نطاقات المستوى الأعلى الشائعة بدل كتالوج كامل عند الإطلاق.
3. المصادقة والتفويض. الوكيل يقدم بيانات اعتماد يقدر المُسجِّل يتحقق منها برمجيًا، مثل مفتاح API مرتبط بحساب ممول أو توقيع محفظة، بدل بطاقة محفوظة خلف صفحة تسجيل دخول.
4. التسجيل. الوكيل يستدعي نقطة نهاية التسجيل. المُسجِّل يمرر الطلب إلى السجل الخاص بالدومين باستخدام EPP، وهو بروتوكول التزويد القابل للتمديد الذي استخدمه المُسجِّلون للتواصل مع السجلات منذ أن وصل إلى حالة المعيار المقترح في 2004؛ ينشئ السجل القيد، ثم تعيد واجهة API تأكيدًا، عادة خلال ثوانٍ.
5. إعداد DNS. بعد تأمين الاسم، يضبط الوكيل خوادم الأسماء أو سجلات DNS منفردة؛ سجل A يشير إلى خادم، أو CNAME يشير إلى منصة استضافة. وغالبًا بيكون ده الاستدعاء اللي بعده مباشرة في نفس المحادثة اللي سجلت الاسم.
6. التأكيد للإنسان. في مسار وكيل متصمم كويس، الإنسان ما يعرفش عن الشراء من كشف البطاقة بعد الواقعة؛ الوكيل بيرجع له بالاسم والسعر والوجهة اللي وجّه الدومين لها.

الخطوة السادسة دي بتعمل شغل أكبر مما يبدو، وده موضوع القسم التالي.

الضوابط: «بدون تدخل بشري» لسه محتاجة سياسة يحددها إنسان

عبارة «بدون تدخل بشري» بتوصف الآلية، مش الحوكمة. واجهة API لا تحتاج شخصًا يضغط زرًا أثناء المعاملة، لكن لسه حد لازم يقرر مقدمًا إيه المسموح للوكيل يعمله بالصلاحية اللي اتمنحت له. وثائق Cloudflare نفسها للنسخة التجريبية واضحة بشأن مكان المسؤولية: "من مسؤولية الإنسان تصميم مسار وكيل لن يشتري دومينات من دون موافقتك." واجهة API تجعل التسجيل ممكنًا من غير صفحة دفع، لكنها لا تقرر من تلقاء نفسها إمتى تسجل؛ ده قرار سياسة لازم الشخص اللي يدمج الوكيل يكتبه.

ثلاثة ضوابط بتنجز معظم المهمة عمليًا:

• تفويض دفع مش مجرد رقم بطاقة. مفتاح API مرتبط برصيد مدفوع مسبقًا أو حساب فوترة بيضع سقفًا لإجمالي التعرض بطبيعته؛ الوكيل ما يقدرش ينفق فوق الرصيد الممول. ومعاملة موقعة بمحفظة بتكون مُفوَّضة لكل عملية شراء ولا يمكن إعادة استخدامها. كل من الاثنين شكل مخاطرة مختلف بوضوح عن بطاقة ائتمان محفوظة، ما عندهاش سقف مدمج.
• حدود للإنفاق وعتبات للتأكيد يحددها الإنسان قبل ما الوكيل يبدأ التنفيذ. إرشادات Cloudflare لمسار وكيل «مصمم جيدًا» هي تأكيد اسم الدومين وسعره مع المستخدم قبل استدعاء نقطة التسجيل، لا بعده؛ نمط تدعمه واجهة API لكنها لا تفرضه.
• مالك واضح للتعرض القانوني. الوكيل اللي يسجل اسمًا ما بيلغيش الواقع القانوني إن للدومين مسجَّلًا في السجل. عرض تحليلي عن دومينات يملكها وكلاء لخّص الخطر: "لو وكيل سجّل دومين واتضح إنه يتعارض مع علامة تجارية، ما فيش إنسان يرد على شكوى UDRP" إذا ما حدش بيراقب ما يُسجَّل ببيانات اعتماده. إزالة صفحة الدفع ما بتلغي عملية UDRP ولا موعد التجديد ولا سجل WHOIS؛ لازم حد يضع المراقبة دي عمدًا.

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

مين بيقدم ده دلوقتي، وفكرة الموزّع

نسخة Cloudflare التجريبية هي المثال الأكثر تغطية لهذا التحول، لكنها مش الوحيدة. Name.com بنى واجهة API قابلة للمقارنة على منهج MCP وOpenAPI نفسه بدءًا من منتصف 2025، وNamefi يشغل خادم MCP مع دفع بتوقيع محفظة يتجاوز إنشاء الحساب تمامًا. الفروق ميزة بميزة، من نموذج التسعير وتغطية TLDs إلى ما إذا كان الدفع يحتاج حسابًا قائمًا، موجودة في Cloudflare مقابل Name.com مقابل Namefi: مُسجِّلون مصممون للوكلاء؛ والمشهد الكامل، بما فيه النقطة اللي يتوقف عندها كبار مُسجِّلي المستهلكين قبل الفئة دي، موجود في منصات الدومينات المعتمدة على وكلاء الذكاء الاصطناعي: دليل 2026.

الأحدث من أي منصة منفردة هو اللي الوكلاء بيبدأوا يعملوه بالقدرة دي أول ما تبقى عندهم. مسح CircleID لصناعة الدومينات في منتصف 2026 صاغ الأمر كده: "وكلاء الذكاء الاصطناعي يتصرفون بصورة متزايدة كموزعين للدومينات، ويفحصون التوافر ويسجلون الأسماء ويضبطون DNS دون تدخل بشري." وده اختيار متعمد للكلمة: الموزّع دور معروف، وهو طرف يبيع أو يوفّر دومينات تحت اعتماد مُسجِّل بدل ما يحمل اعتماده هو. وصف الوكلاء بأنهم موزعون غير رسميين، مش فئة جديدة، معناه إن سير العمل معروف رغم إن المشغل مش شخص: بحث وتسعير وتسجيل وإعداد، بالنيابة عن شخص آخر وعلى نطاق كبير. بنتابع إلى أي مدى النمط ده تحقق فعلًا، وإيه اللي لسه مجرد إعلان، في حالة إدارة الدومينات بالوكلاء، 2026؛ وخادم MCP الخاص بـNamefi مثال ملموس على الأدوات اللي ممكن وكيل يعمل بأسلوب موزع يستدعيها.

الأسئلة الشائعة

إيه بالضبط اللي اتغير يوم 15 أبريل 2026؟

أطلقت Cloudflare واجهة Registrar API في نسخة تجريبية عامة تغطي البحث عن الدومينات، وفحص التوافر والتسعير، والتسجيل، وربطتها بخادم Cloudflare MCP الذي تستخدمه الوكلاء بالفعل في أدوات مثل Cursor وClaude Code. لم تكن أول واجهة API لمُسجِّل يمكن للوكيل استدعاؤها؛ أُطلقت واجهة Name.com في منتصف 2025، وكانت Namefi تعمل بالفعل. لكنها كانت الحالة الأكثر تغطية التي جعل فيها مُسجِّل كبير ومألوف عملية الشراء كلها قابلة للإتمام بواسطة وكيل بدل أن تقتصر على دفع من المتصفح.

هل يحتاج وكيل الذكاء الاصطناعي إلى إذني لكل دومين يسجله؟

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

هل من الآمن فعلًا أن أسمح لوكيل ذكاء اصطناعي بشراء دومينات من غير ما أراقب كل معاملة؟

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

لو وكيل ذكاء اصطناعي سجل دومين، مين المسؤول عنه قانونيًا؟

يبقى للدومين مسجَّل في السجلات، شخص أو منظمة وليس نموذج الذكاء الاصطناعي نفسه، وهو من يتعرض لنزاع علامة تجارية أو شكوى UDRP أو موعد تجديد. إزالة الإنسان من خطوة الشراء لا تزيله من سجل الملكية؛ هي فقط قد تعني إن ما فيش حد بيراقب المخاطر دي ما لم تبنِ المراقبة ضمن المسار.

هل وكلاء الذكاء الاصطناعي بيبقوا موزعي دومينات بالمعنى الرسمي والمعتمد؟

لأ، مش بمعنى اعتماد ICANN؛ الموزّع في العادة شركة تعمل تحت اتفاق اعتماد مُسجِّل. صياغة CircleID تستخدم «موزّع» بصورة وصفية، لنمط السلوك وليس للتسمية القانونية. هل السلوك ده سيتجمع في فئة معترف بها رسميًا يظل واحدًا من الأسئلة المفتوحة في حالة إدارة الدومينات بالوكلاء، 2026.

هل ده شغال مع أي TLD ولا بس مع الشائعة؟

ده يعتمد على المنصة؛ والأفضل تراجعها مباشرة بدل افتراض تغطية كاملة. نسخة Cloudflare التجريبية أُطلقت بما تسميه موادها نفسها مجموعة منتقاة من TLDs الشائعة، وليس كتالوجها كله. التغطية تميل للتوسع مع نضج النسخة التجريبية، لذلك تأكد من دعم TLD الحالي في الوثائق الحية للمنصة قبل ما تعتمد على امتداد معين.

سجّل الدومين التالي بوكيلك أنت، من غير صفحة دفع

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

ابحث عن دومين وسجّله عبر Namefi.

المصادر وقراءات إضافية

• مدونة Cloudflare — إعلان النسخة التجريبية من Registrar API (تاريخ الإطلاق، والعمليات المدعومة، والتسعير بالتكلفة، وتكامل MCP، وإرشادات الموافقة البشرية)
• webhosting.today — وكلاء الذكاء الاصطناعي أصبح بإمكانهم الآن تسجيل دومينات، دون إنسان (تأطير القطاع لنسخة Cloudflare التجريبية بوصفها تحولًا إلى «طبقة الوكلاء»، أبريل 2026)
• dev.to — كيفية تسجيل اسم دومين مع وكيل الذكاء الاصطناعي، من دون إنسان (شرح MCP من طرف ثالث لنموذج صفحة الدفع القديم مقابل التسجيل القابل لاستدعاء الوكيل)
• dev.to — كيف يمكن لوكلاء الذكاء الاصطناعي شراء أسماء دومين خاصة بهم، ولماذا يهم ذلك (عرض تحليلي عن دومينات يملكها وكلاء وفجوة التعرض القانوني)
• CircleID — كون الدومينات في 2026: الذكاء الاصطناعي والأمان ونضج السوق وجبهة نطاقات gTLD الجديدة (تحليل الوكلاء كموزعين، أبريل 2026)
• modelcontextprotocol.io — ما هو بروتوكول سياق النموذج (MCP)؟ (نظرة عامة على البروتوكول)
• llmstxt.org — اقتراح ملف /llms.txt (المواصفات والدافع)
• ويكيبيديا — بروتوكول التزويد القابل للتمديد (معيار مقترح، مارس 2004)
• Namefi — namefi.io/llms.txt (مرجع خادم MCP وواجهة REST API والدفع بالمحفظة لدى Namefi)