Agent Configuration Drift — כשסוכנים בסביבות שונות מתנהגים אחרת בלי שאיש שינה קוד

מאת צוות מדיה דיל · 12.08.2026 · AI Security · 5 דק׳

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

צוות תמיכה מדווח ש-Agent שירות לקוחות ב-Staging עונה בצורה זהירה ומדויקת, בעוד שאותו Agent, לכאורה עם אותו קוד בדיוק, מתנהג בפרודקשן באופן שונה בעליל - יותר "נועז" בהחלטות, לפעמים מבצע פעולות שאף אחד לא ציפה. אף אחד לא נגע בקוד. מה שקרה בפועל: מישהו עדכן את System Prompt ידנית דרך פאנל ניהול בפרודקשן לפני שלושה שבועות "לבדיקה מהירה", ושכח להחזיר אותו, וב-Staging עדיין רץ הגרסה הישנה. שתי הסביבות משתמשות באותו קוד, אותו מודל, ואותו Repository - ובכל זאת מתנהגות אחרת לגמרי. זהו Agent Configuration Drift: התרחקות הדרגתית ובלתי מתועדת בין תצורת ה-Agent שרצה בפועל בסביבות שונות, בלי ששום שינוי קוד מתעד את זה.

למה זה חמור יותר אצל Agents מאשר בתוכנה רגילה

Configuration Drift קיים בכל מערכת תוכנה - Feature Flags שנשארים דולקים, Environment Variables שמתעדכנים ידנית, הגדרות תשתית שמשתנות דרך קונסולה ולא דרך Infrastructure as Code. אבל אצל Agent הבעיה חמורה יותר בגלל אופי התלות: התנהגות ה-Agent לא נקבעת רק על ידי הקוד, אלא גם על ידי System Prompt, גרסת המודל עצמו (שיכולה להשתנות "בשקט" אצל ספק חיצוני), טמפרטורה ופרמטרי דגימה, גרסת מאגר הידע שמוזן ל-RAG, ורשימת הכלים הזמינים - כל אחד מהם משתנה בנפרד, ולעיתים ידנית, בלי לעבור דרך אותו תהליך Review כמו שינוי קוד. שינוי קטן לכאורה בניסוח System Prompt יכול לשנות לגמרי את "אישיות" ההחלטות של ה-Agent, בלי לגעת בשורת קוד אחת - מה שהופך את Drift הזה לבלתי נראה לכלי בקרת גרסאות רגילים שעוקבים רק אחרי שינויי קוד.

מקורות ה-Drift הנפוצים בפועל

  • System Prompt שהשתנה ידנית - עדכון "זמני" דרך פאנל ניהול שלא חזר לגרסה המקורית.
  • גרסת מודל שהוחלפה בשקט - ספקי LLM לעיתים מעדכנים גרסת ברירת מחדל מאחורי אליאס קבוע ("latest"), בלי שהצוות ביקש עדכון מפורש.
  • מאגר ידע (RAG) שהתעדכן בסביבה אחת ולא באחרת - Reindex שרץ בפרודקשן אך לא ב-Staging, כך שתשובות מבוססות מידע שונה.
  • רשימת כלים זמינים שהתרחבה בהדרגה - כלי חדש שנוסף ל-Agent בפרודקשן לצורך בדיקה מהירה, ונשאר שם.
  • פרמטרי דגימה (Temperature, Top-P) שכוונו ידנית - ולא הוחזרו לערך המקורי אחרי ניסוי ספציפי.

המכנה המשותף לכל אלה: שינוי שמתבצע דרך ערוץ שאינו Pull Request מבוקר, ולכן לא מותיר עקבות שקל למצוא ולהשוות בין סביבות.

הפתרון: Configuration as Code, לא רק Infrastructure as Code

העיקרון שכבר מקובל לתשתית (Terraform, Kubernetes Manifests) חייב להיות מוחל באותה קפדנות גם על תצורת ה-Agent כולה: System Prompt, גרסת מודל מוצמדת (לא alias "latest" שמשתנה מתחת לרגליים), רשימת כלים, ופרמטרי דגימה - כולם חיים בקובץ תצורה תחת Version Control, עם Pull Request לכל שינוי, בדיוק כמו שינוי קוד. כל שינוי בפאנל ניהול ידני שלא עובר דרך הערוץ הזה נחשב תקלה, לא תכונה - וצריך להיות פיזית קשה או בלתי אפשרי לבצע, לא רק אסור במדיניות. פאנל ניהול שמאפשר עריכה ישירה של System Prompt בפרודקשן הוא בעצמו נקודת תורפה ל-Drift, גם אם הכוונה מאחוריו הייתה נוחות תפעולית.

