מה זו ערכת-הסוכנים: מעטים-אך-מספיקים "אבני-בניין"
ערכת-הסוכנים של OpenAI (Agents SDK) היא ערכת-הפיתוח הרשמית שהחברה עצמה מספקת לבניית סוכני-AI — לא כלי-צד-שלישי, אלא המסגרת שOpenAI ממליצה עליה למפתחים שרוצים לבנות סוכנים על גבי המודלים שלה. פילוסופיית-העיצוב המוצהרת שלה, לפי התיעוד הרשמי, מבוססת על שני עקרונות שנשמעים כמעט סותרים: "מספיק יכולות לשימוש אמיתי, אבל מעט-מספיק אבני-בניין (Primitives) כדי שיהיה מהיר ללמוד" מצד אחד, וה"יכולת להתאים אישית בדיוק מה שקורה" מצד שני — כלומר, מסגרת שמנסה להישאר פשוטה-להבנה בלי לוותר על גמישות בשעת-הצורך.
מ-Swarm הניסיוני לכלי-ייצור רשמי, מרץ 2025
הערכה הזאת אינה הניסיון הראשון של OpenAI בתחום. מאגר-הקוד של פרויקט-הקודמו, Swarm, נפתח בגיטהאב כבר ב-22 בפברואר 2024 — פרויקט ניסיוני וקטן, לא מיועד לייצור, שהדגים דפוסי-תזמור-רב-סוכנים בסיסיים וצבר עם הזמן כ-22,000 כוכבי-GitHub, אף שמעולם לא היה מיועד לשימוש-בפועל בסביבת-ייצור. ב-11 במרץ 2025 (לפי תאריך-הפתיחה של מאגר-הקוד הרשמי בגיטהאב) פרסמה OpenAI את Agents SDK כ"שדרוג מוכן-לייצור של הניסוי הקודם שלנו לסוכנים, Swarm" — ניסוח רשמי שממקם את הערכה החדשה במפורש כממשיכה-רשמית, לא כפרויקט נפרד, כשנה אחרי שקוד-Swarm המקורי נחשף לראשונה. תוך פחות משנה-וחצי מהשקתה צבר מאגר-הקוד של Agents SDK כמעט 29,700 כוכבי-GitHub, נכון לספטמבר 2026 — קצב-צמיחה מהיר יחסית לגיל-הפרויקט, המשקף חלקית את המשקל שנותנים מפתחים לכך שמדובר בכלי הרשמי של OpenAI עצמה, לא בפרויקט-קהילה.
פילוסופיית-"המעטים-אך-מספיקים" בהשוואה למתחרות
כדאי להשוות את גישת-העיצוב של Agents SDK מול המתחרות שנסקרות באתר זה: אוטוג'ן ולאנגגרף (ראו הערכים הנפרדים) מציעות שכבות-הפשטה עמוקות ומרובות-אפשרויות, מותאמות לתרחישי-שימוש מגוונים-במיוחד — מה שמעניק גמישות רבה, אך גם עקומת-למידה תלולה-יותר למפתח חדש. Agents SDK, לעומת זאת, מכוונת במפורש למספר-קטן של אבני-בניין (התיעוד הרשמי מונה שלוש, ולצידן שכבת-מושבים, כפי שמתואר למטה) שמכסות את רוב-תרחישי-השימוש הנפוצים, במחיר של פחות-גמישות בתרחישים חריגים-במיוחד. הבחירה הזאת אינה מקרית: OpenAI, בתור חברת-המודל עצמה, יכולה להרשות לעצמה למקד את הערכה סביב מה שהיא יודעת שרוב-המפתחים צריכים בפועל, במקום לנסות לכסות כל תרחיש אפשרי מראש.
אבני-הבניין: סוכנים, העברות, מעקות-בטיחות — ולצידן מושבים
התיעוד הרשמי מונה שלוש אבני-בניין מרכזיות — סוכנים, העברות (שמוצגות היום כ"סוכנים ככלים / העברות") ומעקות-בטיחות — ולצידן שכבת-מושבים (Sessions), שמוגדרת בתיעוד כתכונה ולא כאבן-בניין. ארבעת הרכיבים האלה יחד הם מה שמפתח נוגע בו בפועל. "סוכן" (Agent) הוא מודל-שפה שצויד בהוראות ובכלים, עם "לולאה מובנית שממשיכה לרוץ עד שהמשימה הושלמה" — כלומר, הסוכן יכול לקרוא לכלי, לבחון את התוצאה, ולהחליט על צעד נוסף, בלי שהמפתח יצטרך לכתוב את הלולאה הזאת בעצמו בכל פעם — עיקרון-עיצוב שדומה במהותו ללולאת-ReAct שמימשה DSPy כמודול מוכן, וללולאת-הכלים האוטומטית של ערכת ה-AI של Vercel (ראו הערכים הנפרדים), אף שכל אחת מהמסגרות מגיעה מעולם-פיתוח שונה-לגמרי. "העברה" (Handoff) מאפשרת לסוכן "להעביר את הטיפול במשימה לסוכן אחר, ייעודי-יותר" — מנגנון שמאפשר לבנות צוות של סוכנים מתמחים (למשל סוכן-חיוב, סוכן-תמיכה-טכנית) שמעבירים ביניהם את השיחה כשצריך, בלי סוכן-מרכזי אחד שמנסה לדעת הכול. "מעקות-בטיחות" (Guardrails) מריצים בדיקות-תקינות על קלט ופלט "במקביל להרצת-הסוכן" — לא אחריה, כדי לא לבזבז זמן — ומאפשרים לעצור תגובה בעייתית לפני שהיא יוצאת למשתמש. ו"מושבים" (Sessions) הם שכבת-זיכרון מתמשכת ששומרת הקשר-עבודה בין קריאות נפרדות לאותו סוכן, עם תמיכה בגיבויים כמו SQLAlchemy ו-Redis לאחסון-קבוע.
משקל-ההשפעה: מדוע מסגרת "רשמית" משנה את הכללים
יש הבדל מהותי בין מסגרת-סוכנים של צד-שלישי (כמו קרו-איי-איי או לאנגגרף) לבין מסגרת שמפרסמת חברת-המודל עצמה. כשOpenAI מפרסמת דפוס-עיצוב מסוים — למשל, את המושג "Handoff" כמנגנון-רשמי להעברת-שליטה בין סוכנים — הדפוס הזה זוכה לתפוצה מיידית ורחבה בקרב מפתחים שכבר משתמשים במודלי-OpenAI ממילא, בלי שהם צריכים לגלות אותו דרך פרסום עצמאי או המלצת-קהילה. כתוצאה מכך, גם מפתחים שבסוף בוחרים במסגרת-צד-שלישי אחרת נחשפים כמעט תמיד קודם-כל למונחים ולמבנה שOpenAI מציעה, ולעיתים משתמשים באותו אוצר-מילים ("Handoff", "Guardrail") גם כשהם מתארים את הפתרון שבחרו בסופו של דבר — עוד עדות לכך שכלים רשמיים מבית-חברות-המודלים עצמן נושאים משקל-השפעה גדול יותר מגודלם-הטכני היחסי.
התלות ב-Responses API
הערכה נבנתה ומשווקת יחד עם ממשק-API חדש שOpenAI פרסמה באותו זמן בערך — "Responses API" — שמחליף בהדרגה חלק משימושי ה-Chat Completions API הישן עבור בניית-סוכנים, ומספק בסיס-תשתית טוב-יותר ליכולות שהערכה זקוקה להן, כמו ניהול-מצב מתמשך וקריאה-מובנית-לכלים. הערכה עצמה, עם זאת, אינה נעולה רק ל-OpenAI: לפי מאגר-הקוד הרשמי היא "תומכת גם ב-Responses וגם ב-Chat Completions APIs של OpenAI, וכן במעל 100 מודלי-שפה נוספים" — כלומר, אפשר להריץ אותה, עקרונית, גם מול מודלים מתחרים, לא רק מול מודלי-OpenAI. עם זאת, בפועל, השילוב ההדוק ביותר — כולל תמיכה בכל היכולות המתקדמות של הלולאה המובנית ושל המעקב האוטומטי — קיים כשמשתמשים ב-Responses API עצמו; שימוש עם מודל של ספק אחר עשוי לדרוש ויתור על חלק מהיכולות המתקדמות האלה, תלוי ביכולות-שהספק-החלופי תומך בהן.
לצד התמיכה המובנית במעל 100 מודלי-שפה, הערכה כוללת גם תמיכת-בטא במתאם-צד-שלישי ייעודי להרחבת מגוון-הספקים: לפי התיעוד הרשמי, מי שזקוק ל-LiteLLM יכול להתקין חבילת-הרחבה ייעודית ולגשת דרכה למגוון רחב-יותר של ספקי-מודל שאינם נתמכים ישירות. התיעוד ממליץ לפנות למתאם כזה "רק כשנקודות-האינטגרציה המובנות של הספרייה אינן מספיקות", ומזהיר שמתאם-צד-שלישי מוסיף שכבת-תאימות נוספת שבה תמיכת-התכונות וסמנטיקת-הבקשות עשויות להשתנות בין ספק לספק — כלומר גם ספרייה שמזוהה בעיקרה עם מודלי OpenAI משאירה פתח רשמי, אם כי לא-מועדף, למי שרוצה להשתמש בה מול ספקים מתחרים.
מעקב מובנה ומקומה ביחס למסגרות אחרות
מובנה בערכה גם רכיב "מעקב" (Tracing) — תיעוד אוטומטי של ריצות-הסוכן, שמיועד לוויזואליזציה, דיבוג, וניטור של תהליכי-עבודה, ומתחבר לכלי-ההערכה ולכלי-הכוונון-העדין (Fine-Tuning) האחרים של OpenAI. השילוב בין הרכיבים האלה — לולאת-סוכן, העברות, מעקות-בטיחות, זיכרון-מתמשך, ומעקב מובנה — במסגרת רשמית ומצומצמת-יחסית, הוא שהפך את Agents SDK לנקודת-ייחוס שמפתחי-מסגרות אחרים (ובכלל זה מפתחים שמשווים בין כלים שונים) מתייחסים אליה, גם כשהם בוחרים בסוף בכלי-צד-שלישי אחר.
בטיחות כברירת-מחדל, לא כתוספת
החלטת-עיצוב שמייחדת את Agents SDK היא המיקום של מעקות-הבטיחות בתוך הארכיטקטורה: הן אינן שכבה חיצונית ונפרדת שמפתח מוסיף אחרי-שהוא בונה את הסוכן, אלא רכיב מובנה בלולאת-הסוכן עצמה מהיום הראשון. הבחירה הזאת משקפת לקח שהתעשייה למדה בקושי לאורך 2023–2024: מפתחים שהוסיפו בקרות-בטיחות רק בדיעבד, אחרי אירוע בעייתי, גילו לעיתים קרובות שהארכיטקטורה הבסיסית שלהם לא תוכננה מלכתחילה לתמוך בעצירה-אמצע-תהליך או בבדיקה-מקבילה. כשOpenAI מטמיעה Guardrails כרכיב-ליבה ולא כתוסף אופציונלי, היא בעצם מעבירה מסר-עיצובי למפתחים: בטיחות-סוכן צריכה להיות שיקול מהרגע-הראשון של תכנון-המערכת, לא תיקון שמוסיפים אחרי-מעשה.
דוגמת-שימוש: צוות-תמיכה עם העברות
כדי להמחיש איך המרכיבים האלה עובדים יחד, אפשר לחשוב על מוקד-תמיכה אוטומטי: סוכן-"שוער" (Triage Agent) מקבל כל פנייה נכנסת, ומחליט לאיזה סוכן-מתמחה להעביר אותה — "סוכן-חיוב" לשאלות על תשלומים, "סוכן-טכני" לתקלות מוצר, "סוכן-החזרות" לבקשות-ביטול. כל העברה כזו מתבצעת דרך מנגנון ה-Handoff, כך שהסוכן-המתמחה מקבל את מלוא ההקשר של השיחה עד לאותה נקודה, בלי שהמשתמש צריך לחזור ולהסביר את הבעיה מההתחלה. אם הסוכן-המתמחה מזהה שהוא צריך לבצע פעולה רגישה — למשל זיכוי-כספי גדול — מעקה-הבטיחות יכול לעצור את התהליך ולדרוש אישור נוסף לפני שהפעולה מתבצעת בפועל. כל השיחה הזאת, מרגע-הפתיחה ועד סגירתה, נשמרת ב"מושב" (Session) אחד, כך שגם אם המשתמש חוזר שעות אחר-כך עם שאלת-המשך, ההקשר המלא עדיין זמין.
שתי דרכי-בנייה: מדריך-הבחירה הרשמי של OpenAI
OpenAI עצמה מציעה למפתחים שתי דרכים חלופיות לבנות סוכנים, ומבהירה את ההבדל ביניהן במדריך-רשמי: "Agents SDK" מיועדת למי שרוצה "לשלוט בלולאת-הסוכן בתוך האפליקציה שלו" באמצעות סוכנים, כלים, והעברות ניתנים-לשימוש-חוזר, ונדרשת ברמת-מאמץ "בינונית"; חלופה שנייה, עבודה ישירה מול "Responses API", מיועדת למי שרוצה "לעבוד ישירות מול תשובות-המודל ולשלוט באינטגרציה" — בניית סוכן ממש מאפס, ללא שכבת-ההפשטה של הערכה — ונדרשת ברמת-מאמץ "גבוהה". החלוקה הזאת עצמה ממחישה משהו על פילוסופיית-העיצוב של OpenAI: היא לא מנסה לכפות על כל מפתח את אותה רמת-הפשטה, אלא נותנת בחירה מפורשת בין נוחות (Agents SDK) לשליטה-מקסימלית (Responses API ישירות).