როგორ მუშაობს კონვერსაციული AI აგენტი შიგნიდან

როგორ მუშაობს საუბრის AI აგენტი შიგნიდან (OpenClaw არქიტექტურა)

როგორ მუშაობს საუბრის AI აგენტი პრაქტიკაში, ნაბიჯ-ნაბიჯ? ეს პოსტი ხსნის OpenClaw-ის შავ ყუთს: იმ მომენტიდან, როდესაც კლიენტის შეტყობინება WhatsApp-ში მოდის, იმ ტექსტამდე, რომელსაც აგენტი უკან წერს. ტექნიკური იქნება. ღირს, თუ თქვენ პროდუქტის არქიტექტურას წყვეტთ, თუ გადაწყვეტილების შეძენას აპირებთ და სიღრმისეულად გსურთ შეფასება, ან თუ გაინტერესებთ რა ხდება საუბრის უკან.

TL;DR: თითოეული ნაბიჯი გადის 6 ეტაპს — ingest, კონტექსტის გადაწყვეტა, უნარების არჩევა, შემდეგი მოქმედების გადაწყვეტა, guard-rails-ით შესრულება, მეხსიერების შენახვა. მთელი ციკლი მუშაობს <2 წამში Cloudflare-ის edge-ზე, ფიქსირებული სერვერის გარეშე.

---

რატომ არის არქიტექტურა მნიშვნელოვანი

საუბრის აგენტი, რომელიც დემოში მუშაობს, მაგრამ პროდუქციაში იშლება, ჩვეულებრივ ამ 4 პრობლემიდან ერთ-ერთი აქვს:

1. მაღალი ლატენტობა — კლიენტი 8 წამს ელის პასუხს, საუბარი კვდება.
2. კონტროლგარეშე ჰალუცინაცია — აგენტი გამოგონებს ფასს, საათს, პოლიტიკას.
3. დაკარგული კონტექსტი — კლიენტი 2 დღის შემდეგ ბრუნდება და აგენტი ყველაფერს "ივიწყებს".
4. კონტროლგარეშე ხარჯი — თითოეული გრძელი საუბარი ავსებს prompt-ს და თქვენ ბედს იხდით token-ზე.

ეს 4 არქიტექტურის არჩევანია, არა მოდელის შეზღუდვები. OpenClaw აშენდა ამ 4-ის თავიდან ასაცილებლად — და გასაგები გზა არის ერთი ნაბიჯის ციკლის დანახვა.

---

ერთი ნაბიჯის ციკლი (6 ეტაპი)

წარმოიდგინეთ, რომ კლიენტმა ახლახან გაგზავნა შეტყობინება "მინდა შაბათს დილით ჩავწერო". რა ხდება "received"-სა და აგენტის პასუხს შორის?

ეტაპი 1 — Ingest (edge worker, <50ms)

WhatsApp-ის შეტყობინება Meta-ს webhook-ის საშუალებით პირდაპირ მოდის Cloudflare Worker-ში გეოგრაფიულად უახლოეს წერტილში (PoP). ბრაზილიაში ეს ნიშნავს სან-პაულოს ან რიოს, ქსელის ლატენტობა < 20ms.

worker სამ რამეს აკეთებს:

1. ამოწმებს ხელმოწერას webhook-ის (HMAC WABA-ს საიდუმლოს წინააღმდეგ).
2. ადგენს tenant-ს მიმღების ტელეფონის ნომრით (multi-tenant to_number-ით).
3. ნორმალიზებს payload-ს — აუდიო ხდება ტრანსკრიფცია, სურათი ხდება აღწერა, ლოკაცია ხდება {lat,lng}, ტექსტი რჩება როგორც არის.

ეტაპ 1-ის ბოლოს გაქვთ ობიექტი {tenant_id, conversation_id, user_message} მზად შემდეგი ნაბიჯისთვის.

ეტაპი 2 — კონტექსტის გადაწყვეტა (D1 + KV, ~80ms)