# agent-config.yaml — נשמר ב-Git, לא בפאנל ניהול
model: "claude-sonnet-5-20260115"  # מוצמד, לא "latest"
system_prompt_version: "v14"
tools: ["search_kb", "create_ticket"]
temperature: 0.3
kb_index_version: "2026-08-01"

זיהוי אקטיבי: Hash השוואה בין סביבות

גם עם משטר Configuration as Code קפדני, שינויים ידניים "בדרך חירום" קורים בפועל - ולכן נדרשת שכבת זיהוי אקטיבית, לא רק מניעה. הפתרון המעשי הוא שירות Drift Detection שרץ באופן תקופתי (כל שעה, למשל), קורא את התצורה בפועל שכל סביבה משתמשת בה כרגע (לא רק את מה שנמצא ב-Git, אלא את מה שבאמת נטען בזמן ריצה), מחשב Hash לכל רכיב תצורה, ומשווה מול ה-Hash שמוגדר כ"מקור אמת" ב-Repository. כל אי-התאמה מפעילה התראה מיידית עם פירוט מדויק של מה בדיוק סוטה - לא רק "יש הבדל", אלא איזה שדה ספציפי ומה הערך בכל צד.

הקשר ל-Least Agency: Drift שמשנה גם את רמת הסוכנות

מקרה מיוחד וחמור של Drift הוא כשהשינוי הלא-מתועד לא נוגע רק בתוכן אלא ברמת האוטונומיה עצמה - למשל כשמישהו "מדלג" על שער אישור מסוים בפרודקשן כדי לזרז תהליך, ובכך למעשה מעלה את רמת הLeast Agency של ה-Agent בלי החלטה מודעת ומתועדת. זהו בדיוק סוג הזחילה שנדון שם, וההגנה זהה: כל שינוי ברמת סוכנות, כמו כל שינוי תצורה אחר, חייב לעבור דרך אותו ערוץ Version Control מבוקר, ולא להתבצע כ"תיקון מהיר" שאף אחד לא רואה עד שמשהו משתבש.

הבעיה השקטה ביותר: Drift שאף אחד לא יזם

הסוג המסוכן ביותר של Drift הוא לא זה שנוצר על ידי שינוי ידני מכוון, אלא זה שקורה מבלי שאף אחד בצוות עשה משהו בכלל - למשל כשספק ה-LLM מעדכן את ההתנהגות הפנימית של גרסת מודל קיימת (Silent Model Update) בלי לשנות את מספר הגרסה שהצוות מצמיד אליה בקוד. במקרה כזה, אין שום Commit לחפש, אין שינוי תצורה לזהות ב-Git - התצורה שלכם נשארה זהה במדויק, אבל ההתנהגות בפועל השתנתה כי הרכיב שמעבר לגבול השליטה שלכם השתנה. ההגנה היחידה מפני התרחיש הזה היא לא מניעה (אי אפשר למנוע שינוי אצל ספק חיצוני) אלא זיהוי דרך Regression Testing שיטתי: סוללת מקרי בדיקה קבועים (Golden Set) שרצה אוטומטית על כל סביבה על בסיס קבוע, ומשווה את התוצאות מול קו בסיס ידוע - כך שגם שינוי שמקורו מחוץ לשליטה הישירה שלכם מתגלה תוך שעות, לא תוך שבועות של תלונות משתמשים מצטברות. הנושא הזה חופף חלקית לתחום שנדון במדריך על בדיקות אבטחה שוטפות ל-Agents, אבל כאן הדגש הוא לא על איתור פרצות אלא על איתור שינוי התנהגות בלתי מוסבר, ולעיתים דווקא שם, בגבול שבין תצורה מבוקרת לתלות חיצונית שלא ניתנת לשליטה, מתגלים הפערים הכי קשים לתפוס בזמן, ודווקא לכן כדאי להשקיע בהם תשומת לב יחסית לא פרופורציונלית לתדירות שבה הם קורים בפועל.

תגיות: Configuration Drift · Config as Code · system prompt versioning · agent environments · drift detection · AI Ops

← חזרה לבלוג · צור קשר