გეითვეინი და შემობრუნებადი ძრავა

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 მოუწვდომელია მონაცემთა ბაზა.

რა ხდება გაშვების დროს

ჩართვისას გაშვება ახორციელებს რამდენიმე ნაბიჯს მკაცრ თანმიმდევრობით:

ავსებს კავშირის ნაკადს მონაცემთა ბაზასთან,
განახორციელებს ყველა მიგრაციას, რომელიც ელოდება, Postgres-ის კონსულტაციური ბლოკირების გამოყენებით,
შესაძლებელია კონფიგურაცია (მონაცემთა ბაზის მნიშვნელობა → გარემოს ცვლადი → ჩაშენებული) სტანდარტულად), და
ერთამეურნება სერვისებს — როუტერი, ორკესტრატორი, არხები, ინსტრუმენტები, მეხსიერება, მიწოდება — მომუშავე ჭიშკარში.

მნიშვნელოვანი შედეგი ის არის, რომ ფუნქციების უმეტესობა ჩართულია პარამეტრის კლავიშით. ფუნქცია, რომელიც არ არის ჩართული, უბრალოდ არააქტიურია, რაც ინარჩუნებს სტანდარტულ შესრულების დროს მცირე და პროგნოზირებად. თქვენ ჩართავთ ფუნქციებს ადმინისტრატორის ვებინტერფეისის საშუალებით ან AIHUMMER_* მოცემული ცვლადი, ხოლო გეითი გადაწყვეტს მათ შემდეგ გაშვებაზე (ან პირდაპირ, მათთვის, რომლებიც ამას უჭერენ მხარს).

მოვრუნებადი ძრავი

როდესაც შეტყობინება აღწევს პორტალს, კონტროლი გადადის რიგის პროცესორზე. ის ახორციელებს ფუნქციების გამოძახების ციკლი: მოდელს ეძლევა სისტემის შპროდემი და საუბარი, ის შესაძლოა გამოიყენოს ხელსაწყოები (ან შექმნას დამხმარე აგენტები), თითოეული ხელსაწყოს შედეგი გამოდის დაბრუნებულად, და ლუპი გრძელდება სანამ მოდელი საბოლოო პასუხს არ გამოადგენს. შემდეგ პასუხი არის გადაცემულია მიწოდების ფენაზე.

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

მიმდინარე შემთხვევის დეტერმინირებული ბუნების გამო იმის შესახებ, საიდან მოდის თითოეული შეყვანა, პასუხები გადაწყდება საუბრის ისტორიისა და ხელსაწყოს შედეგების მიხედვით — არასდროს არ მატებს დაუჯერებელ ტექსტს ინსტრუქციებში. ამ თვისებაა რას აძლევს ქვემოთ მოცემულ მრავალსაფეხურიან მითითებას უსაფრთხოებას და სიჩქარეს.

მრავალსაფეხურიანი სისტემური რჩევა, რომელიც ოპტიმიზირებულია კეშისთვის

სისტემური აკრძალვა ერთიანი ბლოკი არ არის. ის იკვრება ფენებად, სპეციალურად განსაზღვრულად ეთამაშება ასე, რომ სტაბილური ნაწილები მოდიან პირველად და არასტაბილური ნაწილები მოდიან ბოლოს. ეს მნიშვნელოვანია, რადგან მოდელის მიმწოდებლები კეშირებენ მოთხოვნას მისი წინასიტყვითი ნაწილის მიხედვით: სანამ მოთხოვნის დასაწყისი ბაიტობრივად ემთხვევა, გამოიყენება კეშირებული წინასწარი ნაწილი, ხოლო მხოლოდ ბოლო ნაწილში ხდება დამუშავება.

ზონა	შრეწილები (ხრიკით)	გადარჩენები…
სტაბილური პრეფიქსი (ქეში)	ძირითადი იდენტურობა + ინსტრუმენტების/მეხსიერების სახელმძღვანელო → გაქირავება → პერსონა → უნარები	თხევადად — აგენტის/ქირაიდამისთვის
ფრენადი ეშინი (დამატებულია ბოლოს)	ხრიკების მდგომარეობა → მეხსიერების ინიციალიზაცია → გაშვების თარიღი	ყოველ კუთხეზე

სტაბილური პრეფიქსი შეიცავს ყველაფერს, რაც განსაზღვრავს ვინაა აგენტი: ჩაშენებულ იდენტობას და ინსტრუმენტებთან და მეხსიერებასთან სამუშაო მითითებებს, შემდეგ მორიგი ფენა დაინტერესებულ მხარეს, აგენტის პირსახეობა და block-ი გამოჩენილი უნარები. არც ერთი ეს იცვლება ერთი აგენტის ორი თანმიმდევრული მოძრაობის შორის, ასე რომ ის ქმნის ხელახლა გამოყენებად შენახულ წინას.

ვოლატილური კუდი ემატება მათგან სტაბილური პრეფიქსი ზუსტად ისე, რომ ის არასოდეს გააუქმოს ქეში: ობორდინგის მდგომარეობა, მეხსიერება, ამ კონკრეტული საუბრისთვის ჰიდრატირებული, და მიმდინარე თარიღი იცვლება ნაბიჯ-ნაბიჯ, მაგრამ რადგან ისინი ბოლოს მდებარეობს, ისინი მხოლოდ თქვენს ღირს ის, რასაც ისინი მიამატებენ.

[!TIP] ეს წესრიგი არის მიზეზი იმისა, რომ ასეთი რეალურ დროში არსებული მონაცემები, როგორიცაა დღევანდელი თარიღი, შეიძლება არსებობდეს ყოველჯერზე ყველა იდენტურობის ხელახლა კოდირებისთვის გადახდის გარეშე ყოველ ჯერზე. შეინახეთ კონფიგურირებადი შინაარსი თითოეული აგენტისთვის სტაბილურ შრებლებში (პერსონა, უნარები) და საშუალებას აძლევს ძრავა ფლობს არასტაბილურ კუდს.

სად შემდეგ?

ნახეთ, როგორ არიან მობინადრეები იზოლირებულნი მრავალმომხმარებლური რეჟიმი და idemპოტენტობა.
გაიგეთ, როგორ ბრუნდებიან პასუხები დამოჯერებელი მიწოდება და აღდგენა.
არასავალდებულო შესაძლებლობები დაიწყო როგორც გვერდის ეტლები.