აგენტს სჭირდება კონტექსტის 3 ნაწილი გადაწყვეტამდე:

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

ყველა მოდის D1-დან (Cloudflare-ის განაწილებული SQLite). D1 ცვლის ტრადიციულ Postgres/Mongo-ს — არ არის საჭირო ბაზის სერვერის მოვლა, წვდომა რამდენიმე მილიწამში worker-დან, multi-tenant tenant_id-ის მიხედვით.

მთავარი პუნქტი: ჩვენ არ ვტვირთავთ მთელ საუბარს prompt-ში. OpenClaw-ის Memory Manager v2 (აღწერილი ჩვენს შიდა დოკუმენტაციაში) ირჩევს მხოლოდ მიმდინარე ტურისთვის რელევანტურ ტურებს (ბოლო N + N მაღალი სემანტიკური რელევანტურობით). ეს ინარჩუნებს token-ის ხარჯს პროგნოზირებადს 100+ ტურის საუბრებშიც კი.

ეტაპი 3 — უნარების შერჩევა (policy engine, ~20ms)

თითოეულ აგენტს აქვს ხელმისაწვდომი უნარების ნაკრები — ფუნქციები, რომლებიც მას შეუძლია გამოიძახოს. მაგალითები: consultar_calendario, criar_evento, gerar_link_pagamento, consultar_pedido, chamar_humano.

მოცემული შეტყობინებისთვის "quero marcar pra sábado de manhã", policy engine ფილტრავს:

• უნარებს, რომლებიც თავსებადია გამოვლენილ ინტენციასთან (დაგეგმვა).
• უნარებს, რომლებიც დაშვებულია საუბრის ამ ფაზისთვის (ყველა უნარი ყოველთვის ხელმისაწვდომი არ არის).
• უნარებს, რომლებიც ამ tenant-მა ჩართო (calendar გამოჩნდება მხოლოდ იმ შემთხვევაში, თუ tenant-მა ინტეგრირება გააკეთა).

საბოლოოდ გაქვთ უნარების მცირე ქვესიმრავლე, რომელიც გადაეცემა მოდელს — არა 50 შესაძლო, მხოლოდ 4, რომელიც აქ აზრს იძენს. ეს მკვეთრად ამცირებს მოდელის მიერ არასწორი უნარის გამოძახების შანსს.

ეტაპი 4 — გადაწყვეტილება (LLM call, 400-1200ms)

ახლა მოდელი შედის. OpenClaw აკეთებს ერთჯერად გამოძახებას საზღვრის LLM-ზე (Anthropic Claude, OpenAI GPT, Google Gemini — კონფიგურირებადი tenant-ის მიხედვით) შემდეგით:

• System prompt = აგენტის პერსონა + წესები + ხელმისაწვდომი უნარები.
• History = ეტაპ 2-ში შერჩეული ტურები.
• User message = მიმდინარე ტურის შეტყობინება.

მოდელი პასუხობს ორიდან ერთს:

• საბოლოო პასუხი (პირდაპირი ტექსტი კლიენტისთვის).
• Tool call (მოთხოვნა კონკრეტული უნარის შესრულებისთვის პარამეტრებით).

მაგალითში "quero marcar pra sábado de manhã", მოდელი ჩვეულებრივ აბრუნებს:

{
  "tool": "consultar_calendario",
  "args": { "date_range": "2026-04-19 06:00 to 12:00" }
}

ეტაპი 5 — შესრულება guard-rails-ით (ცვლადი, ~100-500ms)

უნარი არ მუშაობს მოდელში. ის მუშაობს ჩვენს კოდში, რომელიც:

1. ამოწმებს პარამეტრებს (date_range-ს აქვს სწორი ფორმატი? შეესაბამება თუ არა tenant-ის წესებს?).
2. ამოწმებს ნებართვას (ამ აგენტს აქვს თუ არა უფლება მოითხოვოს ეს კალენდარი?).
3. ასრულებს გამოძახებას (Google Calendar API ამ შემთხვევაში).
4. აბრუნებს სტრუქტურირებულ შედეგს მოდელისთვის.

