openclaw20260213 כבר עם 188k כוכבים, אבל עדיין חדש מדי ויש יותר מדי בעיות; אפילו דחיסת הקשר לא בוצעה כמו שצריך — תיעוד של ניפוי תקלות קשה

AIDO debug
, ,
1

ל-openclaw20260213 כבר יש 188k כוכבים, אבל הוא עדיין חדש מדי ויש יותר מדי בעיות; להפתעתי אפילו דחיסת הקשר (context compression) לא נעשתה כמו שצריך–תיעוד של דיבוג קשה במיוחד

מחבר: סאן ג’ו ליאנגשנג (三局两胜)
תאריך: 2026-02-13

זהו תיעוד מלא של תהליך דיבוג שהצלחתי “ללעוס בכוח” ביומיים האחרונים יחד עם הבוט. את המסקנות אני שם קודם:

  • “תשובה ריקה” לא אומרת שהמודל לא זמין, וגם לא תקלה נקודתית בתוסף QQ。
  • שורש הבעיה הוא שהתנפחות בלתי נשלטת של הקשר השיחה (session context) גרמה להפעלת silent overflow（output=0）。
  • בגרסה הנוכחית של OpenClaw אכן קיימת בעיה בתרחיש הזה של “בלי התראה, בלי התאוששות אוטומטית”（כבר יש issue/PR רשמיים）。

א、תסמיני התקלה（המקרה האמיתי שפגשתי）

אצלי זה התבטא כך:

  1. בקבוצת QQ הבוט פתאום התחיל “להחזיר תשובות ריקות”（נראה כאילו לא ענה, או שרק נרשמה פנייה של assistant אבל התוכן ריק）。
  2. במקביל, ב-TG זה נראה תקין, מה שיצר אשליה של “אולי התוסף של QQ התקלקל”。
  3. ב-WebUI רואים שהשיחה ממשיכה לכתוב לוגים, אבל בצד המשתמש אין טקסט תקף。

בהתחלה הבדיקה הייתה מאוד כאוטית, כי באותו חלון זמן התערבבו גם:

  • בעיות בשרשרת שליחת קבצים（NapCat rich media）
  • לוגיקת טריגר מילים/תיוג (艾特)
  • הגדרות מנהלים ורשימת חסימה

הבעיות האלה מפריעות זו לזו בתצפית, ולכן לא קל לתפוס מיד את שורש ה“תשובה הריקה”。

ב、מסלול הבדיקה（לפי סדר זמנים）

1) קודם לוודא שזה לא כיבוי מלא של ה-API

  • קודם אימתתי שה-API במעלה הזרם（newapi/cpa）זמין מלקוחות אחרים。
  • אחר כך בדקתי את לוגי השיחה המקומיים של OpenClaw, וגיליתי שלא מדובר בכשל בקשה, אלא בתבנית רישום אופיינית:
    • usage.input עצום（סדר גודל 200k~300k）
    • usage.output = 0
    • content = []

השלב הזה קריטי: זה אומר שזה לא “לא מצליח לשלוח החוצה”, אלא “בצד המודל הוחזרה יציאה ריקה”。

2) להשוות את נפח השיחה בין QQ ל-TG

משכתי את קובצי השיחה המרכזיים ובדקתי:

  • שיחת קבוצת QQ：cb77ecdc-6d64-489f-8aa1-d63a92d67ce7.jsonl
  • שיחת פרט TG：9c1c29b4-b309-4b71-a1bd-5a7fd8541679.jsonl

התוצאה הייתה מאוד ברורה:

  • היסטוריית השיחה ב-QQ ענקית, ובכמה מקומות הופיע input≈260k~282k。
  • באותו טווח זמן, ב-TG היה בערך input≈36k~38k והתגובות היו תקינות。

3) לאתר במדויק “איזו פעם התנפחה בפתאומיות”

בשיחת קבוצת QQ, נקודת המפנה של ההתנפחות התאימה למשימת “חיפוש” אחת:

  • נכתבו ברצף כמה toolResult ארוכים במיוחד（SearchResults）
  • אורך של רשומה בודדת היה עשרות KB（למשל 48k / 38k / 24k）
  • לאחר מכן ה-input tokens קפצו מיד ל-282k, והופיעו תשובות ריקות רצופות

כלומר, זה לא שמשפט צ’אט רגיל של משתמש “פוצץ” את ההקשר, אלא שתוצאות כלי (tool results) נכתבו לשיחה בשלמותן, ודחפו שיחה שכבר הייתה גדולה מעבר לנקודת הסף。

4) לוודא “האם חיפוש ב-TG נכנס להקשר”

עשיתי השוואה מכוונת:

  • גם ב-TG נכתב toolResult（וגם שם זה נכנס להקשר）
  • אבל בסיס השיחה ב-TG קטן יותר, אז זה לא התפוצץ מיד

השלב הזה שבר את הטעות הנפוצה:

  • לא “ב-TG זה לא נכנס להקשר ורק ב-QQ כן”
  • אלא “בשניהם זה נכנס; מי שמגיע ראשון לתקרה—מתפוצץ ראשון”

5) ניסוי כפוי（להוכיח שזה לא דמיון）

