Gateway og drejemotor — AiHummer Dokumenter

Kernen i AiHummer er en enkelt gateway-tjeneste. Det er samtidig det kontrolplan (admin API, indstillinger, kanalopsætning, markedsplads) og drej motor (funktionsopkaldsløkken, der producerer et svar). En typisk implementering er derfor netop den ene tjeneste plus PostgreSQL — der er intet separat worker-lag, som du er forpligtet til at køre.

Én service, to roller

Gatewayen lytter på offentlig havne :8780 som standard, kontrolleret af AIHUMMER_GATEWAY_ADDR — denne port håndterer al ekstern trafik (API, parring, WS/SSE, indkommende webhooks, app/pocket-proxy og sundhedstjek). Admin Web UI kører på en separate, privat lytter (standard :8781, AIHUMMER_WEBUI_ADDR), serveret ved roden af stien / og ideelt set bundet til en intern-only grænseflade. Under alle omstændigheder er processen altid den samme enkelte service.

# 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 hårde afhængighed er PostgreSQL. Postgres er den eneste sandhedskilde for agenter, indstillinger, samtaler, hukommelse, leveringsstatus og audit. Alt andet — valgfrie tjenester, en vektorlager og modeludbydere — tilsluttes kun, når du konfigurerer det.

[!NOTE] Uden en database starter gatewayen i kun sundhedstilstand: det svarer GET /healthz så en orkestrator eller load balancer kan se, at processen er i live, men det vil ikke tjene nogen formål. GET /readyz tjekker PostgreSQL og returnerer 503 mens databasen er utilgængelig.

Hvad sker der ved opstart

Ved opstart udfører gatewayen nogle få trin i en streng rækkefølge:

åbner databaseforbindelsespuljen,
anvender eventuelle ventende migrationer under en Postgres-rådgivningslås,
løser konfiguration (databaseværdi → miljøvariabel → indbygget) standard), og
forbinder tjenesterne — router, orkestrator, kanaler, værktøjer, hukommelse, levering — ind i en kørende gateway.

Den vigtige konsekvens er, at de fleste funktioner er valgfri via en indstillingsnøgle. En funktion, der ikke er konfigureret, er simpelthen ikke aktiveret, hvilket holder standardkørslen lille og forudsigelig. Du tænder tingene fra webadministrations-UI’en eller med en AIHUMMER_* variabel, og gatewayen løser dem ved næste start (eller hot, for de knapper, der understøtter det).

Vendedrev

Når en besked når gatewayen, tager dreje-motoren over. Den kører en funktionskaldsløkke: modellen får systemprompten og samtalen, den kan bruge værktøjer (eller oprette under-agenter), hvert værktøjsresultat bliver givet tilbage, og løkken fortsætter, indtil modellen producerer et endeligt svar. Dette svar gives derefter 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 med hensyn til hvor hver input kommer fra, bliver svarene løst ud fra samtalehistorikken og værktøjsresultater — aldrig ved at indsætte ubetroet tekst i instruktionerne. Denne egenskab er det, der gør promptlagdelingen nedenfor både sikker og hurtig.

Den lagdelte, cache-venlige systemprompt

Systemets prompt er ikke en enkelt klump. Den er sammensat i lag, bevidst ordnet, så stabile dele kommer først, og de flygtige dele kommer til sidst. Dette er vigtigt, fordi modeludbydere gemmer en prompt baseret på dens præfiks: så længe begyndelsen af prompten er byte-for-byte identisk, genbruges det gemte præfiks, og kun enden behandles igen.

Zone	Lag (i rækkefølge)	Ændringer…
Stabil præfiks (cachebar)	base identitet + værktøj/hukommelsesguide → lejer → persona → færdigheder	sjældent — pr. agent/lejer
Flygtig hale (vedhæftet sidst)	onboarding-tilstand → hukommelses-hydrering → live-datoen	hver vending

Det stabile præfiks bærer alt, hvad der definerer hvem agenten er: den indbyggede identitet og vejledningen til, hvordan værktøjer og hukommelse fungerer, derefter lejerlaget, agentens persona og den gengivne færdighedsblok. Intet af dette ændres mellem to på hinanden følgende omgange af den samme agent, så det danner et genanvendeligt cachet præfiks.

Den flygtige hale er tilføjet efter det stabile præfiks præcist, så det aldrig ugyldiggør cachen: onboarding-tilstand, hukommelsen hydratiseret for denne specifikke samtale, og den aktuelle dato ændrer sig fra tur til tur, men fordi de ligger til sidst, koster de kun, hvad de tilføjer.

[!TIP] Denne rækkefølge er grunden til, at live data som dagens dato kan være til stede i hver vending uden at betale for at genkode hele identiteten hver gang. Bliv ved tilpasset indhold pr. agent i de stabile lag (personlighed, færdigheder) og lad motor ejer den flygtige hale.

Hvor til næste

Se, hvordan lejere er isolerede i Multitenancy og idempotens.
Lær hvordan svar returneres i Pålidelig levering og genopretning.
Valgfrie funktioner kører som Sidevogne.