מה סוכן ה-AI שלי עשה? ארבע שאלות שצריך לענות עליהן עם הוכחות

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

אנחנו מפתחים את Weft. העובדות על מוצרים אחרים לקוחות מהעמודים הרשמיים שלהם, ונבדקו ב-27 באוקטובר 2026.

למה תגובה שאומרת "בוצע" לא מספיקה?

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

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

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

מהן ארבע השאלות?

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

1. מי עשה את זה? איזה לקוח, באיזה חיבור, תפס וסיים את המשימה.
2. מה השתנה? התוצאה, ועוד ראיות שאפשר לבדוק בלי לסמוך על הסוכן: hash של commit, ‏URL, קובץ, מזהה הודעה.
3. מה לא נעשה? החלקים שהוא דילג עליהם, והדברים שהוא לא היה בטוח בהם.
4. מה הוחלט, ולמה? כל בחירה שנעשתה בדרך, עם האפשרויות שנשקלו, וכל פעם שהחזרתם את העבודה.

איך אדע איזה סוכן עשה את זה?

Weft מתחבר ללקוחות AI דרך Model Context Protocol בנקודת קצה אחת, https://letsweft.com/api/mcp. כל לקוח OAuth וכל אסימון גישה אישי הוא שחקן נפרד. משימה רושמת איזה לקוח יצר אותה, והלוח מציג את השם שהלקוח רשם בהתחברות, ועוד אייקון. כל אירוע ביומן המשימה שומר אם הוא הגיע מאדם או דרך MCP, ואיזה לקוח שלח אותו.

היומן המלא (get_task_history במצב full) מציג את מזהה הלקוח הגולמי לכל אירוע: מזהה לקוח OAuth, או mcp-token ואחריו המזהה של האסימון. זה לא שם ידידותי, אבל הוא מדויק, והוא מבדיל בין שני חיבורים גם כשהם מגיעים מאותו מוצר.

גם הבעלות בזמן העבודה מפורשת. סוכן קורא ל-start_task, שתופס את המשימה בחכירה של 20 דקות ומעביר אותה ל-Doing. ‏report_progress מחדש את החכירה. סוכן שני שמנסה לקחת את אותה משימה מקבל already_claimed, וחכירה שפגה משחררת את המשימה למישהו אחר. המדריך ללולאת התפיסה מסביר את זה צעד אחר צעד, והרצת כמה סוכנים על לוח אחד עוסק במקרה של כמה לקוחות.

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

מה השתנה, ואפשר לבדוק את זה בלי לשאול את הסוכן?

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

• outcome: עד 1,000 תווים על מה נעשה ואיפה התוצאה נמצאת.
• artifacts: עד 20 רשומות, כל אחת עם סוג (url, ‏file, ‏message, ‏commit וכן הלאה), מיקום, ואופציונלית תקציר sha256.
• claims: מה שהסוכן טוען שעשה, נשמר כטענות ולא כעובדות מאומתות.
• notDone ו-unknowns: בסעיף הבא.
• nextStep: מה הסוכן יעשה בהמשך אם תאשרו.

complete_task({
  "id": "<task id>",
  "runId": "<from start_task>",
  "leaseToken": "<from start_task>",
  "outcome": "Rate limiting added to /login; PR open, not merged.",
  "artifacts": [
    { "kind": "commit", "uri": "<repo>/commit/<hash>" },
    { "kind": "url", "uri": "<repo>/pull/<number>" }
  ],
  "notDone": ["Did not change the signup endpoint"],
  "unknowns": ["Limit of 5 per minute is a guess; no traffic data"],
  "nextStep": "Merge the PR to main"
})

שורת ה-outcome היא עדיין סיפור. ה-artifacts הם החלק שאפשר לבדוק. hash של commit קיים ב-repository שלכם או שלא. ‏URL נטען או שלא. ה-sha256 של קובץ תואם או שלא. אם בקבלה יש outcome ואין artifacts, התייחסו אליה כעבודה שהסוכן דיווח עליה, כי זה בדיוק מה שהיא. בגרסת הדפדפן, כרטיסי Done מציגים אם משימה היא Verified או Agent-reported.

מה הסוכן לא עשה?

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

קראו את הרשימות האלה קודם. "לא הרצתי את הבדיקות מול מסד הנתונים של staging" משנה את מה שתעשו עכשיו. קבלה בלי אף רשומת notDone על משימה גדולה היא כשלעצמה סיבה לשאול שאלה.

מה הוחלט, ולמה?

החלטות שמתקבלות בצ׳אט נעלמות כשהצ׳אט גולל הלאה. ‏record_decision שומר אותן בשתי דרכים:

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

get_task_history קורא את זה בחזרה בשלושה מצבים: summary (הכרטיס, הקבלה האחרונה שלו וספירות), decisions (כל החלטה לגבי המשימה, כולל למה היא הוחזרה, מה שנשמר גם אחרי אישור מאוחר יותר) ו-full (היומן הגולמי, עד 100 אירועים). ‏get_context מעביר את ההחלטות התקפות לסוכן הבא במסגרת תקציב טוקנים, כך שהריצה הבאה מתחילה ממה שהוחלט ולא מאפס. עוד על זה בלמה החלטות בצ׳אט עם AI הולכות לאיבוד.

איפה בודקים את זה, ועל מה לוחצים?

כברירת מחדל משימה שהושלמה עוברת ישר ל-Done. היא נעצרת ב-Inbox שלכם כשהמשימה דורשת בדיקה או כשבדיקת אימות נכשלת. שם תראו את הקבלה וארבעה כפתורים: Accept, ‏Rework, ‏Later ו-Drop. ‏Rework מבקש הערה, וההערה הזו חוזרת לסוכן.

אם הסוכן העביר nextStep, הוא מופיע מעל כפתור Accept, והאישור מאשר בדיוק את הצעד הזה. האישור תקף ל-72 שעות וחוזר לסוכן דרך get_my_work או start_task כצעד האחד שצריך לעשות הלאה. שאלות שסוכן שואל עם request_input נוחתות באותו Inbox, בדפדפן ובאפליקציות ל-iOS ול-Android, עם התראת push בנייד.

ל-Inbox יש מגבלה בכוונה: 5 פריטים ממתינים בסביבת עבודה של אדם אחד, 10 לצוות, או 45 דקות של זמן בדיקה משוער — המוקדם מביניהם. כשהוא מלא, ‏start_task מסרב עם attention_queue_full, כך שסוכנים מסיימים או מבהירים עבודה במקום לערום עוד דברים שתצטרכו לבדוק.

אילו ראיות לבקש לפי סוג משימה?

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

• קוד: hash של ה-commit ו-URL של ה-PR כ-artifacts. ‏notDone צריך לפרט בדיקות שלא הורצו, מיגרציות שלא הוחלו וקבצים שהושארו בכוונה בלי שינוי.
• תוכן: ה-URL שפורסם, או קובץ הטיוטה עם ה-sha256 שלו אם הוא עוד לא באוויר. ‏unknowns צריך לפרט עובדות שהסוכן לא הצליח לאשר.
• מחקר: URL של מקור לכל טענה מרכזית, וקובץ ההערות. ‏unknowns צריך להפריד בין מה שמקור אומר לבין מה שהסוכן הסיק.
• פנייה ללקוחות: מזהה ההודעה של כל הודעה שנשלחה, ורשימת הנמענים כקובץ. ‏notDone צריך לפרט למי לא פנו ולמה.

איך שולטים מראש במה שסוכן יכול לעשות?

ייחוס בדיעבד עובד הכי טוב עם מגבלות מראש. ב-Weft, לכל חיבור OAuth יש אחת משלוש רמות הרשאה, שנקבעת במסך ההסכמה או מאוחר יותר בהגדרות, תחת Connected AI clients:

• full (ברירת המחדל): כל 32 הכלים.
• write: הכול חוץ משלושת הכלים ההרסניים (trash_task, ‏archive_done_tasks, ‏complete_sprint).
• read: רק 11 הכלים לקריאה בלבד.

הבדיקה רצה בכל קריאה. ניתוק מבטל את ה-refresh tokens של החיבור ודוחה כל אסימון שהונפק לפני הניתוק בקריאה הבאה שלו. לאסימוני גישה אישיים, ללקוחות בלי OAuth, אין scopes: אסימון אחד מגיע לכל 32 הכלים, וביטול שלו נכנס לתוקף בקריאה הבאה. סוכנים יכולים להעביר משימות לסל מחזור של 30 יום, אבל לא למחוק אותן לצמיתות; שחזור מהסל הוא פיצ׳ר של Pro.

מה Weft לא עושה כאן?

• אין לו אינטגרציה עם GitHub או Slack, כך ש-Weft לא מחפש בשבילכם את ה-commits או ההודעות. אתם פותחים את ה-artifact.
• אין לו REST API ציבורי, webhooks או CLI כדי לדחוף קבלות למערכות אחרות. יש ייצוא ל-JSON ול-Markdown.
• הוא לא עוקב אחרי צעדי המודל. כלים שרושמים פרומפטים, טוקנים וזמני תגובה ברמת המודל עושים עבודה אחרת, וייתכן שתרצו גם אחד כזה.
• סוכנים כותבים את הקבלות של עצמם. Weft הופך את הפער בין טענה לראיה לגלוי; הוא לא יכול להפוך סוכן לישר.

אם אתם רוצים לנהל סוכנים כחשבונות שירות דרך REST API, ‏CLI לסקריפטים של CI, או פיצ׳רי AI מובנים כמו כתיבת משימות ומיון, Hypertask מתאימה לזה יותר. העמוד שלנו חלופה ל-Hypertask משווה בין השתיים זו לצד זו.

היסטוריית git לא מספיקה כדי לדעת מה הסוכן שלי עשה?

Git מראה מה השתנה בקוד. הוא לא מראה על מה הסוכן דילג, במה הוא לא היה בטוח, או איזו בחירה הוא עשה בין שתי אפשרויות. השתמשו ב-hash של ה-commit כ-artifact על המשימה, ואת השאר שמרו בקבלה וברשומת ההחלטה.

סוכן לא יכול פשוט להמציא artifact?

הוא יכול לשלוח כל מחרוזת. העיקר ב-artifact הוא שאפשר לפתוח אותו: hash שאפשר לחפש, ‏URL שאפשר לטעון, מזהה הודעה שאפשר למצוא. artifact מומצא נכשל ברגע שבודקים, מה שלא קורה אף פעם עם תגובה. כשלמשימה יש בדיקת אימות ובדיקה חוסמת נכשלת, המשימה לא נכנסת ל-Done.

כל משימה גמורה מחכה לבדיקה שלי?

לא. כברירת מחדל משימה שהושלמה עוברת ל-Done. היא מחכה ב-Inbox שלכם ל-Accept, ‏Rework, ‏Later או Drop רק כשהמשימה דורשת בדיקה או כשבדיקת אימות נכשלת.

אילו לקוחות AI יכולים לכתוב קבלות ל-Weft?

כל לקוח MCP. ב-ChatGPT, ‏Weft זמין כפלאגין שפורסם בכל התוכניות, כולל Free. ‏Claude Code מתחבר עם claude mcp add --transport http weft https://letsweft.com/api/mcp. ‏Claude.ai ו-Claude Desktop משתמשים ב-custom connector. יש עמודי הגדרה ל-33 לקוחות, למשל Claude Code, ChatGPT, Cursor ו-Codex.

כמה זה עולה?

Free כולל 50 משימות ו-200 קריאות AI בחודש. ‏Pro עולה $7 למשתמש לחודש או $60 למשתמש לשנה. ב-Weft אין קרדיטים של AI: החשיבה מתרחשת בלקוח ה-AI שלכם. ראו תמחור.