כיצד סוכן AI שיחתי עובד מבפנים
6 שלבי תור שיחה ב-OpenClaw — עם זמן אחזור אמיתי, עלות לשיחה ו-4 קווי הגנה נגד הזיות.
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: כל תור עובר 6 שלבים — ingest, פתרון הקשר, בחירת skills, החלטה על הפעולה הבאה, ביצוע עם guard-rails, שמירת זיכרון. כל המחזור רץ ב-<2 שניות ב-edge של Cloudflare, ללא שרת קבוע.
למה הארכיטקטורה חשובה
סוכן שיחתי שנראה עובד בדמו אבל נשבר בפרודקשן בדרך כלל יש לו אחת מ-4 הבעיות הללו:
- זמן אחזור גבוה — הלקוח מחכה 8 שניות לתשובה, השיחה מתה.
- הזיות לא מבוקרות — הסוכן ממציא מחיר, שעה, מדיניות.
- הקשר אבוד — הלקוח חוזר אחרי יומיים והסוכן "שוכח" הכל.
- עלות לא מבוקרת — כל שיחה ארוכה ממלאת את ה-prompt ואתה משלם הון ב-token.
כל 4 הן בחירות ארכיטקטורה, לא מגבלות של המודל. ה-OpenClaw נבנה כדי למנוע את כל 4 — והדרך להבין היא להסתכל על מחזור של תור.
מחזור של תור (6 שלבים)
דמיין שהלקוח בדיוק שלח את ההודעה "רוצה לקבוע לשבת בבוקר". מה קורה בין ה-"received" לתשובה של הסוכן?
שלב 1 — Ingest (edge worker, <50ms)
ההודעה מ-WhatsApp מגיעה דרך webhook של Meta ישירות ל-Cloudflare Worker בנקודת הנוכחות (PoP) הקרובה ביותר גיאוגרפית. בברזיל, זה אומר סאו פאולו או ריו, זמן אחזור רשת < 20ms.
ה-worker עושה שלושה דברים:
- מאמת את החתימה של ה-webhook (HMAC מול סוד ה-WABA).
- מזהה את ה-tenant לפי מספר הטלפון של המקבל (multi-tenant לפי
to_number). - מנרמל את ה-payload — אודיו הופך לתמלול, תמונה הופכת לתיאור, מיקום הופך ל-
{lat,lng}, טקסט נשאר כמו שהוא.
בסוף שלב 1 יש לך אובייקט {tenant_id, conversation_id, user_message} מוכן לשלב הבא.
שלב 2 — פתרון הקשר (D1 + KV, ~80ms)
הסוכן צריך 3 חלקי הקשר לפני שהוא מחליט:
- היסטוריה אחרונה של השיחה (N תורות אחרונים רלוונטיים).
- זיכרון לטווח ארוך של הלקוח (העדפות, היסטוריית רכישה, הערות).
- מצב הסוכן (פרסונה, כישורים מופעלים, כללים).
כולם מגיעים מ-D1 (SQLite מבוזר של Cloudflare). D1 מחליף Postgres/Mongo מסורתי — ללא שרת מסד נתונים לתחזוקה, גישה תוך מילישניות ספורות מה-worker, רב-שוכרים לפי tenant_id.
נקודת מפתח: אנחנו לא טוענים את כל השיחה ב-prompt. ה-Memory Manager v2 של OpenClaw (המתואר בתיעוד הפנימי שלנו) בוחר רק את התורות הרלוונטיים לתור הנוכחי (N אחרונים + N בעלי רלוונטיות סמנטית גבוהה). זה שומר על עלות ה-token צפויה גם בשיחות של 100+ תורות.
שלב 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 call, 400-1200ms)
עכשיו המודל נכנס. ה-OpenClaw מבצע קריאה יחידה ל-LLM מתקדם (Anthropic Claude, OpenAI GPT, Google Gemini — ניתן להגדרה לפי שוכר) עם:
- System prompt = פרסונה של הסוכן + כללים + כישורים זמינים.
- 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 — הפעלה עם מגבלות (משתנה, ~100-500ms)
הכישור לא רץ במודל. הוא רץ בקוד שלנו, ש:
- מאמת פרמטרים (האם date_range בפורמט נכון? האם הוא בתוך הכללים של הדייר?).
- בודק הרשאה (האם לסוכן הזה יש זכות לשאול את היומן הזה?).
- מבצע את הקריאה (Google Calendar API במקרה הזה).
- מחזיר תוצאה מובנית למודל.
למה זה חשוב? כי המודל אף פעם לא ממציא את התוצאה. אם היומן מחזיר [10h, 11h], זה בדיוק מה שעובר לקריאה הבאה. אם המיומנות נכשלת, המודל יודע שהיא נכשלה. אפס סיכון שהסוכן "ימציא" שיש שעה ב-9 כשאין.
למקרים שכוללים מידע רגיש (מחיר, מועד, שם לקוח), הצינור כופה tool call — לא נותן למודל לענות מה"ידע" שלו עצמו. זה מבטל את סוג ההזיה הנפוץ ביותר בסוכנים מסחריים.
שלב 6 — תשובה והתמדה (~50ms)
עם תוצאת המיומנות בידיים, המודל עושה את הקריאה השנייה — עכשיו כדי ליצור את התשובה הסופית ללקוח. לדוגמה:
"יש לי שבת ב-10 וב-11. מה אתה מעדיף?"
במקביל, ה-worker:
- שולח את ההודעה בחזרה דרך ה-API של WhatsApp.
- משמר את התור המלא (user + assistant + tool calls + משך זמן) ב-D1.
- מעדכן את הזיכרון לטווח ארוך אם התור יצר עובדה חדשה (לדוגמה: "לקוח מעדיף שבת").
- פולט אירוע של ניטור (מדד זמן השהיה, עלות טוקן, שיעור הסלמה).
כל זה רץ במקביל. ההתמדה לא חוסמת את שליחת ההודעה — הלקוח לא מחכה ל-D1.
איפה ההגנה מפני הזיות
סוכן שמזה בייצור מאבד אמון מהר. ל-OpenClaw יש 4 קווי הגנה:
- מקור אמת כפוי. נתונים עובדתיים (מחיר, שעה, שם) תמיד מגיעים ממיומנות, אף פעם לא מהמודל לבד.
- אימות כפול בנתונים רגישים. תיאום מאושר עם הלקוח לפני השמירה. תשלום מאושר לפני שחרור גישה.
- כללים שליליים מפורשים. פרסונה של כל סוכן כוללת "לעולם אל תמציא X, Y, Z" — המודל מציית.
- גיבוי לאנושי. כשאף מיומנות לא מכסה את השאלה, הסוכן אומר
"תן לי לבדוק עם הצוות"ופותח כרטיס — לא מנחש.
בביקורות שערכנו ב-6 החודשים האחרונים (שיחות אמיתיות שנבדקו ידנית), שיעור ההזיות העובדתיות היה מתחת ל-0.3% מהתורות — וכמעט כל המקרים היו בגלל תצורה (דייר שכח להפעיל מיומנות רלוונטית), לא שגיאת מודל.
העלות לשיחה
ארכיטקטורה טובה היא בלתי נראית עד שאתה מסתכל על החשבונית. בהתחשב בכך שכל תור עושה 1-2 קריאות LLM + חיפושים ב-D1, העלות הטיפוסית לשיחה מלאה (10-15 תורות) היא:
Equipe OpenClaw
פורסם ב- 1 ביוני 2026
