ما هو مُسجِّل النطاقات المصمَّم للوكلاء؟

لدى مُسجِّلي النطاقات واجهات برمجة تطبيقات منذ وقت طويل. وصل بروتوكول التزويد القابل للتمديد (EPP)، وهو اللغة الآلية التي يستخدمها المُسجِّلون للتواصل مع السجلات، إلى حالة المعيار المقترح في مارس 2004 — قبل أكثر من عقدين. ومنذ ذلك الوقت، صار لدى كل مُسجِّل معتمد من ICANN تقريبًا مبني على EPP نوعٌ من واجهات REST أو SOAP للتحقق من التوافر، وإرسال طلب تسجيل، وتحديث السجلات. لذلك فالإجابة الصادقة عن سؤال «هل لدى هذا المُسجِّل API؟» هي، بالنسبة إلى معظم المُسجِّلين في السوق: نعم، ومن سنوات.

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

المقال ده يعرّف المصطلح بدقة، ويعرض قائمة فحص لتقييم أي مُسجِّل (أو أي API) على أساسها، وبعدها يطبق القائمة بأمانة على المنصات التي تطلق خدماتها في 2026، ومنها Namefi. لو عايز مقارنة منصة بمنصة بدل التعريف، شوف Cloudflare مقابل Name.com مقابل Namefi: مُسجِّلو نطاقات مصمَّمون للوكلاء أو دليل منصات النطاقات المدعومة بالوكلاء والذكاء الاصطناعي الأوسع. ولو لسه بتفكر في «الذكاء الاصطناعي والنطاقات» كأنه مجرد مولّد أسماء يقترح سلاسل مناسبة للعلامة التجارية، فقائمة الفحص أدناه هتبيّن لك قد إيه معيار التصميم للوكلاء أبعد من كده — وشوف ما بعد مولِّد أسماء النطاقات بالذكاء الاصطناعي: عصر الوكلاء للفجوة كاملة.

لماذا «لديه API» و«مصمَّم للوكلاء» ادعاءان مختلفان؟

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

الوكيل يصل من دون معرفة مسبقة باستمرار. كل محادثة مع وكيل برمجي، وكل عميل MCP جديد، هي فعليًا مطوّر لم يرَ API الخاصة بك من قبل ويملك ثواني من ميزانية السياق ليفهمها. لو كانت إجابة سؤال «إزاي الوكيل يتعلّم استخدام الـ API دي؟» هي «إنسان قرأ التوثيق وكتب كود الربط من سنين»، يبقى هناك شخص عالق بشكل دائم في مسار التنفيذ، حتى لو لم ينقر أي إنسان على شيء وقت الشراء. المقال ده عن الشروط التي يجب أن يحققها المُسجِّل نفسه لنجاح وكيل يبدأ من الصفر — ولرؤية نفس التسليم من منظور المشتري، راجع كيف يشتري وكلاء الذكاء الاصطناعي النطاقات من دون إنسان (2026).

قائمة فحص المُسجِّل المصمَّم للوكلاء

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

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

قابلية الاكتشاف: llms.txt وMCP هما خريطة الموقع للوكلاء

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

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

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

تنشر Namefi الاثنين. توثق نقطة الدخول على namefi.io/llms.txt خادم MCP على api.namefi.io/mcp، وملف اكتشاف MCP على namefi.io/.well-known/mcp/servers.json، ومرجع REST كاملًا، إلى جانب ملفات مصاحبة للدفع بالمحفظة وسير عمل الوكلاء الصادرين. وبالتحقق المباشر من اثنين من الشركات القائمة: توثق مستندات مُسجِّل Cloudflare ملف llms.txt خاصًا بها على developers.cloudflare.com/registrar/llms.txt، لكن لا شيء في توثيقها العام يذكر أن Cloudflare تدير خادم MCP مخصصًا لمنتج المُسجِّل — ففكرة الإصدار التجريبي، بحسب التغطية، هي أن الـ API «مصممة للعمل داخل الأدوات التي يعمل فيها المطورون بالفعل: محررات الكود التي تدعم MCP مثل Cursor وClaude Code»، وده أضيق نطاقًا — المحرر قادر على MCP، وليس بالضرورة مُسجِّل Cloudflare نفسه. بوابة مطوّري GoDaddy، عند التحقق المباشر، توثق نقاط نهاية REST لمطوّر بشري ولا تعرض مرجعًا إلى llms.txt أو خادم MCP حتى وقت كتابة هذا النص.

الدفع: لماذا تفشل البطاقة المحفوظة مع الوكلاء، وما الذي يحل محلها؟

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

هناك بديلان يتم إطلاقهما. الأول هو الفوترة بمفتاح API: يصدر المُسجِّل بيانات اعتماد مرتبطة بحساب ممول مسبقًا أو مفوتر، ويصادق الوكيل على كل طلب بهذا المفتاح بدلًا من البطاقة. توثق مستندات Namefi إنشاء هذا المفتاح في namefi.io/api-key وتمريره كترويسة x-api-key في كل طلب — بلا جلسة متصفح ولا نموذج بطاقة. وتسعير نطاقات .ai لدى Cloudflare يتبع المنطق نفسه من حيث التكلفة: فهي تقدم «تسجيلات وتجديدات نطاقات .ai بأسعار الجملة، من دون أي زيادات إضافية» — فالسعر الثابت المتوقع أسهل على الوكيل في التعامل معه من سعر يتغير بالعروض الترويجية.

