מדוע סוכנים אוטונומיים של Fetch.ai מאבדים קשר עם הבלוקצ'יין
סוכנים אוטונומיים של Fetch.ai מקבלים החלטות בצד שלהם: מחזיקים מודל מצב, מחשבים תנאי הפעלה וחותמים על הפעולה בעצמם, בלי אדם בלולאה. הרשת, לעומת זאת, חיה לפי חוקים משלה — הסופיות לא מגיעה באופן מיידי, חלק מהאירועים מתבטלים, וסדר הפעולות נקבע על ידי הקונסנזוס, לא על ידי הסוכן.
כל עוד שתי תמונות העולם האלה חופפות, אינטגרציה של סוכני AI נראית עובדת; אי-התאמה במצב מתגלה מאוחר יותר ולא במקום שבו מצפים לה.
כשל טיפוסי מתחיל באורקלים של נתונים: תמונת מצב מגיעה לסוכן באיחור, ובנוסף בתוך הסוכן היא נשמרת במטמון לכמה מחזורים. ההחלטה מתקבלת על נתונים מיושנים — מחיר, נפח זמין או הרשאת גישה ברגע הביצוע כבר שונים. הסוכן פועל נכון פורמלית, אך על תמונה שגויה, ובלוגים שלו זה לא נראה.
החצי השני של הבעיה — פעולות חוזרות. בלי להמתין לאישור, הסוכן לא יודע אם הניסיון הראשון הגיע, ושולח ניסיון שני. המרשם מקבל שתי רשומות זהות, הפוזיציות לא תואמות את הרשומות החשבונאיות, והבירור אורך יותר זמן מאשר העסקה עצמה. אם הפעולה בלתי הפיכה, אי אפשר לבטל אותה ברשת — אפשר רק לפצות עליה.
השורש אחד: הלוגיקה של הסוכן האוטונומי חיה בנפרד ממצב הרשת, והגבול ביניהם אינו נשלט כלל. נבחן כיצד סוגרים זאת — התאמת מצב לפני החתימה, מפתחות אידמפוטנטיים ויומן כוונות של הסוכן.
מה נותנת אינטגרציה של סוכנים: מהירות, כשלים, פעולות ידניות
סוכן ב-Fetch.ai הוא שירות שעוקב בעצמו אחרי אירועים ברשת ומחוצה לה, מיישם כללים ומפעיל את הפעולה הבאה. מערך uAgents יוצר שכבת ביצוע בין המערכות שלכם: הוא לא ממתין שהמפעיל יפתח ממשק, אלא מגיב לשינוי מצב.
האפקט כאן נמדד בארבעה כיוונים — זמן הפעולה, מחלקת כשלים שנמנעה, שיעור ההתאמות הידניות ושלמות הביקורת.
זמן הפעולה מתקצר בגלל שבין האירוע לביצוע אין אדם. הסוכן בודק תנאי, אוסף אישורים ושולח טרנזקציה במעבר אחד — חציון הזמן מהאירוע ועד הביצוע יורד משעות לשניות. ההבדל נראה לא בהדגמה, אלא בזרימה: ככל שיש יותר פעולות ליחידת זמן, כך הסכימה הישנה והחדשה נפרדות זו מזו יותר.
מחלקת כשלים נפרדת — ביצוע כפול ואי-התאמת מצבים — מוסרת ברמת הלוגיקה של הסוכן. מטפלים אידמפוטנטיים, דה-דופליקציה לפי מזהה הפעולה וניסיון חוזר עם הגבלת ניסיונות מסירים חיובים כפולים והזמנות תקועות. שגיאות שבעבר צפו אחרי יממה בזמן ההתאמה נחסמות ברגע העיבוד.
שיעור ההתאמות הידניות יורד, כי כבר אין מה להתאים: מצב הסוכן ומצב המערכת מתכנסים לאותו אירוע. המפעיל מתערב רק בחריגים שהסוכן סימן כמחלוקתיים — תור הבירור מצטמצם פי כמה, לא באחוזים בודדים.
ביקורת נבנית מיומן ההחלטות של הסוכן: נתוני קלט, הכלל שהופעל, התוצאה וחתימת המבצע. לפי רשומה כזו משחזרים את הפעולה צעד אחר צעד, ולכן מחלוקת נבחנת לפי שרשרת אחת, ולא לפי לוגים במערכות שונות. שלמות היומן הזה היא שקובעת אם אפשר להעביר לסוכן פעולות בלי אישור ידני.
אפשרויות אינטגרציה של Fetch.ai: ענן, היברידי, מתחם משלכם
הלוגיקה של הסוכן והמפתחות הפרטיים שלו הם שתי ישויות שונות, ואפשר למקם אותן בדרכים שונות. שאלת המפתח בכל אפשרות אינטגרציה: היכן פיזית נמצאים המפתחות ומי יוזם את חתימת הטרנזקציה. מכך תלויים גם סכימת אחסון המפתחות וגם האם הנתונים שלכם נכנסים למתחם חיצוני.
| אפשרות | מתי מתאימה | מגבלות |
|---|---|---|
| תשתית ענן | הפעלה מהירה של סוכנים, בידוד לא קריטי | מפתחות מחוץ למתחם שלכם, תלות בספק, נדרשת ביקורת הרשאות נפרדת |
| סכימה היברידית | נדרש שליטה במפתחות תחת עומס חישובי חיצוני | ניתוב מורכב יותר, אי-סנכרון מצב בין החלקים |
| מתחם סגור | דרישות רגולטוריות, נתונים רגישים | שירותים חיצוניים אינם זמינים, כל תחזוקת המרשמים בצד שלכם |
איך זה עובד בפועל
בתשתית ענן סוכני uAgents נפרסים בקונטיינרים, מתכווננים לפי עומס ורואים מיד שירותים חיצוניים. הסכימה ההיברידית מייצגת פשרה: החלק החישובי חי בחוץ, ואילו החתימה ואחסון המפתחות נשארים בצומת שלכם — הסוכן עובד עם נתונים חיצוניים בלי למסור את השליטה בנכסים.
מתחם סגור בוחרים כאשר חיבורים חיצוניים אינם מותרים: החלפה מתבצעת בתוך המתחם, נקודות הכניסה סגורות, והקשר עם מרשמים חיצוניים — דרך שערים מבוקרים. המחיר לכך — סנכרון ידני ותחזוקה רבה יותר. תארו את המשימה — נחזור עם הערכה ותוכנית עבודה המותאמת למתחם שלכם.
סדר העבודות: מביקורת תרחישים ועד מסירת המתחם
סדר העבודות זהה גם להרצה ראשונה וגם למתחם פרודקשן: תחילה מקבעים אילו החלטות מקבל הסוכן ועל איזה נתונים, לאחר מכן מתכננים את הסכימה, ורק אחר כך עוברים למימוש. סדר כזה מסיר את הסיכון המרכזי — כשהאינטגרציה כבר בנויה, אבל התרחיש על נתונים אמיתיים לא מתכנס וצריך לחזור על חלק מהעבודה.
- ביקורת תרחישים ונתונים — מפרקים משימות שאותן סוגרים סוכני Fetch.ai, מתארים מקורות, תנאי הפעלה ואיך ההחלטה מתקבלת כיום.
- תכנון סכימת האינטראקציה — מי עם מי מחליף הודעות, מה קורה כשלא זמין מקור, והיכן נדרש צעד אישור ידני.
- הגדרת סוכנים — לוגיקת העיבוד, חיבור מקורות נתונים, כללי התנהגות בשגיאות, מגבלות על תדירות הפניות לשירותים חיצוניים.
- הרצת בדיקה — מריצים תרחישים על נתונים היסטוריים ובמתחם סגור, ומשווים את תשובות הסוכנים לצפויות.
- בדיקת עומס — בקשות שיא, תור הודעות, זמן תגובה ונכונות הכשלים.
- מסירת הפתרון והכשרת הצוות — מוסרים סכימה, קונפיגורציות, יומנים ותקנון הפעלה, ומנתחים עם הצוות שלכם מקרים שנויים במחלוקת.
כל שלב נסגר בארטיפקט ניתן לבדיקה: מפת תרחישים, סכימה, מערכי נתוני בדיקה, דוח עומסים ותיעוד. תוצאות ביניים מתאמים תוך כדי תנועה — אתם רואים התקדמות לפי שלבים, ולא הדגמה סופית.
מה נשאר אצלכם: סכימות, מדיניות, תקנונים, תיעוד
אינטגרציה של סוכנים היא לא רק קוד שעובד ברשת. כעבור חצי שנה כבר איש לא ייזכר למה לסוכן יש דווקא מגבלות כאלה על קריאות, איך הוא מקבל גישה לארנק ומה לעשות כשצומת נופל. לכן אנחנו מוסרים את הפרויקט כך שאפשר לפתח ולתפעל אותו בלעדינו: כל ארטיפקט נפתח, נקרא ומיושם בפועל. להלן — מערך טיפוסי בתום העבודה עם Fetch.ai ו-uAgents.
- סכימות אינטראקציה — אילו סוכנים מחליפים הודעות, באילו נושאים, מי יוזם את הבקשה, והיכן נמצאים שירותים חיצוניים ונקודות כשל.
- קונפיגורציות של סוכנים — פרמטרי הפעלה, מגבלות, שיוך לרשתות, משתני סביבה, כללי עדכון כתובות ומפתחות.
- סכימת זרימות נתונים — מהאירוע הנכנס ועד לרישום ברשת: מה נשמר ואיפה, מה נרשם בלוג, ומה יוצא למערכות חיצוניות.
- מדיניות גישה ותפקידים — מי חותם על פעולות, מי משנה קונפיגורציה, מי קורא יומנים; סדר הנפקה ושלילת מפתחות.
- תקנוני הפעלה — עדכון מתוכנן של סוכנים, חזרה לגרסה קודמת, תגובה לנפילה ולאי-התאמת יתרות.
- נראות תפעולית — מערך מדדים, ערכי סף, לאן מגיעות התראות ומי מגיב להן ראשון.
- תיעוד הפרויקט — תיאור הארכיטקטורה, ההחלטות שהתקבלו והסיבות להן, מגבלות ידועות של הענף הנוכחי.
- העברת ידע לצוות — ניתוח הסביבה עם המהנדסים שלכם, מענה לשאלות, ותיקון משותף של העדכון הראשון.
מקרה בוחן: מרקטפלייס נתונים צמצם התאמות ידניות פי שלושה
מרקטפלייס נתונים מחבר בין ספקים של מערכי נתונים לקונים: הסליקה מתבצעת באון-צ'יין, והרשאות הגישה מונפקות בצד השירות. את ההתאמה בין יומן העסקאות לרשומות הגישה הצוות עשה ידנית — אנליסט השווה מזהי עסקאות, תנאים ומועדים.
זה גזל עד שליש מזמן העבודה של התמיכה, ואי-התאמות צפו כעבור ימים: הקונה כבר עבד עם מערך הנתונים, אף שאישור התשלום לא עבר.
מה שינו בלוגיקת הסוכנים
הרכיבו שכבת סוכנים על uAgents של Fetch.ai: סוכן ספק מפרסם את תנאי העסקה, סוכן קונה בודק אותם ומתחיל את הסליקה, סוכן מבקר מאזין לאירועים ואוסף ראיות לכל פעולה. כללי ההתאמה הועברו לתנאים הצהרתיים — גישה, מועדים, מגבלות, סדר בירור אי-התאמות — והפסיקו לתקן קוד לכל דרישה חדשה.
המטפלים נעשו אידמפוטנטיים עם מפתח לפי מזהה העסקה: מסירה חוזרת של אירוע לא יוצרת כפילות ולא מקלקלת את היומן.
אחרי ההפעלה שיעור הפעולות שעברו להתאמה ידנית ירד מ-34% ל-11%, זמן התגובה לאירוע — מ-40–90 דקות ליחידות של שניות, ומספר הפעולות השנויות במחלוקת הצטמצם פי ארבעה. בירור ידני נשאר רק במקומות שבהם מקורות חיצוניים אינם תואמים, וזה כבר חריג ולא עבודה יומיומית.
לוגיקת הסוכנים לא נתנה "קסם של AI", אלא מתחם צפוי: כל פעולה מותירה עקבות, וכל אי-התאמה משוחזרת לפי היומן.
במה שונה סוכן אוטונומי מסקריפט רגיל ברשת?
סקריפט ברשת הוא רצף מתואר מראש: לבדוק תנאי, לקרוא למתודה של חוזה, לרשום תוצאה. ההחלטה התקבלה על ידי כותב הקוד, והביצוע הולך בדיוק לפי הענף שהוטמן. סוכן אוטונומי מקבל מטרה וכללים, ואת הפעולה הקונקרטית בוחר בעצמו בכל צעד — למה לקרוא, מתי להמתין, ומתי לוותר על העסקה.
ההבדל בין הגישות נראה הכי בבירור במצב בלתי צפוי. סקריפט, לאחר שקיבל תשובה לא נכונה או נתקל במגבלה, קורס או נכנס ללולאת המתנה, הטרנזקציה מתבטלת — והמערכת עומדת עד התערבות אדם.
הסוכן רואה שהמסלול לא עבד, ובונה מחדש את התוכנית: לוקח מקור נתונים חלופי, מעביר את הפעולה לשלב הבא, מפחית את הנפח למותר.
גבולות האוטונומיות לא מופיעים מעצמם — אותם מגדירים בכללים: מה הסוכן קורא, לאילו חוזים הוא פונה, ואילו פעולות חייבות לעבור אישור. ככל שהגבולות צרים יותר, ההתנהגות קרובה יותר לסקריפט: צפויה ואמינה יותר, אבל חסרת תועלת במקום שדרוש בו גמישות.
גם סוג הסיכון משתנה. אצל סקריפט הוא בינארי: פעל או לא פעל. אצל סוכן מופיע מצב שלישי — פעולה שמותרת פורמלית, אבל לא זו שהתכוונו אליה. לכן במתחם מטמיעים מגבלות קשיחות על פעולה, יומן החלטות עם הנמקה ונקודת עצירה שסוגרת את הסוכן בלי לאבד מצב.
ב-Fetch.ai סוכן הוא שירות עם לוגיקה וכתובת משלו, שמחליף הודעות עם סוכנים אחרים. המסקנה המעשית פשוטה: סקריפט מבצע אוטומציה של תרחיש ידוע, ואילו הסוכן ניגש לזה שאי אפשר לתאר מראש במלואו — וזה מוטמע בתכנון מהיום הראשון.
ספקות טכניים: מפתחות, עומס, אבטחה, חזרה לאחור
לפני תחילת אינטגרציה של סוכנים ב-Fetch.ai לקוחות שואלים חמש שאלות: מפתחות, כשל במקור, עומס, חזרה לאחור של שינויים, ותאימות למוצר. להלן תשובות קצרות שנוחות לבדיקת ההתאמה של הפתרון לדרישות.
היכן נשמרים מפתחות החתימה?
מפתח הסוכן נמצא במנהל סודות ומונפק לזמן הפעולה — הוא לא נכנס לקוד או למאגר. רוטציה מתבצעת לפי לוח זמנים, וההרשאות מופרדות: הסוכן חותם רק על הטרנזקציות שלו.
מה יקרה בכשל של מקור?
הסוכן לא שולח טרנזקציה על סמך נתונים מיושנים: הבקשה חוזרת עם השהיה גדלה והולכת, והאירוע עובר לתור. אם המקור שותק יותר מהסף, מופעל מפסק הגנה ונשלחת התראה לתורן.
איך זה ישפיע על העומס?
הסוכן מגיב רק לשינויים מאושרים, ולכן הפניות לרשת הן חלק מזרימת האירועים הכוללת. את התור מפרקים עובדי עיבוד עם הגבלת מקביליות — השיא לא הופך למפולת בקשות.
האם אפשר לחזור לאחור משינויים?
כן, בתכנון אידמפוטנטי. החוזה מנהל יומן פעולות, ניסיון חוזר עם אותו מזהה לא יוצר כפילות, ופעולות שנויות במחלוקת נבחנות ידנית לאחר עצירת הסוכן.
האם זה תואם למוצר הנוכחי?
הסוכן מתחבר כשירות נפרד ועובד דרך הממשקים הקיימים. תרחישים נבדקים תחילה במתחם צללים ומופעלים בהדרגה — אין צורך לכתוב מחדש את המוצר.
נדון במשימה ונחזור עם הערכה ותוכנית עבודה
הערכת הפרויקט נהיית אמיתית רק מתוך תמונת המשימה שלכם, לא מתוך מילים כלליות. לצעד ראשון די בתיאור: אילו תרחישים סוגרים הסוכנים, עם אילו שירותים ונתונים הם עובדים, מי מחזיק במפתחות ולאן מגיעות תוצאות הפעולות שלהם.
בשיחה הראשונה מדייקים את גבולות האוטומציה ואת מצבי העבודה של הסוכנים ב-Fetch.ai: מה הסוכן מבצע בעצמו, מה מאשר אדם, אילו מגבלות שמים על פעולות ואיך חוזרים לאחור מהפעלה שגויה. לאחר מכן מקבעים תוכנית עבודה וחוזרים עם הערכה.
עם מה נחזור אחרי הדיון במשימה:
- מפת תרחישים: אילו סוכנים, אילו משימות, והיכן האוטומציה מתחילה ומסתיימת;
- סכימת אינטגרציה עם השירותים, הארנקים ומקורות הנתונים החיצוניים שלכם;
- מודל הרשאות: מי מחזיק במפתחות, ואילו מגבלות ואישורים חלים על פעולות הסוכן;
- הרכב השלבים עם נקודות קבלה — מה נחשב מוכן בכל צעד;
- לוחות זמנים להטמעה לפי שלבים וסדר הוצאת הסוכנים למצב עבודה;
- רשימת סיכונים ודרכים להסירם, כולל תנאי חזרה למצב הקודם.
הצעד הראשון — מכתב או שיחה קצרה עם תיאור המשימה: זה מספיק כדי לראות את הרכב העבודות. הערכה, תוכנית עבודה ולוחות זמנים להטמעה לפי שלבים נשלחים במסמך אחד, כדי שאפשר יהיה להשוות אותם לסדרי העדיפויות שלכם.