זיכרון ו-Dreaming — שיפור עצמי אסינכרוני בלי לשרוף מיליוני tokens

מוטיבציהamnesiaלמה harness בלי זיכרון חוזר על אותן טעויות

נתחיל מהבעיה, כי היא לא תאורטית. ה-harness שבנית עד עכשיו הוא stateless בין ריצות. בתוך ריצה אחת יש לו message-state (פרק 2) ו-context management (פרק 3) — אבל ברגע שהריצה נגמרת, הכל מתאדה. ה-decision החכם שהסוכן קיבל בריצה של אתמול? נעלם. ה-failure שתפסת יפה עם ה-structured failure record מפרק 5? נכתב ל-trace ב-Langfuse — ואז הסוכן הבא חוזר עליו בדיוק.

זה ההבדל בין stateless (חסר מצב) ל-stateful (בעל מצב) ברמת ה-מערכת, לא ברמת הריצה. המודל עצמו תמיד היה stateless — זו הסיבה שבפרק 2 בנינו harness שמחזיק את ה-state. עכשיו אנחנו מרחיבים את אותו עיקרון מ-"זיכרון בתוך ריצה" ל-"זיכרון בין ריצות".

זה מתחבר ישירות לטענת הליבה של הקורס: 70% מביצועי הסוכן חיים מחוץ למודל (פרק 1). זיכרון הוא דוגמה מובהקת ל-"מחוץ למודל" — אותו Claude, אבל harness שזוכר מנצח harness ששוכח. הפער של פי 6 אצל Harvey הוא בדיוק זה: לא שדרוג מודל, אלא שכבת harness שמצטברת מריצה לריצה.

חשוב להבין למה זה כל כך קל ליפול ל-amnesia. כשבנית את הלולאה בפרק 2, ה-state חי ב-RAM של התהליך — רשימת הודעות בזיכרון. ברגע שהתהליך מסתיים, ה-RAM מתפנה, וה-state נעלם. זו לא תקלה, זו ברירת המחדל. כל מי שבונה harness דק מקבל amnesia בחינם, בלי לבקש. כדי שלא תהיה amnesia, צריך להוסיף שכבה מפורשת שמוציאה state נבחר אל מחוץ לתהליך — בדיוק כמו שבפרק 3 הוצאנו state כבד ל-scratchpad חיצוני כדי לעקוף את ה-compaction. ה-memory store הוא אותו רעיון, מורחב מ-"בין turns" ל-"בין ריצות".

שלוש דרכים שבהן amnesia פוגעת בך, מהזולה ליקרה:

נקודה אחרונה לפני שנבנה: זיכרון הוא לא תחליף ל-context management (פרק 3), הוא שכבה משלימה. ה-context מחזיק את מה שרלוונטי לריצה הנוכחית; ה-memory store מחזיק את מה שנלמד על פני ריצות. שני המנגנונים נפגשים בנקודת ה-READ: בתחילת ריצה, אתה שולף מה-store הקבוע מעט לקחים ומזריק אותם ל-context הזמני. השאלה הקריטית — וזו השאלה שמפרידה harness שמשתפר מ-harness שקורס — היא כמה מזריקים. נחזור לזה שוב ושוב.

ליבהmemory storepersistent memory store — לא "זיכרון חופשי", אלא מבנה

הטעות הראשונה של כל מי שמתחיל עם memory היא לחשוב עליו כעל "להחזיק את כל ההיסטוריה". זה לא זיכרון, זה אגירה — ובדיוק מה שיפוצץ לך את ה-context (פרק 3). persistent memory store טוב הוא מובנה: יש לו schema, קטגוריות, ושאילתות. אתה לא שומר "מה קרה", אתה שומר "מה נלמד".

שלוש קטגוריות הליבה — בדיוק שלוש, כי יותר זה bloat ופחות זה לא מספיק:

שים/י לב להבחנה הקריטית בשורה האחרונה: decisions ו-failures נכתבים ע"י ריצות בודדות (raw material), אבל learned patterns נכתבים רק ע"י Dreaming — תהליך הקונסולידציה שנראה בהמשך. ריצה בודדת לא יודעת אם משהו הוא pattern או מקרה. רק מבט-על על הרבה transcripts יודע.

למה דווקא שלוש קטגוריות ולא שבע? כי כל קטגוריה נוספת היא עוד החלטה שאתה צריך לקבל בכל write — "האם זה decision או observation או hint?" — ובלבול בקטגוריות הופך את ה-store ללא-ניתן-לשליפה. שלוש קטגוריות ממפות נקי לשלושה מקורות: decisions באים מהצלחות, failures באים מה-recovery layer (ch5), ו-patterns באים מ-Dreaming. אם אתה מתלבט לאיזו קטגוריה משהו שייך — כנראה הוא לא צריך להישמר בכלל. זיכרון טוב הוא קמצן.