البديل الثاني هو الدفع الموقّع بالمحفظة، وهو يزيل الحساب نفسه لا البطاقة فقط. توثق Namefi في web3 تدفقًا مبنيًا على رمز حالة HTTP 402 ونمط x402: يعيد طلب نطاق من دون دفع السعر في استجابة 402، وتوقّع محفظة المستدعي تفويض EIP-3009، ثم يعاد تشغيل التفويض الموقّع كترويسة لإكمال التسجيل والتسوية في خطوة واحدة — وبشكل صريح «من دون حساب Namefi أو توقيع EIP-712 مطلوب». النقطة هنا أضيق — إنها طريقة دفع يمكن للبرمجيات الاحتفاظ بها واستخدامها بنفسها، وهو ما لا يمكن أن توفره بطاقة ائتمان محفوظة من حيث البنية. شوف الدفع مقابل النطاقات بمحفظة عملات مشفرة: من دون حاجة إلى حساب لشرح هذا التدفق خطوة بخطوة.

ضوابط السياسات: الصف الذي لم تحله الفئة كلها بعد

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

عند مراجعة توثيق Namefi نفسه، وهو المثال الأكثر قابلية للتحقق: تضع علامة على عمليات معينة باعتبارها مؤثرة، وتوثق أخطاء منظمة قابلة للقراءة آليًا (رموز ثابتة، وعلامة retryable، وتفاصيل منظمة) — وده تقدم حقيقي في هذا الصف. لكننا لم نجد آلية موثقة لسقف إنفاق أو بوابة تأكيد من جانب الخادم في مرجع الـ API العام حتى وقت كتابة هذا النص؛ يوجد هذا الحاجز حاليًا في طبقة أعلى، ضمن أي سياسة يضبطها الإنسان على عميل MCP نفسه. ولم نجد توثيقًا عامًا لآلية سقف إنفاق في APIs مُسجِّلي Cloudflare أو Name.com أيضًا — وهذا هو الصف الذي ينبغي توقع أن يغلقه كل مُسجِّل مصمَّم للوكلاء بعد ذلك.

تقييم منصات اليوم وفقًا لقائمة الفحص

هكذا تقيّم المنصات الثلاث التي يُكثر ذكرها في هذا المجال على قائمة الفحص ذات العناصر الستة، اعتمادًا على ما تحققنا منه مباشرة في التوثيق الحي لكل منصة، لا على النسخ التسويقية:

الصف الوحيد الفارغ في كل الحالات — ضوابط السياسات — فجوة حقيقية على مستوى القطاع، وليست انتقادًا لمنصة بعينها، ومن المهم إعادة التحقق منه مع تطور المجال.

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

ما هو مُسجِّل النطاقات المصمَّم للوكلاء؟

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

لماذا لا تستطيع وكلاء الذكاء الاصطناعي استخدام APIs المُسجِّلين العادية؟

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

ما الفرق بين llms.txt وMCP؟

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

كيف أجعل API الخاصة بي قابلة للاستخدام من وكيل؟

انشر llms.txt يصف API الخاصة بك للنماذج، واعرض خادم MCP (أو على الأقل نقاط نهاية موثقة بـ OpenAPI)، وأعد أخطاء منظمة برموز ثابتة بدلًا من النص، وتأكد أن كل عملية كتابة يمكن أن تكتمل من دون صفحة دفع مستضافة، وادعم طريقة دفع لا تفترض وجود بطاقة إنسان، وأضف حدود إنفاق أو تأكيد حتى يستطيع من يحمل بيانات الاعتماد وضع حد لما يُسمح للوكيل بفعله.

هل Namefi مصمَّمة للوكلاء؟

وفقًا لقائمة الفحص أعلاه، تسجل Namefi «نعم» في خمسة من الصفوف الستة التي تحققنا منها مباشرة: فهي تنشر عائلة llms.txt وخادم MCP، وتوثيقها منظم لاستهلاك الوكلاء، وAPI الصادرة منها تعيد أخطاء منظمة قابلة للقراءة آليًا، ويكتمل التسجيل بالكامل عبر الـ API أو تدفق المحفظة المبني على x402 من دون لوحة تحكم مطلوبة، كما يعمل الدفع بمفتاح API أو معاملة موقعة بمحفظة من دون الحاجة إلى حساب. ولم توثق ضوابط السياسات بعد في مرجع الـ API العام؛ إذ يوجد هذا التحكم حاليًا في جهة العميل.

هل وجود خادم MCP يجعل المُسجِّل مصمَّمًا للوكلاء تلقائيًا؟

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

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

• Wikipedia — بروتوكول التزويد القابل للتمديد (EPP موحَّد كمعيار مقترح في مارس 2004)
• CircleID — كون النطاقات في 2026: الذكاء الاصطناعي والأمان ونضج السوق وحدود gTLD الجديدة («يعمل وكلاء الذكاء الاصطناعي على نحو متزايد كبائعي نطاقات…»)
• webhosting.today — يمكن لوكلاء الذكاء الاصطناعي الآن تسجيل نطاقات، من دون حاجة إلى إنسان (إصدار Cloudflare Registrar API التجريبي، أبريل 2026)
• Name.com — أول منصة نطاقات مصممة للذكاء الاصطناعي («مدعومة بمعايير حديثة مثل بروتوكول سياق النموذج…»)
• llmstxt.org — اقتراح ملف /llms.txt
• modelcontextprotocol.io — ما هو بروتوكول سياق النموذج (MCP)؟
• Schema.org — FAQPage
• Cloudflare — شراء نطاقات .ai بالتكلفة
• Cloudflare Developers — فهرس توثيق المُسجِّل (llms.txt)
• Namefi — namefi.io/llms.txt (مرجع API وخادم MCP — المصدر المرجعي لادعاءات منتج Namefi في هذا المقال)
• Namefi — namefi.io/web3/llms.txt (تدفق الدفع الموقّع بالمحفظة / x402، «لا حاجة إلى حساب Namefi أو توقيع EIP-712»)