איך סוכן AI שיחתי עובד מבפנים

איך סוכן AI שיחתי עובד מבפנים (ארכיטקטורת OpenClaw)

איך סוכן AI שיחתי עובד בפועל, תור אחר תור? הפוסט הזה פותח את הקופסה השחורה של OpenClaw: מהרגע שהודעת הלקוח מגיעה בוואטסאפ ועד הטקסט שהסוכן כותב בחזרה. זה יהיה טכני. שווה את זה אם אתם מחליטים על ארכיטקטורת מוצר, אם אתם הולכים לרכוש פתרון ורוצים להעריך לעומק, או אם אתם פשוט אוהבים לדעת מה קורה מאחורי הקלעים של השיחה.

TL;DR: כל תור עובר 6 שלבים — קליטה, פתרון הקשר, בחירת skills, החלטה על פעולה הבאה, הרצה עם guard-rails, שמירת זיכרון. כל המחזור רץ תוך <2 שניות ב-edge של Cloudflare, ללא שרת קבוע.

---

למה הארכיטקטורה חשובה

סוכן שיחתי שנראה עובד בדמו אבל נשבר בפרודקשן בדרך כלל סובל מאחת מ-4 הבעיות האלה:

1. לטנסי גבוה — הלקוח מחכה 8 שניות לתשובה, השיחה מתה.
2. הזיה לא מבוקרת — הסוכן ממציא מחיר, שעות, מדיניות.
3. הקשר אבוד — הלקוח חוזר אחרי יומיים והסוכן "שוכח" הכל.
4. עלות לא מבוקרת — כל שיחה ארוכה ממלאת את הפרומפט ואתם משלמים הון על טוקנים.

כל ה-4 הן בחירות ארכיטקטורה, לא מגבלות של המודל. OpenClaw נבנה כדי להימנע מכל ה-4 — והדרך להבין זאת היא להסתכל על מחזור של תור.

---

מחזור של תור (6 שלבים)

דמיינו שהלקוח שלח עכשיו את ההודעה "אני רוצה לקבוע לשבת בבוקר". מה קורה בין ה-"received" לבין תשובת הסוכן?

שלב 1 — קליטה (edge worker, <50ms)

ההודעה מוואטסאפ מגיעה דרך webhook של Meta ישירות ל-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 הפניות האחרונות הרלוונטיות).
• זיכרון לטווח ארוך של הלקוח (העדפות, היסטוריית רכישות, הערות).
• מצב הסוכן (פרסונה, skills מופעלים, כללים).

כולם מגיעים מ-D1 (SQLite מבוזר של Cloudflare). D1 מחליף את Postgres/Mongo המסורתיים — אין שרת מסד נתונים לתחזק, גישה תוך מילישניות בודדות מה-worker, multi-tenant לפי tenant_id.

נקודת מפתח: אנחנו לא טוענים את השיחה כולה לתוך ה-prompt. ה-Memory Manager v2 של OpenClaw (מתואר בתיעוד הפנימי שלנו) בוחר רק את הפניות הרלוונטיות לפנייה הנוכחית (N האחרונות + N בעלות רלוונטיות סמנטית גבוהה). זה שומר על עלות טוקנים צפויה גם בשיחות של 100+ פניות.

שלב 3 — בחירת 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 זמין כל הזמן).
• Skills שtenant זה הפעיל (calendar מופיע רק אם ה-tenant ביצע אינטגרציה).

בסוף מתקבלת תת-קבוצה קטנה של skills שמועברת למודל — לא 50 האפשריים, רק 4 שהגיוניים כאן. זה מפחית באופן דרמטי את הסיכוי שהמודל יפעיל skill שגוי.

שלב 4 — החלטה (LLM call, 400-1200ms)

עכשיו המודל נכנס לפעולה. OpenClaw מבצע קריאה יחידה ל-LLM מתקדם (Anthropic Claude, OpenAI GPT, Google Gemini — ניתן להגדרה לפי tenant) עם:

• System prompt = פרסונה של הסוכן + כללים + skills זמינים.
• History = פניות שנבחרו בשלב 2.
• 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" }
}

שלב 5 — הרצה עם guard-rails (משתנה, ~100-500ms)

ה-skill לא רץ במודל. הוא רץ בקוד שלנו, אשר:

1. מאמת פרמטרים (האם ל-date_range יש פורמט נכון? האם הוא בתוך הכללים של ה-tenant?).
2. בודק הרשאה (האם לסוכן הזה יש זכות לשלוח שאילתה ליומן הזה?).
3. מבצע את הקריאה (Google Calendar API במקרה הזה).
4. מחזיר תוצאה מובנית למודל.

למה זה חשוב? כי המודל לעולם לא מפברק את התוצאה. אם היומן מחזיר [10h, 11h], זה בדיוק מה שעובר לקריאה הבאה. אם ה-skill נכשל, המודל יודע שנכשל. אפס סיכון שהסוכן "ימציא" שיש תור ב-9h כשאין.

למקרים שכוללים מידע רגיש (מחיר, זמן אספקה, שם לקוח), ה-pipeline מכריח tool call — לא נותן למודל לענות מה"ידע" שלו עצמו. זה מבטל את סוג ההזיה הנפוץ ביותר בסוכנים מסחריים.

שלב 6 — תגובה ושמירה (~50ms)

עם תוצאת ה-skill ביד, המודל מבצע את הקריאה השנייה — הפעם כדי לגבש את התגובה הסופית ללקוח. לדוגמה:

"יש לי שבת ב-10h וב-11h. מה אתה מעדיף?"

במקביל, ה-worker:

1. שולח את ההודעה חזרה דרך ה-API של WhatsApp.
2. שומר את התור המלא (user + assistant + tool calls + משך) ב-D1.
3. מעדכן את הזיכרון לטווח ארוך אם התור הפיק עובדה חדשה (לדוגמה: "הלקוח מעדיף שבת").
4. פולט אירוע observability (מדד latency, עלות טוקנים, שיעור הסלמה).

כל זה רץ במקביל. השמירה לא חוסמת את שליחת ההודעה — הלקוח לא מחכה ל-D1.

---

איפה ההגנה מפני הזיה

סוכן שמהזה בפרודקשן מאבד אמון מהר. ל-OpenClaw יש 4 קווי הגנה:

1. מקור אמת מאולץ. נתונים עובדתיים (מחיר, שעה, שם) תמיד מגיעים מ-skill, לעולם לא מהמודל לבדו.
2. אימות כפול בנתונים רגישים. קביעת תור מאושרת עם הלקוח לפני שמירה. תשלום מאושר לפני מתן גישה.
3. כללים שליליים מפורשים. הפרסונה של כל סוכן כוללת "לעולם אל תמציא X, Y, Z" — המודל מציית.
4. Fallback לאדם. כשאף skill לא מכסה את השאלה, הסוכן אומר "תן לי לבדוק עם הצוות" ופותח טיקט — לא מנחש.

בביקורות שעשינו ב-6 החודשים האחרונים (שיחות אמיתיות שנבדקו ידנית), שיעור ההזיה העובדתית נשאר מתחת ל-0.3% מהתורות — וכמעט כל המקרים נבעו מתצורה (tenant שכח להפעיל skill רלוונטי), לא שגיאה של המודל.

---

העלות לשיחה

ארכיטקטורה טובה היא בלתי נראית עד שמסתכלים על החשבונית. בהינתן שכל תור מבצע 1-2 קריאות LLM + חיפושים ב-D1, העלות הטיפוסית לשיחה מלאה (10-15 תורות) היא: