אתר לסוכני בינה מלאכותית: סדר הבדיקות לתוכן, ניווט וטפסים

איך מכינים אתר לסוכני בינה מלאכותית: מתחילים במשימה מוגדרת

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

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

נכון ל־28 באוקטובר 2026, הנושא כבר מופיע בתיעוד ובהכרזות של ספקים: Adobe עדכנה ב־23 באוקטובר 2026 הסבר על חשיפת פעולות אתר לסוכנים באמצעות WebMCP. באותו תאריך הודיעה Visamundi על שילובו בטופס בקשת אשרה, תוך השארת האישור והתשלום בשליטת המשתמש. אלה פרסומי החברות על הגישה ועל היישום שלהן, והם אינם הוכחה לתאימות של כל סוכן לכל אתר. ראו את ההסבר של Adobe ואת הודעת Visamundi.

WebMCP מאפשר לדף להציע לסוכן פעולות מוגדרות עם קלט מובנה. בתיעוד הרשמי של Chrome (עודכן ב־7 באוקטובר 2026) הוא עדיין מתואר כהצעה לתקן שנמצאת בדיון פעיל ועשויה להשתנות, ולכן כדאי לבדוק את התמיכה בפועל בדפדפן ובסוכן שנבחרו. אפשר לשפר את האתר הקיים ולהוסיף את החיבור כשכבה נוספת, בהתאם לתיעוד Chrome.

שלב ראשון: ודאו שהמידע הדרוש להחלטה מופיע בטקסט

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

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

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

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

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

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

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

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

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

שלב שלישי: בדקו תוויות, הוראות ושגיאות בכל טופס

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

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

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

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

שלב רביעי: קבעו מתי נדרש אישור אנושי

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

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

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

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

שלב חמישי: הוסיפו ממשק מובנה כשיש צורך ברור

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

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

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

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

שלב שישי: השלימו בדיקת קבלה לפני פתיחה למשתמשים

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

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

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

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