מהו AI agent: חמישה סוגים קלאסיים ושתי הגדרות יריבות

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

ה-percept הוא זוג — איפה אני, והאם מלוכלך כאן — והפעולות הן SUCK, LEFT ו-RIGHT. כל התוכנית היא שורה אחת.

type Percept = { dirty: boolean; where?: "A" | "B" };
type Action = "SUCK" | "LEFT" | "RIGHT";

const textbook = (p: Percept): Action =>
  p.dirty ? "SUCK" : p.where === "A" ? "RIGHT" : "LEFT";   

הריצו אותה מול כל תצורת פתיחה של עולם שני הריבועים:

A dirty, B dirty, start A    -> steps=3 clean=true
A clean, B dirty, start A    -> steps=2 clean=true
A dirty, B clean, start B    -> steps=2 clean=true

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

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

const dirtOnly = (p: Percept): Action => (p.dirty ? "SUCK" : "RIGHT");

A dirty, B dirty, start A    -> steps=3   clean=true   still dirty=0
      t=0 at=A percept={dirty:true}  -> SUCK
      t=1 at=A percept={dirty:false} -> RIGHT
      t=2 at=B percept={dirty:true}  -> SUCK

A dirty, B clean, start B    -> steps=500 clean=false  still dirty=1
      t=0 at=B percept={dirty:false} -> RIGHT
      t=1 at=B percept={dirty:false} -> RIGHT
      t=2 at=B percept={dirty:false} -> RIGHT
      t=3 at=B percept={dirty:false} -> RIGHT

אותה תוכנית, שני ריבועים. ממצב פתיחה אחד היא מסיימת בשלושה צעדים; מאחר היא נוסעת לתוך הקיר הימני חמש מאות פעמים והייתה ממשיכה עד שהסוללה הייתה מתה. היא לא יכולה לתפוס את ההבדל בין שני המצבים, ולכן לא יכולה לפעול בהם אחרת. Russell ו-Norvig מנסחים את התוצאה הכללית בשורה אחת: לולאות אינסופיות הן לעיתים קרובות בלתי נמנעות עבור simple reflex agents בסביבות נצפות חלקית.¹

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

let seed = 12345;
const rnd = () => ((seed = (seed * 1103515245 + 12345) & 0x7fffffff) / 0x7fffffff);

const coin = (p: Percept): Action => (p.dirty ? "SUCK" : rnd() < 0.5 ? "LEFT" : "RIGHT");  

אלפיים הרצות של מסדרון שכולו מלוכלך בשלושה גדלים, עם מחולל seeded אחד לכל האורך:

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

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

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

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

שימו לב איזו שורה יוצאת דופן. כמעט כל צוות שבונה agents ב-2026 כותב את E, A ו-S — סכמות הכלים, האינטגרציות, פורמט ההודעות — כי הקוד לא ירוץ בלעדיהם. כמעט אף אחד לא כותב את P. בלעדיו, ל-"ה-agent שלנו מצליח" אין משמעות שאפשר לבדוק, ו-"רציונלי" לא יכול לחול על המערכת בכלל, רק על הדגמה. פרק 29 עוסק בהפיכת P למספר, וזו הסיבה שהוא קיים.

    ┌───────────────────────── the environment ─────────────────────────┐
    │                                                                   │
    │   ┌──────────────────────── the agent ─────────────────────┐      │
    │   │                                                        │      │
 ───┼──►│  sensors  ──►  the agent program  ──►  actuators  ─────┼──────┼──►
percept │                                                        │    action
    │   └────────────────────────────────────────────────────────┘      │
    └───────────────────────────────────────────────────────────────────┘
                                   ▲
              the performance measure lives out here, in the head of
              whoever built the thing, and the agent cannot change it

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

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

        col  0 1 2 3 4 5 6
      row 0  * . . # . . *
      row 1  . # . # . # .
      row 2  . # . S . # .        S = the robot starts here
      row 3  . # . # . # .
      row 4  * . . # . . *

השדרוג המתבקש הוא זיכרון. ה-agent שומר מפה: כל ריבוע שעליו עמד וכל ריבוע שבו הפגוש הופעל. הכלל שלו הוא ללכת לריבוע סמוך שלא ביקר בו — ימינה, ואז למטה, ואז שמאלה, ואז למעלה — ולסגת כשכל מה שסביבו ידוע. זהו model-based reflex agent: הוא מחזיק מצב פנימי מהיסטוריית ה-percepts, ולכן יכול לפעול לפי מה שאינו רואה כרגע.

זה שיפור אמיתי, ועדיין לא מספיק:

5,000 steps allowed -> steps=5,000  distinct squares visited=13/25  still dirty=2/4

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

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

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

goal-based (fewest moves)      -> moves=27  battery=52  still dirty=0
      from 2,3 -> 4,6 via 5 moves:  2,3 2,4 3,4 4,4 4,5 4,6
      from 4,6 -> 0,6 via 4 moves:  4,6 3,6 2,6 1,6 0,6
      from 0,6 -> 4,0 via 10 moves: 0,6 0,5 0,4 1,4 2,4 2,3 2,2 3,2 4,2 4,1 4,0
      from 4,0 -> 0,0 via 4 moves:  4,0 3,0 2,0 1,0 0,0

עשרים ושבעה מהלכים, הרצפה נקייה. אבל הביטו בעמודת הסוללה ובמקטע האחרון של התוכנית. עמודה 0 מכוסה שטיח: חציית ריבוע עם שטיח עולה שש יחידות סוללה, ריבוע מרוצף עולה אחת. ה-agent חזר הביתה במעלה עמודה 0 כי זה ארבעה מהלכים במקום שמונה, וארבעת המהלכים על השטיח עלו 24, בעוד שהמעקף בן שמונת המהלכים היה עולה 13.

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

השינוי בקוד הוא איבר אחד בתוך החיפוש. חיפוש לרוחב סופר מהלכים; גרמו לו לספור עלות במקום, וקיבלתם את האלגוריתם של Dijkstra ו-agent אחר:

const nd = dist.get(k)! + (byCost ? cell.cost : 1);   // <- the entire difference

goal-based    (fewest moves)   -> moves=27  battery=52  still dirty=0
utility-based (cheapest route) -> moves=31  battery=41  still dirty=0
      from 4,0 -> 0,0 via 8 moves: 4,0 4,1 4,2 3,2 2,2 1,2 0,2 0,1 0,0

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

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

עכשיו תנו ללכלוך לחזור. ארבעה חדרים מתלכלכים שוב בארבעה קצבים שונים, וה-agent לעולם לא מקבל אותם. הוא מבקר בחדר אחד בכל tick ורואה רק את החדר הזה. מדד הביצוע הוא room-ticks שבילו מלוכלכים לאורך 4,000 ticks — נמוך יותר טוב יותר.

learning agent, בפירוק של ספר הלימוד, הוא כל אחד מאלה לעיל בתוספת שלושה חלקים: רכיב למידה שמשנה את ה-agent, מבקר שאומר לו איך ה-agent מתפקד מול תקן ביצוע קבוע, ו-מחולל בעיות שמציע פעולות שכדאי לנסות בגלל מה שילמדו.¹ שלוש מדיניות באותה סביבה. הראשונה לא לומדת; השנייה והשלישית לומדות אותו דבר ומשתמשות בו אחרת.

הקצבים הנסתרים היו 0.35 למטבח, 0.05 למסדרון, 0.02 לחדר העבודה ו-0.01 לעליית הגג — ו-learner A מצא אותם. הוא זיהה נכון את המטבח כחדר המלוכלך ביותר בבית, ואז הלך למטבח בכל tick עד סוף הסימולציה, בעוד שלושת האחרים נשארו מלוכלכים לנצח. הוא גרוע פי חמישה מלא ללמוד בכלל, והוא לא מקולקל.

הלקח הוא של סעיף התועלת. learner A מיקסם "ההסתברות שהחדר שאני עומד לבקר בו מלוכלך". מדד הביצוע היה "room-ticks שבילו מלוכלכים". מספרים שונים; השני הוא מה שהמבקר ניקד, ואף אחד לא אמר זאת ל-agent. learner B מכפיל את אותו קצב שנלמד בזמן שעבר מאז הביקור האחרון — הלכלוך שהוא מצפה למצוא, ולא הסיכוי למצוא בכלל — ומנצח את הסיור שממנו התחיל.

