একটি কথোপকথনমূলক AI এজেন্ট ভেতর থেকে কীভাবে কাজ করে
OpenClaw-এ একটি কথোপকথনের টার্নের ৬টি ধাপ — প্রকৃত লেটেন্সি, প্রতি কথোপকথনের খরচ এবং হ্যালুসিনেশনের বিরুদ্ধে ৪টি প্রতিরক্ষা স্তর।
Equipe OpenClaw · Time de Engenharia & Produto
A Equipe OpenClaw é formada por engenheiros, designers e especialistas em IA dedicados a construir a melhor plataforma de agentes conversacionais para negócios brasileiros. Combinamos expertise…
একটি কথোপকথনমূলক AI এজেন্ট ভেতর থেকে কীভাবে কাজ করে (OpenClaw আর্কিটেকচার)
একটি কথোপকথনমূলক AI এজেন্ট কীভাবে কাজ করে বাস্তবে, টার্ন বাই টার্ন? এই পোস্টটি OpenClaw-এর ব্ল্যাক বক্স খুলে দেয়: গ্রাহকের WhatsApp-এ মেসেজ পাঠানোর মুহূর্ত থেকে এজেন্ট যে টেক্সট ফেরত লেখে সেই পর্যন্ত। এটি টেকনিক্যাল হবে। আপনি যদি প্রোডাক্ট আর্কিটেকচারের সিদ্ধান্ত নেন, কোনো সমাধান কিনতে চান এবং গভীরভাবে মূল্যায়ন করতে চান, অথবা কথোপকথনের পেছনে কী ঘটছে তা জানতে আগ্রহী হন — তাহলে এটি পড়ার মূল্য আছে।
TL;DR: প্রতিটি টার্ন ৬টি ধাপের মধ্য দিয়ে যায় — ingest, কনটেক্সট রিজলভ, স্কিল সিলেক্ট, পরবর্তী অ্যাকশন ডিসাইড, গার্ড-রেইলসহ এক্সিকিউট, মেমোরি পার্সিস্ট। পুরো সাইকেলটি Cloudflare-এর edge-এ <২ সেকেন্ডে চলে, কোনো ফিক্সড সার্ভার ছাড়া।
আর্কিটেকচার কেন গুরুত্বপূর্ণ
কথোপকথনমূলক এজেন্ট যা ডেমোতে কাজ করছে বলে মনে হয় কিন্তু প্রোডাকশনে ভেঙে পড়ে, সাধারণত এই ৪টি সমস্যার একটি থাকে:
- উচ্চ লেটেন্সি — গ্রাহক উত্তরের জন্য ৮ সেকেন্ড অপেক্ষা করে, কথোপকথন মরে যায়।
- অনিয়ন্ত্রিত হ্যালুসিনেশন — এজেন্ট দাম, সময়, পলিসি বানিয়ে বলে।
- হারানো কনটেক্সট — গ্রাহক ২ দিন পর ফিরে আসে এবং এজেন্ট সব "ভুলে যায়"।
- অনিয়ন্ত্রিত খরচ — প্রতিটি দীর্ঘ কথোপকথন প্রম্পট ভরে ফেলে এবং আপনি টোকেনে বিপুল অর্থ খরচ করেন।
এই ৪টিই আর্কিটেকচারের সিদ্ধান্ত, মডেলের সীমাবদ্ধতা নয়। OpenClaw এই ৪টি এড়াতে তৈরি করা হয়েছে — এবং বোঝার পথ হলো একটি টার্নের সাইকেল দেখা।
একটি টার্নের সাইকেল (৬টি ধাপ)
কল্পনা করুন গ্রাহক এইমাত্র মেসেজ পাঠিয়েছে "quero marcar pra sábado de manhã"। "received" এবং এজেন্টের উত্তরের মধ্যে কী ঘটে?
ধাপ ১ — Ingest (edge worker, <50ms)
WhatsApp-এর মেসেজ Meta-র webhook-এর মাধ্যমে সরাসরি ভৌগোলিকভাবে নিকটতম পয়েন্ট অফ প্রেজেন্সে (PoP) একটি Cloudflare Worker-এ আসে। ব্রাজিলে, এর মানে সাও পাওলো বা রিও, নেটওয়ার্ক লেটেন্সি < 20ms।
Worker তিনটি কাজ করে:
- Webhook-এর সিগনেচার ভ্যালিডেট করে (WABA সিক্রেটের বিপরীতে HMAC)।
- রিসিভারের ফোন নম্বর দিয়ে টেন্যান্ট আইডেন্টিফাই করে (মাল্টি-টেন্যান্ট
to_numberদ্বারা)। - পেলোড নরমালাইজ করে — অডিও ট্রান্সক্রিপশনে রূপান্তরিত হয়, ইমেজ বর্ণনায় রূপান্তরিত হয়, লোকেশন
{lat,lng}-তে রূপান্তরিত হয়, টেক্সট যেমন আছে তেমনই থাকে।
ধাপ ১-এর শেষে আপনার কাছে একটি {tenant_id, conversation_id, user_message} অবজেক্ট থাকে যা পরবর্তী ধাপের জন্য প্রস্তুত।
ধাপ ২ — কনটেক্সট রিজলভ (D1 + KV, ~80ms)
সিদ্ধান্ত নেওয়ার আগে এজেন্টের ৩টি কনটেক্সট পিস দরকার:
- সাম্প্রতিক ইতিহাস কথোপকথনের (শেষ N প্রাসঙ্গিক টার্ন)।
- দীর্ঘমেয়াদী মেমরি গ্রাহকের (পছন্দ, ক্রয়ের ইতিহাস, নোট)।
- এজেন্টের স্টেট (পার্সোনা, সক্রিয় skills, নিয়মাবলী)।
সবকিছু আসে D1 থেকে (Cloudflare-এর ডিস্ট্রিবিউটেড SQLite)। D1 প্রচলিত Postgres/Mongo-কে প্রতিস্থাপন করে — কোনো ডাটাবেস সার্ভার রক্ষণাবেক্ষণ করতে হয় না, worker থেকে কয়েক ms-এ অ্যাক্সেস, tenant_id দিয়ে মাল্টি-টেন্যান্ট।
মূল বিষয়: আমরা পুরো কথোপকথন প্রম্পটে লোড করি না। OpenClaw-এর Memory Manager v2 (আমাদের অভ্যন্তরীণ ডকুমেন্টেশনে বর্ণিত) শুধুমাত্র বর্তমান টার্নের জন্য প্রাসঙ্গিক টার্নগুলো নির্বাচন করে (শেষ N + উচ্চ সেমান্টিক প্রাসঙ্গিকতার N টার্ন)। এটি ১০০+ টার্নের কথোপকথনেও টোকেন খরচ অনুমানযোগ্য রাখে।
স্টেজ ৩ — Skills নির্বাচন (policy engine, ~20ms)
প্রতিটি এজেন্টের কাছে একগুচ্ছ উপলব্ধ skills থাকে — যে ফাংশনগুলো সে ইনভোক করতে পারে। উদাহরণ: consultar_calendario, criar_evento, gerar_link_pagamento, consultar_pedido, chamar_humano।
"quero marcar pra sábado de manhã" মেসেজটি পেলে, policy engine ফিল্টার করে:
- শনাক্তকৃত ইনটেন্টের সাথে সামঞ্জস্যপূর্ণ Skills (শিডিউলিং)।
- কথোপকথনের এই পর্যায়ে অনুমোদিত Skills (সব skill সবসময় উপলব্ধ থাকে না)।
- এই tenant সক্রিয় করেছে এমন Skills (calendar শুধু তখনই দেখায় যখন tenant ইন্টিগ্রেট করেছে)।
শেষ পর্যন্ত আপনি মডেলে পাঠানোর জন্য skills-এর একটি ছোট সাবসেট পান — সম্ভাব্য ৫০টি নয়, শুধু ৪টি যেগুলো এখানে অর্থবহ। এটি মডেলের ভুল skill ইনভোক করার সম্ভাবনা ব্যাপকভাবে কমিয়ে দেয়।
স্টেজ ৪ — সিদ্ধান্ত (LLM call, 400-1200ms)
এখন মডেল প্রবেশ করে। OpenClaw একটি ফ্রন্টিয়ার LLM-এ একটি একক কল করে (Anthropic Claude, OpenAI GPT, Google Gemini — tenant অনুযায়ী কনফিগারযোগ্য) যেখানে থাকে:
- System prompt = এজেন্টের পার্সোনা + নিয়মাবলী + উপলব্ধ skills।
- History = স্টেজ ২-এ নির্বাচিত টার্নসমূহ।
- User message = বর্তমান টার্নের মেসেজ।
মডেল দুটির একটি উত্তর দেয়:
- চূড়ান্ত উত্তর (গ্রাহকের জন্য সরাসরি টেক্সট)।
- Tool call (নির্দিষ্ট প্যারামিটার সহ একটি নির্দিষ্ট skill এক্সিকিউট করার অনুরোধ)।
"quero marcar pra sábado de manhã" উদাহরণে, মডেল সাধারণত রিটার্ন করে:
{
"tool": "consultar_calendario",
"args": { "date_range": "2026-04-19 06:00 to 12:00" }
}
স্টেজ ৫ — গার্ড-রেইলস সহ এক্সিকিউশন (পরিবর্তনশীল, ~100-500ms)
Skill মডেলে চলে না। এটি আমাদের কোডে চলে, যা:
- প্যারামিটার যাচাই করে (date_range-এর ফরম্যাট সঠিক? টেন্যান্টের নিয়মের মধ্যে আছে?)।
- অনুমতি পরীক্ষা করে (এই এজেন্টের কি এই ক্যালেন্ডার দেখার অধিকার আছে?)।
- কল এক্সিকিউট করে (এই ক্ষেত্রে Google Calendar API)।
- স্ট্রাকচার্ড রেজাল্ট রিটার্ন করে মডেলের কাছে।
এটা কেন গুরুত্বপূর্ণ? কারণ মডেল কখনো ফলাফল বানিয়ে দেয় না। যদি ক্যালেন্ডার [10h, 11h] রিটার্ন করে, ঠিক এটাই পরবর্তী কলে যায়। যদি স্কিল ব্যর্থ হয়, মডেল জানে যে ব্যর্থ হয়েছে। এজেন্টের "বানিয়ে বলার" ঝুঁকি শূন্য যে সকাল ৯টায় সময় আছে যখন আসলে নেই।
যেসব ক্ষেত্রে সংবেদনশীল তথ্য জড়িত (মূল্য, সময়সীমা, ক্লায়েন্টের নাম), পাইপলাইন tool call বাধ্যতামূলক করে — মডেলকে নিজের "জ্ঞান" থেকে উত্তর দিতে দেয় না। এটি বাণিজ্যিক এজেন্টগুলোতে সবচেয়ে সাধারণ হ্যালুসিনেশনের শ্রেণিটিকে সম্পূর্ণ দূর করে।
স্টেজ ৬ — রেসপন্স এবং পার্সিস্টেন্স (~50ms)
স্কিলের ফলাফল হাতে পেয়ে, মডেল দ্বিতীয় কল করে — এবার ক্লায়েন্টের জন্য চূড়ান্ত রেসপন্স তৈরি করতে। যেমন:
"শনিবার সকাল ১০টা এবং ১১টায় সময় আছে। কোনটা পছন্দ করবেন?"
সমান্তরালভাবে, ওয়ার্কার:
- পাঠায় WhatsApp API-এর মাধ্যমে মেসেজ ফেরত।
- পার্সিস্ট করে সম্পূর্ণ টার্ন (user + assistant + tool calls + সময়কাল) D1-এ।
- দীর্ঘমেয়াদী মেমরি আপডেট করে যদি টার্নে নতুন তথ্য তৈরি হয় (যেমন: "ক্লায়েন্ট শনিবার পছন্দ করে")।
- অবজার্ভেবিলিটি ইভেন্ট এমিট করে (লেটেন্সি মেট্রিক, টোকেন খরচ, এস্কেলেশন রেট)।
এই সবকিছু সমান্তরালে চলে। পার্সিস্টেন্স মেসেজ পাঠানোকে ব্লক করে না — ক্লায়েন্ট D1-এর জন্য অপেক্ষা করে না।
হ্যালুসিনেশনের বিরুদ্ধে প্রতিরক্ষা কোথায়
প্রোডাকশনে হ্যালুসিনেট করা এজেন্ট দ্রুত বিশ্বাসযোগ্যতা হারায়। OpenClaw-এর ৪টি প্রতিরক্ষা স্তর আছে:
- বাধ্যতামূলক সত্যের উৎস। ফ্যাক্চুয়াল ডেটা (মূল্য, সময়, নাম) সবসময় স্কিল থেকে আসে, কখনো একা মডেল থেকে নয়।
- সংবেদনশীল ডেটায় দ্বৈত যাচাই। অ্যাপয়েন্টমেন্ট পার্সিস্ট করার আগে ক্লায়েন্টের সাথে নিশ্চিত করা হয়। পেমেন্ট অ্যাক্সেস দেওয়ার আগে নিশ্চিত করা হয়।
- স্পষ্ট নেতিবাচক নিয়ম। প্রতিটি এজেন্টের পার্সোনায় "কখনো X, Y, Z বানিয়ে বলবেন না" অন্তর্ভুক্ত — মডেল মেনে চলে।
- মানুষের কাছে ফলব্যাক। যখন কোনো স্কিল প্রশ্নের উত্তর দিতে পারে না, এজেন্ট বলে
"আমাকে টিমের সাথে চেক করতে দিন"এবং একটি টিকেট খোলে — আন্দাজে বলে না।
গত ৬ মাসে আমরা যে অডিট করেছি (বাস্তব কথোপকথন ম্যানুয়ালি পর্যালোচনা করা হয়েছে), ফ্যাক্চুয়াল হ্যালুসিনেশনের হার টার্নের ০.৩%-এর নিচে ছিল — এবং প্রায় সব ক্ষেত্রেই কনফিগারেশনের কারণে হয়েছিল (টেন্যান্ট প্রাসঙ্গিক স্কিল সক্রিয় করতে ভুলে গিয়েছিল), মডেলের ত্রুটি নয়।
প্রতি কথোপকথনে খরচ
ভালো আর্কিটেকচার অদৃশ্য থাকে যতক্ষণ না আপনি বিল দেখেন। যেহেতু প্রতিটি টার্ন ১-২টি LLM কল + D1 লুকআপ করে, একটি সম্পূর্ণ কথোপকথনের (১০-১৫ টার্ন) সাধারণ খরচ দাঁড়ায়:
Equipe OpenClaw
প্রকাশিত ২৮ মে, ২০২৬
