Сүйлөшүү ИИ агенти ичинен кандай иштейт

Сүйлөшүү ИИ агенти ичинен кантип иштейт (OpenClaw архитектурасы)

Сүйлөшүү ИИ агенти кантип иштейт практикада, кезек-кезек менен? Бул пост OpenClaw'дун кара кутусун ачат: кардардын билдирүүсү WhatsApp'ка келген учурдан баштап, агент жазган жооп текстине чейин. Техникалык болот. Эгер сиз продукт архитектурасы боюнча чечим кабыл алсаңыз, чечим сатып алып, анын түбүн баалагыңыз келсе, же сүйлөшүүнүн артында эмне болуп жатканын билгиңиз келсе — бул пост сиз үчүн.

TL;DR: ар бир кезек 6 этаптан өтөт — кабыл алуу, контекстти чечүү, көндүмдөрдү тандоо, кийинки аракетти чечүү, коргоо чектери менен аткаруу, эстутумду сактоо. Бүт цикл Cloudflare'дин edge'инде <2 секундда иштейт, туруктуу серверсиз.

---

Эмне үчүн архитектура маанилүү

Демодо иштегендей көрүнүп, продукцияда бузулган сүйлөшүү агентинде адатта ушул 4 көйгөйдүн бири болот:

1. Жогорку кечигүү — кардар жоопту 8 секунд күтөт, сүйлөшүү өлөт.
2. Контролсуз галлюцинация — агент баа, убакыт, саясат ойлоп табат.
3. Жоголгон контекст — кардар 2 күндөн кийин кайтат, агент баарын "унутат".
4. Контролсуз чыгым — ар бир узун сүйлөшүү промптту толтурат жана сиз токен үчүн абдан көп төлөйсүз.

Бул 4өө — архитектуралык тандоолор, моделдин чектөөлөрү эмес. OpenClaw бул 4өөнү болтурбоо үчүн курулган — жана түшүнүүнүн жолу бир кезектин циклин карап чыгуу.

---

Бир кезектин цикли (6 этап)

Кардар жаңы эле "ишембиге эртең мененге жазгым келет" деген билдирүү жөнөттү деп элестетиңиз. "Кабыл алынды" менен агенттин жообунун ортосунда эмне болот?

1-этап — Кабыл алуу (edge worker, <50мс)

WhatsApp'тан билдирүү Meta'нын webhook'у аркылуу географиялык жактан эң жакын Cloudflare Worker катышуу чекитине (PoP) түз келет. Бразилияда бул Сан-Паулу же Рио дегенди билдирет, тармак кечигүүсү < 20мс.

Worker үч нерсе кылат:

1. Webhook'тун кол тамгасын текшерет (WABA сырына каршы HMAC).
2. Кабыл алуучунун телефон номери боюнча tenant'ти аныктайт (to_number боюнча мульти-tenant).
3. Payload'ду нормалдаштырат — аудио транскрипцияга айланат, сүрөт сүрөттөмөгө айланат, жайгашуу {lat,lng} болот, текст өзгөрүүсүз калат.

1-этаптын аягында кийинки кадамга даяр {tenant_id, conversation_id, user_message} объектиңиз бар.

2-этап — Контекстти чечүү (D1 + KV, ~80мс)

Агент чечим кабыл алуудан мурун 3 контекст бөлүгүнө муктаж:

• Сүйлөшүүнүн жакынкы тарыхы (акыркы N тиешелүү кайрылуу).
• Кардардын узак мөөнөттүү эстутуму (артыкчылыктары, сатып алуу тарыхы, жазуулары).
• Агенттин абалы (персона, иштетилген көндүмдөр, эрежелер).

Баары D1 (Cloudflare'дин бөлүштүрүлгөн SQLite'ы) аркылуу келет. D1 салттуу Postgres/Mongo'ну алмаштырат — тейлөө үчүн маалымат базасынын сервери жок, worker'ден бир нече мс ичинде жетүү, tenant_id боюнча көп ижарачылуу.

Негизги жагдай: биз бүт сүйлөшүүнү промптка жүктөбөйбүз. OpenClaw'дун Memory Manager v2'си (биздин ички документацияда сүрөттөлгөн) учурдагы кайрылуу үчүн тиешелүү кайрылууларды гана тандайт (акыркы N + семантикалык жактан жогорку актуалдуулуктагы N). Бул 100+ кайрылуулуу сүйлөшүүлөрдө да токен чыгымын алдын ала айтууга мүмкүн кылат.

