מעבדת n8n: תהליך Human in the Loop (על סטרואידים)

תוכן עניינים

בתרגול הכיתה האחרון (Human in the Loop) בנינו מנגנון אישור בסיסי: הסוכן כותב, האדם מאשר או דוחה, והתהליך מסתיים.
 
כעת, בתרגול הבית למתקדמים, נממש את הפוטנציאל האמיתי של אוטומציה היברידית: לולאת המשוב (Feedback Loop).
במקום שדחייה תסיים את התהליך (ותשלח אותנו לעבוד ידנית), היא תפעיל סוכן "מתקן", שייקח את ההערות שלנו, ישכתב את המייל, ויחזיר אותו לאישור מחדש. המעגל הזה ימשך עד שנהיה מרוצים ב-100%.
תהליך זה משלב בפועל את העקרון של Human in the Loop, יחד עם מודל Evaluator-Optimizer, כאשר במקרה שלנו ה Evaluator הוא הגורם האנושי.
 
שימו לב – תרגול זה יוצא מנקודת הנחה שכבר עברתם כברת דרך נכבדת במסע שלכם לאוטומציה עסקית וסוכני Ai על n8n. ההוראות בתרגול מנוסחות בקיצור וללא פירוט יתר, עם הרבה מקום לחקירה אישית, בדיקה ומציאת השדות וההגדרות הנדרשות באופן עצמאי. חלק חשוב מתהליך הלימוד הוא הניסוי, הטעיה וההסתבכות.
 
בכל מקרה של חוסר יכולת התקדמות – נא להיעזר בקבוצת הווצאפ המלווה. כמו״כ בסוף התרגול יינתן קישור לייבוא ה workflow המלא. אנו ממליצים בחום להשתמש בו רק לצורך השוואה ובדיקה מול התהליך שבניתם בכוחות עצמכם.
 
בהצלחה!

פרק 1: הכנת הקרקע למשוב מילולי

בתרגול הכיתה, כפתור ה-Disapprove פשוט עצר את התהליך. כעת עלינו לשנות את הקונפיגורציה כך שהמשתמש יוכל להזין טקסט (Feedback) שיסביר מה לתקן.

 

  1. שדרוג מנגנון האישור (Gmail – Wait)
     

    • חזרו ל-Workflow שבניתם בכיתה.
       
      נתקעתם? צרו Workflow חדש, ובצעו "Import from URL". בשורת הכתובת, הכניסו את הכתובת הבאה:

      https://almaya.ai/wp-content/uploads/2025/10/n8n-On-Boarding-Process-HITL-Simplified.json
    • היכנסו להגדרות ה-Response Type בתוך בלוק ה-Gmail – Wait, והגדירו Custom Form.
    • במצב זה יישלח למנהל האנושי מייל עם לחצן יחיד – שמוביל אותו למילוי טופס, לפי ההגדרה שלנו.
    • בהגדרות הטופס (המשך חלון הגדרות בלוק Gmail – Wait), הגדירו שדה אחד מסוג Radio Button – שמטרתו לתת פגובה חד משמעית של אישור (Approval) או דחיה (Disapproval).
    • השדה השני בטופס יהיה מסוג Text Area ויכיל הערות ספציפיות לתיקון, במקרה שנוסח המייל לא מאושר ע״י המנהל.
    • קריטי! כעת נוסיף שדה "מוסתר" לטופס האישור. שדה מוסתר הוא שדה שלא מופיע כחלק מהטופס לאישור המנהל, אלא הוא מכיל ערך קבוע שאנו מעוניינים לחלחל במהלך ה Data-Flow שלנו. זה חיוני כדי שגם נוסח המייל המקורי יעבור מהסוכן הראשוני להמשך תהליך האישור.
       
      הוסיפו שדה נוסף מסוג Hidden Field וקראו לו בשם Last Email Body. משכו את ערך נתון ה body מהבלוק הקודם, לשדה ה Field Value. נתון זה יחלחל בהמשך צינור הדאטה שלנו ונוכל להתייחס אליו.
    • בדיקת קלט: הריצו פעם אחת את תהליך האישור במייל, כאשר הבלוק Gmail-Wait מסיים את השרשרת, ובדקו את מבנה האובייקט הפלט שמתקבל.
    • עכשיו תוכלו להשתמש בבלוק IF כדי לבדוק את ערך ה-Radio Button שהוספתם לטופס האישור. במידה והוא מציג אישור מנהל – שלחו את הנוסח ישירות ללקוח. ענף זה של התהליך – הסתיים.

פרק 2: הסוכן המתקן (The Optimizer)

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

 
הכנה

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

  1. הוספת סוכן ה Optimizer
     

    • ביציאת ה-False, הוסיפו בלוק AI Agent חדש.
    • מטרת הסוכן הזה היא לקבל שני קלטים:
       

      1. הטקסט המקורי (שהיה בטיוטה הקודמת)
      2. המשוב של המשתמש (מה-Gmail Wait)
    • חברו מודל שפה לבחירתכם לסוכן ה Optimizer.
  2. הגדרת הפרומפט (System Prompt)
     

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

      
      # Role
      You must make corrections to the original email message body according to the user's input.
      Do NOT change anything except the user's input.
      
      # instructions
      - export the corrected message in 'body' field
      
      # Original Message:
      {{ $json.data['Last Email Body'] }}
      
    • חשוב: שימו לב שנוסח המייל המקורי מתקבל דרך פניה לשדה המוסתר "Last Email Body", מהבלוק הקודם, ולא דרך פניה לבלוק הסוכן המקורי בשמו. זה קריטי – כיוון שערכי הקלט יישתנו בכל סיבוב נוסף שהמערכת שלנו תבצע.
  3. אחידות במבנה הנתונים (קריטי!)
     

    • כדי שהלולאה תעבוד, הסוכן הזה חייב להוציא פלט במבנה זהה לחלוטין לסוכן הראשון (זה שיצר את המייל המקורי).
    • ודאו שגם הסוכן הזה מוציא JSON עם השדה: body כמו הסוכן המקורי. שאר השדות (subject ו-email) לא צריכים להופיע כאן. הם אינם הולכים להשתנות בתהליך האישור, ולכן נוכל למשוך אותם מהסוכן המקורי (ולפנות אליו בשמו) בעת שליחת המייל ללקוח.
    • אם המבנה לא יהיה זהה, הבלוק הבא (Wait) לא ידע לקרוא את הנתונים בשני הסיבובים. השתמשו ב Output Parser כפי שלמדנו וודאו שמבנה הפלט עקבי ואחיד.

