openclaw_qq 2026-03-20 הסבר על שינויי התנהגות ברירת מחדל

openclaw_qq
, , ,
1

openclaw_qq 2026-03-20 הסבר על התאמות התנהגות ברירת מחדל

המוקד בסבב הזה אינו לשנות את אופן העבודה של OpenClaw core, אלא לכוון את ערכי ברירת המחדל ואת אסטרטגיית הפלט של openclaw_qq להיות שמרניים יותר, ומתאימים יותר לתרחישי השימוש בפועל של QQ.

ברמת העיקרון, השינויים בסבב הזה הם בעיקר:

  • התאמת תצורת ברירת המחדל של תוסף QQ.
  • תיקון מספר פרטי מימוש בשכבת תוסף QQ, כדי שאסטרטגיית ברירת המחדל תיושם באמת כפי שמתועד.
  • לא להכריח החלפה של החוויה הישנה; אם אתם מעדיפים את ההתנהגות הקודמת, עדיין אפשר להחזיר אותה ידנית דרך אפשרויות תצורה.

למה צריך להתאים בסבב הזה

לפני כן נבדקו ברצף כמה סוגים של בעיות מעשיות:

  • תגובות ארוכות אמנם כבר עברו ל"העברה ממוזגת" (merged forward), אבל עדיין ממשיכות להתפצל למספר צמתי העברה, וחוויית הקריאה לא טובה.
  • הגבול בין משפטי תהליך לבין גוף טקסט ארוך לא יציב: לפעמים משפט תהליך קצר שהיה אמור להישלח כרגיל לא נשלח, ולפעמים טקסט ארוך סופי מתפצל לכמה הודעות.
  • בצד QQ, הודעות מצוטטות ורמזים לטקסט המקורי בתוך העברה ממוזגת לא נכנסים בצורה יציבה לקונטקסט של המודל.
  • למרות שבתיעוד interruptOnNewMessage כתוב שברירת המחדל היא כבוי, בפועל המימוש היה קרוב ל"ברירת מחדל מופעל", מה שמשפיע על מסלול המשימות של OpenClaw עצמו.

לכן הגישה בסבב הזה אינה שינוי לוגיקה גדול, אלא צמצום התנהגות ברירת המחדל לסט אסטרטגיות שמתאים יותר לתרחיש QQ.

התאמות ערכי ברירת המחדל בסבב זה

1. ברירת מחדל: כיבוי “הודעה חדשה קוטעת תגובה ישנה”

  • interruptOnNewMessage=false

ובמימוש זה גם שונה כך: רק אם אתם מגדירים במפורש ל-true, תגובה מסבב קודם תיקטַע בגלל הודעה חדשה באותו סשן שיחה.

המשמעות היא שבברירת מחדל, הבוט ייטה יותר להשלים את המשימה הנוכחית עד הסוף, ולא יקטע את עצמו רק בגלל שהגיעה עוד הודעה באמצע.

2. ברירת מחדל: יישום לפי הודעת assistant מלאה

  • blockStreaming=true
  • blockStreamingBreak=message_end

המטרה של סט ערכי ברירת המחדל הזה היא:

  • משפטי תהליך קצרים מסוג commentary עדיין יישלחו כרגיל.
  • אבל לא לחזור לפלט מפוצל עוד יותר בסגנון חיתוך לפי מקטעים.
  • commentary / final מיושמים ככל האפשר לפי גבולות הודעה מלאה, מתאים יותר לקריאה בקבוצות QQ.

3. ברירת מחדל: גוף טקסט ארוך מעל 300 תווים עובר ל"העברה ממוזגת" של QQ

  • forwardLongReplyThreshold=300

אסטרטגיית ברירת המחדל עכשיו היא:

  • commentary קצר: נשלח כהודעה רגילה.
  • final_answer ארוך: מעל 300 תווים עובר אוטומטית ל"העברה ממוזגת" של QQ.

כך בקבוצה עדיין רואים משפטי תהליך קצרים, אבל גוף ארוך לא יהפוך להרבה הודעות קטנות ומטרידות.

4. ברירת מחדל: העברה כבר לא מתפצלת לצמתים לפי אורך

  • forwardNodeCharLimit=0

ה-0 כאן אינו כיבוי העברה, אלא מציין:

  • לאחר שמופעלת העברה ממוזגת, לא ממשיכים לפצל באופן מלאכותי לפי “כמה תווים בכל צומת”.
  • תגובה ארוכה מאותו סבב תישאף להתמזג ככל האפשר להעברה אחת.

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

מה חיזקו בשכבת התוסף בסבב הזה

מעבר להתאמות ערכי ברירת המחדל, בסבב הזה נוספו גם כמה תיקונים במימוש בשכבת תוסף QQ, כדי שאסטרטגיית ברירת המחדל לעיל באמת תעבוד:

1. חיזוק קריאת הקונטקסט של reply / forward

כעת בתוך הודעות QQ:

  • הטקסט המקורי של הודעה מצוטטת
  • רמזי טקסט בתוך העברה ממוזגת

ייכנסו בצורה יציבה יותר לבניית הקונטקסט, כך שלמודל קל יותר להבין “את מי אתם מצטטים, ומה תוכן הציטוט”.

2. תגובה ארוכה בסבב אחד כבר לא מתפצלת למספר צמתי העברה בגלל block

במהלך הבדיקה נמצא בעיה מעשית: OpenClaw core במקרים מסוימים מפצל את התשובה הסופית של אותו סבב למספר block-ים ושולח אותם לתוסף. כאשר תוסף QQ לא מצליח לקבל phase יציב, בעבר הוא היה ממשיך לפצל ולשלוח את התוכן הזה.

בסבב הזה נוספה בשכבת תוסף QQ אסטרטגיית איגום שמרנית יותר:

  • רצף של unknown block ייכנס תחילה לאגירה קצרה.
  • משפטי תהליך קצרים יכולים להישלח בנפרד.
  • גוף טקסט ארוך אמיתי ייבחן כמכלול האם לעבור ל"העברה ממוזגת".
  • אם עוברים להעברה, כברירת מחדל לא ממשיכים לפצל לפי אורך צומת.

כך זה מתקרב יותר להתנהגות היעד הבאה:

  1. משפטי תהליך לא ארוכים — נשלחים כהודעה רגילה.
  2. הטקסט הארוך המלא שאחריהם, אם עובר את הסף — נכנס כמכלול ל"העברה ממוזגת" אחת של QQ.
  3. לא ממשיכים לפצל final של אותו סבב לצמתי העברה מרובים או להודעות קטנות בגלל גבולות block פנימיים.

אם אתם רוצים להחזיר את החוויה הקודמת

בסבב הזה לא מוחקים פונקציונליות — רק משנים ערכי ברירת מחדל.

אם אתם מעדיפים את הדרך הישנה האגרסיבית יותר של החלפה/פיצול, אפשר להחזיר ידנית, למשל:

{
  "channels": {
    "qq": {
      "interruptOnNewMessage": true,
      "blockStreamingBreak": "text_end",
      "forwardLongReplyThreshold": 800,
      "forwardNodeCharLimit": 1000
    }
  }
}

כך זה יהיה קרוב יותר לחוויה הישנה:

  • הודעה חדשה יכולה לקטוע תגובה ישנה.
  • גבולות הפלט מפוצלים יותר.
  • טקסט ארוך צריך להיות ארוך יותר כדי לעבור להעברה.
  • צמתי העברה ימשיכו להתפצל לפי אורך.

המאגר והתיעוד סונכרנו

הקוד והתיעוד של סבב זה כבר סונכרנו ל-GitHub:

-提交：47c4a85

גם תיעוד המאגר כבר הוסיף נקודות כניסה:

  • README.md
  • docs/index.md
  • docs/config-reference.md
  • docs/advanced.md

סיכום

הליבה בסבב הזה אינה “לשנות את אופן העבודה של OpenClaw”, אלא לכוון את התנהגות ברירת המחדל של openclaw_qq להיות שמרנית יותר ומתאימה יותר להרגלי האינטראקציה בפועל ב-QQ:

  • ברירת מחדל לא קוטעת.
  • משפטי תהליך נשלחים כרגיל.
  • גוף ארוך מעל הסף עובר אוטומטית להעברה.
  • לאחר העברה, ברירת מחדל לא מפצלת עוד צמתים.
  • קריאת הקונטקסט של reply / forward יציבה יותר.

אם אתם צריכים את החוויה הקודמת, אפשרויות התצורה עדיין נשמרו, ואפשר להחזיר בעצמכם.