APIs לסוכני AI: מ-MCP ועד נקודות קצה מותאמות

כאשר LLMs למדו לקרוא לפונקציות

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

היכולת ששינתה זאת מקבלת מעט מדי קרדיט. היא נתנה למודל בחירה בין יצירת טקסט לבין קריאה לפונקציה. במקום להפיק תמיד את הטוקן הבא, המודל יכול היה כעת להחזיר אובייקט JSON מובנה שמציין שם פונקציה ואת הארגומנטים שלה. סביבת הריצה הייתה מבצעת את הפונקציה הזאת, מזינה את התוצאה בחזרה למודל, והמודל היה ממשיך משם. מאמר ReAct (Yao et al., 2022) הגדיר זאת פורמלית כ-לולאת Thought-Action-Observation. המודל מסיק מה לעשות, מבצע פעולה (קורא לכלי), צופה בתוצאה, וחוזר על כך. כל סוכן AI רציני בשנת 2026 פועל על גרסה כלשהי של התבנית הזאת.

הלולאה

Claude Code, OpenClaw, Codex, Devin ועשרות מערכות אג׳נטיות אחרות פועלות כולן באותו אופן. קוראים לכלי, צופים בתוצאה, מחליטים מה לעשות בהמשך, וחוזרים על כך. Simon Willison ניסח זאת היטב: “סוכן LLM מריץ כלים בלולאה כדי להשיג מטרה.”

Claude Code, למשל, משתמש ב-לולאת מאסטר חד-תהליכית ללא נחיל רב-סוכנים או גרף תזמור מורכב: while(tool_call) -> execute -> feed results -> repeat.

המחקר של Anthropic על אוטונומיית סוכנים מראה ש-משך התורות ב-Claude Code כמעט הוכפל במשך שלושה חודשים, מ-25 ליותר מ-45 דקות. משתמשים נותנים יותר ויותר אמון בלולאה שתפעל בעצמה. הנתונים מראים שמשתמשים מנוסים מפריעים לעיתים קרובות יותר (מעבר מאישור לכל פעולה לניטור אסטרטגי), בעוד שהסוכן עצמו מבקש הבהרה יותר מפי שניים ממספר הפעמים שמשתמשים מפריעים לו.

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

מה נחשב כלי?

LLMs נותנים לנו חופש ניכר להחליט באיזו רמת הפשטה כלי צריך לפעול. בקצה אחד יש נקודות קצה API ספציפיות מאוד: “צור איש קשר ב-HubSpot עם 12 השדות האלה.” בקצה השני יש כלים כמו “הרץ את פקודת ה-bash הזאת” או “בצע את קוד ה-Python הזה”, שהם למעשה “עשה מה שאתה רוצה.”

Devin פועל עם שלושה כלים: shell, code editor, browser. הכלי העיקרי של Claude Code הוא גם shell. OpenClaw משתמש במערכת דינמית של תוספי skills. המגמה בכלי קוד אג׳נטיים הייתה לכיוון פחות כלים, כלליים יותר, במקום הרבה כלים ספציפיים.

Simon Willison הבחין ש-MCP “התפוצץ בתחילה אבל לאחר מכן הרגיש פחות מרכזי” עבור סוכני קוד, משום ש-bash הוא הכלי האוניברסלי. קבצים וסקריפטים הם פרימיטיב עם תקורה נמוכה יותר ממימושים מלאים של שרתי MCP. אם הסוכן יכול לכתוב ולהריץ קוד, הוא יכול לעשות כמעט כל דבר בלי להזדקק להגדרת כלי ייעודית.

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

מה פירושה של נקודת קצה API כיום

עבור סוכני AI, נקודת קצה API מתפקדת כהצהרת יכולת. פרסום נקודה כזאת אומר שאתם (או סוכן ה-AI שלכם) יכולים כעת לעשות משהו שלא היה אפשרי קודם.

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