פרט מימוש אחד הכריע את התוצאה. בגרסה הראשונה של learner B, חדר שבו לא הופיע לכלוך בשלושה ביקורים קיבל קצב של בדיוק אפס — ואפס כפול כל דבר הוא אפס, לכן לא ביקרו בו שוב לעולם וההערכה לא יכלה להתעדכן. החלקת השבר, הצלחות ועוד אחת מעל ניסיונות ועוד שתיים, הפכה 11,895 ל-1,576. "עדיין לא נצפה" ו-"נמדד ויצא אפס" הן טענות שונות, ומערכת ששומרת אותן באותו שדה מקבלת החלטות שאינה יכולה לבטל.

  1  simple reflex    percept ────────────────────────────────► rules ────► action
  2  model-based      percept ──► [state] ──────────────────► rules ────► action
  3  goal-based       percept ──► [state] ──► [goal] ──────► search ───► action
  4  utility-based    percept ──► [state] ──► [goal] ──► [U] ──► argmax ► action
  5  learning         all of the above, plus [critic] ──► changes the parts above

כל אחד מהחמישה נמצא היום בפרודקשן בשם אחר.

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

צ'אט הוא model-based reflex agent שהמודל שלו אינו פנימי. בספר הלימוד המצב הוא משתנה בתוך תוכנית ה-agent. בצ'אט הוא התמליל: הוא חי בצד שלכם, נשלח מחדש במלואו בכל קריאה, ונבנה מאפס בתוך המודל בכל פעם. זה החשבון הריבועי של פרק 16, וזה אותו אובייקט שספר הלימוד צייר כתיבה שכותרתה "state". הנה ההבדל, כפי שנמדד על שאלת המשך אחת עם ובלי שתי ההודעות שלפניה:

with the transcript      prompt=67  "The current temperature in Lisbon, Portugal is 15°C."
without the transcript   prompt=29  "Lisbon is the capital of Portugal, not a city in Portugal."

אותו מודל, אותן שלוש מילים של קלט משתמש, והשני הוא רובוט המסדרון שנוסע לתוך הקיר. לא היו כלים בהרצה הזו, לכן ה-15 מומצא — אבל המצב הוא מה שגורם לשאלת ההמשך להיות בעלת משמעות בכלל. אתם בונים אותו מחדש בכל פעם ומשלמים עליו פי 2.3 input tokens בשיחה בת שני תורים. פרק 16 מדד לאן המכפיל הזה מגיע בתור ארבעים.

Reflexion הוא learning agent שמשנה את הקלט שלו ולא את התוכנית שלו. בפירוק של ספר הלימוד רכיב הלמידה משנה את רכיב הביצוע. Reflexion משאיר את המשקלים כפי שהם וכותב טקסט רפלקטיבי לתוך buffer אפיזודי שהניסיון הבא קורא.³ רכיב הלמידה הוא prompt, הזיכרון הוא שורת מסד נתונים, רכיב הביצוע הוא מודל קפוא — והתרשים הוא זה של ספר הלימוד, בלי שינוי.

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

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

הלולאה למטה שולחת את השיחה למודל; אם התשובה מכילה tool call היא מבצעת את הכלי, מצרפת את התוצאה ושולחת את הכול שוב. היא רצה מול Qwen2.5-0.5B-Instruct מקומי מאחורי endpoint בצורת OpenAI על המכונה הזו — התפר מפרק 14, כך שללולאה לא אכפת ואינה יודעת מה נמצא מאחורי הפורט.

const BASE = process.env.LLM_BASE_URL ?? "http://127.0.0.1:8799/v1";

async function loop(question: string, maxTurns = 6) {
  const messages: Msg[] = [
    { role: "system", content: SYSTEM },
    { role: "user", content: question },
  ];

  for (let turn = 1; turn <= maxTurns; turn++) {
    const reply = await call(messages, TOOLS);
    const calls = reply.choices[0].message.tool_calls ?? [];
    messages.push(reply.choices[0].message);

    if (!calls.length) return messages;                      

    for (const c of calls) {
      const out = runTool(c.function.name, JSON.parse(c.function.arguments));
      messages.push({ role: "tool", name: c.function.name, content: out });
    }
  }
  throw new Error("turn cap reached");                       
}

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

