Gateway- och turbinmotor

# 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

Hjärtat av AiHummer är **en enda gateway-tjänst**. Det är samtidigt det **kontrollplan** (admin-API, inställningar, kanalanslutning, marknadsplats) och **vrid motor** (funktionsanropsloopen som producerar ett svar). En typisk distribution är därför bara den ena tjänsten plus PostgreSQL — det finns inget separat arbetarlager som du måste köra. ## En tjänst, två roller Gatewayen lyssnar på **offentlig** hamn `:8780` som standard, kontrollerad av `AIHUMMER_GATEWAY_ADDR` — denna port hanterar all extern trafik (API, parning, WS/SSE, inkommande webhooks, app/pocket-proxy och hälsokontroller). Administratörens webgränssnitt körs på en **separat, privat** lyssnare (standard `:8781`, `AIHUMMER_WEBUI_ADDR`), serverad på rotvägen `/` och helst bunden till ett internt-gränssnitt. I vilket fall som helst är processen alltid samma enkla tjänst. ```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) ``` Den **endast hård beroende är PostgreSQL**. Postgres är den enda sanningskällan för agenter, inställningar, konversationer, minne, leveransstatus och revision. Allt annat — valfria tjänster, en vektorlager och modellleverantörer — kopplas in endast när du konfigurerar det. > [!NOTE] > Utan en databas startar gatewayen i **endast hälsoläge**: det svarar > `GET /healthz` så att en orkestrator eller lastbalanserare kan se att processen är > levande, men det kommer inte att vara till någon nytta. `GET /readyz` kontrollerar PostgreSQL och > returnerar `503` medan databasen är otillgänglig. ## Vad som händer vid start Vid uppstart utför gatewayen några steg i en strikt ordning: 1. öppnar databasanslutningspoolen, 2. tillämpar eventuella väntande migrationer under ett Postgres-rådgivningslås, 3. löser konfiguration (databasvärde → miljövariabel → inbyggd standard), och 4. kopplar tjänsterna — router, orkestrator, kanaler, verktyg, minne, leverans — in i en pågående gateway. Den viktiga konsekvensen är att **de flesta funktioner är valbara via en inställningsnyckel**. En funktion som inte är konfigurerad är helt enkelt inte aktiverad, vilket håller standardkörningen liten och förutsägbar. Du aktiverar saker från webbadministrationsgränssnittet eller med ett `AIHUMMER_*` variabel, och gatewayen löser dem vid nästa start (eller på plats, för de rattar som stöder det). ## Vändmotorn När ett meddelande når gatewayen tar omkopplingsmotorn över. Den kör en **funktionsanrop-loop**: modellen får systemprompten och konversationen, den kan använda verktyg (eller skapa underagenter), varje verktygsresultat återförs, och loopen fortsätter tills modellen producerar ett slutgiltigt svar. Det svaret ges sedan till leveranslagret. ```text inbound message └─▶ turn engine ├─ assemble layered system prompt ├─ call model ──▶ tool calls / sub-agents ──▶ tool results ─┐ │ ▲ │ │ └────────────────────────────────────────────────-─┘ └─ final answer ─▶ reliable delivery ─▶ originating channel ``` Eftersom loopen är deterministisk när det gäller *var* varje indata kommer ifrån, löses svaren från konversationshistoriken och från verktygsresultat — aldrig genom att injicera otillförlitlig text i instruktionerna. Den egenskapen är vad som gör promptlagringen nedan både säker och snabb. ## Den lager-på-lager, cache-vänliga systemprompten Systemets uppmaning är inte en enda klump. Den är sammansatt i lager, medvetet ordnade så att **stabila delar kommer först och de flyktiga delarna kommer sist**. Detta är viktigt eftersom modellleverantörer cachelagrar en prompt efter dess prefix: så länge början av prompten är identisk byte-för-byte, återanvänds det cachelagrade prefixet och endast slutet bearbetas på nytt. | Zon | Lager (i ordning) | Förändringar… | |---|---|---| | **Stabil prefix** (cachebar) | basidentitet + verktyg/minnesguide → hyresgäst → persona → färdigheter | sällan — per agent/hyresgäst | | **Flyktig svans** (bifogad sist) | ombordstigningsstatus → minneshydrering → live-datumet | varje sväng | Det stabila prefixet innehåller allt som definierar *vem agenten är*: den inbyggda identiteten och guiden till hur verktyg och minne fungerar, sedan hyreslagsnivån, agentens persona och den renderade färdighetsblocket. Inget av detta förändras mellan två på varandra följande turer av samma agent, så det bildar ett återanvändbart cachat prefix. Den flyktiga svansen är bifogad **efter** det stabila prefixet precis så att det aldrig ogiltigförklarar cachen: onboarding-status, minnet som hydratiserats för denna specifika konversation, och det aktuella datumet ändras vartefter, men eftersom de ligger i slutet kostar de bara det de tillför. > [!TIP] > Denna ordning är orsaken till att live-data såsom dagens datum kan finnas i > varje vändning utan att betala för att koda om hela identiteten varje gång. Behåll > anpassat innehåll per agent i de stabila lagren (personlighet, färdigheter) och låt > motor äger den flyktiga svansen. ## Vart härnäst - Se hur hyresgäster isoleras i [Fleranvändarsystem och idempotens](/sv/v1.0/architecture/multitenancy-idempotency). - Lär dig hur svar returneras i [Pålitlig leverans och återhämtning](/sv/v1.0/architecture/delivery-outbox). - Valfria funktioner körs som [Sidvagnar](/sv/v1.0/architecture/sidecars).