איך לשפר סוכן AI: שבע השורות שמפרידות בין סקריפט לסוכן

23.8.2026 · 8 דקות קריאה · AI

איך לשפר סוכן AI: שבע השורות שמפרידות בין סקריפט לסוכן

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

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

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

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

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

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

מילון מושגים קצר

למה סוכן שעובד עדיין לא בשל

הפער בין דמו לייצור הוא כמעט אף פעם לא פער של מודל או של פרומפט. הוא בכל מה שמסביב. ארבע שאלות שאף אחד לא שואל בשבוע הראשון:

  1. מי אישר שהסוכן הזה רץ, ומי אחראי עליו כשהוא נופל?
  2. במה מותר לו לגעת, ובאיזו רמת הרשאה?
  3. כמה עלתה הריצה, ומה עוצר אותה כשהיא מתחילה לרוץ בלולאה?
  4. אם לקוח ישאל מחר למה נשלחה ההודעה הזו, יש תשובה מתועדת?

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

המודל: סוכן הוא רשומה בת שבעה שדות

זה הגרעין. סוכן בשל הוא רשומה שאפשר להסתכל עליה ולדעת עליה שבעה דברים:

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

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

האודיט: שמונה שאלות על סוכן קיים

קחו סוכן אחד שרץ אצלכם עכשיו. כל שאלה היא כן או לא. תשובה שדורשת הסבר היא לא.

  1. יש לו שם, בעלים וגרסה? קובץ מניפסט אחד לכל סוכן.
  2. רשימת הכלים סגורה ומוצהרת מראש? אם התשובה היא "מה שהמודל יבחר", זו לא רשימה.
  3. יש לו גבול נתונים ולא מפתחעל? בפרויקטים שמבוססים על Supabase זו התשובה הכי נפוצה שהיא לא.
  4. הפעולות הבלתי הפיכות עוברות דרך אישור אנושי? שליחה ללקוח, מחיקה, תשלום. הרף מוגדר במספר.
  5. אתם יודעים איפה הוא רץ ולאן מותר לו לפנות? פונקציה, קרון, worker, ולאילו דומיינים.
  6. יש תקרת הוצאה שנאכפת בקוד? מונה טוקנים ומונה איטרציות שעוצרים את הריצה בפועל.
  7. כל קריאת כלי נרשמת? מה נשאל, מה חזר, כמה עלה.
  8. הסוכן פועל בהרשאות המשתמש שהפעיל אותו? רלוונטי מהרגע שיותר מאדם אחד משתמש בו.

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

סדר התיקונים

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

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

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

שלושה שדרוגים שמשנים סוכן

1. תקרה שנאכפת, לא התראה שנשלחת

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

const MAX_TURNS = 12;
const MAX_TOKENS = 120000;

let turns = 0;
let tokens = 0;

while (true) {
  if (++turns > MAX_TURNS) throw new Error('agent: turn cap reached');
  if (tokens > MAX_TOKENS) throw new Error('agent: token cap reached');

  const res = await model.run(messages);
  tokens += res.usage.input_tokens + res.usage.output_tokens;

  if (!res.tool_calls?.length) return res;
  messages.push(...await runTools(res.tool_calls));
}

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

2. המודל לא רואה סוד

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

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

3. הסוכן פועל בהרשאות מי שהפעיל אותו

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

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

טבלת האודיט

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

create table agent_runs (
  id            uuid primary key default gen_random_uuid(),
  agent_slug    text not null,
  agent_version text not null,
  run_id        uuid not null,
  turn          int  not null,
  tool_name     text,
  input         jsonb,
  output        jsonb,
  approved_by   text,
  tokens_in     int  default 0,
  tokens_out    int  default 0,
  cost_usd      numeric(10,4) default 0,
  status        text not null,
  created_at    timestamptz default now()
);

create index on agent_runs (agent_slug, created_at desc);

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

בונה ומפעיל, אותו כיסא

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

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

איך מעבירים את האודיט למישהו אחר

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

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

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

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

ארבע טעויות שחוזרות

מה לקחת מכאן

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

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

צעד ראשון להיום: בחרו סוכן אחד שרץ אצלכם, ענו עליו את שמונה השאלות, ותקנו את שלושת הראשונים בסדר התיקונים. אחר צהריים אחד.