3-этап — Көндүмдөрдү тандоо (policy engine, ~20мс)

Ар бир агенттин жеткиликтүү көндүмдөр жыйнагы бар — ал чакыра ала турган функциялар. Мисалдар: consultar_calendario, criar_evento, gerar_link_pagamento, consultar_pedido, chamar_humano.

"ишембиге эртең менен жазылгым келет" деген билдирүү берилгенде, policy engine чыпкалайт:

• Аныкталган ниет менен (жазылуу) шайкеш көндүмдөр.
• Сүйлөшүүнүн бул фазасында уруксат берилген көндүмдөр (бардык көндүмдөр дайыма жеткиликтүү эмес).
• Бул ижарачы иштеткен көндүмдөр (calendar ижарачы интеграциялаган учурда гана көрүнөт).

Акырында моделге берилүүчү көндүмдөрдүн кичинекей бөлүгү калат — мүмкүн болгон 50 эмес, бул жерде мааниси бар 4 гана. Бул моделдин туура эмес көндүм чакыруу мүмкүнчүлүгүн кескин азайтат.

4-этап — Чечим (LLM чалуу, 400-1200мс)

Эми модель кирет. OpenClaw алдыңкы катардагы LLM'ге (Anthropic Claude, OpenAI GPT, Google Gemini — ижарачы боюнча конфигурацияланат) бир чалуу жасайт:

• System prompt = агенттин персонасы + эрежелер + жеткиликтүү көндүмдөр.
• History = 2-этапта тандалган кайрылуулар.
• User message = учурдагы кайрылуунун билдирүүсү.

Модель экинин биринен жооп берет:

• Акыркы жооп (кардарга түз текст).
• Tool call (белгилүү бир көндүмдү параметрлер менен аткаруу өтүнүчү).

"ишембиге эртең менен жазылгым келет" мисалында модель адатта мындай кайтарат:

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

5-этап — Коргоо чектери менен аткаруу (өзгөрмөлүү, ~100-500мс)

Көндүм моделде иштебейт. Ал биздин коддо иштейт, ал:

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. Толук turnду (user + assistant + tool calls + узактык) D1ге сактайт.
3. Turn жаңы факт чыгарса (мисалы: "кардар ишембини жактырат") узак мөөнөттүү эстутумду жаңыртат.
4. Байкоо окуясын чыгарат (кечигүү метрикасы, токен наркы, эскалация ылдамдыгы).

Мунун баары параллелдүү иштейт. Сактоо кабарды жөнөтүүнү бөгөттөбөйт — кардар D1ди күтпөйт.

---

Галлюцинациядан коргоо кайда

Продукцияда галлюцинация кылган агент ишенимди тез жоготот. OpenClawда коргоонун 4 линиясы бар:

1. Мажбурланган чындык булагы. Фактылык маалыматтар (баа, убакыт, ат) ар дайым skillден келет, эч качан моделден жалгыз эмес.
2. Купуя маалыматтарда кош текшерүү. Жазылуу сактоодон мурун кардар менен ырасталат. Төлөм кирүүгө уруксат берүүдөн мурун ырасталат.
3. Ачык тыюу эрежелери. Ар бир агенттин персонасы "эч качан X, Y, Z ойлоп таппа" дегенди камтыйт — модель баш ийет.
4. Адамга кайтуу. Эч бир skill суроону камтыбаганда, агент "команда менен текшерип алайын" деп айтат жана тикет ачат — божомолдобойт.

Акыркы 6 айда биз жүргүзгөн аудиттерде (кол менен каралган чыныгы сүйлөшүүлөр), фактылык галлюцинация ылдамдыгы turnдардын 0,3%ынан төмөн болду — жана дээрлик бардык учурлар конфигурациядан улам болгон (tenant тиешелүү skillди иштетүүнү унутуп калган), моделдин катасынан эмес.

---

Бир сүйлөшүүнүн наркы

Жакшы архитектура эсепти көргөнгө чейин көрүнбөйт. Ар бир кайрылуу 1-2 LLM чалуу + D1 суроолорун жасай турганын эске алганда, толук сүйлөшүүнүн (10-15 кайрылуу) типтүү наркы төмөнкүдөй болот: