منصات الدومينات لوكلاء الذكاء الاصطناعي: دليل 2026

من سنة، كانت عبارة «الذكاء الاصطناعي والدومينات» معناها مولِّد أسماء: تكتب فكرة مشروع في مربع، فيطلع لك اقتراحات لـ .com و.ai، وبعدها تكمّل في صفحة دفع عادية لشخص بشري. الفئة دي ما زالت موجودة ومفيدة. لكنها لم تعد القصة كلها.

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

هذا الدليل هو الخريطة. يشرح أنماط الواجهات التي تجعل المنصة قابلة للاستخدام من وكيل أصلاً، ويمر على المنصات التي تدعم التسجيل بالوكيل اليوم تحديداً (وما يستطيع كل منها فعله وما لا يستطيع، بعد التحقق من وثائقها)، ويقارنها بما يقدمه كبار المُسجِّلين القدامى بدلاً من ذلك. ويختتم بجدول قرار وأسئلة شائعة. لو عايز الأرقام في المقارنة المباشرة، انتقل فوراً إلى Cloudflare مقابل Name.com مقابل Namefi.

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

لماذا انتقل تسجيل الدومين إلى طبقة الوكلاء؟

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

تغير أمران بسرعة متتالية. أولاً، في يوليو 2025، أعلنت Name.com ما وصفته بأول منصة دومينات مصممة للذكاء الاصطناعي: واجهة API مبنية حول بروتوكول سياق النموذج (MCP) ومخططات OpenAPI، ومصممة صراحةً لكي يقرأ وكيل برمجي المواصفة ويكتب كود تسجيل يعمل من طلب بلغة عادية مثل «أضف تسجيل دومين إلى تطبيقي» (Name.com). ثانياً، في 15 أبريل 2026، طرحت Cloudflare واجهة Registrar API في بيتا عامة مع الرسالة الصريحة: «تتيح Registrar API البحث عن الدومينات والتحقق من إتاحتها وتسجيلها برمجياً» (مدونة Cloudflare، عبر تغطية متخصصة) — والأهم أنها وصلتها مباشرة بخادم Cloudflare MCP الذي كان وكلاء Cursor وClaude Code يملكون الوصول إليه بالفعل.

الخطوة الثانية هي التي كُتب عنها على نطاق واسع، لأن Cloudflare مُسجِّل كبير ومألوف ولأن طرحها كان مباشراً: تسجيل الدومين، وهي مهمة قاومت الأتمتة لأنها احتاجت إنساناً يضغط «أوافق» ويدخل رقم بطاقة، صار بهدوء شيئاً يستطيع الوكيل تنفيذه كإجراء فرعي. ووضع استطلاع CircleID لقطاع الدومينات في منتصف 2026 الأمر بوضوح: «يعمل وكلاء الذكاء الاصطناعي بصورة متزايدة كبائعي دومينات يعيدون البيع، ويفحصون الإتاحة ويسجلون الأسماء ويضبطون DNS من دون تدخل بشري» (CircleID، أبريل 2026).

لم يحدث أي من هذا لأن السجلات غيّرت قواعدها. بل لأن مجموعة صغيرة من المنصات قررت أن تجعل مسار الشراء القائم لديها مقروءاً لمستدعي آلي، لا لمتصفح فقط؛ واتضح أن ذلك يتطلب أكثر من مجرد «انشر واجهة API».

ثلاثة أنماط للواجهات: API مباشرة وخادم MCP وllms.txt

ليست كل واجهة API صالحة لوكيل، والفجوة مهمة لدرجة أنها تستحق تعريفاً دقيقاً. راجع ما هو المُسجِّل المصمم للوكلاء؟ للاطلاع على قائمة الفحص كاملة؛ أما الخلاصة فهي أن ثلاثة أنماط متداخلة تظهر في المنصات التي يغطيها هذا الدليل.

