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

איך הופכים סיפור מהעבודה לסוכן שיודע לפעול? בתרגול הזה תחלצו את המשימה, תתכננו נתונים וכלים, ותבנו סוכן חדש ב-n8n בעזרת Claude Code. משך התרגול: כ-50 דקות.

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

צריכים עזרה? עברו לעוזר ה-AI. קלוד עוזר לחשוב ובונה דרך אותה שיחת Code ב-Claude Desktop. אתם בוחרים, פותחים את ההגדרות ב-n8n, מדייקים כלי או הוראה ובודקים את ההרצות. את הודעות הבדיקה שולחים בצאט של התהליך ב-n8n.

פרק 1: בוחרים סיפור ומחלצים משימה

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

ציוד:
EQ-11: מד לחץ P20, מדידה עד 20 בר, פנוי. מתאים למדידה יציבה.
EQ-12: מד לחץ P100, מדידה עד 100 בר, פנוי. מתאים למדידה יציבה וגם לשינויי לחץ מהירים.
EQ-13: מד לחץ P100, מדידה עד 100 בר, תפוס. מתאים למדידה יציבה וגם לשינויי לחץ מהירים.

ניסיון קודם:
H-01: בניסוי "פתיחת שסתום מהירה" עם EQ-11 התצוגה פיגרה אחרי השינוי. המכשיר לא מתאים לתיעוד שינויים מהירים.
H-02: בניסוי "פעימות לחץ בצינור" עם EQ-12 נרשמו השינויים המהירים בהצלחה.

בקשות חדשות:
REQ-01: צריך למדוד לחץ עד 12 בר בזמן פתיחה וסגירה מהירות של שסתום. מבקש: אורי.
REQ-02: צריך לבדוק לחץ בצינור. מבקשת: מאיה.

שתי הבקשות מתחילות במצב "חדש", ללא ציוד מומלץ וללא נימוק.

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

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

# סיפור המקרה

# Task
Help me translate the case I append into an n8n agent. Do not build anything yet.
I will propose answers and you will challenge them. Ask one question at a time and wait.
Explore: user, trigger, desired result, required information, differences between cases, and when a person is needed.
Do not invent missing facts. Separate facts, assumptions, and open questions.
Finish with a short task definition and two examples requiring different next steps. Ask for my approval. Respond in Hebrew.

# Case

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

פרק 2: מגדירים מוח, זיכרון, נתונים וכלים

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

א. בוחרים מודל וזיכרון עם קלוד

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

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

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

ב. מגדירים טבלאות, כלים והרשאות

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

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

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

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

1. מודל: בדוק אילו מודלים זמינים בחיבור שלי ותומכים בכלים. השווה שני מועמדים לפי המשימה, איכות קריאות הכלים, עלות וזמן תגובה. השתמש בתיעוד רשמי עדכני ליכולות ולמחיר. ציין מה לא בדקת בפועל. המלץ על שם מודל מדויק ועל Node מתאים ב-n8n. אם אינך רואה את הרשימה, בקש שאעתיק אותה משדה Model.
2. זיכרון: המלץ על Simple Memory או על מאגר שיחות מתמשך ונמק לפי הצורך שלי. קבע Session ID שמגיע מהצאט ו-Context Window Length מנומק. נקודת התחלה לתרגול היא 5 חילופי דברים קודמים. ציין אילו עובדות חייבות להישמר בטבלאות ולא רק בשיחה.
3. טבלאות: הצע עד שלוש Data Tables חדשות. לכל אחת: משמעות שורה, מזהה ייחודי, שמות עמודות, סוגי נתונים ונתוני ההתחלה מהסיפור. מותר לשמור ניסיון קודם בשדה בטבלת הציוד, אם הוא נשאר ניתן לזיהוי ולקריאה.
4. כלים: הצע עד שלושה כלי Data Table המחוברים ישירות ל-AI Agent. בליבת התרגול אל תבנה תהליכי משנה או עטיפות Call n8n Workflow Tool. סמן בדיקות אכיפה נוספות כמועמדים לפרק 6, בלי לממש אותן כעת. לכל כלי כתוב שם, תיאור מדויק למודל עם מתי להשתמש ומתי לא, קלט ופלט. לכל שדה סמן קבוע או למילוי המודל. לשדה שהמודל ממלא כתוב שם, סוג, תיאור, ערכים מותרים, מקור הערך ומה לעשות אם הוא חסר. טבלה, פעולה ועמודות כתיבה יישארו קבועות.
5. הוראות מערכת: הפרד בין הגבלות שמוגדרות טכנית בכלים לבין כללי התנהגות שנכתוב ב-System Message. אל תציג תיאור שדה כאכיפה של ערכיו.
6. בדיקות: הגדר מקרה רגיל, מידע חסר וחריגה מהרשאה, עם קלט ותוצאה צפויה לכל אחד.

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

# Plan before building
Using the approved task, help me make the following decisions. Do not build yet. Respond concisely in Hebrew.

1. Model: check which models are available through my connection and support tools. Compare two candidates for the task, tool-call quality, cost, and response time. Use current official documentation for capabilities and pricing. State what you have not actually tested. Recommend an exact model name and suitable n8n node. If you cannot see the list, ask me to copy it from the Model field.
2. Memory: recommend Simple Memory or a persistent chat store based on my needs. Set a chat-derived Session ID and justify Context Window Length. Start with 5 previous interactions for this exercise. Identify facts that must be stored in tables rather than only in the conversation.
3. Tables: propose up to three NEW Data Tables. For each: row meaning, unique identifier, column names, data types, and seed data from the case. Past experience may be stored in an equipment-table field if it remains identifiable and readable.
4. Tools: propose up to three Data Table tools connected directly to AI Agent. In the core exercise, do not build sub-workflows or Call n8n Workflow Tool wrappers. Mark additional enforcement checks as candidates for chapter 6. Do not implement them yet. For each give a name, precise model-facing description including when to use and when not to, input and output. Mark each field as fixed or model-filled. For every model-filled field give a name, type, description, allowed values, value source, and missing-value behavior. Keep the table, operation, and writable column names fixed.
5. System instructions: separate technically configured tool restrictions from behavior rules for System Message. Do not present a field description as value enforcement.
6. Tests: define normal, missing-information, and unauthorized-request cases, each with input and expected result.

Pause for my model and memory choices. Then show a consolidated design and ask for approval before building.

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

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

פרק 3: בונים ומבינים מה נבנה

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

# בנייה לפי התכנון שאישרתי
בנה דרך חיבור ה-n8n הקיים תהליך חדש וטבלאות Data Tables חדשות. הוסף לשמות את הקידומת agent-lab ואת שמי כדי להבדיל מתוצרים אחרים. בקש את שמי אם חסר.
אל תשנה תהליכים או טבלאות קיימים. אל תייבא פתרון מוכן.
הקם Chat Trigger, AI Agent, ואת המודל, הזיכרון, חלון ההקשר והכלים שאישרתי בתכנון. חבר לסוכן כלי Data Table ישירים בלבד. אל תיצור תהליכי משנה או עטיפות לכלים בליבה. השאר בדיקות אכיפה נוספות כמועמדים לפרק 6. השתמש ב-sessionId מהצאט כמפתח הזיכרון, ללא מפתח קבוע שמשותף לכל המשתמשים.
השתמש רק במודל ובחיבור זמינים. אם אינך יכול לבצע פעולה, ציין בדיוק מה חסום ותן לי צעד ידני ממוקד באותו ממשק.
צור נתוני התחלה מהסיפור שאצרף, בלי להפוך אותם להוראות בתוך ה-System Message.
הגבל טכנית את כלי הכתיבה לטבלת הבקשות החדשה ולעמודות שאישרתי. קבע טבלה ופעולה, ומפה ידנית רק את העמודות המותרות. העתק לכל כלי את התיאור שאישרתי. בשדות שהמודל ממלא הגדר שם פרמטר, סוג ותיאור מפורט לפי התכנון. אל תחבר כלי מחיקה או כלי שליחה חיצונית.
הפעל Return Intermediate Steps ב-AI Agent והגבל את מספר הסבבים ל-6.
הצע System Message קצר עם תפקיד, מטרה, מקורות, כלים, גבולות, תנאי עצירה ופלט.
בסיפור המעבדה כל תשובה שמציגה המלצת ציוד תסתיים בדיוק במשפט: "נדרש אישור נועה לפני שימוש בציוד." במקרה אישי, ציין במשפט סיום את האישור האנושי הנדרש, אם נדרש.
הצג את ההוראות לאישורי לפני בדיקת הסוכן.
החזר קישור לתהליך ושמות הטבלאות והכלים. עצור לפני הרצת בדיקות.

