गेटवे और टर्न इंजन

# gateway.env — the only required setting
AIHUMMER_DATABASE_URL=postgres://user:pass@localhost:5432/aihummer?sslmode=disable
# Admin Web UI after start at http://localhost:8781/ (the private Web UI listener)

inbound message
   └─▶ turn engine
         ├─ assemble layered system prompt
         ├─ call model ──▶ tool calls / sub-agents ──▶ tool results ─┐
         │       ▲                                                    │
         │       └────────────────────────────────────────────────-─┘
         └─ final answer ─▶ reliable delivery ─▶ originating channel

AiHummer का दिल है **एक एकल गेटवे सेवा**. यह एक ही समय में है **कंट्रोल-प्लेन** (एडमिन API, सेटिंग्स, चैनल वायरिंग, मार्केटप्लेस) और **इंजन चालू करें** (उत्तर देने वाला फंक्शन-कॉलिंग लूप)। इसलिए, एक सामान्य डिप्लॉयमेंट केवल वह एक सेवा और PostgreSQL ही होता है — कोई अलग वर्कर स्तर नहीं है जिसे आपको चलाने की आवश्यकता हो। ## एक सेवा, दो भूमिकाएँ गेटवे पर सुनता है **सार्वजनिक** बंदरगाह `:8780` डिफ़ॉल्ट रूप से, नियंत्रित किया गया `AIHUMMER_GATEWAY_ADDR` — यह पोर्ट सभी बाहरी ट्रैफिक (API, जोड़ी बनाना, WS/SSE, इनबाउंड वेबहुक, ऐप/पॉकेट प्रॉक्सी और हेल्थ प्रोब्स) को संभालता है। एडमिन वेब यूआई पर चलता है **अलग, निजी** सुनने वाला (डिफ़ॉल्ट `:8781`, `AIHUMMER_WEBUI_ADDR`), रूट पाथ पर परोसा गया `/` और आदर्श रूप से इसे केवल आंतरिक इंटरफ़ेस से बाँधा जाना चाहिए। किसी भी स्थिति में प्रक्रिया हमेशा वही एकल सेवा है। ```ini # gateway.env — the only required setting AIHUMMER_DATABASE_URL=postgres://user:pass@localhost:5432/aihummer?sslmode=disable # Admin Web UI after start at http://localhost:8781/ (the private Web UI listener) ``` द **केवल कड़ी निर्भरता PostgreSQL है**. पोस्टग्रेस एजेंट्स, सेटिंग्स, संवाद, मेमोरी, डिलीवरी स्थिति और ऑडिट के लिए सच्चाई का एकमात्र स्रोत है। बाकी सब — वैकल्पिक सेवाएँ, एक वेक्टर स्टोर और मॉडल प्रदाता — केवल तब जोड़े जाते हैं जब आप इसे कॉन्फ़िगर करते हैं। > [!NOTE] > बिना डेटाबेस के गेटवे शुरू होता है **स्वास्थ्य-केवल मोड**: यह जवाब देता है > `GET /healthz` तो एक ऑर्केस्ट्रेटर या लोड बैलेंसर यह देख सकता है कि प्रक्रिया है > जिंदा, लेकिन यह काम नहीं आएगा। `GET /readyz` PostgreSQL और की जांच करता है > लौटाता है `503` जब डेटाबेस पहुंच से बाहर हो। ## स्टार्टअप पर क्या होता है स्टार्टअप पर गेटवे कुछ चरणों को सख्त क्रम में अंजाम देता है: 1. डेटाबेस कनेक्शन पूल खोलता है, 2. पोस्टग्रेस सलाहकारी लॉक के अंतर्गत किसी भी लंबित माइग्रेशन को लागू करता है, 3. कॉन्फ़िगरेशन हल करता है (डेटाबेस मान → वातावरण चर → अंतर्निर्मित) डिफ़ॉल्ट), और 4. सर्विसेस को जोड़ता है — राउटर, ऑर्केस्ट्रेटर, चैनल, टूल्स, मेमोरी, डिलीवरी — एक चल रहे गेटवे में। महत्वपूर्ण परिणाम यह है कि **अधिकांश सुविधाएँ सेटिंग्स कुंजी के माध्यम से स्वेच्छा से शामिल की जाती हैं**. एक क्षमता जो कॉन्फ़िगर नहीं की गई है वह बस सक्रिय नहीं होती, जो डिफ़ॉल्ट रनटाइम को छोटा और अनुमानित बनाए रखती है। आप चीज़ों को वेब एडमिन UI से या इसके साथ चालू करते हैं `AIHUMMER_*` वैरिएबल, और गेटवे उन्हें अगले स्टार्ट पर (या उन नॉब्स के लिए हॉट पर, जो इसका समर्थन करते हैं) हल करता है। ## टर्न इंजन जब एक संदेश गेटवे तक पहुँचता है, तो टर्न इंजन संभाल लेता है। यह चलाता है **फ़ंक्शन-कॉलिंग लूप**: मॉडल को सिस्टम प्रॉम्प्ट और बातचीत दी जाती है, यह टूल्स का उपयोग कर सकता है (या सब-एजेंट्स उत्पन्न कर सकता है), प्रत्येक टूल का परिणाम वापस फीड किया जाता है, और यह चक्र तब तक जारी रहता है जब तक मॉडल अंतिम उत्तर उत्पन्न नहीं कर देता। उस उत्तर को फिर डिलीवरी लेयर को सौंप दिया जाता है। ```text inbound message └─▶ turn engine ├─ assemble layered system prompt ├─ call model ──▶ tool calls / sub-agents ──▶ tool results ─┐ │ ▲ │ │ └────────────────────────────────────────────────-─┘ └─ final answer ─▶ reliable delivery ─▶ originating channel ``` क्योंकि लूप इस बात के बारे में निर्धारक है कि प्रत्येक इनपुट कहां से आता है, उत्तर बातचीत के इतिहास और टूल के परिणामों से हल होते हैं — कभी भी अनविश्वसनीय टेक्स्ट को निर्देशों में सम्मिलित करके नहीं। यह गुण ही नीचे दिए गए प्रॉम्प्ट लेयरिंग को सुरक्षित और तेज बनाता है। ## परतदार, कैश-अनुकूल सिस्टम प्रॉम्प्ट सिस्टम प्रॉम्प्ट एक ही टुकड़ा नहीं है। इसे परतों में संयोजित किया गया है, जानबूझकर इस तरह से क्रमबद्ध किया गया है ताकि **स्थिर भाग पहले आते हैं और अस्थिर भाग आख़िर में आते हैं**यह महत्वपूर्ण है क्योंकि मॉडल प्रदाता एक प्रॉम्प्ट को इसके प्रिफिक्स द्वारा कैश करते हैं: जब तक प्रॉम्प्ट की शुरुआत बाइट-फॉर-बाइट समान होती है, कैश किया गया प्रिफिक्स पुनः उपयोग किया जाता है और केवल अंत को पुनः संसाधित किया जाता है। | क्षेत्र | परतें (क्रम में) | परिवर्तन… | |---|---|---| | **स्थिर उपसर्ग** (कैशेबल) | बेस पहचान + उपकरण/स्मृति गाइड → किरायेदार → व्यक्तित्व → कौशल | कभी-कभार — प्रति एजेंट/किरायेदार | | **अस्थिर पूँछ** (अंत में संलग्न) | ऑनबोर्डिंग स्थिति → मेमोरी हाइड्रेशन → लाइव तिथि | हर मोड़ | स्थिर उपसर्ग वह सब कुछ ले जाता है जो यह निर्धारित करता है कि *एजेंट कौन है*: अंतर्निर्मित पहचान और यह मार्गदर्शन कि उपकरण और स्मृति कैसे काम करते हैं, फिर किरायेदार परत, एजेंट का व्यक्तित्व, और प्रदर्शित कौशल ख block. उसी एजेंट के दो लगातार चरणों के बीच इनमें से कोई भी बदलता नहीं है, इसलिए यह एक पुन: प्रयोज्य कैश किए गए उपसर्ग का रूप लेता है। अस्थिर पूंछ संलग्न की गई है **के बाद** स्थिर प्रीफिक्स ठीक वैसे ही ताकि यह कभी कैश को अमान्य न करे: ऑनबोर्डिंग स्थिति, इस विशेष बातचीत के लिए संस्मरण हाइड्रेटेड, और वर्तमान तारीख हर मोड़ पर बदलती रहती है, लेकिन क्योंकि वे अंत में रहते हैं, इसलिए वे केवल वही खर्च करते हैं जो वे जोड़ते हैं। > [!TIP] > इस क्रम का कारण है कि आज की तारीख जैसे लाइव डेटा मौजूद हो सकते हैं > हर बार पूरी पहचान को फिर से एन्कोड किए बिना हर मोड़ पर भुगतान किए बिना रखें > स्थिर परतों (व्यक्तित्व, कौशल) में एजेंट-विशेष कस्टम सामग्री और इसे अनुमति दें > इंजन अस्थिर पूंछ का मालिक है। ## अगला कहाँ - देखिए कि किरायेदारों को कैसे अलग किया जाता है [मल्टीटेनेंसी और आइडेम्पोटेंसी](/hi/v1.0/architecture/multitenancy-idempotency). - जानें कि उत्तर कैसे लौटाए जाते हैं [भरोसेमंद डिलीवरी और रिकवरी](/hi/v1.0/architecture/delivery-outbox). - वैकल्पिक क्षमताएँ के रूप में चलती हैं [साइडकार](/hi/v1.0/architecture/sidecars).