בניתי עם קלוד קוד אייג’נט שמתארח על AgentCore ומחובר לבוט טלגרם מקומי. יש לו זיכרון, CloudWatch, X-ray tracing, כלי חיפוש, שליחת מיילים וביצוע משימות מתוזמנות.

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

Event Delivery Patterns

כשמערכת A צריכה לדעת שמשהו קרה במערכת B, איך היא יודעת?

יש כמה שיטות לקבל עדכונים בין מערכות (event delivery):

  • Polling - לשאול כל הזמן “יש משהו חדש?” - לא יעיל
  • Long polling - להחזיק את הבקשה פתוחה עד שיש תשובה - קצת פחות בזבזני
  • Webhook - צד אחד מודיע כשיש משהו - יעיל, חד כיווני
  • WebSocket - קו פתוח - יעיל, דו כיווני
  • Server-Sent Events (SSE) - מהשרת ללקוח בלבד (למשל feed של חדשות)
  • Message Queues - תקשורת בין שירותים דרך תור: שירות A שם הודעה בתור, שירות B מושך כשהוא מוכן. טוב לעיבוד א-סינכרוני.
  • gRPC streaming - תקשורת דו-כיוונית מעל HTTP/2, פופולרי בין microservices.

הנפוצות ביותר לאפליקציות web הן Webhook, WebSocket, ו-SSE.

העמקה: מה ההבדל בין Webhook ל-WebSocket?

WebSocket: חיבור פתוח דו כיווני

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

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

דוגמה נוספת: Slack - ההודעות מופיעות מיד בלי לרענן. השרת “דוחף” הודעות חדשות דרך החיבור הפתוח.

WebSocket דורש שרת שרץ כל הזמן כי מישהו צריך “להחזיק את הקו פתוח” ולזכור מי מחובר. זה stateful: יש זיכרון בין בקשות. WebSocket זוכר “יש לי 50 משתמשים מחוברים עכשיו”.

Webhook: “דפיקה בדלת” חד-פעמית

בקשת HTTP POST חד פעמית: כמו SMS או דואר, מישהו שולח לך הודעה, אין חיבור ביניכם, הוא לא יודע אם קראת.

דוגמה: GitHub webhook - כשעושים push לריפו, GitHub שולח POST request לכתובת שהגדרת. הוא שולח את ההודעה ומסיים - לא מחכה לתשובה, לא יודע מה עשית איתה.

דוגמה נוספת: Stripe payment - כשתשלום מצליח, Stripe שולח POST לשרת שלך עם פרטי העסקה.

Webhooks הם stateless: כל בקשה עומדת בפני עצמה. אם צריך זיכרון, שומרים אותו במקום אחר (database, AgentCore memory, וכו’).

לסיכום:

  • Webhook = “תתקשר אליי כשיש חדש”
  • WebSocket = “נשאר על הקו ביחד”

לבוט טלגרם, webhook מתאים - שולחים POST כשמישהו כותב לבוט, Lambda מתעוררת, מטפלת, וחוזרת לישון.

למה Webhook מתאים לבוט טלגרם בענן?

בוט טלגרם לא צריך לשלוח הודעות מיוזמתו כל הזמן - הוא רק מגיב למשתמשים. אז למה לשלם על שרת שרץ 24/7 ומחכה? עדיף לתת לטלגרם “להעיר” את ה-Lambda רק כשצריך.

ההבדל המרכזי בפרקטיקה:

עם WebSocket (ג’ימייל): החיבור תמיד פתוח, אז אם מישהו שולח מייל, רואים את ההתראה מיד. השרת של גוגל מחזיק מיליוני חיבורים פתוחים.

עם Webhook (הבוט של טלגרם): טלגרם “דופק בדלת” רק כשיש הודעה חדשה. ה-Lambda יכולה לישון בינתיים ולא לעלות כסף.

דוגמה: אייג’נט שמתארח על AgentCore ומחובר לבוט טלגרם

איך זה עובד:

  1. המשתמש פונה לבוט בטלגרם
  2. הבקשה עוברת דרך API Gateway ומגיעה ל-Lambda
  3. מ-Lambda לאייג’נט שרץ על AgentCore
  4. מהאייג’נט בחזרה ל-Lambda ולטלגרם

מושגי מפתח:

Lambda - פונקציה בענן: קוד שרץ רק כשקוראים לו, בלי לנהל שרת.

המודל המסורתי: יש שרת (EC2/VPS) שרץ 24/7. גם אם אף אחד לא משתמש בו בשעה 3 בלילה, הוא דולק ומישהו משלם. עלות: ~$10-30/חודש גם אם הבוט לא בשימוש.

המודל של Lambda: הקוד “ישן” איפשהו ב-AWS. כשמגיעה בקשה (HTTP, טריגר מ-EventBridge, הודעה מטלגרם) - AWS “מעירה” את הקוד, מריצה אותו, ומחזירה תשובה. משלמים רק על זמן הריצה בפועל. עלות: אגורות בודדות אם השימוש נמוך.

API Gateway - שומר סף בכניסה לענן. כל בקשה מבחוץ (מטלגרם, מאפליקציה, מאתר) עוברת דרכו קודם.