ה-schema בקוד

נגדיר schema מינימלי וברור. דוגמה מייצגת ב-Python (ה-store עצמו יכול להיות קובץ JSON, SQLite, או KV — לא משנה כרגע):

# memory_store.py  — דוגמה מייצגת
from dataclasses import dataclass, asdict
from enum import Enum
import json, time, hashlib

class MemoryKind(str, Enum):
    DECISION = "decision"
    FAILURE  = "failure"
    PATTERN  = "pattern"   # נכתב רק ע"י Dreaming

@dataclass
class MemoryItem:
    kind: MemoryKind
    task_type: str          # למשל "lead_enrichment" — מפתח השליפה
    content: str            # התובנה עצמה, קצרה
    evidence: str           # מאיפה היא באה (trace_id / turn)
    created_at: float
    weight: float = 1.0     # Dreaming יעלה/יוריד לפי כמה זה חזר

    def key(self) -> str:
        h = hashlib.sha1(f"{self.kind}:{self.task_type}:{self.content}".encode())
        return h.hexdigest()[:12]

class MemoryStore:
    def __init__(self, path="memory.json"):
        self.path = path
        self._load()

    def _load(self):
        try:
            self.items = json.load(open(self.path))
        except FileNotFoundError:
            self.items = {}

    def write(self, item: MemoryItem):
        self.items[item.key()] = asdict(item)   # dedup לפי key
        json.dump(self.items, open(self.path, "w"), ensure_ascii=False, indent=2)

    def read(self, task_type: str, kinds=None, limit=5):
        rows = [i for i in self.items.values() if i["task_type"] == task_type]
        if kinds:
            rows = [i for i in rows if i["kind"] in kinds]
        rows.sort(key=lambda i: i["weight"], reverse=True)
        return rows[:limit]     # רק ה-top-N הרלוונטיים — לא הכל

שתי החלטות עיצוב חשובות בקוד הזה. ראשית, key() עושה dedup אוטומטי — אותו לקח לא נכתב פעמיים. שנית, read() מחזיר limit=5 top-N לפי weight, לא את כל הזיכרון. זה הסעיף שמונע את הטעות הקלאסית של "לזרוק את כל ה-store ל-context".

איזה backend? JSON, SQLite, או KV

שים/י לב שב-schema למעלה ה-store הוא קובץ JSON — וזה בכוונה. אתה לא צריך vector database ביום הראשון. רוב מי שמתחיל עם memory קופץ ישר ל-embeddings ול-semantic search, ומגלה חודש אחרי שהוא בנה תשתית מסובכת כדי לשלוף 5 שורות. בחר/י backend לפי נפח, לא לפי אופנה:

הכלל: task_type הוא ה-index שלך, לא embedding. כל עוד אתה יודע מראש לאיזה סוג משימה הריצה שייכת (וברוב ה-harnesses אתה יודע — אתה זה שמפעיל אותה), שליפה לפי task_type מדויקת, זולה ודטרמיניסטית. vector search שמור/י לרגע שבו אתה לא יודע את הקטגוריה מראש. ה-syllabus וה-research מזכירים שלמפתח ישראלי יש כאן נקודה נוספת: עברית עשירה מורפולוגית, ואם בכל זאת תלך לכיוון retrieval סמנטי על תוכן עברי — השתמש/י ב-tokenizer או lemmatizer מותאם-עברית, אחרת ה-context יתנפח וה-retrieval ייכשל (local_market_notes ב-research).

read/write בלולאה — בלי לזהם את ה-context

איפה בלולאה (פרק 2) משולב הזיכרון? בשתי נקודות בלבד:

# בתוך ה-harness loop — דוגמה מייצגת
def run_task(goal, task_type, store: MemoryStore):
    # 1) READ — בתחילת המשימה, מזריקים patterns + failures רלוונטיים בלבד
    lessons = store.read(task_type, kinds=["pattern", "failure"], limit=5)
    memory_block = "\n".join(f"- {l['content']}" for l in lessons)
    system = BASE_SYSTEM + (f"\n\nלקחים מריצות קודמות:\n{memory_block}" if lessons else "")

    result = agent_loop(goal, system_prompt=system)   # הלולאה מפרק 2

    # 2) WRITE — בסוף, רושמים decision שעבד / failure שנתפס
    if result.succeeded and result.key_decision:
        store.write(MemoryItem(MemoryKind.DECISION, task_type,
                    result.key_decision, result.trace_id, time.time()))
    for f in result.captured_failures:        # מ-ch5
        store.write(MemoryItem(MemoryKind.FAILURE, task_type,
                    f.summary, f.trace_id, time.time()))
    return result