=== a question the model cannot answer, one tool available
  turn 1  prompt= 187  out= 21  finish=tool_calls  CALL get_temperature({"city": "Oslo"})
          tool  get_temperature -> {"city":"Oslo","celsius":4}
  turn 2  prompt= 238  out= 12  finish=stop        TEXT "The current temperature in Oslo is 4
                                                        degrees Celsius."
  => model calls=2  prompt tokens=425  output=33  wall=6,257 ms
  => stopped by: the model produced text instead of a call

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

עוד שתי הרצות שוות את המקום. כשמבקשים ממנו להשוות שתי ערים, המודל מוציא שתי tool calls באותו תור, מקבל את שתי הקריאות בחזרה, וטועה בהשוואה:

  turn 1  prompt= 188  out= 43  finish=tool_calls  CALL get_temperature({"city": "Oslo"}),
                                                        get_temperature({"city": "Lisbon"})
          tool  get_temperature -> {"city":"Oslo","celsius":4}
          tool  get_temperature -> {"city":"Lisbon","celsius":19}
  turn 2  prompt= 284  out= 13  finish=stop        TEXT "Oslo is currently warmer than Lisbon
                                                        at 4°C."

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

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

  turn 1  prompt= 187  out= 21  CALL get_temperature({"city": "Oslo"})
  turn 2  prompt= 238  out= 12  TEXT "The current temperature in Oslo is 4 degrees Celsius."
  turn 3  prompt= 261  out= 30  TEXT "Could you please specify the exact location you're..."
  turn 4  prompt= 302  out= 14  TEXT "Sure! Could you tell me which city you're interested in?"
  turn 5  prompt= 327  out= 35  TEXT "I'm sorry, but I need more details to provide an..."
  turn 6  prompt= 373  out= 12  TEXT "Which city would you like to know the temperature for?"
  => model calls=6  prompt tokens=1,688  output=124  wall=25,261 ms  stopped by: turn cap

פי ארבעה input tokens, פי ארבעה זמן שעון, וסיום שבו ה-agent שכח מה שאלו אותו והוא חוקר את המשתמש על שאלה שכבר ענה עליה בתור הראשון. התשובה הנכונה הייתה על המסך בתור 2, וכל תור אחריו החמיר את התמליל.

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

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

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

"ב-Anthropic, אנחנו מסווגים את כל הווריאציות האלה כ-agentic systems, אבל מותחים הבחנה ארכיטקטונית חשובה בין workflows לבין agents: Workflows הן מערכות שבהן LLMs וכלים מתוזמרים דרך נתיבי קוד מוגדרים מראש. Agents, לעומת זאת, הן מערכות שבהן LLMs מכוונים באופן דינמי את התהליכים ואת השימוש בכלים של עצמם, ושומרים על שליטה באופן שבו הם מבצעים משימות."⁴

המבחן הוא שאלה על קוד המקור שלכם: מי בחר את הצעד הבא? switch בתוכנית שלכם: workflow. המודל: agent. אותו מסמך אומר ש-agents "הם בדרך כלל פשוט LLMs שמשתמשים בכלים על בסיס משוב סביבתי בלולאה" — וזה בדיוק הקוד שלמעלה.

הגדרה שתיים שמה את הגבול בעצמאות מהמשתמש. A practical guide to building agents של OpenAI פותח את עמוד ההגדרה שלו כך:

"בעוד שתוכנה קונבנציונלית מאפשרת למשתמשים לייעל ולאוטומט workflows, agents מסוגלים לבצע את אותם workflows בשם המשתמשים בדרגת עצמאות גבוהה. Agents הם מערכות שמבצעות משימות באופן עצמאי בשמכם."⁵

שני משפטים אחר כך, באותו עמוד, הוא מחריג:

"אפליקציות שמשלבות LLMs אבל לא משתמשות בהם כדי לשלוט בביצוע workflow — חשבו על chatbots פשוטים, LLMs של תור יחיד, או מסווגי סנטימנט — אינן agents."⁵

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

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

שלוש מערכות שקיימות ב-2026, תחת שתי ההגדרות.

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

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

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

שום דבר מזה אינו חדש. Wooldridge ו-Jennings סקרו את המשמעויות המתחרות של "agent" ב-1995;⁶ Franklin ו-Graesser שאלו את שאלת הפרק הזה ב-1996, אספו את ההגדרות שהסתובבו אז וגילו שהן לא מסכימות.⁷ סקר מ-2023 עדיין מגדיר agents מעקרונות ראשונים — "ישויות מלאכותיות שחשות את סביבתן, מקבלות החלטות ופועלות"⁸ — כי לא הייתה הסכמה מודרנית שאפשר לצטט, ו-CoALA מתאר חלקים במקום למתוח גבול בכלל.⁹ שלושים שנה של הימנעות מהסכמה אומרות שהמילה עושה יותר מעבודה אחת.

