Gateway og svingemotor — AiHummer Dokumenter

Hjertet til AiHummer er en enkelt gateway-tjeneste. Det er samtidig kontrollplan (admin-API, innstillinger, kanaloppsett, markedsplass) og dreie motor (funksjons-kall-loopen som produserer et svar). En typisk distribusjon er derfor bare den ene tjenesten pluss PostgreSQL — det finnes ingen separat arbeidernivå du er pålagt å kjøre.

Én tjeneste, to roller

Gateways lytter på offentlig havn :8780 som standard, kontrollert av AIHUMMER_GATEWAY_ADDR — denne porten håndterer all ekstern trafikk (API, paring, WS/SSE, innkommende webhooks, app-/lommeproxy og helsesjekker). Administrasjonsnettgrensesnittet kjører på en separat, privat lytter (standard :8781, AIHUMMER_WEBUI_ADDR), servert på rotstien / og ideelt sett bundet til et internt-tilgjengelig grensesnitt. Uansett er prosessen alltid den samme enkeltjenesten.

# 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 den eneste harde avhengigheten er PostgreSQL. Postgres er den eneste sannhetskilden for agenter, innstillinger, samtaler, minne, leveringsstatus og revisjon. Alt annet — valgfrie tjenester, en vektorlager og modellleverandører — kobles kun inn når du konfigurerer det.

[!NOTE] Uten en database starter gatewayen i helse-modus: det svarer GET /healthz så en orkestrator eller lastbalanserer kan se at prosessen er i live, men det vil ikke tjene omslag. GET /readyz sjekker PostgreSQL og returnerer 503 mens databasen er utilgjengelig.

Hva skjer ved oppstart

Ved oppstart utfører gatewayen noen få trinn i en streng rekkefølge:

åpner databaseforbindelsespoolen,
utfører eventuelle ventende migrasjoner under en Postgres rådgivningslås,
løser konfigurasjon (databaseverdi → miljøvariabel → innebygd standard), og
kobler tjenestene — ruter, orkestrator, kanaler, verktøy, minne, levering — inn i en løpende gateway.

Den viktige konsekvensen er at de fleste funksjoner er valgbare via en innstillingsnøkkel. En funksjon som ikke er konfigurert, er ganske enkelt ikke aktivert, noe som holder standard kjøretid liten og forutsigbar. Du slår på funksjoner fra webadministrasjonsgrensesnittet eller med en AIHUMMER_* variabel, og gatewayen løser dem ved neste oppstart (eller umiddelbart, for knappene som støtter det).

Vri-motoren

Når en melding når gatewayen, tar turnmotoren over. Den kjører en funksjonskall-løkke: modellen får systemprompten og samtalen, den kan kalle på verktøy (eller opprette under-agenter), hvert verktøyresultat mates tilbake, og loopen fortsetter til modellen produserer et endelig svar. Det svaret blir deretter levert til leveringslaget.

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

Fordi løkken er deterministisk når det gjelder hvor hver inngang kommer fra, blir svarene løst ut fra samtalehistorikken og fra verktøyresultater — aldri ved å injisere upålitelig tekst i instruksjonene. Denne egenskapen er det som gjør prompt-lagdelingen nedenfor både sikker og rask.

Den lagdelte, cache-vennlige systemprompten

Systemets prompt er ikke en enhetlig blokk. Den er satt sammen i lag, med en bevisst rekkefølge slik at stabile deler kommer først og de flyktige delene kommer til slutt. Dette er viktig fordi modelltilbydere cacher en prompt etter dens prefiks: så lenge begynnelsen av prompten er byte-for-byte identisk, gjenbrukes den cachelagrede prefiksen og kun halen bearbeides på nytt.

Sone	Lag (i rekkefølge)	Endringer…
Stabil prefiks (bufringsbar)	baseidentitet + verktøy/minneveiledning → leietaker → persona → ferdigheter	sjelden — per agent/leietaker
Flyktig hale (vedlagt sist)	onboarding-tilstand → minnehydrering → lanseringsdato	hver sving

Den stabile prefiksen bærer alt som definerer hvem agenten er: den innebygde identiteten og veiledningen til hvordan verktøy og minne fungerer, deretter leietakerlaget, agentens persona, og den gjengitte ferdighetsblokken. Ingenting av dette endres mellom to påfølgende runder med samme agent, så det danner en gjenbrukbar bufret prefiks.

Den flyktige halen blir lagt til etter det stabile prefikset nøyaktig slik at det aldri ugyldiggjør cachen: ombordstigningsstatus, minnet hydrert for denne spesifikke samtalen, og den gjeldende datoen endres hver tur, men fordi de ligger til slutt, koster de bare det de legger til.

[!TIP] Denne rekkefølgen er grunnen til at live data som dagens dato kan være til stede i hver vending uten å betale for å re-kode hele identiteten hver gang. Fortsett brukertilpasset innhold per agent i de stabile lagene (personlighet, ferdigheter) og la motor eie den flyktige halen.

Hvor til neste

Se hvordan leietakere er isolert i Flerbrukerarkitektur og idempotens.
Lær hvordan svar blir returnert i Pålitelig levering og gjenoppretting.
Valgfrie funksjoner kjører som Sidevogner.