שים/י לב: ה-READ מזריק 5 שורות לכל היותר ל-system prompt — לא מסמך. זה ההבדל בין memory שמשפר ל-memory שמפוצץ context. נחזור לזה בקטע ה-frameworks.

למה ל-system prompt ולא ל-user message? כי לקחים נלמדים הם config של ה-harness, לא חלק מהמשימה — בדיוק כמו שבפרק 2 ראינו שה-system prompt הוא חלק מהנדסת ה-harness, לא רק "הוראות". לקח כמו "ה-API של Apollo דורש header מסוים" הוא ידע מערכתי שמלווה את הסוכן לאורך כל הריצה, לא בקשה חד-פעמית. הזרקה ל-system גם שורדת טוב יותר את ה-compaction (פרק 3): ברוב ה-harnesses ה-system prompt מוגן מדחיסה, בעוד הודעות user ישנות נדחסות ראשונות. כלומר ה-READ ל-system לא רק נכון לוגית — הוא גם עמיד יותר.

# memory_store.py — starter מינימלי לתרגיל 1 (מוכן לרוץ).
import json, time, hashlib
from dataclasses import dataclass, asdict
from enum import Enum

class MemoryKind(str, Enum):
    DECISION = "decision"; FAILURE = "failure"; PATTERN = "pattern"

@dataclass
class MemoryItem:
    kind: MemoryKind; task_type: str; content: str
    evidence: str = ""; created_at: float = 0.0; weight: float = 1.0
    def key(self) -> str:
        return hashlib.sha1(f"{self.kind}:{self.task_type}:{self.content}".encode()).hexdigest()[:12]

class MemoryStore:
    def __init__(self, path="memory.json"):
        self.path = path
        try: self.items = json.load(open(self.path))
        except FileNotFoundError: self.items = {}
    def add(self, item: MemoryItem):                  # add — ה-API שתרגיל 1 דורש
        self.items[item.key()] = asdict(item)
        json.dump(self.items, open(self.path,"w"), ensure_ascii=False, indent=2)
        return item.key()
    write = add                                       # alias — הפרק משתמש גם בשם הזה
    def read(self, task_type, kinds=None, limit=5):
        rows = [i for i in self.items.values() if i["task_type"] == task_type]
        if kinds: rows = [i for i in rows if i["kind"] in kinds]
        rows.sort(key=lambda i: i["weight"], reverse=True)
        return rows[:limit]

if __name__ == "__main__":
    s = MemoryStore()
    s.add(MemoryItem(MemoryKind.DECISION, "lead_enrichment", "קרא enrich לפני draft", "t1", time.time(), 2.0))
    s.add(MemoryItem(MemoryKind.FAILURE,  "lead_enrichment", "Apollo enrich 403 בלי X-Version header", "t2", time.time(), 1.5))
    s.add(MemoryItem(MemoryKind.PATTERN,  "lead_enrichment", "enrich לפני draft חוסך turn", "t3", time.time(), 3.0))
    print(f"store size = {len(s.items)}")
    for h in s.read("lead_enrichment", kinds=["pattern","failure"]):
        print(f"  [{h['kind']}|w={h['weight']}] {h['content']}")

משקל, דעיכה ואיכות פריט — מה הופך pattern לשימושי

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

הכלל שאתה רוצה להפנים: pattern טוב הוא pattern שאתה יכול לבדוק. אם אתה לא יכול להצביע על trace_id ולהגיד "הנה איפה שזה קרה", הפריט לא ראוי ל-store. ה-store הוא לא יומן — הוא תובנה מאומתת.

מנגנון דעיכה מומלץ (decay), בדוגמה מייצגת:

# decay.py — אופציונלי, מופעל ב-curation. דוגמה מייצגת
import time
HALF_LIFE_DAYS = 60        # אחרי 60 יום בלי שימוש, weight יורד לחצי
ARCHIVE_AFTER  = 180       # אחרי חצי שנה בלי שימוש → ארכיון (לא מחיקה)

def decay(weight: float, last_used: float, now: float) -> float:
    days_unused = (now - last_used) / 86400
    factor = 0.5 ** (days_unused / HALF_LIFE_DAYS)
    return round(weight * factor, 3)

def should_archive(weight: float, last_used: float, now: float) -> bool:
    days_unused = (now - last_used) / 86400
    return (days_unused > ARCHIVE_AFTER) and (weight < 0.5)

