Ярилцах AI Агентын Дотоод Ажиллагаа Хэрхэн Явагддаг Вэ

Харилцан Яриа Хийх Хиймэл Оюун Ухааны Агент Дотроос Хэрхэн Ажилладаг (OpenClaw Архитектур)

Харилцан яриа хийх хиймэл оюун ухааны агент бодит байдалд, ээлж бүрт хэрхэн ажилладаг вэ? Энэ нийтлэл OpenClaw-ийн хар хайрцгийг нээж үзүүлнэ: үйлчлүүлэгчийн мессеж WhatsApp-д ирсэн мөчөөс эхлээд агент буцааж бичсэн текст хүртэл. Энэ техникийн агуулга байх болно. Хэрэв та бүтээгдэхүүний архитектурын шийдвэр гаргадаг, шийдлийг худалдаж авахаар төлөвлөж гүнзгий үнэлгээ хийхийг хүсч байгаа, эсвэл ярианы ард юу болж байгааг мэдэхийг сонирхдог бол үнэ цэнэтэй байх болно.

Товч хураангуй: ээлж бүр 6 үе шатаар дамждаг — оролт, контекст шийдвэрлэх, ур чадвар сонгох, дараагийн үйлдэл шийдэх, хамгаалалттай гүйцэтгэх, санах ой хадгалах. Бүх мөчлөг Cloudflare-ийн edge дээр <2 секундэд ажилладаг, тогтмол сервергүй.

---

Архитектур яагаад чухал вэ

Демо дээр ажиллаж байгаа мэт харагдах боловч үйлдвэрлэлд эвдэрдэг харилцан яриа хийх агент ихэвчлэн эдгээр 4 асуудлын аль нэгтэй тулгардаг:

1. Өндөр хоцролт — үйлчлүүлэгч хариулт авахын тулд 8 секунд хүлээх, яриа тасалдах.
2. Хяналтгүй хуурмаг мэдээлэл — агент үнэ, цаг, бодлого зохиож гаргах.
3. Алдагдсан контекст — үйлчлүүлэгч 2 хоногийн дараа буцаж ирэхэд агент бүгдийг "мартах".
4. Хяналтгүй зардал — урт яриа бүр prompt-ыг дүүргэж, та token-д асар их төлдөг.

Энэ 4 нь загварын хязгаарлалт биш, архитектурын сонголт юм. OpenClaw-ийг энэ 4-ийг зайлсхийхээр бүтээсэн — ойлгох арга бол нэг ээлжийн мөчлөгийг харах явдал юм.

---

Нэг ээлжийн мөчлөг (6 үе шат)

Үйлчлүүлэгч дөнгөж сая "бямба гарагийн өглөө цаг авмаар байна" гэсэн мессеж илгээсэн гэж төсөөлөөд үз. "Хүлээн авсан" болон агентын хариултын хооронд юу болдог вэ?

Үе шат 1 — Оролт (edge worker, <50ms)

WhatsApp-ийн мессеж Meta-ийн webhook-оор дамжуулан газарзүйн хувьд хамгийн ойрхон байрлалын цэг (PoP) дээрх Cloudflare Worker руу шууд ирдэг. Бразилд энэ нь Сан Паулу эсвэл Рио гэсэн үг, сүлжээний хоцролт < 20ms.

Worker гурван зүйл хийдэг:

1. Webhook-ийн гарын үсгийг баталгаажуулах (WABA-ийн нууц эсрэг HMAC).
2. Хүлээн авагчийн утасны дугаараар tenant-ийг тодорхойлох (multi-tenant to_number-ээр).
3. Payload-ыг нормчлох — аудио транскрипц болох, зураг тайлбар болох, байршил {lat,lng} болох, текст хэвээрээ үлдэх.

Үе шат 1-ийн төгсгөлд та дараагийн алхамд бэлэн {tenant_id, conversation_id, user_message} объект авна.

Үе шат 2 — Контекст шийдвэрлэх (D1 + KV, ~80ms)

Агент шийдвэр гаргахаасаа өмнө 3 контекстын хэсэг хэрэгтэй:

• Харилцааны сүүлийн түүх (сүүлийн N холбогдолтой эргэлт).
• Үйлчлүүлэгчийн урт хугацааны санах ой (сонголт, худалдан авалтын түүх, тэмдэглэл).
• Агентын төлөв (persona, идэвхжүүлсэн ур чадвар, дүрэм).

Бүгд D1 (Cloudflare-ийн тархсан SQLite)-аас ирдэг. D1 нь уламжлалт Postgres/Mongo-г орлодог — хадгалах өгөгдлийн сангийн сервер байхгүй, worker-ээс хэдхэн ms-д хандах боломжтой, tenant_id-ээр олон түрээслэгч.

Гол цэг: бид бүтэн харилцааг prompt-д ачаалдаггүй. OpenClaw-ийн Memory Manager v2 (манай дотоод баримт бичигт тайлбарласан) зөвхөн одоогийн эргэлтэд холбогдолтой эргэлтүүдийг сонгодог (сүүлийн N + семантик хувьд өндөр холбогдолтой N). Энэ нь 100+ эргэлттэй харилцаанд ч token-ий зардлыг таамаглах боломжтой байлгадаг.

Үе шат 3 — Ур чадвар сонгох (policy engine, ~20ms)