עשיתי שני סבבי ניסויים:

  • קודם שיניתי את היעד של השיחה（TG מצביע לשיחת QQ）
  • ואז ניסוי דריסת קבצים（העתקתי את תוכן שיחת ה-QQ הענקית לקובץ השיחה של TG）

בסוף הוכח: כל עוד נותנים ל-TG “לאכול” את אותה היסטוריה ענקית—גם שם מתקבלות תשובות ריקות. זה חיזק עוד יותר את שורש הבעיה。

ג、מסקנת שורש הבעיה

אפשר לסכם את השורש בשלושה משפטים:

  1. היסטוריית השיחה גדולה מדי（במיוחד כשהיא מכילה הרבה toolResult/תוכן חיפוש גולמי）。
  2. כשהבקשה מגיעה/עוברת את חלון ההקשר האפקטיבי של המודל, מתקבל stopReason=length + output=0。
  3. ב-OpenClaw הנוכחי, אסטרטגיית ההתאוששות בענף ה“silent overflow” הזה אינה מספקת; בצד המשתמש זה נראה כמו “הבוט מת” ומחזיר תשובות ריקות。

ד、למה התחושה מהבעיה כל כך גרועה

כי יש לה שלוש נקודות “לא אינטואיטיביות”:

  • זה לא שגיאה מפורשת：במקרים רבים לא נזרקת שגיאה ברורה, אלא “נראה שהכול הסתיים בהצלחה אבל בלי תוכן”。
  • זה לא משתחזר מיד：לרוב זה קורה פתאום אחרי הצטברות של שיחה ארוכה。
  • זה לא תלוי פלטפורמה אחת：QQ/TG עלולים להיפגע; ההבדל הוא רק מי מגיע קודם לנפח קריטי。

ה、פתרון זמני לעצירת דימום（פרקטי）

  1. כשמופיעה תשובה ריקה—קודם לעשות /newsession או לעבור למפתח שיחה חדש, ולא לנסות “לשוחח בכוח” בתוך שיחה שכבר התנפחה.
  2. להפחית הכנסת טקסט כלי ארוך למסד/שיחה, במיוחד תוצאות חיפוש וגוף מלא של דפי אינטרנט.
  3. להוסיף “אזהרת עומס הקשר” בשכבת התוסף（למשל אם input עובר סף—להציע לפתוח שיחה מחדש）。
  4. בסביבת קבוצות מומלץ להשתמש ב“קבוצת בדיקה קטנה（קבוצת שני אנשים）” לתצפית תפעולית, כדי לאמת מהר את מצב הבוט.

ו、מצב רשמי: כבר יש Issue/PR, אבל זה עדיין בתיקון

1) issue רשמי（בעיה דומה）

2) PR תיקון תואם（הרעיון המרכזי）

הרעיון המרכזי ב-PR הזה הוא:

  • לזהות את הענף של “silent overflow”
  • להכניס אותו ל-overflow recovery（להפעיל compaction/retry），במקום להתייחס אליו כהשלמה תקינה

לדעתי הכיוון הזה נכון, ובוודאי אמין יותר מ“המשתמש ימחק ידנית קובץ שיחה”。

ז、שינויים נוספים שעשיתי（בצד התוסף）

במהלך הדיבוג הזה, יישמתי גם סט תיקונים תומכים（כדי שלא יתערבבו בעיות אחרות）:

  • תיקון בידוד מפתח שיחה בין QQ פרט/קבוצה, כדי למנוע “חוטים מצטלבים” בין ערוצים.
  • תיקון /newsession מ“פקודה למראית עין” ל“ניקוי שיחה אמיתי”.
  • הוספת הודעת גיבוי במקרה של תשובה ריקה, כדי שהמשתמש לא יחווה ניתוק מוחלט.
  • תיקון הצטברות כפולה של סיומת עסוק（למנוע 昵称(输入中)(输入中)）。

אבל חשוב להדגיש: אלו רק משפרים את החוויה; ה“silent overflow” של הקשר ענק עדיין דורש טיפול בשכבת הליבה。

ח、המלצות למי שיבוא אחר כך

אם גם אצלך “הלוגים נראים רצים, אבל יש רק תשובות ריקות”:

  1. קודם לבדוק usage.input/output של ה-session הרלוונטי.
  2. אם רואים output=0 ו-input עצום—לחשוד קודם כל ב-overflow של ההקשר.
  3. לפתוח מיד שיחה חדשה כדי לאמת, ולא לנסות שוב ושוב בשיחה הישנה.
  4. לבדוק האם כותבים toolResult גדול（חיפוש/דפי אינטרנט）לשיחה בלי קיצוץ.
  5. לעקוב אחרי ההתקדמות של המיזוג של #14064 / #14157。

זו באמת הייתה חוויית דיבוג “קשה מאוד אבל שווה מאוד”.
OpenClaw חזק, אבל הוא גם עדיין חדש; להשתמש תוך כדי תיקון זה המצב הרגיל.
מקווה שהתיעוד הזה יעזור לאחרים לחסוך סיבובים מיותרים.

— סאן ג’ו ליאנגשנג (三局两胜)