• واجهة REST API مباشرة. أقدم نمط. أي مُسجِّل يملك API للمطورين يتيح تقنياً للبرامج تسجيل دومين. المشكلة هي الاكتشاف: على الوكيل أن يعرف سلفاً أن الـ API موجودة، وأن تكون الوثائق في سياقه، وأن يكون هناك عميل مكتوب لها مسبقاً. API وحدها لا تخبر وكيلاً عاماً بوجودها أو بطريقة استخدامها الصحيحة.
• خادم MCP. ‏MCP بروتوكول مفتوح ومحايد للنماذج — يصفه القائمون عليه بأنه «طريقة موحّدة لتوصيل تطبيقات الذكاء الاصطناعي بالأنظمة الخارجية»، أشبه بـ «منفذ USB-C لتطبيقات الذكاء الاصطناعي» (modelcontextprotocol.io) — لعرض مجموعة محددة من الأدوات القابلة للاستدعاء لأي عميل ذكاء اصطناعي متوافق: Claude وCursor وWindsurf وغيرهم. عندما يوفّر مُسجِّل خادم MCP، فهو يعطي الوكيل قائمة عمليات دقيقة (search_domain وregister_domain وset_dns_record) بدلاً من جدار من وثائق REST عليه أن يفكّ شفرته.
• واجهة API يمكن اكتشافها عبر llms.txt. ‏llms.txt صيغة نص عادي — ملف /llms.txt عند جذر الموقع — اقتُرحت في 2024 لتمنح النماذج اللغوية فهرساً موجزاً ومنتقًى لأهم وثائق الموقع وقدراته، بالطريقة نفسها التي يمنح بها robots.txt زواحف الويب قواعد الإذن. مُسجِّل ينشر ملفاً كهذا، مثلاً عند namefi.io/llms.txt، يمكّن وكيلاً لم ير المنصة من قبل من اكتشاف ما تفعله من دون أن يلصق إنسان وثائق الـ API في المحادثة أولاً.

هذه ليست معايير متنافسة؛ أقوى المنصات تضع الثلاثة فوق بعضها: llms.txt للاكتشاف، وخادم MCP لاستدعاء الأدوات الفعلية، وREST API تحت كليهما.

المنصات بالتفصيل

Cloudflare Registrar API (بيتا)

بيتا Cloudflare، المتاحة منذ 15 أبريل 2026، تغطي ثلاث عمليات: البحث، وفحص الإتاحة والتسعير، والتسجيل — ما تصفه Cloudflare نفسها بأنه «أول لحظة حرجة في دورة حياة الدومين»، مع وعد بإضافة النقل والتجديد وتحديثات بيانات الاتصال لاحقاً في السنة (مدونة Cloudflare). يتبع التسعير نموذج Cloudflare المعروف للمُسجِّل: «نفرض بالضبط ما تفرضه السجلات»، من دون هامش ربح، سواء جاء الاستدعاء من لوحة التحكم أو الـ API أو وكيل (مدونة Cloudflare).

الجزء الموجّه للوكيل هو التكامل، لا منتج منفصل: «Registrar API جزء من Cloudflare API الكاملة، ما يعني أن الوكلاء يملكون الوصول إليها اليوم عبر Cloudflare MCP»، و«يمكن لوكيل يعمل في Cursor أو Claude Code أو أي بيئة متوافقة مع MCP أن يكتشف نقاط Registrar ويستدعيها» (مدونة Cloudflare). وصف Cloudflare نفسه للتدفق المقصود يحتفظ بنقطة تحقق: يمكن للوكيل أن «يقترح أسماء، ويؤكد أيها قابل للتسجيل فعلاً، ويعرض السعر للموافقة، ثم يتم الشراء» (مدونة Cloudflare)، لكن ذلك، وفقاً للموثق، اقتراح تصميم لا آلية حد للإنفاق مفروضة داخل الـ API نفسها.

هناك تنبيهان يستحقان المعرفة قبل أن تبني خطتك عليها: البيتا لا تغطي بعد كتالوج Cloudflare الكامل من نطاقات المستوى الأعلى، بل ما تسميه Cloudflare «مجموعة منتقاة من نطاقات TLD الشائعة في البداية» (مدونة Cloudflare)، كما أن الفوترة مرتبطة بحساب Cloudflare موجود، أي علاقة بفواتير عملة تقليدية بدأها إنسان، حتى لو كان الوكيل هو من يستدعي الـ API.

واجهة Name.com المصممة للذكاء الاصطناعي

منصة Name.com، التي أُعلن عنها في يوليو 2025، مبنية حول فكرة التحويل نفسها من اللغة العادية إلى الكود: يصف المطور أو الوكيل ما يريده («أضف تسجيل دومين إلى تطبيقي») وتكون وثائق المنصة منظمة بحيث يستطيع عميل ذكاء اصطناعي تحويل ذلك إلى كود تكامل يعمل، مستخدماً MCP وOpenAPI كبنية تحتية، مع وصول ذاتي الخدمة للمطورين ودعم لأدوات مثل Claude وCursor (Name.com). التسعير شفاف ويعتمد على الحجم، مع هيكل هامش إعادة البيع المعتاد في واجهات API الخاصة بالمُسجِّلين.

ما لا توثقه Name.com في إعلانها هو مسار دفع بالعملات المشفرة أو بالمحفظة، أو خطوة تأكيد صريحة من إنسان مدمجة في الـ API نفسها — كلاهما معقول في نموذج حساب مطور عادي، لكن المصدر لا يذكرهما، لذا اعتبر «فواتير بالعملة التقليدية وعلى أساس الحساب» افتراض العمل، لا تفصيلاً مؤكداً تماماً.

Namefi: خادم MCP مع دفع بالمحفظة