რატომ არის ეს მნიშვნელოვანი? რადგან მოდელი არასოდეს გამოგონებს შედეგს. თუ კალენდარი დააბრუნებს [10h, 11h], ზუსტად ეს გადაეცემა შემდეგ გამოძახებას. თუ skill ვერ შესრულდება, მოდელი იცის, რომ ვერ შესრულდა. ნულოვანი რისკი, რომ აგენტი "გამოიგონებს", რომ არის დრო 9 საათზე, როცა არ არის.

შემთხვევებისთვის, რომლებიც მოიცავს მგრძნობიარე ინფორმაციას (ფასი, ვადა, კლიენტის სახელი), pipeline აიძულებს tool call-ს — არ აძლევს მოდელს საშუალებას უპასუხოს საკუთარი "ცოდნიდან". ეს აღმოფხვრის ჰალუცინაციის კლასს, რომელიც ყველაზე გავრცელებულია კომერციულ აგენტებში.

ეტაპი 6 — პასუხი და შენახვა (~50ms)

skill-ის შედეგის ხელში ჩაგდებით, მოდელი ასრულებს მეორე გამოძახებას — ახლა კლიენტისთვის საბოლოო პასუხის ჩამოსაყალიბებლად. მაგ:

"მაქვს შაბათი 10 საათზე და 11 საათზე. რომელს ირჩევთ?"

პარალელურად, worker:

1. აგზავნის შეტყობინებას უკან WhatsApp-ის API-ს მეშვეობით.
2. ინახავს სრულ ტურს (user + assistant + tool calls + ხანგრძლივობა) D1-ში.
3. აახლებს გრძელვადიან მეხსიერებას, თუ ტურმა შექმნა ახალი ფაქტი (მაგ: "კლიენტი ამჯობინებს შაბათს").
4. გამოსცემს დაკვირვების მოვლენას (დაყოვნების მეტრიკა, token-ის ღირებულება, ესკალაციის მაჩვენებელი).

ეს ყველაფერი მუშაობს პარალელურად. შენახვა არ ბლოკავს შეტყობინების გაგზავნას — კლიენტი არ ელოდება D1-ს.

---

სად არის დაცვა ჰალუცინაციის წინააღმდეგ

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

1. იძულებითი source-of-truth. ფაქტობრივი მონაცემები (ფასი, დრო, სახელი) ყოველთვის მოდის skill-იდან, არასოდეს მხოლოდ მოდელიდან.
2. ორმაგი შემოწმება მგრძნობიარე მონაცემებზე. დანიშვნა დასტურდება კლიენტთან შენახვამდე. გადახდა დასტურდება წვდომის გაცემამდე.
3. აშკარა უარყოფითი წესები. თითოეული აგენტის პერსონა მოიცავს "არასოდეს გამოიგონო X, Y, Z" — მოდელი ემორჩილება.
4. Fallback ადამიანზე. როცა არცერთი skill არ მოიცავს კითხვას, აგენტი ამბობს "მომეცით შევამოწმო გუნდთან" და ხსნის ტიკეტს — არ ვარაუდობს.

აუდიტებში, რომლებიც ჩავატარეთ ბოლო 6 თვის განმავლობაში (რეალური საუბრები ხელით გადახედილი), ფაქტობრივი ჰალუცინაციის მაჩვენებელი იყო 0,3%-ზე ნაკლები ტურებისა — და თითქმის ყველა შემთხვევა იყო კონფიგურაციის გამო (tenant-მა დაავიწყდა შესაბამისი skill-ის ჩართვა), არა მოდელის შეცდომა.

---

ღირებულება საუბარზე

კარგი არქიტექტურა უხილავია, სანამ ინვოისს არ გადახედავთ. იმის გათვალისწინებით, რომ თითოეული ტურის დროს ხდება 1-2 LLM გამოძახება + D1-ში ძიება, ტიპიური ღირებულება სრული საუბრისთვის (10-15 ტური) შეადგენს: