Bramka i silnik obrotowy — AiHummer Dokumenty

Serce AiHummera to pojedyncza usługa bramy. Jest to jednocześnie płaszczyzna sterowania (admin API, ustawienia, konfiguracja kanału, rynek) i uruchomić silnik (pętla wywołująca funkcje, która generuje odpowiedź). Typowe wdrożenie to więc tylko ta jedna usługa plus PostgreSQL — nie ma oddzielnej warstwy pracowników, którą musisz uruchamiać.

Jedna usługa, dwie role

Bramka nasłuchuje na publiczny port :8780 domyślnie, kontrolowany przez AIHUMMER_GATEWAY_ADDR — ten port obsługuje cały ruch zewnętrzny (API, parowanie, WS/SSE, przychodzące webhooki, proxy aplikacji/kieszeni oraz sondy zdrowia). Panel administracyjny Web UI działa na oddzielny, prywatny słuchacz (domyślnie :8781, AIHUMMER_WEBUI_ADDR), podawane w ścieżce głównej / i najlepiej związany z interfejsem tylko wewnętrznym. Tak czy inaczej proces zawsze jest tą samą pojedynczą usługą.

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

Ten jedyną twardą zależnością jest PostgreSQL. Postgres jest jedynym źródłem prawdy dla agentów, ustawień, rozmów, pamięci, stanu dostawy i audytu. Wszystko inne — opcjonalne usługi, magazyn wektorów i dostawcy modeli — jest podłączane tylko wtedy, gdy je skonfigurujesz.

[!NOTE] Bez bazy danych brama startuje w tryb tylko zdrowia: to odpowiada GET /healthz więc orchestrator lub load balancer może zobaczyć, że proces jest żywy, ale nie będzie użyteczny. GET /readyz sprawdza PostgreSQL i zwraca 503 podczas gdy baza danych jest nieosiągalna.

Co się dzieje podczas uruchamiania

Podczas uruchamiania brama wykonuje kilka kroków w ściśle określonej kolejności:

otwiera pulę połączeń z bazą danych,
stosuje wszystkie oczekujące migracje pod blokadą doradczą Postgresa,
rozwiązuje konfigurację (wartość w bazie danych → zmienna środowiskowa → wbudowana) domyślnie), i
łącza usługi — router, orkiestrator, kanały, narzędzia, pamięć, dostawa — do działającej bramki.

Ważnym następstwem jest to, że większość funkcji jest opcjonalna za pomocą klucza ustawień. Funkcja, która nie jest skonfigurowana, po prostu nie jest aktywowana, co utrzymuje domyślny czas wykonywania małym i przewidywalnym. Możesz włączać funkcje z poziomu interfejsu administracyjnego w sieci Web lub za pomocą AIHUMMER_* zmienna, a brama rozwiązuje je przy następnym uruchomieniu (lub na gorąco, w przypadku pokręteł, które to obsługują).

Silnik skrętu

Kiedy wiadomość dotrze do bramki, silnik obrotu przejmuje kontrolę. Działa on jako pętla wywoływania funkcji: model otrzymuje podpowiedź systemową i rozmowę, może wywoływać narzędzia (lub uruchamiać pod-agenty), każdy wynik narzędzia jest przekazywany z powrotem, a pętla trwa, aż model wygeneruje ostateczną odpowiedź. Ta odpowiedź jest następnie przekazywana do warstwy dostarczania.

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

Ponieważ pętla jest deterministyczna co do skąd pochodzi każde dane wejściowe, odpowiedzi są rozwiązywane z historii rozmowy i wyników narzędzi — nigdy przez wprowadzanie nieznanego tekstu do instrukcji. To właściwość sprawia, że warstwowanie promptów poniżej jest zarówno bezpieczne, jak i szybkie.

Warstwowy, przyjazny pamięci podręcznej systemowy prompt

Polecenie systemu nie jest jedną całością. Jest składane w warstwy, celowo uporządkowane tak, aby stabilne części pojawiają się pierwsze, a zmienne części pojawiają się na końcu. To ma znaczenie, ponieważ dostawcy modeli buforują zapytanie według jego prefiksu: dopóki początek zapytania jest identyczny bajt po bajcie, buforowany prefiks jest ponownie używany, a przetwarzany jest tylko ogon.

Strefa	Warstwy (w kolejności)	Zmiany…
Stabilny prefiks (możliwe do buforowania)	podstawowa tożsamość + przewodnik po narzędziach/pamięci → najemca → persona → umiejętności	rzadko — na agenta/najemcę
Lotny ogon (dołączone na końcu)	stan wdrożenia → nawodnienie pamięci → data uruchomienia	każdy zakręt

Stabilny prefiks zawiera wszystko, co definiuje kim jest agent: wbudowaną tożsamość i przewodnik po tym, jak działają narzędzia i pamięć, następnie warstwę najemcy, osobowość agenta oraz wyrenderowany blok umiejętności. Żadne z tego nie zmienia się między dwoma kolejnymi turami tego samego agenta, więc tworzy to wielokrotnego użytku, pamiętany prefiks.

Lotny ogon jest dołączany po stabilny prefiks dokładnie tak, aby nigdy nie unieważniał pamięci podręcznej: stan wprowadzania, pamięć wypełniona dla tej konkretnej rozmowy i bieżąca data zmieniają się z tury na turę, ale ponieważ znajdują się na końcu, kosztują tylko to, co dodają.

[!TIP] To uporządkowanie jest powodem, dla którego dane na żywo, takie jak dzisiejsza data, mogą być obecne w każdy zakręt bez płacenia za ponowne kodowanie całej tożsamości za każdym razem. Zachowaj niestandardowa zawartość dla poszczególnych agentów w stabilnych warstwach (osobowość, umiejętności) i pozwól na silnik posiada niestabilny ogon.

Dokąd dalej

Zobacz, jak najemcy są izolowani w Wielodostępność i niezmienność.
Dowiedz się, jak zwracane są odpowiedzi w Niezawodna dostawa i odzyskiwanie.
Opcjonalne funkcje działają jako Sidelivery.