החצי-חיים (half-life) הוא המודל הנכון לזיכרון סוכן, ולא "תאריך תפוגה קשיח" — כי לקחים לא מתיישנים ביום מסוים, הם דועכים בהדרגה. אחרי חודשיים ללא שימוש, weight=2 יורד ל-1. אחרי חצי שנה, ל-0.5 — ואז הוא מועבר לארכיון, לא נמחק (תמיד אפשר לחפש בו). הסיבה לדעיכה: pattern שאף ריצה לא הזדקקה לו ב-60 יום כנראה לא רלוונטי, ועדיף לפנות מקום לחדשים.

canonicalization של failure signatures

בעיה שלא רואים עד שמתחילים לספור failures: אותו כשלון מופיע ב-20 וריאציות קלות של אותו טקסט. "API returned 403", "Got 403 from API", "HTTP 403 Forbidden", "403" — כולם אותו דבר, אבל ה-key שלך (sha1 על ה-content) יוצר 4 פריטים נפרדים, וה-Dreaming רואה "4 failures שונים" במקום "failure אחד שחוזר 20 פעמים".

הפתרון: canonicalize לפני שמכניסים ל-content. בערך:

# canonicalize.py — נרמול signatures לפני כתיבה
import re

def failure_signature(error_text: str) -> str:
    """מחזיר חתימה יציבה של failure — בלי זמנים, IDs, מספרי שורה"""
    s = error_text.lower()
    s = re.sub(r"0x[0-9a-f]+", "<HEX>", s)             # כתובות זיכרון
    s = re.sub(r"\b\d{4,}\b", "<NUM>", s)               # מספרים ארוכים (IDs, ports)
    s = re.sub(r"\b\d{1,3}(?:\.\d{1,3}){3}\b", "<IP>", s)  # כתובות IP
    s = re.sub(r"\d{4}-\d{2}-\d{2}T\d{2}:\d{2}:\d{2}", "<TS>", s)  # timestamps
    s = re.sub(r"\s+", " ", s).strip()
    return s[:120]   # חתוך — רק החלק המבדיל

עכשיו "Apollo 403 at 10.0.0.5" ו-"apollo 403 at 192.168.1.1" מצטמצמים לאותה חתימה, ה-key זהה, ה-dedup עובד, ו-Dreaming רואה failure אחד שחוזר במקום עשרים. בלי canonicalization, ה-store שלך יציג "המון נושאים" כשבעצם יש מעטים, וה-patterns ש-Dreaming יחלץ יהיו רועשים. זו דוגמה קטנה לכלל גדול: ב-store של זיכרון, עקביות של ה-input קובעת את איכות ה-output.

ליבהDreamingClaude Dreaming — מה זה ומה הוא עושה בפועל

עד עכשיו ה-store שלנו צובר decisions ו-failures גולמיים. אבל מי הופך 100 failures גולמיים ל-pattern אחד מנוסח? כאן נכנס Claude Dreaming.

לפי course.research.json (feature: "Claude Dreaming", Research Preview שהושק ב-6 במאי 2026 בכנס Code with Claude 2026): Dreaming הוא תהליך רקע אסינכרוני (asynchronous background process) ל-Claude Managed Agents, שסוקר transcripts של sessions קודמים ו-memory stores — בזמן שהסוכן לא רץ. השם לא מקרי: כמו שינה אצל בני אדם מקנסלת זיכרונות מהיום, Dreaming מקנסל את הזיכרון של הסוכן ברקע.

מה Dreaming עושה בפועל, לפי המקור — ארבע פעולות:

הנקודה החשובה: Dreaming הוא אופרטור על ה-memory store. ה-harness שלך כותב גולמי (decisions, failures) במהלך ריצות; Dreaming רץ אחר כך, מזקק את הגולמי ל-learned patterns, וכותב בחזרה. הריצה הבאה קוראת patterns מזוקקים — לא רעש.

contradiction resolution — דוגמה מוחשית

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

ריצה בודדת לא יכולה להכריע — היא ראתה רק את עצמה. אבל Dreaming, שמסתכל על כל ה-12 ביחד, רואה את התמונה: enrich-קודם מצליח ב-86% מהמקרים מול 40% ל-draft-קודם. הוא פותר את הסתירה: כותב pattern יחיד — "enrich לפני draft (86% הצלחה על פני 7 ריצות)" עם weight גבוה, ומסמן את ה-decision הנגדי כ-deprecated. בריצה הבאה, ה-READ שולף את ה-pattern המנצח בלבד. זה ההבדל בין store שצובר רעש סותר ל-store שמתכנס לאמת.

שים/י לב למה זה חייב להיות Dreaming ולא הלולאה: ההכרעה דורשת ספירה על פני transcripts רבים — בדיוק מה שריצה בודדת לא רואה. זו אותה הבחנה כמו ב-framework של dedup: מבט-על מול מבט-נקודה.

