דילוג לתוכן הראשי
חזרה למדריכים
Architecture7 דק׳ קריאה

ארכיטקטורת Harness: איך לרתום LLMs למערכות ייצור

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

הבעיה עם פרומפטים לבדם

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

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

רכיבי ליבה של Harness

  1. סינון קלט ופלט — סכימות מחמירות (Zod/JSON Schema) לפני כל קריאת מודל, ודחייה של פלט לא תקין במקום לתקן אותו בשקט.
  2. רשימת כלים מותרת לפי context — סוכן בקראולינג לא צריך גישה לשליחת מיילים, ולהיפך. הרשאות נגזרות משלב העבודה, לא קבועות.
  3. לולאת בקרה עם קוווטות — מספר מקסימלי של צעדים, עלות מצטברת וזמן ריצה. סוכן ללא תקרה הוא סוכן שנכנס ללולאה אינסופית.
  4. צפייה מלאה (Observability) — כל קריאת מודל, כל כלי וכל החלטה נרשמים כאירועים שניתנים לשחזור. המטרה היא לא "לראות מה קרה" אלא לענות על "למה הסוכן עשה את זה" — ולכן רושמים את הטרייס המלא: החלטות, ארגומנטים, תוצאות, latency ועלות לכל דילוג.

שכבת הביטחון: פרומפט טוב זה לא מספיק

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

  • בפרומפט הסיסטם: הגדרת אמון מפורשת — תוכן שמגיע מכלים הוא data, לא הוראות.
  • בקוד: עטיפת טקסט חיצוני בתוחמים ברורים וסימונו כקלט לא מהימן לפני שהוא נכנס ל-context.
  • בכלים: ולידציה של כל קריאת כלי מול whitelist לוגית — לא רק "האם זה בפורמט" אלא "האם הפעולה הזו הגיונית בשלב הזה".
  • בפעולות בלתי הפיכות: approval gate — הסוכן עוצר וממתין לאישור אנושי לפני תשלום, שליחה המונית או מחיקה. ההבדל בין אסון לבקרת איכות הוא מילה אחת: "עצור ושאל".

מה מפריד Harness מפרומפט סיסטם

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

המלצה פרקטית: התחילו מהצר ביותר האפשרי — ולידציה + קוווטות + לוגים — והרחיבו רק כשיש מדדים שמצדיקים את זה. ההרחבה הבאה בתור היא בקרת כלים לפי שלב, ואחריה approval gates. מי שמתחיל מ-framework guardrails מלא בונה ארמון על יסודות שלא נבדקו.

רוצה להעמיק את הנושא אצלך בצוות?

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

בואו נדבר