Агент бүр ур чадваруудын багцтай — түүний дуудаж болох функцүүд. Жишээ нь: consultar_calendario, criar_evento, gerar_link_pagamento, consultar_pedido, chamar_humano.

"quero marcar pra sábado de manhã" гэсэн мессежийг өгөхөд policy engine шүүдэг:

• Илрүүлсэн зорилготой нийцэх ур чадварууд (цаг товлох).
• Харилцааны энэ үе шатанд зөвшөөрөгдсөн ур чадварууд (бүх ур чадвар үргэлж боломжтой байдаггүй).
• Энэ түрээслэгч идэвхжүүлсэн ур чадварууд (calendar нь зөвхөн түрээслэгч нэгтгэсэн тохиолдолд гарч ирнэ).

Эцэст нь та загварт дамжуулах жижиг ур чадваруудын дэд багцтай болно — боломжит 50 биш, зөвхөн энд утга учиртай 4. Энэ нь загварын буруу ур чадвар дуудах магадлалыг эрс бууруулдаг.

Үе шат 4 — Шийдвэр (LLM дуудлага, 400-1200ms)

Одоо загвар орж ирнэ. OpenClaw нь хил дээрх LLM (Anthropic Claude, OpenAI GPT, Google Gemini — түрээслэгчээр тохируулах боломжтой)-д нэг удаагийн дуудлага хийдэг:

• System prompt = агентын persona + дүрэм + боломжтой ур чадварууд.
• 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. Бүтэцтэй үр дүнг загварт буцаах.

Энэ яагаад чухал вэ? Учир нь загвар хэзээ ч үр дүнг зохиодоггүй. Хэрэв календар [10ц, 11ц] гэж буцаавал яг энэ нь дараагийн дуудлага руу очно. Хэрэв skill амжилтгүй болвол загвар амжилтгүй болсныг мэднэ. Агент 9 цагт цаг байхгүй байхад "байна" гэж "зохиох" эрсдэл тэг.

Мэдрэмтгий мэдээлэл (үнэ, хугацаа, үйлчлүүлэгчийн нэр) агуулсан тохиолдлуудад pipeline нь tool call-ийг албадна — загварт өөрийн "мэдлэгээс" хариулахыг зөвшөөрдөггүй. Энэ нь арилжааны агентуудад хамгийн түгээмэл төөрөгдлийн ангиллыг устгадаг.

6-р үе шат — Хариулт ба хадгалалт (~50ms)

Skill-ийн үр дүнтэй болсны дараа загвар хоёр дахь дуудлага хийнэ — одоо үйлчлүүлэгчид эцсийн хариулт бүрдүүлэхийн тулд. Жишээ нь:

"Бямба гарагт 10ц болон 11ц байна. Алийг нь илүүд үзэх вэ?"

Зэрэгцээд worker нь:

1. Илгээх мессежийг WhatsApp-ийн API-аар буцааж.
2. Хадгалах бүтэн эргэлтийг (user + assistant + tool calls + үргэлжлэх хугацаа) D1-д.
3. Урт хугацааны санах ойг шинэчлэх хэрэв эргэлт шинэ баримт үүсгэсэн бол (жишээ нь: "үйлчлүүлэгч бямба гарагийг илүүд үзнэ").
4. Ажиглах чадварын үйл явдал гаргах (хоцролтын хэмжүүр, токены зардал, өсгөх хувь хэмжээ).

Энэ бүгд зэрэгцээ ажиллана. Хадгалалт нь мессеж илгээхийг блоклодоггүй — үйлчлүүлэгч D1-ийг хүлээдэггүй.

---

Төөрөгдлийн эсрэг хамгаалалт хаана байна

Үйлдвэрлэлд төөрөгддөг агент итгэлийг хурдан алддаг. OpenClaw нь 4 хамгаалалтын шугамтай:

1. Албадан үнэний эх сурвалж. Баримтат өгөгдөл (үнэ, цаг, нэр) үргэлж skill-ээс ирдэг, хэзээ ч зөвхөн загвараас биш.
2. Мэдрэмтгий өгөгдөлд давхар шалгалт. Товлолт нь хадгалахаас өмнө үйлчлүүлэгчтэй баталгаажуулагдана. Төлбөр нь хандалт нээхээс өмнө баталгаажуулагдана.
3. Тодорхой сөрөг дүрэм. Агент бүрийн persona нь "хэзээ ч X, Y, Z зохиож болохгүй" гэсэн зүйлийг агуулдаг — загвар дагадаг.
4. Хүн рүү шилжих нөөц хувилбар. Ямар ч skill асуултыг хамрахгүй үед агент "багтай шалгаж үзье" гэж хэлээд тикет нээнэ — таамаглахгүй.

Сүүлийн 6 сард хийсэн аудитуудад (бодит ярианууд гараар дахин шалгагдсан) баримтат төөрөгдлийн хувь хэмжээ эргэлтийн 0.3%-иас доош байсан — мөн ихэнх тохиолдол нь загварын алдаа биш config-ийн (tenant холбогдох skill идэвхжүүлэхээ мартсан) улмаас байсан.

---

Ярианы зардал

Сайн архитектур нь төлбөрийн нэхэмжлэхийг харах хүртэл үл үзэгдэх байдаг. Нэг ээлж бүр 1-2 LLM дуудлага + D1 дээр хайлт хийдэг тул бүрэн яриа (10-15 ээлж) бүрийн ердийн зардал нь: