מ־בוט QQ אל שולחן העבודה של Discourse: תחקיר אמיתי על גבולות הכלים

כללי
1

TL;DR

  • המטרה המרכזית בתקופה הזו לא הייתה “לעשות בוט QQ”, אלא לשפר את יעילות שיתוף-הפעולה מרובה-המשימות ואת איכות שקיעת/הצטברות ההקשר.
  • תוסף ה-QQ כבר השלים סט יכולות ריצה מלא: אמינות, בקרת סיכונים, סלוטים לשיחות, מולטי-מודאליות, פקודות ניהול ועוד — לא “מעביר הודעות” פשוט.
  • הערך של תוסף Discourse הוא להפוך “צ’אט” ל“מיכל משימות”, שמתאים יותר למעקב, לתחקור/רטרוספקטיבה ולהצטברות ידע.
  • בחנתי ברצינות סנכרון דו-כיווני QQ↔Discourse; טכנית זה אפשרי, אבל בשלב הנוכחי ה-ROI לא גבוה, והמורכבות ועלויות התחזוקה גדולות.
  • לכן האסטרטגיה הנוכחית ברורה: Discourse 优先（主工作台） , QQ 入口化（低门槛触达）。
  • התוצר האמיתי של העבודה הזו הוא לא רק פונקציונליות, אלא מתודולוגיה: הפרדה בין ניתוב להצגה, צמצום אחריות הפלטפורמות, ובחירות הנדסיות שמעדיפות ערך.

מבוט QQ לעמדת עבודה ב-Discourse: רטרוספקטיבה אמיתית על “גבולות כלי”

המאמר הזה הוא סיכום-ביניים של התקופה שבה, באקוסיסטם של OpenClaw, פיתחתי תוסף QQ, פיתחתי תוסף Discourse, חשבתי על סנכרון בין קצוות, ולבסוף צמצמתי ביוזמתי את הפתרון. זו לא כתבת יח״צ, אלא תיעוד החלטות הנדסה ומוצר.

1. נקודת ההתחלה: מלכתחילה לא בניתי “בוט QQ”

הבעיה שבאמת רציתי לפתור מעולם לא הייתה “באיזו פלטפורמה לשוחח”, אלא:

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

לשלוש המטרות האלה יש מתח טבעי בתוך אותה מערכת:

  • היתרון של QQ הוא נגישות ומיידיות;
  • היתרון של Discourse הוא מבנה, ריבוי-שרשורים, שקיעה וניהול;
  • היתרון של OpenClaw הוא לחבר ערוצים רבים לאותו Agent ולאותה מערכת שיחות.

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

2. מה תוסף ה-QQ באמת השיג (זה לא רק “אפשר לדבר”)

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

2.1 אמינות הערוץ (בסיס פרודקשן)

  • חיבור OneBot v11 דרך WebSocket ומנגנון התחברות מחדש (נסיגה מעריכית);
  • זיהוי heartbeat/חוסר פעילות, כדי לאתר “חיבורים תקועים”;
  • כשל שליחה מוחזר אוטומטית לתור, ונשלח מחדש לאחר שחיבור מתאושש;
  • הימנעות ממצב שבו health-monitor מזהה בטעות שהערוץ יצא וגורם ללולאת אתחול (הערוץ נשאר תושב עד abort).

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

2.2 אבטחה ובקרת סיכונים (חובה כדי לנחות באמת ב-QQ)

  • requireMention מופעל כברירת מחדל כדי להימנע מהפעלה על כל משפט בקבוצה;
  • רשימת קבוצות מורשות (whitelist), ורשימת משתמשים חסומים (blacklist);
  • adminOnlyChat (רק מנהל יכול להפעיל) + דיבאונס להודעות למי שאינו מנהל;
  • שליחה במקטעים + מרווחי שליחה (להפחתת סיכון מול מנגנוני הסיכון);
  • antiRiskMode שמבצע הימנעות/עקיפה עבור חלק מהתוכן (כגון URL).

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

2.3 הנדסת שיחות (זה הנכס המרכזי של העבודה הזו)

  • יצירת מפתח שיחה תחת ניתוב סטנדרטי (מועבר ל-OpenClaw core routing);
  • סלוטים לשיחות זמניות בקבוצות (כמו /临时、/临时重命名、/临时列表、/临时结束 ועוד);
  • /newsession מבצע איפוס מדויק לסלוט השיחה הנוכחי;
  • שם תצוגה לשיחה (displayName) אחוד לפורמט חדש:
    • qq:<peer>-<YYYYMMDDHHmm>-<title>

המשמעות: אני יכול להריץ במקביל כמה תתי-משימות בתוך אותה קבוצה, בלי למרוח את כל ההקשר לעיסה אחת.

2.4 מולטי-מודאליות וחילוץ מידע

  • ניתוח at、שרשרת תשובות, תמונות, קול, קבצים והודעות מועברות;
  • טיפול בכתובות תמונה URL/base64/file references והזרקת הנחיות;
  • השלמת הקשר של קבצים מצורפים מתוך הודעות תשובה;
  • בצד השליחה: תמיכה בטקסט, תמונות, קול וקבצים עם נתיב fallback;
  • תמיכה בהודעות QQ Channel (Guild).

2.5 תפעוליות

  • פקודות ניהול: /status、/help、/mute、/kick;
  • פקודות יכולת: /models、/model、/newsession、/grok_draw;
  • ויזואליזציה של מצב “עסוק”: שינוי זמני של סיומת כרטיס השם בקבוצה בזמן עיבוד (כגון “输入中”);
  • הודעת ברירת מחדל למקרה של תשובה ריקה, להפחתת אבחון שגוי של “נראה שנתקע”.

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

3. מה תוסף Discourse עשה נכון: להפוך “שיחה” ל“משימה”

הערך של הקו של Discourse ברור מאוד:

  • כניסה מונעת וובהוק (webhook), אסינכרוני מטבעו וניתן למעקב מטבעו;
  • topic כקונטיינר משימה — מבחינה מבנית זה מודל ידידותי לניהול ריבוי משימות;
  • לכל תשובה, לכל עריכה ולכל שאלת המשך יש היסטוריה שניתן לחזור אליה;
  • מאפשר שיתוף פעולה של כמה אנשים ושקיעת ידע — במקום שזרם הצ’אט ישטוף הכול וייעלם.

באיטרציה הזו השלמתי כמה נקודות מפתח:

  • ניתוח כותרת נושא (topic title) וקאשינג; בעת הצורך משיכה של /t/{topicId}.json להשלמה;
  • כלל אחיד לשם תצוגה לשיחה:
    • discourse:<site>-<YYYYMMDDHHmm>-<title>
  • כתיבה בו-זמנית של ConversationLabel ושל ThreadLabel, כדי לשפר את הקריאות בלוח השיחות;
  • סקריפט לשינוי-שם בקבוצות לשיחות ישנות, להאחדת עקביות נתוני עבר.

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

4. למה בחנתי ברצינות סנכרון QQ↔Discourse, ואז החלטתי בינתיים לא לעשות

באמצע בחנתי ברצינות פתרון:

  • QQ ככניסה; לאחר התאמת כללים — העברה אוטומטית ל-Discourse;
  • לאחר ש-Discourse מטפל — דחיפה חזרה ל-QQ;
  • בשני הצדדים רואים את השיחה, כמו “מגשר”.

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

4.1 “אפשר” לא אומר “כדאי”

כדי שסנכרון דו-כיווני יהיה באמת יציב, צריך לכל הפחות לפתור בנוסף:

  • לולאות (A דוחף ל-B, ואז B דוחף חזרה ל-A);
  • דה-דופליקציה (webhook replays/רטט רשת שגורמים למסירה כפולה);
  • עקביות סדר (טיימסטמפים והתנהגות retry בין מערכות);
  • ממשל מיפויים (איך לתחזק לאורך זמן מיפוי בין שיחות QQ לבין topic);
  • אובדן סמנטיקה במדיה בין קצוות (הורדת רמת ביטוי של קבצים/קול מ-QQ בפורום).