פרק 3: סגירת הלולאה (Closing the Loop)

זהו החלק הארכיטקטוני החשוב ביותר. אנו מחברים את הסוף להתחלה.

 

  1. ביצוע החיבור המעגלי
     

    • קחו את היציאה (Output) של סוכן ה-Optimizer (שיצרתם בפרק הקודם).
    • משכו את החיבור אחורה, וחברו אותו לכניסה (Input) של בלוק ה-Gmail – Wait.
    • כעת, לבלוק ה-Wait יש שני "הורים": סוכן ה Draft, וסוכן ה Optimizer.
       
      לולאת ה Feedback
  2. פתרון בעיית ה-Variable Scope
     

    • זוהי הנקודה שבה רוב התלמידים נכשלים.
    • גשו לבלוק ה-Gmail – Wait.
    • עד עכשיו, בטח משכתם את המידע (Subject, Message) על ידי בחירה בבלוק הספציפי של ה-AI Agent הראשון (למשל: {{ $('AI Agent 1').item.json.body }}).
    • זה לא יעבוד בלולאה! בסיבוב השני, המידע מגיע מבלוק אחר ("Optimizer Agent").
    • עליכם לשנות את המיפוי בבלוק ה-Wait למיפוי גנרי (Input based):
    • לכן וודאו שוב שהשדה המוסתר Last Email Body נמשך מהבלוק האחרון שמחובר לפני ה Gmail-Wait! והפעם זה בלוק סוכן ה Optimizer.
    • לצורך כך, השתמשו בביטוי הגנרי: {{ $json.output.body }} (או משהו בסגנון… רק לא פניה לבלוק ספציפי בשמו!)
    • ביטוי זה אומר ל-n8n: "לא משנה מי היה הבלוק הקודם (הראשון או ה-Optimizer) – קח את ה-JSON שהוא הביא".
  3. בדיקת הלולאה
     

    • הריצו את התהליך מחדש, ועקבו אחר הודעות האישור שתקבלו למייל.
    • דחו את נוסח המייל כמה פעמים תוך השארת הוראות ספציפיות לתיקון הנוסח. שימו לב להתקדמות הביצוע ובקשות האישור.
    • לאחר אישור הנוסח – ודאו כי המייל מתקבל אצל הלקוח.
  4. הורדת ה-Workflow המלא
     

    כאמור, תרגול זה מיועד לתלמידים מתקדמים שכבר עברו כברת דרך משמעותית ב n8n. במידה ולא הצלחתם להגיע לתהליך הפעיל – תוכלו לייבא אותו ל workflow חדש, להשוות אותו מול הנסיונות שלכם, וללמוד מכך לעתיד.
     
    לצורך כך – צרו Workflow חדש, בתפריט שלוש-הנקודות (למעלה מימין), בחרו Import from URL… והכניסו את הכתובת הבאה:

    https://almaya.ai/wp-content/uploads/2025/10/On-boarding-process-HITL-Hi-Reliability.json


פרק 4: תרגול פתוח – ניהול זיכרון ורשימת תפוצה

הלולאה עובדת! המערכת תציק לכם שוב ושוב עד שתאשרו את המייל. כעת נסו לאתגר את המערכת:

 

  • היסטוריית גרסאות (Google Docs):
    לפני שהסוכן המתקן דורס את הגרסה הקודמת, שמרו את הגרסה המקורית ואת הפידבק שלכם בתוך מסמך Google Doc או שורה ב-Sheets. כך תוכלו לראות את ה"אבולוציה" של המייל.
  • מניעת לולאה אינסופית (Safety):
    הוסיפו מנגנון ספירה (Counter). אם עשינו כבר 3 סבבי תיקונים והמנהל עדיין לא מרוצה – עצרו את התהליך ושלחו התראה ב-Slack "נדרשת התערבות ידנית דחופה", במקום להמשיך לשרוף טוקנים של AI.
    רמז: השתמשו ב-Code Node כדי לקדם משתנה `retry_count` בכל מעבר בלולאה.
  • Context מלא:
    כרגע הסוכן המתקן רואה רק את התיקון האחרון. נסו לגרום לו לראות את כל שרשור התיקונים הקודמים, כדי שלא יחזור על טעויות מהעבר. (זה דורש צבירת ההיסטוריה במשתנה שעובר בלולאה).
  • שיפור עיצוב המייל הסופי:
    לאחר שנוסח המייל הסופי התקבל ואושר – נסו להשתמש בסוכן נוסף שתפקידו רק לעצב את ההודעה ללקוח בפורמט HTML עשיר.

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