فهرس Namefi القابل للقراءة آلياً — namefi.io/llms.txt — مثال بحد ذاته على نمط الواجهة الثالث أعلاه، وهو المصدر الوحيد المعتمد لما يأتي. تشغّل Namefi خادم MCP على api.namefi.io/mcp عبر Streamable HTTP، ويعرض أدوات مُحددة النوع للتسجيل وفحوص الإتاحة وإدارة DNS؛ ويمكن إضافته إلى Claude Code بأمر واحد (claude mcp add --transport http namefi https://api.namefi.io/mcp). وتحته REST API (api.namefi.io/v-next/) ومصادَق عليها بهيدر x-api-key — ويجب إنشاء المفتاح من المحفظة التي تملك الدومين، ما يربط الوصول إلى الـ API مباشرة بالحيازة على السلسلة بدلاً من مسار منفصل لاستعادة الحساب.

الفارق هو الدفع. توثق Namefi مسارين: مسار مفتاح API القياسي، المفوتر مقابل رصيد مُسبق الدفع من NFSC (Namefi Service Credits)، ومسار أصلي للعملات المشفرة يستخدم توقيعات المحفظة — بما فيها SIWE ‏(Sign-In With Ethereum) — لما تصفه وثائقها بمستخدمي Web3 و«محافظ الوكلاء»، فيتيح تفويض الشراء من دون إنشاء حساب مُسجِّل على الإطلاق. بعد التسجيل، تدعم Namefi كامل عمليات CRUD لسجلات DNS ‏(A وAAAA وCNAME وMX وTXT وغيرها)، والتجديد التلقائي، وركن الدومين وإعادة توجيهه، وإنشاء سجلات ENS تلقائياً، و— الميزة التي تميزها بنيوياً عن المنصتين الأخريين هنا — ترميز الدومين: تمثيل دومين حقيقي مسجل لدى ICANN كأصل على السلسلة تحتفظ به محفظة. الشرح خطوة بخطوة — لـ Claude وCodex وCursor وثلاثة وكلاء آخرين — موجود في كيفية تسجيل دومين باستخدام وكيل الذكاء الاصطناعي على Namefi، مع شرح أعمق خاص بـ Claude في اشترِ دومين باستخدام Claude: دليل Namefi MCP خطوة بخطوة. ولرؤية شكل طلب اللغة العادية فعلاً، راجع كيف تشتري دوميناً بلغة طبيعية (2026).

هناك فجوة يجدر التنبيه إليها بوضوح: لا ينشر llms.txt الخاص بـ Namefi قائمة ثابتة بنطاقات TLD المدعومة. إذا كانت تغطية نطاقات TLD هي العامل الحاسم في حالة استخدامك، فتحقق منها مباشرة في الوثائق الحالية قبل أن تلتزم.

ما الذي يقدمه الكبار مثل GoDaddy وNamecheap بدلاً من ذلك؟

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

جدول القرار الرئيسي

للحصول على النسخة الكاملة من هذا الجدول، ميزة بميزة — البحث عن الإتاحة، وإدارة DNS، وأتمتة التجديد، والملكية المرمزة وغيرها — راجع Cloudflare مقابل Name.com مقابل Namefi: مُسجِّلات مصممة للوكلاء.

كيف تختار؟

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

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

هل يستطيع ChatGPT أو Claude شراء دومين لي الآن؟

ذلك يعتمد كلياً على الأدوات التي يملك هذا العميل الحواري المحدد الوصول إليها، لا على النموذج نفسه. نموذج مثل Claude لا يملك قدرة مدمجة لتسجيل دومين؛ يجب توصيله بخادم MCP أو API لمنصة ما (مثل خادم Namefi MCP، أو Registrar API الخاصة بـ Cloudflare عبر Cloudflare MCP) قبل أن يستطيع البحث والتسعير وإتمام الشراء. من دون هذا الاتصال، لا يستطيع مساعد الذكاء الاصطناعي إلا اقتراح أسماء لكي تسجلها بنفسك.

هل من الآمن أن أسمح لوكيل ذكاء اصطناعي بتسجيل دومينات وصرف المال من دون الرجوع إليّ أولاً؟

تعامل معها كما تتعامل مع أي صلاحية شراء مؤتمتة: ضع حدودها قبل أن تمنحها. أكثر الأنماط أماناً التي توثقها هذه المنصات هي رصيد مسبق الدفع يحدد إجمالي التعرض (مسار مفتاح API في Namefi)، أو توقيع لكل معاملة لا يمكن إعادة استخدامه (الدفع بتوقيع المحفظة)، أو خطوة تأكيد يدوي قبل استدعاء الشراء الأخير. لا تفرض أي من المنصات في هذا الدليل حد إنفاق عام بالنيابة عنك — أنت من يضع الحاجز، عادة عبر حدود تمويل الحساب أو خطوة تأكيد صريحة في سير عمل وكيلك.

ما الفرق الفعلي بين API وخادم MCP وllms.txt؟

REST API هي مجموعة العمليات القابلة للاستدعاء في الأساس. خادم MCP يغلّف مجموعة محددة من تلك العمليات كأدوات منفصلة يستطيع أي عميل ذكاء اصطناعي متوافق مع MCP استدعاءها مباشرة، من دون كود تكامل مخصص. وملف llms.txt طبقة اكتشاف: فهرس قصير ومنتقًى عند جذر الموقع يخبر الوكيل بالوثائق والقدرات الموجودة من الأساس، بالطريقة التي يخبر بها robots.txt الزاحف بما يجوز له فهرسته. يمكن أن تملك المنصة أيّاً من الثلاثة وحده، لكن أقوى المنصات المصممة للوكلاء تجمعها: llms.txt ليعثر عليها الوكيل، وMCP ليستدعيها، وREST تحتهما.

هل أحتاج إلى محفظة عملات مشفرة لاستخدام أي من هذه المنصات؟

لا. تستخدم Cloudflare وName.com فواتير عادية بعملة تقليدية وعلى أساس الحساب، وتدعم Namefi النوع نفسه من الفوترة بمفتاح API مقابل رصيد مسبق الدفع. المحفظة مطلوبة فقط إذا أردت تحديداً مسار الدفع في Namefi بتوقيع المحفظة ومن دون حساب، أو ميزة الملكية المرمزة.

أي هذه المنصات هو «الأكثر اكتمالاً» اليوم؟

لا ينبغي التعامل مع أي منها كمواصفة مكتملة وثابتة — Cloudflare مصنفة صراحةً كبيتا بقائمة نطاقات TLD أضيق من كتالوجها الكامل، وخصائص البيتا، بحكم تعريفها، قابلة للتغير. تحقق من الإمكانات الحالية في الوثائق الحية لكل منصة قبل أن تبني اعتماداً على ميزة محددة.

اشترِ دومينك التالي ورمّزه على Namefi

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

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

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

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