# נתוני התחלה

# Build the approved design
Using the existing n8n connection, create a NEW workflow and NEW Data Tables. Prefix names with agent-lab and my name. Ask for my name if missing.
Do not modify existing workflows or tables. Do not import a finished solution.
Build Chat Trigger, AI Agent, and the approved model, memory store, context window and tools. Connect Data Table tools directly to the agent. Do not add sub-workflows or tool wrappers in the core exercise. Keep additional enforcement checks as candidates for chapter 6. Use the chat sessionId as the memory key, never a fixed key shared by all users.
Use only available models and connections. If an action is blocked, identify it precisely and give me a focused manual step in the relevant interface.
Seed data from the case I append. Do not embed the records as instructions in System Message.
Technically restrict writing to the NEW requests table and approved columns. Fix the table and operation, and manually map only the permitted columns. Apply each approved tool description. For model-filled fields configure a parameter name, type, and detailed description from the plan. Do not connect deletion or external sending tools.
Enable Return Intermediate Steps on AI Agent and limit iterations to 6.
Propose a short System Message covering role, goal, sources, tools, boundaries, stopping rules and output.
For the lab case, end every reply that presents an equipment recommendation with the exact Hebrew sentence: "נדרש אישור נועה לפני שימוש בציוד." For a personal case, add a closing sentence about the required human approval, if any.
Show the instructions for approval before agent testing.
Return the workflow link and table/tool names. Stop before running tests. Respond in Hebrew.

# Seed data

א. בודקים טבלאות, מודל וזיכרון

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

1. אחרי הבנייה פתחו את הקישור לתהליך שקלוד החזיר. אם קבוצה מקופלת מסתירה את ה-Nodes, לחצו Expand על המסגרת שלה. ודאו שהסוכן מחובר למודל, לזיכרון ולכלים שבתכנון.
2. בפרויקט ב-n8n פתחו Data tables. השוו שדות ורשומות לנתוני ההתחלה. חזרו לקנבס ופתחו את Node המודל. בדקו ששדה Model תואם לבחירה שלכם. זה המודל שמריץ את הסוכן, בנפרד מהמודל של Claude Code שבנה אותו.
3. פתחו את Node הזיכרון. ב-Simple Memory בדקו Session ID = Connected Chat Trigger Node, מפתח sessionId מהצאט, ו-Context Window Length לפי התכנון. אם בחרתם מאגר אחר, בדקו גם את החיבור למאגר ואת מפתח השיחה.

ב. מדייקים כלי אחד ושדות שהמודל ממלא

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

1. פתחו את ה-Node בלחיצה כפולה. בלשונית Parameters, בחרו Tool Description → Set Manually. בשדה Description כתבו מה הכלי עושה, מתי להשתמש, מתי לא ומה הוא מחזיר.
2. ודאו ש-Operation והטבלה קבועים. תחת Mapping Column Mode בחרו Map Each Column Manually. השאירו ב-Values to update רק עמודות שמותר לעדכן. הסירו עמודות שאסור לשנות, גם אם הן מוצגות ללא ערך.
3. בכל שדה שהמודל צריך למלא לחצו על לחצן הכוכבים, Let the model define this parameter. יופיע Defined by agent ולצידו Description. הזינו תיאור שמסביר מאיפה לקחת את הערך, מה מותר להחזיר ומה לעשות כשחסר מידע. אם כבר מופיע Defined by agent, ערכו את התיאור הקיים.

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

איך בודקים את ההגדרה? קראו את התיאור כאילו אתם המודל: האם ברור מתי לקרוא לכלי ומה למלא בכל שדה? בקשו מקלוד לתקן תיאור עמום, או הסבירו למה התיאור הקיים מספיק. לתיאור שדה אין כוח לחסום ערך שגוי. כלל שחייב להיאכף תמיד הוא מועמד לבדיקה קבועה בפרק 6.

