הנדסת הקשר לסוכני AI ארוכי־טווח

יחד, הניתוח של Arize, מאמר arXiv על גלישת חלון הקשר, ההסבר היישומי של Redis וההשוואה של Atlan להנדסת מעטפת מצביעים על שינוי מעשי בתכנון סוכנים. סוכנים שרצים לאורך זמן נשפטים פחות לפי גודל חלון ההקשר של המודל, ויותר לפי שכבת הבקרה שסביבו. Arize הופכת את השינוי הזה למוחשי. היא מציינת כלי סוכנים ומערכות זיכרון/מעטפת שכבר נשלחו, כולל Pi, OpenClaw, Claude Code ו-Letta, כדוגמאות להנדסת הקשר ברמת המעטפת, ומתארת סימולטור אינטראקטיבי שמראה חלון של 200K טוקנים מתמלא.

הפרטים הציבוריים הזמינים במקורות המצוטטים אינם אחידים. Arize נותנת מספרי יישום קונקרטיים עבור Pi, OpenClaw, Claude Code ו-Letta. מאמר מחקר על פתרון גלישת חלון הקשר בסוכני AI נותן מנגנון כללי יותר לטיפול בפלטי כלים שיכולים לחרוג מכל חלון מעשי. ההסבר של Redis על גלישת חלון הקשר מסכם את התסמינים בסביבת production: שגיאות API קשיחות, ירידה שקטה באיכות, הצטברות פלטי כלים, והשהיה ארוכה יותר ככל שה-prompts גדלים. ההשוואה של Atlan בין הנדסת prompt, הקשר ומעטפת מספקת מטאפורת מחסנית שימושית: הנדסת prompt מעצבת את ההודעה, הנדסת הקשר מעצבת את מה שהמודל רואה, והנדסת מעטפת מעצבת את כל סביבת הסוכן.

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

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

דרך נקייה יותר לקרוא את מערך המגבלות הראשון היא:

• Pi: קריאות קבצים נעצרות ב-2,000 שורות או 50KB, המוקדם מביניהם. התוכן שמוחזר כולל רמז המשך שמספר למודל איזה טווח שורות הוצג ואיך להמשיך עם offset ו-limit. OpenClaw יורשת את ההתנהגות הזו, ואז מוסיפה מכסות נפרדות: קובצי bootstrap מוגבלים ל-12,000 תווים לכל קובץ ול-60,000 תווים בסך הכול. לתוצאות כלים יש תקציב נוסף של 16,000 תווים או 30% מחלון ההקשר, הקטן מביניהם.

Claude Code משתמשת בעיצוב של שני שערים. לפי Arize, היא בודקת מגבלת בתים של 256KB לפני פתיחת קובץ, ואז סופרת את הטוקנים של התוצאה מול תקציב של 25,000 טוקנים אחרי הקריאה. גם עבור קבצים שמתחת למגבלה, ברירת המחדל היא להחזיר 2,000 שורות מההתחלה, ולקטוע שורות ארוכות מ-2,000 תווים. אם המודל קורא מחדש את אותו טווח קובץ והקובץ לא השתנה, Claude Code יכולה להחזיר stub במקום לחזור על התוכן המלא.

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

הדפוס הבא הוא להתייחס להקשר כמו ל-viewport, לא כמו לאחסון.

Pi ו-Claude Code חושפות עימוד דרך offset ו-limit. OpenClaw מוסיפה קטיעת ראש/זנב במקומות מסוימים, ושומרת את ההתחלה והסוף כשהאמצע פחות צפוי להיות חשוב. Arize אומרת ש-OpenClaw משתמשת בפיצול של 75% ראש / 25% זנב עבור קובצי bootstrap גדולים מדי, ועשויה לשמור גם את הראש וגם את הזנב עבור תוצאות כלים כשהזנב נראה חשוב, למשל שגיאות, סוגרי JSON מסיימים או מילות מפתח שנראות כמו סיכום.

Letta הולכת רחוק יותר בכך שהיא גורמת לקבצים לחיות מחוץ ל-prompt. קבצים שהועלו מפורקים, מחולקים למקטעים ומוטמעים ב-vector store, מה שנותן לסוכן צפייה ישירה, חיפוש מדויק וחיפוש סמנטי. כשקובץ פתוח בהקשר, Letta מציגה תצוגה מנוהלת שגודלה משתנה לפי הקשר המודל: 5,000 תווים עבור הקשר 8K, 15,000 עבור 32K, 25,000 עבור 128K ו-40,000 עבור 200K+. גם מספר הקבצים הפתוחים בו־זמנית משתנה, מ-3 עבור מודלים קטנים ועד 15 עבור גדולים מאוד, עם מדיניות LRU שמפנה את הקבצים שניגשו אליהם הכי פחות לאחרונה.

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

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

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

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

Arize מדווחת ש-Pi מפעילה דחיסה כאשר מספר טוקני ההקשר המשוער חורג מחלון ההקשר פחות טוקני הרזרבה, עם רזרבת ברירת מחדל של 16,384 טוקנים. היא שומרת בערך את 20,000 הטוקנים האחרונים ומסכמת תוכן ישן יותר להודעת משתמש סינתטית שמוצמדת לפני הזנב שנשמר. היא גם נמנעת מחיתוך באמצע זוגות קריאת כלי/תוצאת כלי.