שרת MCP הוא חבילה אצורה של נקודות קצה API עם תפיסה מוקדמת לגבי האופן שבו יש להשתמש בהן. יוצר ה-MCP כבר קיבל החלטות לגבי אילו נקודות קצה לחשוף, איך לקרוא להן, אילו פרמטרים להציג, ובמשתמע אילו תהליכי עבודה לתמוך בהם. האוצרות הזאת היא גם החוזקה (נוחות, סטנדרטיזציה) וגם החולשה (קשיחות, הגדרת היקף מוטה). השרת של Notion הוא דוגמה קונקרטית: הוא מפרסם 28 כלים, ו-סוכן help-center צריך ארבעה מהם, המחולקים על פני שני חיבורים.

MCPs מחליפים שליטה בנוחות שימוש. בשנת 2026, AI כותב את רוב קוד האינטגרציה. אם סוכן יכול לקרוא תיעוד API ולכתוב את האינטגרציה בעצמו, הטיעון של “נוחות שימוש” לטובת MCP נחלש. שכבת ה-MCP עשויה להיות חשובה בעיקר בתקופת המעבר, בזמן שהכלים עדיין לא הדביקו את יכולת המודל. המדריך של Anthropic על תבניות תכנון לשימוש בכלים הוא מקור מעשי לבניית סכמות כלים, בין אם משתמשים ב-MCP ובין אם בנקודות קצה בודדות.

התפתחות קשורה: llms.txt הוא תקן מוצע שבו אתרים מפרסמים קובץ /llms.txt כדי להנחות מודלי AI למשאבים בעלי ערך גבוה. Anthropic, Cloudflare, Docker ו-Stripe אימצו אותו. MCP מסטנדרט קריאות לכלים; llms.txt מסטנדרט גילוי תיעוד. שניהם מנסים להפוך את הווב לקריא יותר למכונות, מזוויות שונות.

מהי נקודת קצה API בהקשר של סוכני AI?

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

בניגוד למפתחים אנושיים שיכולים לקרוא מדריכים ולדבג באופן איטרטיבי, סוכן מסתמך על הסכמה והתיאור של נקודת הקצה כדי לבצע קריאה נכונה אחת. זו הסיבה ש-תיעוד API המתוכנן לצריכת AI חשוב יותר מאי פעם. רק 24% מהמפתחים מתכננים כיום APIs מתוך מחשבה על סוכני AI, למרות ש-89% משתמשים ב-AI בתהליך העבודה שלהם.

מהו MCP (Model Context Protocol)?

MCP הוא פרוטוקול פתוח שהוצג על ידי Anthropic ומסטנדרט את האופן שבו סוכני AI מתחברים לכלים חיצוניים ולמקורות נתונים. אפשר לחשוב עליו כ-USB-C ל-AI. מחבר יחיד שכל ספק כלי יכול לממש וכל סוכן AI יכול לצרוך. שרת MCP חושף סט כלים (למעשה נקודות קצה API) עם סכמות סטנדרטיות, ולקוח MCP (הסוכן) יכול לגלות אותם ולקרוא להם ללא קוד אינטגרציה מותאם. להסבר טכני מעמיק יותר, ראו את הפוסט שלנו MCP Explained. לתיאור מעשי של MCP בפרודקשן, ראו את הניתוח שלנו של אתגרים אמיתיים בבנייה על MCP של Shopify.

ספקטרום השליטה ב-Quickchat AI

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

Remote MCP: חיבור והפעלה

Remote MCP הוא הדרך המהירה ביותר לחבר AI Agent לפונקציונליות חיצונית. אתם מספקים URL של שרת MCP, Quickchat AI מתחבר אליו, מגלה את כל הכלים הזמינים, ומאפשר לכם לבחור באילו מהם הסוכן שלכם ישתמש.

איך להגדיר זאת:

