/always-on-agent-inputs – Kontext für einen persistenten Agenten bereitstellen
Sie entwerfen, was ein ständig aktiver Agent sieht, hört und weiß. Die Architektur-Fähigkeit kümmert sich darum, wo das Gedächtnis lebt. Diese Fähigkeit kümmert sich darum, was hineinkommt – die rohen Signale, wie sie strukturiert sind, wann der Agent aufwacht und wie das Kontextfenster ehrlich gehalten wird.
ENTSCHEIDUNGSPUNKTE
AUSWAHL DER ABRUFSTRATEGIE
Agent-Aufgabentyp → Abrufstrategie
WENN gesprächsorientiert/Chat:
├─ Aktualität zuerst verwenden (70% zeitlich, 30% semantisch)
├─ Budget: 15K Gesprächsverlauf + 4K letzte Erinnerungen
└─ Archiv überspringen, es sei denn, der Benutzer fragt "Erinnerst du dich, als..."
WENN Problemlösung/Debugging:
├─ Relevanz zuerst verwenden (60% semantisch, 40% zeitlich)
├─ Budget: 8K Archiv + 4K Erinnerungen + 2K Umgebung
└─ Fehlermuster aus früheren Lösungen einschließen
WENN Kontextwechsel erkannt:
├─ Häufigkeitsbasiert verwenden (woran arbeitet der Benutzer am meisten?)
├─ Budget: 6K Projektkontext + 2K aktuell + 4K Ziele
└─ Entitätshistorie für aktive Dateien/Personen abrufen
WENN geplanter Trigger (morgendliche Besprechung):
├─ Strukturierte Agenda verwenden (Kalender + Aufgaben + Aktualisierungen)
├─ Budget: 4K Kalender + 4K unerledigte Aufgaben + 2K Änderungen
└─ Kein Gesprächsverlauf erforderlich
WENN reaktiver Trigger (CI-Fehler, Meeting beginnt):
├─ Ereignisspezifisches Kontextladen verwenden
├─ Budget: 8K Ereigniskontext + 4K relevanter Verlauf
└─ Allgemeines Gespräch überspringen, sofern nicht relevant
FILTERUNG VON UMGEBUNGSDATEN
Bildschirm-/Audio-Beobachtung → Filter-Entscheidung
WENN gleiche App + gleicher Text >5 Minuten:
└─ VERWERFEN (keine Änderung, Rauschen)
WENN App-Wechsel erkannt:
├─ Übergangsdatensatz BEHALTEN
└─ Relevanz des neuen App-Inhalts bewerten
WENN hochsignifikante Schlüsselwörter gefunden:
├─ Gegen aktive Projekte/Ziele prüfen
├─ WENN Übereinstimmungswert >0,6 → IM Archiv + Erinnerungen SPEICHERN
├─ WENN Übereinstimmungswert 0,3-0,6 → NUR in Erinnerungen SPEICHERN
└─ WENN Übereinstimmungswert <0,3 → VERWERFEN
WENN technischer Fehler/Ausnahme sichtbar:
├─ IMMER SPEICHERN (Debugging-Kontext)
└─ Mit Dringlichkeitsstufe taggen
WENN Kalenderereignis erwähnt:
├─ IMMER SPEICHERN (zeitlicher Anker)
└─ Mit tatsächlichem Kalender abgleichen
ZUTEILUNG DER TRIGGER-DRINGLICHKEIT
Ereignistyp + Kontext → Dringlichkeitsstufe
WENN CI-Fehler:
├─ Produktionsbranch → AKTIV (Benutzer benachrichtigen)
├─ Feature-Branch + Benutzer programmiert gerade → PASSIV (erwähnen, wenn Benutzer nächstes Mal interagiert)
└─ Alter Branch/PR → STILL (nur protokollieren)
WENN Meeting beginnt:
├─ <5 Minuten → AKTIV (mit Vorbereitung unterbrechen)
├─ 5-15 Minuten → ABZEICHEN (Vorbereitung verfügbar anzeigen)
└─ >15 Minuten → STILL (Vorbereitung im Hintergrund)
WENN Code-Änderung erkannt:
├─ Erster Commit auf neuem Branch → PASSIV (neue Arbeit notieren)
├─ Commit behebt vorherigen Fehler → PASSIV (Lösung notieren)
└─ Regelmäßige Commits → STILL (Fortschritt verfolgen)
WENN in Slack erwähnt:
├─ Direktnachricht → AKTIV (Antwort erforderlich)
├─ Kanalerwähnung + dringende Schlüsselwörter → AKTIV
└─ Kanalerwähnung, normal → ABZEICHEN (prüfen, wenn es passt)
FEHLERMODI
Schema-Aufblähung
- Symptome: Kontextfenster ständig maximal ausgelastet, langsame Antworten, hohe Token-Kosten trotz Filterung
- Ursache: Beobachtungsschemata erfassen jedes Feld, anstatt nur das, was der Agent zum Denken benötigt
- Erkennungsregel: Wenn die durchschnittliche Kontextgröße >50K Token oder der Beobachtungsspeicher >1MB/Tag beträgt, liegt Schema-Aufblähung vor
- Behebung: Schemata monatlich überprüfen. Felder entfernen, die in 30 Tagen keine Entscheidung beeinflusst haben. Zusammenfassung anstelle von Rohspeicherung verwenden.
Abruf-Thrashing
- Symptome: Der Agent erwähnt veraltete Informationen, übersieht aktuellen Kontext oder ruft wiederholt irrelevante Erinnerungen ab
- Ursache: Einstufige Vektorsuche ohne Neubewertung oder zeitlich/semantische Gewichtung schlecht abgestimmt
- Erkennungsregel: Wenn >30% des abgerufenen Kontexts in Antworten ungenutzt bleibt oder der Benutzer den Agenten zu aktuellen Ereignissen korrigiert
- Behebung: Zweistufigen Abruf implementieren (breite Suche + Neubewertung). A/B-Tests mit verschiedenen zeitlich/semantischen Gewichtsverhältnissen durchführen.
Trigger-Spam
- Symptome: Benutzer deaktiviert Agentenbenachrichtigungen, beschwert sich über Unterbrechungen oder der Agent wird ignoriert
- Ursache: Keine Dringlichkeitseinstufung oder Schwellenwerte für aktive/Unterbrechungs-Trigger zu niedrig angesetzt
- Erkennungsregel: Wenn der Benutzer >50% der aktiven Benachrichtigungen verwirft oder die durchschnittliche Zeit zwischen Benutzerinteraktionen >4 Stunden beträgt
- Behebung: Alles standardmäßig auf still setzen. Benutzer explizit konfigurieren lassen, was eine aktive Benachrichtigung verdient. Verwerfungsraten verfolgen.
Kontextveralterung
- Symptome: Der Agent handelt auf Basis veralteter Informationen, übersieht, dass der Benutzer den Fokus/die Projekte geändert hat
- Ursache: Keine Frischeabnahme des Kontexts oder Abrufgewichte berücksichtigen Aktualität nicht ausreichend
- Erkennungsregel: Wenn der Agent Informationen referenziert, die >7 Tage alt sind, obwohl aktueller Kontext existiert, oder abgeschlossene Projekte erwähnt
- Behebung: Exponentiellen Verfall der Relevanzwerte hinzufügen. Aktuelle Beobachtungen 2-3x höher gewichten als Archivmaterial.
Umgebungsrauschen-Überflutung
- Symptome: Hohe Kosten, schlechte Antwortqualität, Agent erwähnt irrelevanten Bildschirmkontext
- Ursache: Rohdaten der Umgebung umgehen die Filterung oder Relevanzschwellen sind zu großzügig eingestellt
- Erkennungsregel: Wenn Umgebungsbeobachtungen >30% der gespeicherten Erinnerungen ausmachen oder die Token-Kosten >10$/Tag betragen
- Behebung: Relevanzbewertung verschärfen. Umgebungsbeobachtungen in 5-Minuten-Fenstern bündeln. 2+ Signale zur Bestätigung der Relevanz erfordern.
DURCHGEFÜHRTE BEISPIELE
Szenario: Untersuchung eines Abrechnungsfehlers mit Token-Budget-Beschränkungen
Benutzer meldet: "Die Abrechnungsberechnung für Enterprise-Kunden ist falsch."
Schritt 1: Kontextbudget-Zuteilung (40K gesamt)
System + Identität: 4K Token (fest)
Kernspeicher: 2K Token (Benutzereinstellungen, aktive Projekte)
ENTSCHEIDUNG: Problemlösungsaufgabe → relevanzbasierten Abruf verwenden
Zugewiesen: 8K Archiv + 4K Erinnerungen + 2K Umgebung + 15K Gespräch + 5K Ausgabepuffer
Schritt 2: Ausführung der Abrufstrategie
# Breite semantische Suche nach abrechnungsbezogenen Erinnerungen
archiv_kandidaten = vector_suche(
abfrage="billing calculation enterprise customer error bug",
top_k=20,
filter={"Projekt": ["billing", "payments"]}
)
# Neubewertung nach echter Relevanz (nicht nur Embedding-Ähnlichkeit)
neu_bewertet = neu_bewerten(archiv_kandidaten, abfrage, top_k=5)
# Ergebnis: Holt "Enterprise-Rabattlogik-Fehler von vor 3 Wochen",
# den die reine Vektorsuche auf Platz 12 eingestuft hatte
# Zeitliche Suche nach aktueller Abrechnungsarbeit
aktuelle_arbeit = zeitliche_suche(
zeitraum="letzte_7_tage",
entitätsfilter=["billing", "enterprise"],
max_ergebnisse=3
)
# Ergebnis: Benutzer hat gestern an Preisstufen für Enterprise gedebuggt
Schritt 3: Integration von Umgebungskontext
# Prüfen, was der Benutzer gerade tut
bildschirm_zusammenfassung = umgebungs_zusammenfassung_abrufen(letzte_30_minuten)
# Ergebnis: "Benutzer hat billing_calculator.py geöffnet, betrachtet
# Funktion calculate_enterprise_discount()"
# Budget-Prüfung: 8K Archiv + 4K aktuell + 2K Umgebung = 14K (unter Budget)
Schritt 4: Schnell vs. Vollständig – Abwägung Der Agent hat zwei Optionen:
- Schneller Abruf (aktuell): 14K Kontext, konzentriert sich auf aktuelle Fehlermuster
- Vollständiger Kontext: Git-Verlauf, zugehörige PR-Diskussionen hinzufügen (+8K Token, überschreitet Budget)
Entscheidung: Beim schnellen Abruf für die erste Antwort bleiben. Wenn der Benutzer nach tiefergehender Untersuchung fragt, einen Folgeabruf mit erweitertem Kontextbudget auslösen.
Qualität der Agentenantwort:
- Anfängeransatz: Würde den gesamten abrechnungsbezogenen Kontext ausgeben, das Budget überschreiten und eine verwirrte Antwort erhalten
- Expertenansatz: Kuratierte 14K des relevantesten Kontexts, erwähnt den spezifischen Enterprise-Rabatt-Fehler von vor 3 Wochen, den die reine Vektorsuche übersehen hätte, bleibt unter Budget
QUALITÄTSGATES
- Kontextfenster-Zuteilung explizit über Ebenen hinweg budgetiert (System/Kern/abgerufen/Gespräch)
- Gesamte Token-Anzahl pro Anfrage beträgt durchschnittlich <40K für Routineinteraktionen
- Umgebungsbeobachtungen werden vor der Speicherung durch die Relevanz-Pipeline gefiltert
- Abruf verwendet einen zweistufigen Prozess (breite Suche + Neubewertung)
- Alle Trigger sind nach Dringlichkeit kategorisiert (still/Abzeichen/passiv/aktiv/unterbrechend)
- Beobachtungsschemata enthalten Zeitstempel, Konfidenzwert und Quelle
- Filter-Pipeline getestet: <30% des abgerufenen Kontexts bleibt in Antworten ungenutzt
- Benutzer verwirft <20% der aktiven Benachrichtigungen (Trigger-Spam-Prüfung)
- Der Agent referenziert aktuelle Informationen (letzte 24h), wenn verfügbar, anstatt standardmäßig auf Archiv zurückzugreifen
- Speicherwachstumsrate <100MB/Woche pro Benutzer (Effizienzprüfung)
GRENZEN UND AUSSCHLÜSSE
Verwenden Sie /always-on-agent-inputs für:
- Entscheiden, welche Daten aus der Benutzerumgebung erfasst werden sollen
- Strukturieren von Triggern und Beobachtungsschemata
- Budgetierung des Kontextfensters und Auswahl der Abrufstrategie
- Filtern von Umgebungsdaten, bevor sie den Agenten erreichen
NICHT verwenden für:
- Entwurf der Speicherarchitektur (Vektor-Datenbanken, Speicher, Speicherebenen) →
/always-on-agent-architectureverwenden - Ideenfindung für Anwendungen und Anwendungsfälle →
/always-on-agent-applicationsverwenden - Datenschutz und Sicherheit der erfassten Daten →
/always-on-agent-safetyverwenden - Allgemeine Prompt-Engineering-Techniken →
/prompt-engineerverwenden - Denkmuster von Agenten →
/agentic-patternsverwenden