arrow_forwardסוכני AI / מקרה בוחן

בניתי עוזר אישי ב-n8n לפני שסוכני AI ידעו לגעת ביומן

זה לא מדריך "איך לבנות סוכן ב-10 דקות". זו מערכת שרצה אצלי בפועל, נבנתה בתקופה שבה אף מודל לא ידע לפתוח את היומן שלי, ורוב מה שהיא עושה הפך מאז לפיצ'ר מובנה. השאלה המעניינת היא מה דווקא לא התייתר.

n8n Telegram Bot LangChain Agent מקרה בוחן

המצב שבו זה נבנה

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

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

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

מה הוא עשה בפועל

calendar_month

הזנת משמרות ובקשות ליומן

הודעה חופשית בטלגרם — "משמרת ראשון 07:00 עד 15:00" — הפכה לאירוע ביומן. בלי טופס, בלי פורמט קבוע, בלי לפתוח אפליקציה.

mark_email_read

סיכום תיבת המייל

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

mic

הודעות קוליות

אפשר היה פשוט להקליט. ההודעה עברה תמלול ואז נכנסה לאותו מסלול כמו טקסט.

psychology

זיכרון שיחה

"תזיז את זה לשעה אחר כך" עבד, כי הסוכן זכר על מה דיברנו בהודעה הקודמת.

הארכיטקטורה

המבנה הוא 29 צמתים ב-n8n. המעניין הוא לא הכמות אלא החלוקה: מסלול קלט שמנרמל קול וטקסט לאותה נקודה, וסוכן יחיד שמחזיק את כל הכלים.

Telegram Webhook
      |
      v
   Switch ----- voice --> Telegram download --> OpenAI Whisper --+
      |                                                          |
      +------ text -----> Edit Fields -------------------------->+
                                                                 |
                                                                 v
                                                      +-------------------+
                                                      |  Jarvis  (agent)  |
                                                      +---------+---------+
                                                                |
        +------------------+------------------+-----------------+
        |                  |                  |                 |
   Gmail send        Calendar read        SerpAPI        Window Buffer
   Gmail get         Calendar create      Wikipedia         Memory
   Gmail delete      Calendar delete      Calculator
        |                  |                  |                 |
        +------------------+------------------+-----------------+
                                 |
                     OpenAI model + Anthropic model
                                 |
                                 v
                        Telegram  (reply)

שלוש החלטות ולמה

למה טלגרם ולא ממשק ייעודיexpand_more

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

למה Switch לפני הסוכן ולא טיפול בקול בתוכוexpand_more

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

למה מחיקה היא כלי נפרד מיצירהexpand_more

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

מה השתנה מאז — ובכנות

רוב מה ש-Jarvis עשה זמין היום מובנה. מודלים מסחריים מתחברים ליומן ולמייל, מתמללים קול, וזוכרים שיחה. אם הייתי מתחיל היום מאפס רק בשביל "תוסיף משמרת ליומן" — לא הייתי בונה את זה. זה לא כישלון של הפרויקט; זה מה שקורה כשתשתית מדביקה פער.

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

מה עדיין שווה לבנות בעצמך

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

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

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

שאלות נפוצות

האם כדאי לבנות סוכן אישי כזה היום?

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

למה שני ספקי מודל באותו סוכן?

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

מה התפקיד של Window Buffer Memory?

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

כמה זה עולה להריץ?

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

מה הסיכון בלתת לסוכן גישה למייל וליומן?

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