یک عامل هوش مصنوعی مکالمه‌ای از درون چگونه کار می‌کند

چگونه یک عامل هوش مصنوعی مکالمه‌ای از درون کار می‌کند (معماری OpenClaw)

چگونه یک عامل هوش مصنوعی مکالمه‌ای در عمل، نوبت به نوبت کار می‌کند؟ این پست جعبه سیاه OpenClaw را باز می‌کند: از لحظه‌ای که پیام مشتری در واتساپ می‌رسد تا متنی که عامل در پاسخ می‌نویسد. فنی خواهد بود. ارزشش را دارد اگر شما تصمیم‌گیرنده معماری محصول هستید، اگر قصد خرید یک راه‌حل را دارید و می‌خواهید عمق آن را ارزیابی کنید، یا اگر علاقه‌مندید بدانید پشت مکالمه چه اتفاقی می‌افتد.

خلاصه: هر نوبت از ۶ مرحله عبور می‌کند — دریافت، حل زمینه، انتخاب مهارت‌ها، تصمیم‌گیری اقدام بعدی، اجرا با حفاظ‌ها، ذخیره حافظه. کل چرخه در کمتر از ۲ ثانیه در edge کلادفلر اجرا می‌شود، بدون سرور ثابت.

---

چرا معماری اهمیت دارد

عامل مکالمه‌ای که در دمو به نظر کار می‌کند اما در تولید خراب می‌شود، معمولاً یکی از این ۴ مشکل را دارد:

1. تأخیر بالا — مشتری ۸ ثانیه منتظر پاسخ می‌ماند، مکالمه می‌میرد.
2. توهم کنترل‌نشده — عامل قیمت، ساعت، سیاست جعلی اختراع می‌کند.
3. از دست رفتن زمینه — مشتری بعد از ۲ روز برمی‌گردد و عامل همه چیز را «فراموش می‌کند».
4. هزینه کنترل‌نشده — هر مکالمه طولانی پرامپت را پر می‌کند و شما هزینه هنگفتی بابت توکن می‌پردازید.

هر ۴ مورد انتخاب‌های معماری هستند، نه محدودیت‌های مدل. OpenClaw برای اجتناب از هر ۴ مورد ساخته شده — و راه درک آن، نگاه کردن به چرخه یک نوبت است.

---

چرخه یک نوبت (۶ مرحله)

تصور کنید مشتری همین الان پیام "quero marcar pra sábado de manhã" را فرستاده است. بین «دریافت شد» و پاسخ عامل چه اتفاقی می‌افتد؟

مرحله ۱ — دریافت (edge worker، کمتر از ۵۰ میلی‌ثانیه)

پیام واتساپ از طریق وب‌هوک Meta مستقیماً به یک Cloudflare Worker در نزدیک‌ترین نقطه حضور (PoP) جغرافیایی می‌رسد. در برزیل، این یعنی سائوپائولو یا ریو، با تأخیر شبکه کمتر از ۲۰ میلی‌ثانیه.

Worker سه کار انجام می‌دهد:

1. اعتبارسنجی امضای وب‌هوک (HMAC در مقابل رمز WABA).
2. شناسایی tenant بر اساس شماره تلفن گیرنده (چند-مستأجری بر اساس to_number).
3. نرمال‌سازی پی‌لود — صوت به رونوشت تبدیل می‌شود، تصویر به توصیف، موقعیت مکانی به {lat,lng}، و متن همان‌طور که هست باقی می‌ماند.

در پایان مرحله ۱ شما یک شیء {tenant_id, conversation_id, user_message} آماده برای مرحله بعد دارید.

مرحله ۲ — حل زمینه (D1 + KV، حدود ۸۰ میلی‌ثانیه)

عامل قبل از تصمیم‌گیری به ۳ قطعه زمینه نیاز دارد:

• تاریخچه اخیر مکالمه (آخرین N نوبت مرتبط).
• حافظه بلندمدت مشتری (ترجیحات، تاریخچه خرید، یادداشت‌ها).
• وضعیت ایجنت (پرسونا، مهارت‌های فعال‌شده، قوانین).

همه اینها از D1 (SQLite توزیع‌شده Cloudflare) می‌آیند. D1 جایگزین Postgres/Mongo سنتی می‌شود — بدون نیاز به نگهداری سرور پایگاه داده، دسترسی در چند میلی‌ثانیه از worker، چند-مستأجری با tenant_id.

نکته کلیدی: ما کل مکالمه را در prompt بارگذاری نمی‌کنیم. Memory Manager v2 در OpenClaw (که در مستندات داخلی ما توضیح داده شده) فقط نوبت‌های مرتبط با نوبت فعلی را انتخاب می‌کند (آخرین N + N با ارتباط معنایی بالا). این کار هزینه توکن را حتی در مکالمات بیش از ۱۰۰ نوبت، قابل پیش‌بینی نگه می‌دارد.

مرحله ۳ — انتخاب مهارت‌ها (policy engine، حدود ۲۰ میلی‌ثانیه)

هر ایجنت مجموعه‌ای از مهارت‌های در دسترس دارد — توابعی که می‌تواند فراخوانی کند. مثال‌ها: consultar_calendario، criar_evento، gerar_link_pagamento، consultar_pedido، chamar_humano.

با توجه به پیام "quero marcar pra sábado de manhã"، policy engine فیلتر می‌کند:

• مهارت‌های سازگار با نیت شناسایی‌شده (نوبت‌دهی).
• مهارت‌های مجاز برای این فاز مکالمه (همه مهارت‌ها همیشه در دسترس نیستند).
• مهارت‌هایی که این مستأجر فعال کرده است (تقویم فقط در صورتی ظاهر می‌شود که مستأجر آن را یکپارچه‌سازی کرده باشد).

در نهایت شما زیرمجموعه کوچکی از مهارت‌ها دارید که به مدل ارسال می‌شود — نه ۵۰ مهارت ممکن، فقط ۴ مهارتی که اینجا معنا دارند. این کار به‌شدت احتمال فراخوانی اشتباه مهارت توسط مدل را کاهش می‌دهد.

مرحله ۴ — تصمیم‌گیری (فراخوانی LLM، ۴۰۰ تا ۱۲۰۰ میلی‌ثانیه)

حالا مدل وارد می‌شود. OpenClaw یک فراخوانی واحد به یک LLM پیشرو (Anthropic Claude، OpenAI GPT، Google Gemini — قابل تنظیم برای هر مستأجر) انجام می‌دهد با:

• System prompt = پرسونای ایجنت + قوانین + مهارت‌های در دسترس.
• History = نوبت‌های انتخاب‌شده در مرحله ۲.
• 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" }
}

مرحله ۵ — اجرا با حفاظ‌ها (متغیر، حدود ۱۰۰ تا ۵۰۰ میلی‌ثانیه)

مهارت در مدل اجرا نمی‌شود. در کد ما اجرا می‌شود، که:

1. اعتبارسنجی پارامترها (آیا date_range فرمت صحیحی دارد؟ آیا در چارچوب قوانین tenant قرار دارد؟).
2. بررسی دسترسی (آیا این ایجنت حق مشاهده این تقویم را دارد؟).
3. اجرای فراخوانی (در این مورد Google Calendar API).
4. بازگرداندن نتیجه ساختاریافته به مدل.

چرا این مهم است؟ چون مدل هرگز نتیجه را جعل نمی‌کند. اگر تقویم [10h, 11h] برگرداند، دقیقاً همین مقدار به فراخوانی بعدی ارسال می‌شود. اگر skill با خطا مواجه شود، مدل می‌داند که خطا رخ داده است. ریسک صفر برای اینکه ایجنت «اختراع کند» که ساعت ۹ وقت خالی دارد در حالی که ندارد.

برای مواردی که شامل اطلاعات حساس هستند (قیمت، مهلت، نام مشتری)، پایپلاین tool call را اجباری می‌کند — اجازه نمی‌دهد مدل از «دانش» خودش پاسخ دهد. این کار رایج‌ترین دسته توهم در ایجنت‌های تجاری را حذف می‌کند.

مرحله ۶ — پاسخ و ذخیره‌سازی (~50ms)

با داشتن نتیجه skill، مدل فراخوانی دوم را انجام می‌دهد — این بار برای تشکیل پاسخ نهایی به مشتری. مثال:

"شنبه ساعت ۱۰ و ۱۱ وقت دارم. کدوم رو ترجیح میدید؟"

به صورت همزمان، worker:

1. ارسال پیام بازگشتی از طریق API واتساپ.
2. ذخیره‌سازی نوبت کامل (user + assistant + tool calls + مدت زمان) در D1.
3. به‌روزرسانی حافظه بلندمدت در صورتی که نوبت، واقعیت جدیدی تولید کرده باشد (مثلاً: "مشتری شنبه را ترجیح می‌دهد").
4. ارسال رویداد مشاهده‌پذیری (متریک تأخیر، هزینه توکن، نرخ ارجاع به انسان).

همه اینها به صورت موازی اجرا می‌شوند. ذخیره‌سازی مانع ارسال پیام نمی‌شود — مشتری منتظر D1 نمی‌ماند.

---

خط دفاعی در برابر توهم کجاست

ایجنتی که در محیط تولید دچار توهم شود، به سرعت اعتماد را از دست می‌دهد. OpenClaw دارای ۴ خط دفاعی است:

1. منبع حقیقت اجباری. داده‌های واقعی (قیمت، ساعت، نام) همیشه از skill می‌آیند، هرگز از مدل به تنهایی.
2. تأیید مضاعف در داده‌های حساس. نوبت‌دهی قبل از ذخیره‌سازی با مشتری تأیید می‌شود. پرداخت قبل از اعطای دسترسی تأیید می‌شود.
3. قوانین منفی صریح. پرسونای هر ایجنت شامل "هرگز X، Y، Z را اختراع نکن" است — مدل اطاعت می‌کند.
4. بازگشت به انسان. وقتی هیچ skill‌ای پاسخگوی سؤال نیست، ایجنت می‌گوید "بذارید با تیم چک کنم" و یک تیکت باز می‌کند — حدس نمی‌زند.

در ممیزی‌هایی که طی ۶ ماه گذشته انجام دادیم (مکالمات واقعی که به صورت دستی بازبینی شدند)، نرخ توهم واقعی زیر ۰.۳٪ از نوبت‌ها بود — و تقریباً تمام موارد به دلیل پیکربندی بود (tenant فراموش کرده بود skill مربوطه را فعال کند)، نه خطای مدل.

---

هزینه هر مکالمه

معماری خوب تا زمانی که صورت‌حساب را نگاه نکنید نامرئی است. با توجه به اینکه هر نوبت ۱-۲ فراخوانی LLM + جستجو در D1 انجام می‌دهد، هزینه معمول برای هر مکالمه کامل (۱۰-۱۵ نوبت) برابر است با: