LLMs تعرف HTTP بالفعل. هذا هو الركيزة الكاملة.
كل إمكانية Hoody هي استدعاء HTTP. LLM مدرَّب على الإنترنت العام يعرف بالفعل كيفية استخدامها.
HTTP في كل مكان · أكثر من 100 نقطة نهاية لكل حاوية · معمارية نظيرة · عملاء تطلق عملاء
البروتوكول الذي تدرّبت عليه LLMs بالفعل.
كل GPT وClaude وGemini وLlama قرأ ملايين أمثلة HTTP أثناء التدريب المسبق. الاتصال بـ Hoody يستخدم مهارة موجودة بالفعل.
لا خطوة توليد SDK
عملاء Hoody لا يحتاجون SDK. LLM يقرأ مواصفة OpenAPI أو مجرد التوثيق، ثم يصدر استدعاءات HTTP.
محوّلات MCP تصبح اختيارية
عميل MCP (/platform/mcp) يوسّع مجموعة أدوات العميل بخوادم طرف ثالث. لكن الأدوات الأصيلة لا تحتاج MCP — هي مجرد HTTP.
OpenAPI هو العقد
كل خدمة Kit تكشف /openapi.json. العملاء يقرؤون المواصفة ويعرفون المخططات ويستدعون النقاط الصحيحة.
تصحيح مقروء للإنسان
العميل ارتكب خطأً؟ انظر إلى curl الذي ولّده. الأثر بنفس الصيغة التي يقرأها الإنسان.
كل حاوية تمنح العميل مئة أداة عند الوصول.
خدمات Kit تكشف أكثر من 100 نقطة نهاية HTTP موثّقة لكل حاوية. تنفيذ الطرفية، الملفات، قاعدة البيانات، المتصفح — كل ذلك من نفس HTTP.
تشغيل الأوامر وبث المخرجات والتقاط الجلسات وتصدير التاريخ
اقرأ واكتب وابحث وضغّط وانقل عبر أكثر من 60 backend سحابي
انشر سكربتات كـ HTTP APIs، نفّذ بمصادقة، خزّن النتائج مؤقتاً
استعلام وتعديل وفحص المخططات وكتابة آمنة للتزامن
تصفح، لقطة شاشة، تفاعل، استخراج، ملء النماذج
لقطة شاشة X11، قائمة النوافذ، رصد حالة GUI
الحاويات نظراء. الوكلاء يتحدثون مباشرة.
لا منسق مركزي. وكيل في الحاوية A يمكنه فتح رابط الحاوية B وقراءة ملفاتها وتنفيذ أوامر وكتابة في قاعدة بياناتها مباشرةً.
تسلسل الوكلاء
الوكيل A يُشغّل الوكيل B عبر HTTP. B يقوم بعمل متخصص ويُرجع. التسلسل يتشكّل من الاستدعاءات.
توازي التوزيع
الوكيل A يطلق 10 نسخاً من مهمة عبر 10 حاويات. كل منها وكيل مستقل يعمل بالتوازي.
سلسلة المراجعة
الوكيل A يصيغ كوداً. الوكيل B يراجع بفتح ملفات A. الوكيل C يشغّل الاختبارات بإرسال POST إلى Exec. سلسلة من النظراء.
وكلاء متخصصون
وكيل مخصص لعمل نظام الملفات. آخر لقاعدة البيانات. آخر للمتصفح. يتحدثون عبر HTTP.
العميل لا يقترح. بل يطلق.
إعدادات العملاء القديمة تتوقف عند 'أخبر الإنسان بما يجب تشغيله.' عملاء Hoody يشغّلون الأمر أنفسهم.
تفكير
العميل يقرأ ويفكر ويخطط — نفس حلقة LLM.
تصرف
العميل يرسل POST إلى terminal / exec / files / sqlite. الأمر يُنفَّذ في الإنتاج.
رصد
العميل يقرأ الاستجابة ورمز الخروج وتغيير نظام الملفات وstderr. تغذية راجعة من العالم الحقيقي.
تعافٍ
شيء انكسر؟ PATCH إلى لقطة (/methods/data-state) يتراجع. آمن لتقبّل المخاطر.
العملاء يُنشئون حاويات. الحاويات تشغّل عملاء.
لأن إنشاء الحاوية هو HTTP POST واحد، يمكن للعميل إنشاء حاويات جديدة عند الطلب، ونشر عملاء فيها وتنسيقها عبر HTTP.
العميل يقرر التوازي
المهمة اختبار 10 فروع بالفرضيات. العميل يتعرف على فرصة التوزيع.
POST /projects/ID/containers × 10
عشر حاويات جديدة، كل منها مع نموذج عميل خاص بها.
توزيع
كل عامل يحصل على فرع مختلف. العملاء يعملون بالتوازي ويُرجعون النتائج للأصل.
تفكيك
الفائز يستمر. الخاسرون يُحذفون بـ DELETE. التكلفة: شبه صفر لكل حاوية مؤقتة.
كل استدعاء HTTP هو بيانات تدريب مستقبلية.
عندما تكون جميع العمليات طلبات HTTP، تُلتقط جميعها كسجلات بروكسي افتراضياً. مجموعة بيانات تدريب تنمو مع استخدامك.
كل إجراء في سجلات البروكسي
سجلات البروكسي تلتقط الطريقة والمسار والجسم (اختياري) والاستجابة. كل عملية قابلة للتتبع.
منظّمة افتراضياً
طلبات ومستجيبات JSON بالشكل الصحيح بالفعل للضبط الدقيق الخاضع للإشراف أو RLHF.
بياناتك، تدريبك
السجلات تبقى على معدنك الخام. Hoody لا ترى شيئاً منها إلا إذا صدّرت.
بنية تحتية تبني نفسها
سكربتات MITM يمكنها توليد توثيق وتحسين نقاط النهاية أو التنبؤ بأكثر الطلبات شيوعاً تالياً.
أعطِ LLM curl وهو يعرف بالفعل كيف يستخدمه.
سلّم عميلك رابط حاوية Hoody ورمزاً. الآن يمكنه تنفيذ أوامر وكتابة ملفات والاستعلام عن SQLite والتصفح عبر HTTP.
راجع أيضاً — /platform/ai-gateway لجانب النموذج، /platform/mcp لتكامل الأدوات الخارجية.