Poartă și motor de virare — AiHummer Documentație

Inima AiHummer este un singur serviciu gateway. Este în același timp și plan de control (API de administrare, setări, configurare canal, piață) și rotați motorul (bucla de apelare a funcției care produce un răspuns). O implementare tipică este, prin urmare, doar acel serviciu plus PostgreSQL — nu există un nivel de lucru separat pe care trebuie să îl rulezi.

Un serviciu, două roluri

Poarta ascultă pe public port :8780 implicit, controlat de AIHUMMER_GATEWAY_ADDR — acest port gestionează tot traficul extern (API, împerechere, WS/SSE, webhook-uri de intrare, proxy-ul aplicației/pocket și probele de sănătate). Interfața Web UI de administrare rulează pe un separat, privat ascultător (implicit :8781, AIHUMMER_WEBUI_ADDR), servit la calea rădăcină / și ideal legat de o interfață accesibilă doar intern. În orice caz, procesul este întotdeauna același serviciu unic.

# 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)

singura dependență strictă este PostgreSQL. Postgres este singura sursă de adevăr pentru agenți, setări, conversații, memorie, starea livrării și audit. Tot ce este în plus — servicii opționale, un depozit vectorial și furnizori de modele — este conectat doar atunci când îl configurezi.

[!NOTE] Fără o bază de date, gateway-ul pornește în mod doar sănătate: răspunde GET /healthz așa încât un orchestrator sau un echilibrator de sarcină să poată vedea procesul este în viață, dar nu va mai fi util. GET /readyz verifică PostgreSQL și returnează 503 în timp ce baza de date este inaccesibilă.

Ce se întâmplă la pornire

La pornire, gateway-ul efectuează câțiva pași într-o ordine strictă:

deschide pool-ul de conexiuni la baza de date,
aplică orice migrare în așteptare sub un blocaj consultativ Postgres,
rezolvă configurația (valoare din baza de date → variabilă de mediu → încorporată) implicit), și
conectează serviciile — router, orchestrator, canale, unelte, memorie, livrare — într-un gateway activ.

Consecința importantă este că majoritatea caracteristicilor sunt activate opțional printr-o cheie de setări. O capacitate care nu este configurată pur și simplu nu este activată, ceea ce menține timpul de execuție implicit redus și predictibil. O activezi din interfața web de administrare sau cu un AIHUMMER_* variabilă, iar gateway-ul le rezolvă la următoarea pornire (sau la cald, pentru butoanele care o suportă).

Motorul de întoarcere

Când un mesaj ajunge la poartă, motorul de rotație preia controlul. Acesta rulează un buclă de apelare a funcției: modelului i se oferă promptul sistemului și conversația, poate apela unelte (sau poate genera sub-agenti), fiecare rezultat al uneltelor este returnat, iar ciclul continuă până când modelul produce un răspuns final. Acel răspuns este apoi predat nivelului de livrare.

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

Pentru că bucla este deterministă în ceea ce privește de unde provine fiecare intrare, răspunsurile sunt rezolvate din istoricul conversației și din rezultatele instrumentelor — niciodată prin injectarea de text neîncredere în instrucțiuni. Această proprietate este ceea ce face stratificarea promptului de mai jos sigură, precum și rapidă.

Promptul sistemului stratificat, prietenos cu cache-ul

Promptul sistemului nu este un singur bloc. Este asamblat în straturi, ordonate în mod deliberat astfel încât părțile stabile vin mai întâi și părțile volatile vin la urmă. Acest lucru contează deoarece furnizorii de modele înregistrează în cache un prompt după prefixul său: atâta timp cât începutul promptului este identic byte-cu-byte, prefixul din cache este reutilizat și doar coada este re-procesată.

Zonă	Straturi (în ordine)	Schimbări…
Prefix stabil (poate fi stocat în cache)	identitate de bază + ghid de unelte/memorie → chiriaș → persoană → abilități	rar — pe agent/chiriaș
Coada volatilă (atașat ultima)	starea de integrare → hidratarea memoriei → data de activare	la fiecare cotitură

Prefixul stabil poartă tot ceea ce definește cine este agentul: identitatea încorporată și ghidul despre cum funcționează instrumentele și memoria, apoi stratul de chiriaș, persona agentului și blocul de abilități redat. Nimic din toate acestea nu se schimbă între două runde consecutive ale aceluiași agent, așa că formează un prefix cache reutilizabil.

Coada volatilă este adăugată după prefixul stabil exact astfel încât să nu invalideze niciodată cache-ul: starea de onboarding, memoria hidratată pentru această conversație specifică și data curentă se schimbă de la o tură la alta, dar deoarece stau la sfârșit, costă doar ceea ce adaugă.

[!TIP] Această ordonare este motivul pentru care datele live, cum ar fi data de astăzi, pot fi prezente în fiecare rotație fără a plăti pentru a re-codifica întreaga identitate de fiecare dată. Păstrează conținut personalizat per agent în straturile stabile (persoană, abilități) și permite motorul deține coada volatilă.

Unde următor?

Vezi cum sunt izolați chiriașii în Multichiria & idempotență.
Aflați cum sunt returnate răspunsurile în Livrare și recuperare de încredere.
Capabilități opționale care rulează ca Atelaje laterale.