Gateway և turn engine — AiHummer Փաստաթղթեր

AiHummer-ի սիրտը մեկ gateway ծառայությունն է։ Այն միաժամանակ control-plane-ն է (ադմին API, կարգավորումներ, ալիքների միացում, marketplace) և turn engine-ը (function-calling ցիկլը, որը ստեղծում է պատասխանը)։ Տիպիկ տեղակայումը հետևաբար ընդամենը այդ մեկ ծառայությունն է գումարած PostgreSQL — չկա առանձին worker-ի շերտ, որը պարտադիր է աշխատեցնել։

Մեկ ծառայություն, երկու դեր

Gateway-ը ըստ լռելյայնի լսում է :8780-ի վրա՝ կառավարվելով AIHUMMER_GATEWAY_ADDR-ով։ Տեղադրիչը կարող է ընտրել այլ ազատ port, սակայն պրոցեսը միշտ նույն մեկ ծառայությունն է։

# gateway.env — the only required setting
AIHUMMER_DATABASE_URL=postgres://user:pass@localhost:5432/aihummer?sslmode=disable
# Admin UI after start at http://localhost:8781/

Միակ կոշտ կախվածությունը PostgreSQL-ն է։ Postgres-ը ճշմարտության միակ աղբյուրն է. agent-երը, կարգավորումները, զրույցները, հիշողությունը, outbox-ը և աուդիտը բոլորն այնտեղ են ապրում։ Մնացած ամեն ինչ — sidecar-ներ, vector store, message bus, model provider-ներ — ընտրովի է և միացվում է միայն այն ժամանակ, երբ դուք այն կարգավորում եք։

[!NOTE] Առանց տվյալների բազայի gateway-ը գործարկվում է միայն-առողջության ռեժիմում. այն պատասխանում է GET /healthz-ին, որպեսզի օրկեստրատորը կամ load balancer-ը կարողանա տեսնել, որ պրոցեսը կենդանի է, սակայն այն չի սպասարկի turn-եր։ GET /readyz-ը ստուգում է PostgreSQL-ը և վերադարձնում 503, քանի դեռ տվյալների բազան անհասանելի է։

Ինչ է տեղի ունենում գործարկման ժամանակ

Գործարկման ժամանակ gateway-ը կատարում է մի քանի քայլ խիստ հերթականությամբ.

բացում է տվյալների բազայի կապի pool-ը,
կիրառում է ցանկացած սպասող migration Postgres advisory lock-ի ներքո,
լուծում է կարգաձևը (տվյալների բազայի արժեք → environment variable → ներկառուցված լռելյայն), և
միացնում է ծառայությունները — router, orchestrator, ալիքներ, գործիքներ, հիշողություն, առաքում — աշխատող gateway-ի մեջ։

Կարևոր հետևանքն այն է, որ հատկություններից շատերը ընտրովի-միացվող են կարգավորման key-ի միջոցով։ Չկարգավորված հնարավորությունն ուղղակի ակտիվացված չէ, ինչը լռելյայն runtime-ը պահում է փոքր և կանխատեսելի։ Դուք միացնում եք բաները վեբ ադմին UI-ից կամ AIHUMMER_* փոփոխականով, և gateway-ը լուծում է դրանք հաջորդ գործարկման ժամանակ (կամ տաք՝ այն փականների համար, որոնք աջակցում են դա)։

Turn engine-ը

Երբ հաղորդագրությունը հասնում է gateway-ին, turn engine-ը ստանձնում է ղեկը։ Այն աշխատեցնում է function-calling ցիկլ. մոդելին տրվում է system prompt-ը և զրույցը, այն կարող է կանչել գործիքներ (կամ ստեղծել ենթա-agent-ներ), յուրաքանչյուր գործիքի արդյունքը հետ է մատուցվում, և ցիկլը շարունակվում է, մինչև մոդելը ստեղծի վերջնական պատասխան։ Այդ պատասխանն այնուհետև փոխանցվում է առաքման շերտին։

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

Քանի որ ցիկլը դետերմինիստական է այն հարցում, թե որտեղից է գալիս յուրաքանչյուր մուտք, պատասխանները լուծվում են զրույցի պատմությունից և գործիքների արդյունքներից — երբեք ոչ թե անվստահելի տեքստ ներարկելով հրահանգների մեջ։ Հենց այդ հատկությունն է, որ ստորև բերված prompt-ի շերտավորումը դարձնում է թե՛ անվտանգ, թե՛ արագ։

Շերտավորված, քեշին հարմար system prompt-ը

System prompt-ը մեկ կտոր չէ։ Այն հավաքվում է շերտերով՝ դիտավորյալ դասավորված այնպես, որ կայուն մասերը գան առաջինը, իսկ անկայուն մասերը՝ վերջինը։ Սա կարևոր է, քանի որ model provider-ները քեշավորում են prompt-ն ըստ դրա նախածանցի. քանի դեռ prompt-ի սկիզբը բայթ առ բայթ նույնական է, քեշավորված նախածանցը կրկին օգտագործվում է, և միայն պոչն է վերամշակվում։

Գոտի	Շերտեր (հերթականությամբ)	Փոխվում է…
Կայուն նախածանց (քեշավորելի)	base identity + tool/memory guide → tenant → persona → skills	հազվադեպ — ըստ agent/tenant-ի
Անկայուն պոչ (ավելացվում է վերջում)	onboarding state → memory hydration → the live date	ամեն turn-ի ժամանակ

Կայուն նախածանցը կրում է այն ամենը, ինչ սահմանում է ով է agent-ը. ներկառուցված ինքնությունը և գործիքների ու հիշողության աշխատանքի ուղեցույցը, ապա tenant-ի շերտը, agent-ի persona-ն և ներկայացված skills բլոկը։ Դրանցից ոչ մեկը չի փոխվում նույն agent-ի երկու հաջորդական turn-երի միջև, ուստի այն կազմում է կրկին օգտագործվող քեշավորված նախածանց։

Անկայուն պոչը ավելացվում է կայուն նախածանցից հետո հենց այն պատճառով, որ այն երբեք չանվավերացնի քեշը. onboarding state-ը, այս կոնկրետ զրույցի համար hydrate արված հիշողությունը և ընթացիկ ամսաթիվը բոլորը փոխվում են turn-ից turn, սակայն քանի որ դրանք գտնվում են վերջում, դրանք արժենում են միայն այն, ինչ ավելացնում են։

[!TIP] Այս դասավորությունն է պատճառը, որ կենդանի տվյալները, ինչպիսին է այսօրվա ամսաթիվը, կարող են ներկա լինել ամեն turn-ում՝ առանց ամեն անգամ ամբողջ ինքնությունը վերակոդավորելու վճարելու։ Պահեք agent-ի համար հատուկ բովանդակությունը կայուն շերտերում (persona, skills) և թողեք, որ շարժիչը տիրապետի անկայուն պոչին։

Ուր հաջորդիվ

Տեսեք, թե ինչպես են tenant-ները մեկուսացված Բազմավարձակալություն և իդեմպոտենտություն-ում։
Իմացեք, թե ինչպես են պատասխանները վերադարձվում Առաքում, outbox և վերականգնում-ում։
Ընտրովի հնարավորությունները աշխատում են որպես Sidecar-ներ։