סיכוןtoken burnה-Dreaming Token Burn — הסכנה השקטה

עכשיו החלק שאי אפשר לדלג עליו. לפי course.research.json (gotchas): "The 'Dreaming' Token Burn: Asynchronous background memory curation runs Claude over up to 100 past session transcripts, burning millions of tokens."

תעצור/י על המספר הזה. ריצת Dreaming אחת סוקרת עד 100 transcripts. transcript של session אמיתי הוא לא קצר — הוא יכול להיות עשרות אלפי tokens. 100 כאלה × עיבוד ע"י Claude = מיליוני tokens לריצת curation אחת. וזה רץ ברקע, אסינכרוני, כשאתה לא מסתכל. החשבון מתפוצץ בשקט.

הסיבה שזה מסוכן יותר מ-cost explosion של subagents (פרק 6): שם ראית את ה-tokens נשרפים בזמן אמת, בריצה שאתה מסתכל עליה. כאן זה רקע. תזמנת Dreaming "אחרי כל ריצה כדי שתמיד יהיה חכם" — ופתאום, כל ריצה רגילה גוררת ריצת curation של מיליוני tokens. עשר ריצות ביום = עשר ריצות curation = עשרות מיליוני tokens ביום שאתה לא רואה עד החשבון.

שלושת בקרי ה-burn

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

שים/י לב כמה זה דומה למה שכבר בנית: תקציב background tokens הוא ה-budget cap מפרק 6, רק שמופעל על curation במקום על subagent. אותו עיקרון של harness engineering — שום תהליך לא רץ בלי תקרה. אם הפנמת בפרק 6 שכל subagent חייב max-turns ו-budget cap, אז Dreaming הוא פשוט עוד "subagent" — היקר ביותר — וחל עליו אותו חוק.

ובכל זאת, יש כאן הבדל מהותי אחד ש-makes it worse: subagent רץ בקדמת הבמה, בריצה שאתה מסתכל עליה, ואם הוא בורח אתה רואה את ה-latency. Dreaming רץ ברקע, מנותק מכל ריצה ספציפית. אין מי ש"מרגיש" שהוא יקר עד שמגיע החשבון. לכן שני בקרים מתוך השלושה — תדירות ו-scope — קיימים לא רק כדי לחסוך, אלא כדי למנוע מהעלות להיות בלתי-נראית. אתה לא יכול לסמוך על תחושה כשהתהליך אסינכרוני.

# dreaming_config.py — ריסון ה-burn. דוגמה מייצגת
# שים לב: ה-API המדויק ב-research preview ועלול להשתנות — ראה fallback בהמשך
from datetime import datetime, timedelta

DREAMING = {
    "schedule":        "0 3 * * 0",     # cron: כל יום ראשון 03:00 — לא after-run
    "max_transcripts": 30,              # scope cap, לא 100
    "only_since_last": True,            # רק transcripts חדשים
    "token_budget":    2_000_000,       # תקרה קשיחה לריצת curation אחת
    "scope_filter":    {"task_type": "lead_enrichment"},  # לקנסל ממוקד
}

def estimate_burn(num_transcripts, avg_tokens_per_transcript=40_000):
    """אומדן גס לפני שמפעילים — דוגמה מייצגת"""
    est = num_transcripts * avg_tokens_per_transcript
    capped = min(est, DREAMING["token_budget"])
    return est, capped

שים/י לב לפונקציה estimate_burn: לפני שאתה מפעיל Dreaming, אתה אומד כמה זה יעלה. 30 transcripts × 40K ≈ 1.2M tokens. עם budget cap של 2M אתה בטוח. בלי האומדן הזה — אתה מגלה את העלות מהחשבון.

שתי החלטות תזמון נוספות ששווה לקבל מודע, לא בדיפולט:

• incremental מול full: only_since_last=True אומר לסקור רק transcripts שנוספו מאז ה-curation הקודם, לא את כל ההיסטוריה בכל פעם. זה הופך את ה-burn מ"גדל ללא הגבלה ככל שהפרויקט מזדקן" ל"קבוע פחות או יותר לכל ריצה". בלי זה, ככל שתצבור transcripts, כל ריצת Dreaming תתייקר — וזו הפתעה לא נעימה אחרי חודש.
• scope_filter ממוקד: אם יש לך כמה task_types, curation על כולם ביחד מערבב הקשרים ומבזבז. עדיף ריצת Dreaming אחת לכל task_type חשוב — קטנה, ממוקדת, וזולה. ה-patterns שייצאו יהיו חדים יותר כי הם לא מדוללים ברעש ממשימות אחרות.