עכשיו ההשלכה שמגיעה לפני הפילוסופיה, שהיא החשבון.

כל מדידה כאן היא באותה צורה. הקריאה היחידה עלתה 39 input tokens; אותה שאלה עם כלי אחד עלתה 420 על פני שתי קריאות; הלולאה שתנאי העצירה שלה הוסר עלתה 1,688 על פני שש. הגידול גרוע מלינארי, כי תור n נושא איתו כל תור קודם: עמודת ה-prompt של הרצת ששת התורים היא 187, 238, 261, 302, 327, 373. פרק 16 גזר שהסך הוא $\Theta(n^2)$ והתאים את העקומה לשיחה אמיתית. agent הופך כל משימה לשיחה הזו, בין שאדם רואה אותה ובין שלא.

אם ספירות ה-token המדודות האלה היו הולכות ל-endpoint מסחרי בתעריפים שפרק 16 קרא ב-6 בספטמבר 2026 — $2.00 למיליון input tokens ו-$12.00 למיליון output — ארבע ההרצות היו מתומחרות כך:

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

וזו הסיבה שהחצי המועיל בשני המסמכים הוא החצי על לא לבנות את זה. Anthropic ישירה: מצאו את הפתרון הפשוט ביותר האפשרי והוסיפו מורכבות רק כשצריך, מה ש"עשוי לומר לא לבנות agentic systems בכלל", משום ש-agentic systems "מחליפות שיהוי ועלות בביצועי משימה טובים יותר" ו"עבור יישומים רבים, אופטימיזציה של קריאות LLM יחידות עם retrieval ודוגמאות in-context בדרך כלל מספיקה".⁴ המקרה שלה בעד agent צר: בעיות פתוחות שבהן אי אפשר לחזות את מספר הצעדים ואי אפשר לקודד מסלול hardcoded, בסביבה שאתם סומכים עליה, תוך קבלה של "עלויות גבוהות יותר, והפוטנציאל לשגיאות מצטברות".⁴ המסך של OpenAI הוא תמונת ראי — שיפוט מורכב, מערכי כללים שאי אפשר לתחזק, נתונים לא מובנים — ומסתיים באותו אופן: "אחרת, פתרון דטרמיניסטי עשוי להספיק".⁵

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

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

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

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

LLM Powered Autonomous Agents של Lilian Weng (2023) הוא הפירוק המוכר ביותר של language agent לתכנון, זיכרון ושימוש בכלים, והוא הקריאה הבאה הנכונה לצד שני מסמכי הספקים; שלושת הרכיבים שלו הם פרקים 23, 24 ו-18 של הקורס הזה, בסדר הזה.

כל מספר בפרק הזה הופק על המכונה הזו ושום דבר לא הוערך. המסדרון, תוכנית הרצפה, ארבעת ה-agents שהולכים בה ושלוש מדיניות הסיור הם ה-TypeScript שלמעלה, רץ על Node 22; נתוני ה-agent האקראי הם ממוצעים על פני 2,000 הרצות seeded כל אחד, ונתוני הסיור הם הרצות seeded יחידות של 4,000 ticks. עקבות המודל מגיעים מ-Qwen2.5-0.5B-Instruct ב-float32 על CPU עם greedy decoding, שהוגש מעל loopback על ידי endpoint מקומי קטן ב-Python שטוען את המשקלים ומדבר בצורת OpenAI chat-completions — שוב התפר, עם הטנזורים בצד ה-Python והלולאה בצד ה-TypeScript — כך שספירות ה-token הן של ה-tokenizer של אותו מודל וה-latencies הן של אותה מכונה. הנתונים היחידים שנלקחו ממקום אחר הם שני המחירים בטבלת העלות, שהם התעריפים שפרק 16 קרא מדף התמחור של OpenAI ב-6 בספטמבר 2026, ומוחלים כאן על ספירות token שנמדדו מקומית כהמחשה ולא כחשבונית שנצפתה.