1. עברו אל AI Actions ב-dashboard של Quickchat AI
2. לחצו על “Add Remote MCP”
3. הדביקו את ה-URL של שרת ה-MCP שלכם (למשל, https://mcp.example.com/sse)
4. הוסיפו אופציונלית authentication token או custom headers (השניים מוציאים זה את זה)
5. לחצו על “Connect.” Quickchat AI מגלה את כל הכלים הזמינים ומציג את שמותיהם
6. הפעילו או כבו כלים בודדים כדי לשלוט באילו מהם הסוכן שלכם יכול להשתמש
7. הגדירו את הדגל “default tool is active” כדי לשלוט אם כלים חדשים שמתגלים יופעלו או יושבתו אוטומטית

מה קורה מתחת לפני השטח:

כאשר לוחצים על Connect, Quickchat AI מזהה אוטומטית את פרוטוקול התעבורה מתוך ה-URL. אם ה-URL מכיל sse, נעשה שימוש בתעבורת SSE; אחרת streamable_http הוא ברירת המחדל. כאשר מספקים auth token, הוא נשלח כ-token מסוג Bearer בכותרת Authorization.

Tool filtering פועל באמצעות מערכת תלת-שכבתית. כל כלי משרת ה-MCP נבדק מול שתי קבוצות: כלים שהופעלו במפורש תמיד נכללים, כלים שהושבתו במפורש תמיד מוחרגים, וכל כלי שאינו באף אחת מהקבוצות נופל חזרה להגדרת “default tool is active” שבחרתם. המשמעות היא שכאשר שרת MCP מוסיף כלים חדשים, אתם שולטים אם הם יהיו זמינים אוטומטית לסוכן שלכם או ידרשו הפעלה מפורשת.

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

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

ראו גם: חיבור הסוכן שלכם לשרת MCP מרוחק, איך להשיק את Quickchat AI MCP שלכם, שיקולי אבטחת MCP, מסמכי Quickchat AI: ערוץ MCP.

AI Actions (HTTP Request): נקודת קצה אחת, שליטה מלאה

AI Action ב-Quickchat AI הוא נקודת קצה יחידה של HTTP API שאתם מגדירים בנפרד עבור ה-AI Agent שלכם. בעוד ש-MCP מייבא חבילת כלים בבת אחת, כל AI Action נותן לכם שליטה מלאה ביכולת ספציפית אחת. לדוגמה מלאה שעובדה מקצה לקצה, ארבע פעולות שיוצרות ומעשירות אנשי קשר, מתעדות עסקאות ופותחות tickets ב-CRM, ראו את מדריך HubSpot AI Actions.

הגדרת AI Action:

1. Name (מקסימום 64 תווים): זה הופך לשם הכלי שה-LLM רואה. הוא מנורמל למזהה תקין (למשל, “Check Order Status” הופך ל-Check_Order_Status)
2. Description (מקסימום 1,000 תווים): זה השדה החשוב ביותר. התיאור אומר ל-LLM מתי להשתמש בכלי הזה. תיאורים טובים מציינים באילו נסיבות שיחה לקרוא לו, איזה מידע לאסוף קודם מהמשתמש, ואיך יש להעביר את התוצאות בחזרה
3. HTTP method: GET, POST, PATCH, DELETE או PUT
4. URL (מקסימום 10,000 תווים): יכול להכיל מצייני מיקום {{parameter_name}} לערכים דינמיים
5. Headers: זוגות מפתח-ערך לאימות ולסוג תוכן
6. Body items / Body JSON: גוף בקשה עם הזרקת פרמטרים
7. Query parameters: ערכי מחרוזת שאילתה ב-URL
8. Parameters (מקסימום 10): לכל אחד שם, תיאור (מקסימום 500 תווים), סוג (str, int, float, bool או custom), דגל required וערך ברירת מחדל אופציונלי

מצייני המיקום {{parameter_name}} הם המנגנון המרכזי. כאשר ה-LLM קורא לכלי, הוא מספק ערכים לכל פרמטר על בסיס הקשר השיחה. לאחר מכן Quickchat AI מזריק את הערכים האלה לתבניות ה-URL, הכותרות, הגוף ומחרוזת השאילתה לפני ביצוע בקשת ה-HTTP. קיימים גם ארבעה משתנים מובנים שניתן להזריק כך: scenario_id, conversation_id, conversation_channel ו-conversation_url.

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

מתחת לפני השטח: Quickchat AI בונה דינמית סכמה מטיפוסת מתוך הגדרות הפרמטרים שלכם עבור כל AI Action. חמשת הסוגים הנתמכים (str, int, float, bool, custom) ממופים למקבילות המקוריות שלהם, והסכמה הזאת משמשת לאימות הקלטים של ה-LLM לפני ביצוע בקשת ה-HTTP.

דוגמה ל-AI Action לבדיקת סטטוס הזמנה:

{
  "name": "check_order_status",
  "description": "כאשר המשתמש שואל על סטטוס ההזמנה שלו וסיפק מספר הזמנה, קרא לנקודת הקצה הזאת כדי לאחזר את הסטטוס הנוכחי. דווח למשתמש על הסטטוס, תאריך המסירה המשוער ומספר המעקב (אם זמין).",
  "method": "GET",
  "url": "https://api.example.com/orders/{{order_id}}",
  "headers": [
    { "name": "Authorization", "value": "Bearer YOUR_API_KEY" },
    { "name": "Content-Type", "value": "application/json" }
  ],
  "parameters": [
    {
      "name": "order_id",
      "description": "מזהה ההזמנה שסופק על ידי המשתמש (למשל, ORD-12345)",
      "type": "str",
      "is_required": true
    }
  ]
}

Testing: ב-dashboard יש כפתור “Test” שמאפשר לכם לספק ערכי פרמטר לדוגמה ולראות את בקשת ה-HTTP בפועל (כולל פקודת curl שנוצרה) ואת התגובה לפני פריסה.

טיפים לכתיבת תיאורי AI Action יעילים:

• היו ספציפיים לגבי מתי הסוכן צריך לקרוא לו: “כאשר המשתמש שואל על סטטוס ההזמנה שלו ומספק מספר הזמנה, קרא לנקודת הקצה הזאת”
• ציינו איזה מידע לאסוף קודם: “לפני הקריאה, ודא שיש לך את כתובת האימייל של המשתמש ואת מזהה ההזמנה”
• תארו איך לטפל בתגובה: “אם הסטטוס הוא ‘shipped’, אמור למשתמש את מספר המעקב מהתגובה”
• עבור תהליכי עבודה מרובי שלבים, תארו את הרצף ב-system prompt הראשי של הסוכן ולא בתיאורי פעולות בודדות, וכדי להעביר ערך בין פעולות ולחסום את הכתיבה על פיו, השתמשו ב-Save to memory יחד עם run-condition

דוגמה מלאה: ל-AI Action צעד אחר צעד שמתעד לידים, שאלות ללא מענה ובקשות דמו ישירות בגיליון אלקטרוני, ראו איך לחבר סוכן AI ל-Google Sheets.

Generate from Text: לתת ל-AI להבין זאת

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

איך זה עובד:

1. אתם מקלידים תיאור בשפה טבעית של מה שאתם רוצים, למשל, “אני רוצה שה-AI Agent שלי יוכל להפעיל Tesla של משתמש כשהוא מבקש”
2. Quickchat AI שולח זאת ל-LLM כאשר הכלי web_search מופעל
3. המודל חוקר את הווב כדי למצוא את ה-API המתאים, קורא תיעוד רשמי, ויוצר מפרט AI Action מלא הכולל URL, method, headers, parameters ודרישות authentication
4. התוצאה חוזרת עם תצורת הפעולה המלאה, ציטוטים לתיעוד שבו נעשה שימוש, והודעת הסבר שמציינת הנחות ופערים
5. אתם בודקים, ממלאים את פרטי הגישה שלכם, ומפעילים

הזנת תיאור בשפה טבעית של היכולת הרצויה.

תצורת ה-AI Action שנוצרה, עם ציטוטים לתיעוד ה-API שבו נעשה שימוש.

יצירת AI Action אוטומטית בנויה סביב שלוש עדיפויות:

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

ה-prompt משתמש בשתי מוסכמות של מצייני מיקום. {{param}} מסמן פרמטרים בזמן ריצה שה-LLM ממלא מתוך הקשר השיחה. [[secret_name]] (סוגריים מרובעים כפולים) מסמן קבועי מפתח כמו מפתחות API ומזהי חשבון שיש להגדיר ידנית לפני הפעלה. כל שם פרמטר חייב להופיע כמציין מיקום {{that_exact_name}} במקום כלשהו בהגדרת הבקשה, ואסור שיהיו מצייני מיקום יתומים.

המערכת משתמשת ב-מדיניות fail-closed. אם המודל אינו יכול לאמת מתוך התיעוד פרט קריטי (שיטת ה-HTTP, ה-URL, סכמת האימות, או מבנה ה-payload הנדרש), לא נוצרת פעולה. במקום זאת, המערכת מחזירה הסבר תמציתי של מה שחסר, במקום לנחש.

כאן הנקודה הפילוסופית לגבי סוכני AI שמגלים APIs מתחברת ליכולת מוצר קונקרטית. יכולת Generate from Text היא ממש סוכן AI (LLM עם חיפוש בווב) שבונה הגדרת כלי עבור סוכן AI אחר (סוכן Quickchat AI שישתמש בו בשיחות).

דוגמה מלאה: למדריך המלא שהופך שני משפטים מוקלדים לשתי פעולות חיות ונבדקות (חיפוש מזג אוויר ללא מפתח ואחת של NASA עם מפתח, כולל סירוב fail-closed), ראו איך לחבר את סוכן ה-AI שלכם לכל API באנגלית פשוטה.

בזמן ריצה, כל סוגי הכלים האלה מורכבים יחד. Quickchat AI אוסף כלי AI Action מסוג בקשת HTTP, כלי Shopify MCP, כלי knowledge base, כלי remote MCP, כלי Discord וכלים מותאמים אחרים לאוסף שיוצג ל-LLM. המודל אינו רואה ביניהם הבחנה. כלי Remote MCP ו-AI Action שהוגדר ידנית נראים זהים ברגע שהם נמצאים ברשימת הכלים.

APIs פתוחים כ-SEO החדש

אם סוכני AI עומדים לגלות ולהשתמש ב-APIs באופן אוטונומי, אז API מתועד היטב וקל לשימוש הופך לנכס הפצה. Gartner צופה שיותר מ-30% מהעלייה בביקוש ל-API תגיע מסוכני AI עד 2026.

חברות שיש להן APIs פתוחים עם חסמי הרשאות מינימליים עשויות לגלות שה-APIs שלהן הופכים לערוץ הרכישה הטוב ביותר שלהן. במקום חשיפות בחיפוש Google, ה”חשיפות” הן סוכני AI שבוחרים להשתמש בשירות שלכם על פני שירות של מתחרה.

אותו היגיון חל גם רמה אחת למעלה. סוכן AI שעונה מתוך התיעוד שלכם יכול בעצמו להיות חשוף כשרת MCP ש-ChatGPT, Claude ו-Cursor קוראים לו ככלי, מה שהופך את הידע שלכם, ולא רק את ה-API שלכם, לניתן לגילוי על ידי הווב האג׳נטי.

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

חברות שה-APIs שלהן אינם מתועדים או חסומים מאחורי דרישות הרשאה כבדות עשויות למצוא את עצמן בלתי נראות לווב האג׳נטי, באותו אופן שבו חברות ללא אתרים הפכו בלתי נראות ל-Google בשנות ה-2000.

שימוש במחשב לעומת APIs

יש השקעה משמעותית בלימוד מודלי AI “שימוש במחשב” (לחיצה על כפתורים, מילוי טפסים, ניווט בממשקי משתמש). Anthropic, OpenAI (Operator) ופרויקטי קוד פתוח כמו Browser Use מציעים כולם גרסאות לכך.

אבל שימוש בדפדפן הוא מעקף ל-API חסר. קריאת POST /orders נמשכת מילישניות ומחזירה נתונים מובנים. סוכן דפדפן שמנווט בתהליך checkout נמשך דקות ועלול להישבר כאשר כפתור זז שלושה פיקסלים שמאלה. APIs מהירים יותר, דטרמיניסטיים יותר וזולים יותר להרצה.

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

התגובה ארוכת הטווח הטובה יותר ל”אין לנו API לזה” היא כנראה לבנות את ה-API במקום ללמד AI להשתמש ב-GUI. ככל שיותר תוכנה נכתבת על ידי סוכני AI עבור סוכני AI, עלות הבנייה והתחזוקה של APIs יורדת. החישוב הכלכלי שהפך scraping של UI לזול יותר מבניית API משתנה.

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

כלים לעולם הפיזי

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

RT-2 ו-Gemini Robotics של Google DeepMind משתמשים באותה ארכיטקטורה, אלא שהכלים שולחים פקודות ל-actuators במקום ל-APIs. מסגרת SPCA (Sense-Plan-Code-Act) מגדירה זאת פורמלית לרובוטיקה: סריקת הסביבה, תכנון הגישה, יצירת קוד בר ביצוע, ביצועו, וצפייה בתוצאות.

אין API עבור “הזז את הצמח שעל השולחן שלי ימינה.” אבל רובוט עם מצלמה יכול להגדיר את move_object(object_id="plant_01", direction="right", distance_cm=15) ככלי תוך כדי תנועה ואז לקרוא לו. הגדרת הכלי משמשת כממשק בין שכבת ההסקה לבין שכבת הביצוע הפיזית, אותו תפקיד שנקודות קצה API ממלאות בתוכנה.

ארכיטקטורת LLM + כלים + לולאה היא כללית. במקרה היא הכי קלה למימוש בתוכנה כיום, אבל הרובוטיקה מדביקה את הפער.

APIs שנכתבים על ידי AI, עבור AI

בתוך כשנתיים (2024 עד 2026), עברנו ממצב שבו רוב הקוד נכתב על ידי בני אדם ל-מצב שבו רוב הקוד נכתב על ידי AI. זה רגע טוב לשקול מחדש מהי נקודת קצה API. יותר ויותר, נקודת קצה היא הצהרת יכולת שנועדה להתגלות ולהיות מופעלת על ידי מכונות, לא ממשק טכני שמפתחים אנושיים קוראים עליו תיעוד ואז משלבים ידנית.

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

הספקטרום שעברנו עליו ב-Quickchat AI Agents משקף נקודה רחבה יותר. רמת השליטה הנכונה תלויה במקרה השימוש שלכם. Remote MCP מתאים היטב ליצירת אבטיפוס מהירה. Individual AI Actions נותנים לכם שליטה מדויקת לסוכנים מול לקוחות בפרודקשן. Generate from Text מאפשר ל-AI לחקור את ה-API ולבנות עבורכם את הגדרת הכלי כאשר אתם עדיין בוחנים אפשרויות.

ובכל רמה, התבנית הבסיסית זהה. LLM, סט כלים, לולאה. בין אם הכלים הם פקודות bash, נקודות קצה API, שרתי MCP או actuators של רובוט, אלה כלים לאורך כל הדרך.