וקריטי: תזמון Dreaming הוא לא after-each-run, אבל גם לא "פעם בכמה שאזכר". זה cron קבוע — לילי או שבועי — כי curation לא-מתוזמן הוא או תכוף מדי (burn) או נדיר מדי (ה-store מתיישן וה-patterns לא מתעדכנים). ה-"0 3 * * 0" בקוד למעלה אומר "כל ראשון ב-03:00", שעה שבה ממילא אין עומס — זו נקודת התזמון הקלאסית לעבודת רקע כבדה.

גישה ל-Dreaming — אזהרת freshness

לפי course.research.json: Dreaming הוא Research Preview (הושק מאי 2026), הגישה "must be requested via the Anthropic Console", והוא "consumes background tokens for curation runs". ה-syllabus מסמן את פרק 7 כ-freshness_sensitive: pricing, מגבלות GA וה-API מתפתחים.

fallbackself-improvement דלself-improvement בלי Dreaming — הגרסה הדלה

מה אם אין לך גישת preview, או שאתה לא רוצה תלות ב-feature לא יציב? יש self-improvement דל שאתה בונה לבד ב-50 שורות — לא חזק כמו Dreaming, אבל מספיק להרבה מקרים, ויציב לחלוטין.

הרעיון: במקום ש-Claude יסקור 100 transcripts מלאים, ה-harness שלך מסכם תקופתית את ה-failures מה-store (שכבר מובנים מ-ch5), מקבץ אותם לפי דמיון, וכותב את הנפוצים כ-patterns. זה לא "dreaming" אמיתי — אין resolution של סתירות מתוחכם — אבל הוא תופס את הזכייה הגדולה: failures שחוזרים.

# poor_mans_dream.py — fallback ל-Dreaming. דוגמה מייצגת
from collections import Counter

def consolidate(store: MemoryStore, task_type: str, min_repeats=3):
    """גרסה דלה: מזהה failures חוזרים והופך אותם ל-patterns.
       אין סקירת transcripts מלאים — רק ה-store המובנה מ-ch5."""
    failures = store.read(task_type, kinds=["failure"], limit=1000)
    # קיבוץ גס לפי content מנורמל (חתימת שגיאה)
    counts = Counter(f["content"][:80] for f in failures)
    for signature, n in counts.items():
        if n >= min_repeats:                     # חוזר מספיק → pattern
            store.write(MemoryItem(
                MemoryKind.PATTERN, task_type,
                f"חוזר {n} פעמים: {signature}",
                evidence="poor_mans_dream",
                created_at=time.time(),
                weight=float(n)))                # weight = כמה חזר

זה ה-fallback מאחורי ה-abstraction מהקטע הקודם. ה-interface זהה (consolidate(...)), אז המעבר בין "Dreaming אמיתי" ל-"דל" הוא החלפת implementation אחת — ה-harness לא יודע מי מקנסל.

מה הגרסה הדלה לא עושה, וחשוב להיות כן/ה לגביו: היא לא פותרת סתירות חכם (היא רק סופרת חזרות), היא לא סוקרת את ה-transcript המלא (רק את ה-failure records המובנים מ-ch5), והיא לא מזהה patterns חוצי-task_type. במילים אחרות — היא תופסת את ה-"failures שחוזרים", שזו כ-80% מהערך, ומפספסת את ה-20% המתוחכם. לרוב פרויקט מוקדם, 80% הערך ב-50 שורות ובאפס סיכון freshness זו עסקה מצוינת. כשהדל מפסיק לתפוס patterns מורכבים שאתה רואה ידנית ב-Langfuse — זה האות לשדרג ל-Dreaming.

חיבורmulti-agentmemory משותף בין subagents — מתי עוזר ומתי מזהם

בפרק 6 בנית supervisor שמפצל subagents, כל אחד session נפרד. שאלה טבעית: האם ה-subagents חולקים memory store אחד, או שלכל אחד יש משלו?

התשובה היא תלוי, וההבחנה חשובה כי memory משותף יכול גם לעזור וגם לזהם:

הכלל המנחה: store משותף, read מסונן. כל ה-subagents כותבים לאותו store (כי Dreaming צריך לראות הכל כדי לקנסל), אבל כל subagent קורא רק את ה-patterns שרלוונטיים ל-task_type שלו. זה מחבר ישירות ל-read(task_type, limit) מהקטע הראשון — הסינון הוא מה שמונע זיהום.

מדידהROIמדידת ROI — האם הזיכרון באמת שיפר?

בנית memory, הפעלת Dreaming (או הדל). השאלה היחידה שחשובה: האם זה עבד? בלי מדידה, "זיכרון" הוא אמונה. עם מדידה, הוא החלטה. וזה מתחבר ישירות ל-observability מפרק 5 — ה-traces ב-Langfuse הם המקור.

שלוש מטריקות before/after שתופסות את כל הסיפור:

שים/י לב למלכוד עלות: צריך לכלול את עלות ה-Dreaming עצמו בחישוב. אם Dreaming מוריד 5% מעלות הריצות אבל שורף יותר ב-curation — הפסדת. ה-ROI האמיתי הוא: (חיסכון בריצות) − (עלות curation) > 0. זו בדיוק הסיבה שתרגיל 2 (מחשבון ה-burn) קודם למדידה כאן.

memory debt — מתי ה-store זקוק לניקוי

מטריקה רביעית שלא מדברים עליה מספיק: memory debt — היחס בין פריטים "רועשים" (לא-מאומתים, לא-בשימוש, סותרים) לבין פריטים "מועילים" (מאומתים, נקראים ב-30 יום, חד-משמעיים). ככל שה-debt עולה, ה-READ שלך מתחיל להחזיר רעש במקום signal — בלי שתשים לב. דרך מהירה לאמוד:

# memory_health.py — אומדן בריאות ה-store. דוגמה מייצגת
def memory_health(store: MemoryStore) -> dict:
    items = list(store.items.values())
    n = len(items)
    if n == 0:
        return {"items": 0, "debt_ratio": 0.0, "verdict": "empty"}
    low_weight   = sum(1 for i in items if i["weight"] < 1.0)
    no_evidence  = sum(1 for i in items if not i.get("evidence"))
    old_unused   = sum(1 for i in items if (time.time() - i["created_at"]) > 90*86400)
    debt = (low_weight + no_evidence + old_unused) / (3 * n)
    verdict = "healthy" if debt < 0.2 else ("watch" if debt < 0.5 else "needs cleanup")
    return {"items": n, "debt_ratio": round(debt, 2), "verdict": verdict}

הסף המעשי: debt מעל 0.5 = ה-store מפריע יותר ממה שהוא עוזר. הפעולה: הפעל decay (קטע "משקל, דעיכה ואיכות פריט"), הרץ archive, ובדוק אם ה-READ שלך מחזיר יותר איכות. memory debt היא לא מטריקה יפה — היא סימן אזהרה מוקדם לבעיה שתתפוצץ לך ב-context בלי התראה.

תפעולdebuggingבדיקה ואיתור באגים בזיכרון — למה הסוכן לא משתמש ב-patterns

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

חמש סיבות נפוצות לכך ש-memory לא משפיע, מהנפוצה ביותר לנדירה:

הצעד הראשון תמיד: לוג של ה-READ. הוסף/י שורה ב-run_task():

if os.getenv("DEBUG_MEMORY"):
    print(f"[mem] task_type={task_type} → {len(lessons)} lessons")
    for l in lessons:
        print(f"  - [{l['kind']}|w={l['weight']}] {l['content'][:60]}")

בלי הלוג הזה, אתה מנחש. איתו, אתה רואה בדיוק מה ה-READ החזיר, והבעיה הופכת לברורה תוך שניות: "ה-pattern בכלל לא נטען", "הוא נטען אבל במקום השלישי", "הוא נטען אבל ל-task_type אחר". רוב באגי ה-memory נופלים בסעיף הראשון — task_type לא תואם — בגלל טעות הקלדה פשוטה או inconsistency בין קוד הכתיבה לקוד הקריאה.

items = [
  {"kind":"pattern","task_type":"lead_enrichment","content":"Apollo needs X-Version header","weight":2.0,"evidence":"t1","created_at":time.time()},
  {"kind":"pattern","task_type":"Lead_Enrichment","content":"wrong-case pattern","weight":5.0,"evidence":"t2","created_at":time.time()},  # BUG
  {"kind":"pattern","task_type":"lead_enrichment","content":"noisy low-weight pattern","weight":0.2,"evidence":"t3","created_at":time.time()},
  {"kind":"pattern","task_type":"lead_enrichment","content":"Apollo rate-limits after 50 req/min","weight":3.5,"evidence":"t4","created_at":time.time()},
  # ... 8 more decoys
]

פרטיותPIIPII ופרטיות — מה לא לשמור ב-store

נושא שרוב המדריכים מדלגים עליו: memory store הוא מאגר נתונים. אם הסוכן שלך רץ על נתוני לקוחות (שמות, אימיילים, כתובות, טלפונים), אתה צריך להחליט לפני שה-write הראשון קורה מה באמת נכנס ל-store. ברירת המחדל — "הכל נכתב" — היא הסכנה.

הנה הקטגוריות שכמעט תמיד לא שייכות ב-store:

הכלל: store זוכר עקרונות, לא ערכים. "Apollo needs X-Version header" — כן, זה עיקרון. "הלקוח יוסי כהן מתל אביב שלח אימייל עם API key sk-..." — לא, זה תוכן. אם אתה לא יכול להוציא את המזהים מבלי לאבד את הערך של הלקח — כנראה הלקח עצמו לא שייך ב-store. ה-store שלך הוא לא logs; הוא lessons learned in the abstract.

# redact.py — סניטציה לפני כתיבה. דוגמה מייצגת
import re

_PATTERNS = [
    (re.compile(r"\b[A-Za-z0-9._%+-]+@[A-Za-z0-9.-]+\.[A-Za-z]{2,}\b"), "<EMAIL>"),
    (re.compile(r"\b(?:\+972|0)(?:-?\d){8,10}\b"),                            "<PHONE>"),
    (re.compile(r"\bsk-[A-Za-z0-9]{20,}\b"),                                 "<SECRET>"),
    (re.compile(r"\b\d{4}[ -]?\d{4}[ -]?\d{4}[ -]?\d{4}\b"),                 "<CARD>"),
]

def redact(text: str) -> str:
    for pat, repl in _PATTERNS:
        text = pat.sub(repl, text)
    return text

ולא רק בזמן הכתיבה — גם בזמן הקריאה. אם ה-pattern נכתב נקי אבל ה-system prompt שאתה בונה משרשר אותו עם נתונים גולמיים מהמשימה, ה-PII נכנס בעקיפין. תמיד redact בשני הצדדים — write ו-read.

בדיקה עצמיתבדיקה עצמית

סיכוםגשרסיכום וגשר לפרק הבא

צ'קליסטצ'קליסט סיום פרק 7

סמן/י כל פריט לפני המעבר לפרק 8. אם פריט לא מסומן — חזור/י לקטע הרלוונטי.

• הגדרתי memory_store.py עם שלוש קטגוריות (decision / failure / pattern) ו-schema ברור.
• ה-write() עושה dedup אוטומטי לפי key — אותו לקח לא נכתב פעמיים.
• ה-read() מחזיר top-N מסונן לפי task_type — לא את כל ה-store (מונע זיהום context מ-ch3).
• חיברתי read בתחילת המשימה (5 שורות ל-system) ו-write בסופה (decisions + failures מ-ch5) — תרגיל 1 רץ עם פלט גלוי.
• אני מבין/ה שאת ה-learned patterns כותב רק Dreaming, לא ריצה בודדת.
• אני יודע/ת מה Dreaming עושה: pattern extraction, contradiction resolution, dedup, consolidated write-back.
• הפנמתי את ה-Dreaming Token Burn: עד 100 transcripts = מיליוני tokens, רץ ברקע.
• הגדרתי שלושת בקרי ה-burn: תדירות מרוסנת + scope cap + token budget קשיח.
• בניתי מחשבון burn (תרגיל 2) שמשווה after-each-run מול שבועי, עם USD/ILS+VAT.
• עטפתי את Dreaming מאחורי abstraction עם fallback ל-self-improvement דל (תרגיל 3).
• בניתי גרסת self-improvement דלה (poor_mans_dream) שעובדת בלי preview.
• הגדרתי memory משותף בין subagents כ-"store משותף, read מסונן" — לא context משותף.
• הגדרתי שלוש מטריקות ROI (חזרה-על-טעויות, הצלחה, עלות) מ-Langfuse, כולל עלות ה-curation עצמו.
• אימתתי את זמינות ומחיר Dreaming מול הדף הרשמי managed-agents/dreams (research preview).
• הגדרתי weight scoring + decay (half-life 60 יום) + archive (180 יום) כדי שה-store לא ייצבור רעש.
• הוספתי canonicalization ל-failure signatures (regex על IDs, IPs, timestamps) לפני write.
• הוספתי DEBUG_MEMORY=1 לוג ל-READ כדי לאבחן במהירות "למה הסוכן לא משתמש ב-pattern".
• תרגלתי memory audit (תרגיל 4) ומצאתי pattern שהוסתר בגלל task_type case-sensitivity.
• הוספתי redact() לפני כל write ל-store (אימייל, טלפון, secrets, cards).
• הרצתי pii_scan() על ה-store הקיים (תרגיל 5) ואישרתי 0 דליפות.
• הגדרתי memory_health() וסף debt<0.5; תיעדתי מה עושים כשחורגים.
• קבעתי שגרת עבודה שבועית: כתיבה יומית אוטומטית, curation שבועי, בדיקת מטריקות 5 דק', ROI + memory_health חודשי.

מילוןמילון מונחים — פרק 7