מה הוא עושה:

  • כתובת URL קבועה לעולם החיצון
  • מפנה בקשות ל-Lambda הנכונה
  • אבטחה בסיסית (rate limiting, authentication)
  • לוגים

בלעדיו Lambda לא נגישה מבחוץ - אין לה כתובת ציבורית.

SSM Parameter - שירות של AWS לשמירת הגדרות וסודות. במקום לשים את ה-Telegram token בקוד או ב-.env, שומרים אותו ב-AWS בהצפנה. ה-Lambda קוראת אותו בזמן ריצה. יתרונות: אבטחה, ניהול מרכזי, אין סודות בקוד.

השוואה בין Polling ל-Webhook:

Polling:

  • הבוט רץ כל הזמן ושואל טלגרם “יש הודעות חדשות?”
  • דורש process שרץ 24/7
  • לא מתאים ל-Lambda (Lambda רצה רק כשקוראים לה)

Webhook:

  • טלגרם שולח הודעות כשיש משהו חדש
  • Lambda “ישנה” עד שמגיעה הודעה
  • משלם רק על שימוש בפועל

זאת הדרך הסטנדרטית להריץ בוט בענן.

בוט טלגרם: מעבר מהרצה מקומית לענן

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

הבוט עצמו לא מתארח בענן - הוא חי בשרתים של טלגרם. מה שרץ על Lambda זה הקוד שמטפל בהודעות (webhook handler). הבוט בטלגרם, הלוגיקה ב-Lambda.

מה זה כולל:

  • Webhook handler ב-Lambda
  • API Gateway
  • SSM Parameter - שירות של AWS לשמירת הגדרות וסודות. במקום לשים את ה-Telegram token בקוד או ב-.env, שומרים אותו ב-AWS בהצפנה. ה-Lambda קוראת אותו בזמן ריצה. יתרונות: אבטחה, ניהול מרכזי, אין סודות בקוד.

איך האייג’נט מתקשר דרך הטלגרם:

הודעה נכנסת (webhook): המשתמש שולח לטלגרם → API Gateway → Lambda → AgentCore

הודעה יוצאת (קריאת HTTP): AgentCore → Lambda → טלגרם

הכלים של האייג’נט: חיפוש, שליחת מייל, שליחת הודעה לטלגרם.

מה חסר: שהאייג’נט יוכל לתזמן בעצמו - כלי ליצירת EventBridge rule או DynamoDB entry.

הוספת תזמון: EventBridge vs DynamoDB

האייג’נט היה צריך לתזמן תזכורות בעצמו.

DynamoDB: טבלת DB רגילה, גמישה, צריך Lambda שסורקת כל דקה, משלמים על קריאות.

EventBridge: שירות מובנה של AWS, קשיח יותר, זול.

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

אפשר ליצור דינמית EventBridge rules דרך AWS SDK, אבל:

  • מגבלת 300 rules ב-EventBridge (ברירת מחדל)
  • צריך לנקות rules אחרי שרצו
  • הרשאות IAM נוספות

לשימוש קטן - EventBridge יעבוד מצוין. להרבה תזכורות - DynamoDB עדיף.

למה עם DynamoDB למבדה רצה כל דקה? polling לא יעיל?

DynamoDB זה רק database - הוא לא יודע “להעיר” משהו בזמן מסוים. אז צריך Lambda שבודקת כל דקה “יש משהו שהזמן שלו הגיע?”. זה אכן polling, אבל פנימי בתוך AWS (זול וסביר).

EventBridge לעומת זאת הוא scheduler - הוא יודע להגיד “תפעיל את זה ב-X”.

מה בניתי

בחרתי EventBridge ונוספו:

  • schedule_reminder tool לתזכורת חד פעמית
  • schedule_recurring tool קבוע שחוזר על עצמו
  • Reminder Lambda שנקראת ע”י EventBridge
  • הרשאות IAM לניהול EventBridge rules

עכשיו האייג’נט יכול:

  1. לקבל בקשה כמו “תזכיר לי מחר ב-10 לבדוק מיילים”
  2. לפרסר את הזמן ל-ISO format
  3. ליצור EventBridge rule חד-פעמי או קבוע
  4. כשהזמן מגיע - שולח הודעה לטלגרם וה-rule נמחק אם צריך

שתי למבדות:

  1. EventBridge מעיר את ה-Reminder Lambda כשיש תזמון, והיא קוראת לסוכן והוא מבצע את הפעולות
  2. Webhook Lambda שמעבירה הודעות נכנסות מטלגרם לאייג’נט

סיכום

  • האייג’נט מתארח ב-AgentCore runtime
  • הבוט בטלגרם הוא שכבת תקשורת - צינור להעברת הודעות מטלגרם לסוכן וחזרה. אותו סוכן יכול לקבל הודעות מ-Web UI, מ-Slack, מ-WhatsApp - לא משנה לו. הלוגיקה והזיכרון ב-AgentCore, לא בבוט.
  • התזמונים מנוהלים ב-EventBridge
  • יש שתי למבדות: אחת לתזמונים ואחת ל-webhook של טלגרם
  • AgentCore מחזיר תשובה לטלגרם דרך קריאת API רגילה

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

אחרי: המשתמש פונה מהטלגרם והפנייה עוברת דרך API Gateway באמצעות webhook ל-Lambda רק כשצריך, ואז לאייג’נטקור.