AiHummer
Հայերեն
ՄուտքԱնձնական գրասենյակ
v1.0.x
{ }Swagger

Գեյթ և պտտվող շարժիչ

v1.0.x · թարմացվել է 2026-06-26

AiHummer-ի սիրտը — մի դարպասի ծառայություն. Միևնույն ժամանակ դա կառավարման հարթակ (կառավարչի API, կարգավորումներ, ալիքների միացում, շուկա) և վրա գնել շարժիչը (ֆունկցիայի կանչման ցիկլը, որը արտադրում է պատասխան): Տիպային տեղադրում, հետեւաբար, դա ընդամենը մեկ ծառայություն է՝ միասին PostgreSQL-ի հետ — առանձին աշխատանքի գործընթացների մակարդակ, որը անհրաժեշտ է գործարկել, չկա։

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

Շարադրել լսում է հանրային պորտ :8780 պայմանավորված, վերահսկվում է AIHUMMER_GATEWAY_ADDR — այս պորտը մշակում է ամբողջ արտաքին տրաֆիկը (API, ինտեգրում, WS/SSE, եկող webhook-ներ, հավելվածի/գրպանի պրոքսի և վիճակի ստուգման համար): Վարչարարական վեբ-միջերեսը գործում է անձնական, մասնավոր մեկնաբան (ստանդարտով) :8781, AIHUMMER_WEBUI_ADDR), սպասարկվում է արմատային ուղիով / մանրէ և իդեալապես կապված է միայն ներքին օգտագործման համար ինտերֆեյսի հետ։ Ամեն դեպքում գործընթացը միշտ նույնն է և ծառայությունը նույնը։

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

Այս միակ բարդ կախվածությունը՝ PostgreSQL. Postgres- ին միակ ճշմարտության աղբյուրն է գործակալների, կարգավորումների, խոսակցությունների, հիշողության, առաքման վիճակի և աուդիտի համար: Սրանքից մնացած բոլորն — լրացուցիչ ծառայություններ, վեկտորային պահոց և մոդելների մատակարարներ — միացվում են միայն այն ժամանակ, երբ դուք կարգավորեք դա։

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

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

Սեղմվելիս զանգվածը կատարում է մի քանի քայլեր խիստ հերթականությամբ՝

  1. բացում է բազայի կապերի պուլը,
  2. կիրառում է ցանկացած սպասող միգրացիա՝ օգտագործելով Postgres-ի խորհրդատվական արգելափակում,
  3. լուծում է կազմաձևը (վահանակի արժեք → միջավայրի փոփոխական → ներառված) դրա լռելյայնությամբ), և
  4. Միավորում է ծառայությունները — ռուտեր, օրհեստրատոր, ալիքներ, գործիքներ, հիշողություն, տրամադրում — աշխատող դարպասը:

Կարևոր հետևանքը այն է, որ հիմնական առանձնահատկությունների մեծ մասը հասանելի է միայն ընտրովի կարգավորումներով. Ընկած հնարավորությունը, որը չի կարգավորվել, պարզապես ակտիվ չէ, ինչը պահպանում է ստանդարտ ֆունկցիայի փուլը փոքր և կանխատեսելի: Դուք միացնում եք գործառույթները ադմինիստրատորի վեբ ինտերֆեյսի միջոցով կամ օգտագործելով AIHUMMER_* փոփոխական, և դարպասը դրանք լուծում է հաջորդ սկսման ժամանակ (կամ տաք, այն knop-երի համար, որոնք դա աջակցում են)։

Հրամկող շարժիչ

Երբ հաղորդագրությունը հասնում է դարպասին, կառավարումը անցնում է հերթի պրոցեսորին։ Այն կատարում է ֆունկցիաների կանչի ցիկլ: Մոդելը ստանում է համակարգային հրավեր և զրույց, այն կարող է օգտագործել գործիքներ (կամ ստեղծել ենթաքաղացված գործակալներ), յուրաքանչյուր գործիքի արդյունքը վերադառնում է, և ցիկլը շարունակվում է մինչև այն պահը, երբ մոդելը կտա վերջնական պատասխան։ Այս պատասխանն այնուհետև հանձնարարված է առաքման շերտին։

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

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

Բազմաստիճան համակարգային հուշում, օպտիմիզացված պահեստավորման համար

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

Ատել Շերտեր (հերթականությամբ) Փոփոխություններ…
Կայուն նախածանց (կեշավորված) հիմնական ինքնություն + գործիքների/հիշողության ուղեցույց → վարձակալ → անձ → հմտություններ հակառակ դեպքում՝ գործակալի/վարձակալին
Թռչող պոչ (ավելացված է վերջում) հարմարման վիճակ → հիշողության սկզբում → գործարկման ամսաթիվ ամեն մի պտույտում

Կայուն նախածանցը պարունակում է ամենը, ինչը սահմանում է արդյոք ով է գործակալը՝ ներառական ինքնությունը և գործիքների ու հիշողության աշխատանքային ուղեցույցը, այնուհետև վարձակալության շերտը, գործակցի անձը և ցուցադրվող հմտությունների բլոկը: Ոչ մեկը այսը փոխվում է նույն գործակալի երկու հաջորդական քայլերի միջև, այնպես որ դա ձևավորում է կրկնակի օգտագործվող պահպանված նախապատմություն:

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

[!TIP] Այս կարգն այն պատճառն է, որ նման իրական ժամանակի տվյալները, kuten օրվա tarikhi, կարող են համեմատվել ամեն անգամ առանց վճարման ամբողջ նույնականացումը կրկնօրինակելու համար ամեն անգամ: Պահպանեք նույնականացված բովանդակություն յուրաքանչյուր գործակալի համար կայուն շերտերում (դեր, հմտություններ) և թույլ տալ ենքին քամին է պահում բասհանդքը:

Որտեղից հետո