אף נקודה פה לא נעלמת באמת עם “כמה שורות glue code”.

4.2 בשלב הנוכחי מה שחסר יותר הוא “יעילות משימות”, לא “עקביות בין כל הערוצים”

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

  • Discourse כבר יכול לשאת את תהליך הליבה;
  • QQ צריך רק להיות כניסה קלה (חברים בלי VPN יכולים לזרוק פנימה דרישות);
  • לעשות סנכרון מורכב כדי ש“יראה יותר שלם” נותן ROI נמוך בטווח הקצר.

4.3 לוותר ביוזמה זו לא כישלון

אני יותר ויותר מזדהה עם עיקרון אחד:

בגרות יכולת הנדסית אינה “להיות מסוגל לעשות יותר”, אלא “לדעת איזו משימה לא עושים עכשיו”.

לכן את רעיון הסנכרון אני משאיר כ“רעיון מעניין”, אבל לא ממשיך לבזבז עליו אנרגיה בשלב הזה.

5. הנכסים ההנדסיים שבאמת שקעו בתקופה הזו

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

5.1 ניסיון ביציבות בצד הערוץ

  • ניהול מחזור חיים של חיבור;
  • אישור שליחה ונסיגה במקרה כשל;
  • heartbeat ושיפוט חיות (liveness);
  • דרך חשיבה על תצפיתיות (observability) במערכות חיבור מתמשך.

5.2 מתודולוגיה של מערכת שיחות

  • הפרדה בין “מפתח ניתוב (routing key)” לבין “שם תצוגה”;
  • ההשפעה הישירה של קריאות שם התצוגה על יעילות התפעול;
  • לאחר האחדת כללי השמות, עלות איתור התקלות יורדת משמעותית.

5.3 הבנת שונות בין פלטפורמות

  • QQ לא מתאים לשאת Markdown מורכב ושיתופי פעולה בשרשרת ארוכה;
  • פורום (Discourse) מתאים באופן טבעי למשימתיות ולשקיעת ידע;
  • אותו Agent לא אומר שכל הערוצים צריכים לשאת אחריות שווה.

5.4 מודעות לממשל קונפיגורציה

  • הגנה מפני שימוש-לרעה/ספאם, whitelist וגבולות מנהל חייבים להיות מקדימה;
  • גרנולריות של מתגים צריכה להיות עדינה (שכבות של פונקציות, הרשאות ומדיניות התראות);
  • התאמה להבדלי סמנטיקה בין קלטי קונפיגורציה של WebUI ושל CLI.

5.5 יכולת קבלת החלטות מוצר

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

6. המיצוב הסופי: QQ ככניסה, Discourse כעמדת עבודה

נכון לעכשיו, אני מגדיר את המיקום של שני הערוצים כך:

  • QQ:

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

  • Discourse:

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

זה לא “איזה יותר מתקדם”, אלא להחזיר כל פלטפורמה למקום שבו היא חזקה.

7. שלוש תזכורות לעצמי בעתיד

  1. אל תבלבל בין “יכולת ערוץ” לבין “ערך מוצר” עצמו.
  2. כשאתה מתחיל לערום מורכבות בשביל תרחישי קצה, שאל קודם: האם זה ניסיון לברוח מהבעיה המרכזית האמיתית.
  3. כל תוסף עשוי להפסיק לקבל תחזוקה, אבל המתודולוגיה ותחושת הגבולות יישארו — וזה החלק הכי שווה.

8. סיכום

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

  • במה כדאי להמשיך להשקיע;
  • מה כדאי להניח בצד זמנית;
  • מהו הנתיב הראשי האמיתי של המערכת.

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

במקום לרדוף אחרי “שלמות בכל הפלטפורמות”, עדיף קודם להעמיק ולייצב את “זרימת המשימות שבאמת חשובה”.

ובשבילי, הנתיב הראשי הזה כרגע הוא: Discourse קודם, ו-QQ ככניסה.