OpenClaw מוסיפה מדיניות היסטוריה אגרסיבית יותר. כשההיסטוריה חורגת מ-50% מחלון ההקשר, היא מפצלת הודעות למקטעי טוקנים בעלי מסה שווה, משמיטה את המקטע הישן ביותר, מסכמת את התוכן שהושמט באמצעות סיכום רב־מעברי מדורג, ומתקנת צימוד של קריאת כלי/תוצאה. היא גם מבצעת flush לפני דחיסה: תור סוכני שקט נותן לסוכן הזדמנות לשמר מצב בקובצי זיכרון לפני שההיסטוריה נעלמת. בנפרד, היא גוזמת תוצאות כלים בזיכרון עם התנהגות soft-trim ו-hard-clear על TTL מטמון של 5 דקות.

Claude Code דוחסת סמוך לסוף החלון. Arize אומרת שהטריגר שלה הוא חלון ההקשר האפקטיבי פחות buffer של 13,000 טוקנים, מה שממקם את הדחיסה סביב 167K טוקנים עבור מודל עם הקשר 200K. prompt הסיכום שלה מבקש סעיפים מובנים המכסים את הבקשה העיקרית, מושגים טכניים, קבצים וקוד, שגיאות ותיקונים, פתרון בעיות, הודעות משתמש, משימות ממתינות, עבודה נוכחית והצעד הבא. אחרי דחיסה, היא יכולה לצרף מחדש עד 5 קבצים שנקראו לאחרונה במסגרת תקציב טוקנים.

הדפוס ברור: דחיסה אינה ״לסכם את הצ׳אט״. היא checkpointing. סוכן שרץ לאורך זמן צריך מקבילה לקובץ שמירה: מטרה, אילוצים, החלטות, ידיות פתוחות, ראיות אחרונות והפעולה הבאה.

יש פלטים שלעולם לא צריכים להיות ממוקמים בחלון ההקשר בכלל.

מאמר arXiv הופך זאת למוחשי באמצעות תהליך עבודה במדעי החומרים. כלי אחד מייצר מבנה רשת אלקטרוני עבור מולקולה: מטריצה תלת־ממדית בממדים 128 × 128 × 128, ובסך הכול 2,097,152 רכיבי float32. הפלט הזה חורג בהרבה מחלון ההקשר של LLMs נפוצים. אבל הכלי הבא צריך את הרשת כקלט.

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

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

אותו היגיון חל גם מעבר למערכים מדעיים. תגובות JSON גדולות, PDFs, לוגים, embeddings, קובצי מדיה וייצואי מסדי נתונים שייכים לעיתים קרובות לאחסון, לא ל-prompt. עבור מערכות שנבנות סביב כלי MCP או מחברי API מותאמים אישית, העברת מצביעים צריכה להיות בחירת עיצוב מדרגה ראשונה, לא טלאי אחרי הגלישה הראשונה.

חלון הקשר של 200K טוקנים מרגיש גדול עד שסוכן מתחיל לפעול. prompt מערכת, הגדרות כלים, כמה מסמכים שאוחזרו, קריאות קבצים, לוגים, עקבות שגיאה וסיכומים יכולים לצרוך אותו מהר מהצפוי. המסגרת המעשית אינה כמה גדול החלון נראה על הנייר, אלא כמה מהר סוכנים מוציאים אותו בזמן ריצה. הנחיות זיכרון הסוכנים של Redis מצביעות לכיוון זיכרון חיצוני ועמיד למצב שצריך לשרוד בין קריאות, בעוד שמסגור הנדסת ההקשר של Atlan מפריד בין prompts טובים יותר לבין הרכבת הקשר טובה יותר. יחד, הם מתייחסים לחלון ההקשר פחות כמו למחסן ויותר כמו לסט עבודה מוגבל.

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

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

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

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

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

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

לבסוף, בדקו אובדן מטרה בנפרד מגלישה. סוכן יכול להישאר מתחת לחלון הקשיח ועדיין לסטות. השאלה הנכונה אינה רק ״האם ה-API קיבל את ה-prompt?״ אלא ״האם הפעולה הבאה עדיין משרתת את המשימה המקורית?״

הסיכום שלמטה הופך את הדפוסים האלה לצ׳קליסט מהיר לפני ה-FAQ.

• סוכנים ארוכי־טווח נכשלים גם דרך גלישת הקשר וגם דרך אובדן מטרה, ולכן המעטפת חייבת לנהל יותר מאורך ה-prompt.
• מערכות סוכנים ב-production משתמשות בתקציבים קשיחים על קבצים, פלטי כלים והיסטוריה לפני שנתונים גולמיים מגיעים למודל.
• עימוד, חיפוש ותצוגות מנוהלות מתייחסים להקשר כאל viewport מוגבל ולא כאל אחסון קבוע.
• דחיסה עובדת הכי טוב כ-checkpointing: היא משמרת מטרות, אילוצים, החלטות, עבודה ממתינה ושלמות קריאות כלים.
• פלטי כלים גדולים שייכים לעיתים קרובות לאחסון חיצוני, עם מצביעים קצרים שמועברים בין כלים במקום ערכים מלאים ב-prompt.

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

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

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

הן מגדירות תקציבים לכל מקור, מדפדפות קריאות קבצים, מאחזרות רק תצוגות רלוונטיות, דוחסות היסטוריה סביב מצב, מבטלות כפילויות בקריאות חוזרות ומאחסנות פלטים גדולים מחוץ ל-prompt.

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

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