ג. מדייקים את הוראות המערכת

פתחו את Node הסוכן. תחת Options → System Message קראו את ההוראות שקלוד הציע. בדקו שיש בהן:

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

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

פרק 4: מריצים ובודקים מול הנתונים

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

1. חזרו לקנבס של התהליך ולחצו Open chat. לפני כל בדיקה נפרדת לחצו על סמל החץ המעוקל Reset ליד Session בראש הצאט. ודאו שמזהה השיחה השתנה. בבדיקת מידע חסר, אל תאפסו את השיחה לפני הודעת ההשלמה. לפני כל בדיקה צפו במצב הרשומה הרלוונטית.
2. במקרה אישי השתמשו בשלוש הבדיקות שאישרתם בפרק 2. בסיפור המצורף שלחו את ההודעות בטבלה הבאה, כל שורה בבדיקה נפרדת. בבדיקת המידע החסר, הודעת ההשלמה נשארת באותה שיחה.

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

בדיקת הזיכרון: לחצו Reset כדי לפתוח שיחה חדשה, ושלחו "מה מצב REQ-02?". במקרה אישי השתמשו במזהה של הבקשה שבדקתם. התשובה צריכה להתבסס על קריאה מהטבלה. פרטי השיחה הקודמת לבדם אינם ראיה.

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

פרק 5: רואים את הלולאה ומדייקים

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

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

1. אחרי ההרצה, השאירו את הצאט פתוח. בקנבס Editor פתחו את אזור Logs ליד הצאט. אם הוא נמוך, גררו את הגבול העליון שלו כלפי מעלה.
2. ברשימת Logs, אם מופיעה קבוצה מקופלת, פתחו תחילה את החץ שלצידה. אחר כך לחצו על הסוכן ופתחו את החץ שלצידו. תראו את הקריאות למודל, לזיכרון ולכלים. בדוגמא המצולמת: המודל פנה לכלי בקשות ולכלי ציוד וניסיון קודם, ואז המודל הופעל שוב ליצירת תשובה.
3. לחצו על כלי אחד ברשימה. ב-Input וב-Output השוו את הפרמטרים ואת התוצאה. חזרו לשורת הסוכן ובחרו פלט JSON. בתוך intermediateSteps חפשו action.tool לשם הכלי, toolInput לערכים שנשלחו ו-observation לתוצאה. בכלי קריאה ללא פרמטרים ייתכן קלט ריק.
4. אם intermediateSteps חסר, פתחו בעריכה את הסוכן והפעילו Options → Add Option → Return Intermediate Steps. שמרו והריצו שוב. כדי לחזור להרצה שמורה אחרת, השתמשו בלשונית Executions.

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

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

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

# הראיות שלי

# Evidence-based review
I append the submitted input, expected result, agent reply, tool calls, and record before/after.
Compare them. State what worked, what did not, and the evidence for each finding.
Distinguish data, tool-definition, permission, and system-instruction defects.
Propose only one change and wait for approval.
If the result is already correct, say so and suggest an additional test. Do not invent a failure. Respond in Hebrew.

# My evidence

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

פרק 6: מזהים מועמד לתהליך דטרמניסטי

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

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

# Which rules belong in fixed logic?
Read the system instructions and tool definitions we built.
Find up to three rules that can be checked unambiguously on input or before a write.
For each: condition, action or rejection, enforcement location and test.
Label them "candidate for a deterministic process". Do not implement yet.
Also explain which decision still requires interpretation and judgment.
Instruction length alone does not justify automation. Respond in Hebrew.

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

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

תרגול פתוח

לבחירה לאחר השלמת הליבה. בחרו הרחבה אחת כדי לבדוק גבול נוסף של הסוכן.

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

שאלות להמשך מחקר

אפשר להמשיך אחרי המפגש:

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

עוזר ה-AI

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

קרא את התרגול בכתובת: https://almaya.ai/edu-content/story-to-agent-workshop/

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

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

מקורות טכניים: AI Agent וקריאות כלים, Data tables, Simple Memory, סוגי זיכרון, שדות שהמודל ממלא ולחצן הכוכבים.