דלג לתוכן הראשידלג לצור קשר
    דף הביתארכיטקטורה אגנטיתפרק 4
    פרק 4 מתוך 30 · 20.3
    ארכיטקטורה אגנטית

    אכיפה והעברה

    כללי המשחק בין סוכנים

    פרק 4 / 30

    אודות הפרק

    ההבדל בין אכיפה בפרומפט לאכיפה בקוד, Prerequisite Gates, ואיך להעביר שליטה לנציג אנושי בצורה נכונה.

    פרומפט לעומת קוד: שתי דרכים לאכיפה

    יש שתי דרכים להגיד לאייג'נט מה לעשות. הראשונה — Prompt-based guidance. כותבים בפרומפט: "תמיד תוודא את הלקוח לפני שאתה מעבד החזר." הבעיה? זה הסתברותי (Probabilistic). הוא ישמע לכם רוב הזמן. לא תמיד.

    הדרך השנייה — Programmatic enforcement. אכיפה בקוד. שום דבר לא עובר בלי שהתנאי התקיים. זה דטרמיניסטי. אין 8% שגיאה. יש אפס.

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

    Prerequisite Gate — שער תנאי מוקדם

    Prerequisite Gate הוא מנגנון שחוסם פעולה עד שתנאי מוקדם התקיים. למשל — הפקודה process_refund חסומה. היא לא תרוץ עד ש-get_customer החזיר מזהה לקוח מאומת. זה לא הצעה. זה חסימה בקוד. האייג'נט פיזית לא יכול לדלג.

    # Prerequisite Gate example
    class RefundGuard:
        def __init__(self):
            self.verified_customer_id = None
    
        def verify_customer(self, customer_id: str) -> dict:
            """Must be called before process_refund"""
            result = get_customer(customer_id)
            if result.verified:
                self.verified_customer_id = result.id
                return {"status": "verified", "id": result.id}
            raise ValueError("Customer not verified")
    
        def process_refund(self, amount: float) -> dict:
            """Blocked until verify_customer succeeds"""
            if not self.verified_customer_id:
                raise PermissionError(
                    "Cannot process refund: customer not verified. "
                    "Call verify_customer first."
                )
            return execute_refund(self.verified_customer_id, amount)

    process_refund חסום פיזית עד שהלקוח מאומת — אכיפה דטרמיניסטית

    Handoff — העברת שליטה לנציג אנושי

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

    Handoff Summary חייב לכלול חמישה שדות:

    1. מזהה לקוח
    2. סיכום הבעיה
    3. סיבת שורש
    4. סכום החזר (אם רלוונטי)
    5. המלצה לפעולה
    // Handoff Summary structure
    interface HandoffSummary {
      customer_id: string;
      problem_summary: string;
      root_cause: string;
      refund_amount?: number;
      recommended_action: string;
    }
    
    // Example
    const handoff: HandoffSummary = {
      customer_id: "CUST-4829",
      problem_summary: "Customer charged twice for order #8812",
      root_cause: "Payment gateway timeout caused duplicate charge",
      refund_amount: 149.90,
      recommended_action: "Approve refund for duplicate charge",
    };

    חמישה שדות שהנציג חייב לקבל — הסיכום עומד לבד

    נקודות חשובות לבחינה

    • סיכון גבוה (כסף, רגולציה, אבטחה) = אכיפה בקוד, לא בפרומפט
    • Prerequisite Gate חוסם פעולה עד שהתנאי התקיים — דטרמיניסטי
    • Prompt-based guidance = הסתברותי, מתאים רק לסיכון נמוך
    • Handoff Summary חייב לעמוד לבד — הנציג לא רואה את השיחה
    • חמישה שדות: מזהה לקוח, סיכום בעיה, סיבת שורש, סכום, המלצה

    "אם כותבים בפרומפט 'תוודא את הלקוח' — הוא ישמע 92% מהזמן. אם חוסמים בקוד — 100%. בפרודקשן, ה-8% האלה עולים כסף."

    💡 טיפ: בפרק הבא (יום 5) נלמד על SDK Hooks — שם מיישמים את האכיפה הזאת בפועל בקוד.