מדריך: כך הופכים API ל-agent-ready עם Apigee של גוגל קלאוד

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

01מה גוגל פרסמה ולמה זה חשוב עכשיו

המדריך החדש, שנכתב על ידי טיילר איירס ופורסם במסגרת עדכוני Google Cloud, מוביל מפתחים דרך שלושה שלבים מרכזיים: שכפול ריפוזיטורי לדוגמה, פריסה באמצעות כלי בשם Apigee Feature Templater (בקיצור aft), ובדיקת ה-endpoint שנוצר. המטרה: לקחת נתוני API רגילים ולהפוך אותם לניתנים לגילוי בקלות על ידי סוכני קידוד, בלי לכתוב שכבת תיווך ידנית לכל שירות.

התזמון לא מקרי. ב-13 באוגוסט התקיים גם TechTalk קהילתי של גוגל קלאוד שהדגים את הצד השני של המשוואה: איך אוכפים סינון כלים גרנולרי, מנהלים מכסות הרצה ומרחיבים אקוסיסטמות סוכנים מאובטחות, בלי להאט את קצב הפיתוח. המסר של גוגל ברור: agent-ready APIs הופך מפיצ'ר נחמד לדרישת חובה בארגונים שמאמצים סוכני AI.

02שלב אחר שלב: מריפוזיטורי לדוגמה ועד endpoint עובד

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

1. משכפלים את ריפוזיטורי הדוגמה של גוגל קלאוד למכונה המקומית או ל-Cloud Shell, ומוודאים שיש לכם פרויקט GCP פעיל עם Apigee מופעל.
2. מתקינים ומריצים את Apigee Feature Templater (aft), שמייצר מתוך התבנית את קונפיגורציית ה-proxy וההגדרות שהופכות את ה-API לניתן לגילוי.
3. פורסים את התוצר לסביבת Apigee שלכם באמצעות ה-CLI, ועוקבים אחרי הלוגים כדי לוודא שהפריסה הסתיימה בהצלחה.
4. בודקים את ה-endpoint החדש בקריאה ידנית, ואז נותנים לסוכן קידוד לנסות לגלות ולצרוך אותו בעצמו, זה מבחן הקבלה האמיתי.
5. מוסיפים מדיניות: סינון כלים גרנולרי כדי שהסוכן ייחשף רק למה שמותר לו, ומכסות הרצה שימנעו מסוכן שנתקע בלולאה לרוקן לכם את התקציב.

# שכפול ריפוזיטורי הדוגמה ופריסה עם aft
git clone <sample-repo-url>
cd sample-repo
aft deploy --project=$GCP_PROJECT --env=eval

# בדיקת ה-endpoint שנוצר
curl -H "Authorization: Bearer $(gcloud auth print-access-token)" \
  https://$APIGEE_HOST/agent-ready/v1/health

03הצד השני של המטבע: אבטחה ומכסות לפני הכל

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

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

הנקודה החשובה שגוגל מדגישה: אפשר לעשות את כל זה בלי לפגוע במהירות הפיתוח. ההגדרות יושבות בשכבת ה-gateway, כך שצוותי המוצר ממשיכים לפתח כרגיל וה-governance נאכף במקום אחד.

04מה זה אומר למפתחים ולארגונים בישראל

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

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

05מה הלאה

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