Betreibt jemand KI-Agenten als langlebige Hintergrundprozesse, nicht nur als Chat-Schnittstellen?

Agenten sind hauptsächlich aufgrund von Speicherbeschränkungen zerbrechlich

Was Sie fragen, wird derzeit nicht gemacht, weil Watcher-Apps es besser können. K-I-S-S ist wirklich der beste Standard

Zu Ihren Punkten:

Überwachung und Alarmierung können lokal mit 0 Agenten durchgeführt werden

Verarbeitungswarteschlangen würden eine Übergabe erfordern. Ich hoste derzeit selbst ein Fizzy-Board und habe MCPs an Grok-cli und Kiro-cli angeschlossen. Die Webhooks benachrichtigen die Gruppe, wenn ein Agent eine Aufgabe abgeschlossen hat. Dies gibt mir auch eine visuelle Karte dessen, was in meinem Projekt passiert

Tägliche Zusammenfassungen sind absolut machbar und könnten mit jedem der gängigen Harnesses (OpenClaw, Hermes usw.) durchgeführt werden

Das Beobachten von Ereignissen könnte über RSS erfolgen oder, wenn Sie es wirklich agentisch haben möchten, erstellen Sie einfach einen Scraper für Ihren Ereignistyp und richten Sie ihn auf die Seiten, die Ihrer Meinung nach die besten Ergebnisse liefern (Konzerte = stubhub). Dies könnte auch von Ihrer agentischen Harness übernommen werden

Ich hoffe, diese Informationen sind hilfreich für Sie. Alles Gute

Technisch gesehen waren Dinge wie automatisierte OCR bei eingehenden Dokumenten und Indizierung für Suchanfragen schon KI, lange bevor LLMs ein Thema waren, aber das ist wahrscheinlich nicht das, worauf Sie sich beziehen.

LLMs sind von Natur aus probabilistisch, daher ist der sinnvolle Anwendungsfall etwas, das unstrukturierte Daten als Eingabe nimmt und entweder unstrukturierte oder halbstrukturierte Ausgabe erzeugt, ohne dass es eine konsistente Möglichkeit gibt, diese Zuordnung durchzuführen.

Neue Artikel erscheinen online, fassen Sie zusammen und ordnen Sie sie vorhandenen Datenpunkten zu, damit wir einen Informationsgraphen zu einem Thema erstellen können. Generieren Sie eine KI-Zusammenfassung der Nachrichten aus einem Dutzend RSS-Feeds, die ich sonst nicht lesen würde, und senden Sie mir ein Briefing per E-Mail. Fassen Sie neue Antworten auf eine offene Umfragefrage zusammen und aktualisieren Sie ein Dashboard, um einen gleitenden Durchschnitt der Meinungen zu erhalten. Überwachen Sie ein GitHub-Repository und prüfen Sie auf häufige Fehler oder Codeverbesserungen und reichen Sie einen Pull-Request ein. Analysieren Sie anomales Verhalten und senden Sie eine Zusammenfassung an einen menschlichen Entscheider. All dies existiert in Systemen, die ich entweder betreibe oder im Rahmen meiner Arbeit handhabe, und sie alle funktionieren, indem sie explizite Eingabeauslöser, Grenzen für das, was sie produzieren, und Token-Obergrenzen dafür haben, wie viele Token in einer einzigen Pipeline generiert werden können. Sie können Ihre Kosten bestimmen, indem Sie die Anzahl der möglichen Auslösungen mit der Anzahl der Token multiplizieren, die jeder Auslöser aufnehmen und generieren kann, und das ist Ihre obere Kostengrenze.

Bei etwas mit unbestimmter Eingabegröße oder das öfter ausgelöst werden könnte, müssen Sie an der Quelle Schutzmaßnahmen einbauen. Sie können sich nicht darauf verlassen, dass der Agent den Endpunkt allein herausfindet. Stecken Sie kein LLM, um Ihre Loki-Protokolle direkt zu lesen, sondern lassen Sie es nur feuern, wenn es einen diskreten Anstieg der von Prometheus oder Kuma gemeldeten Probleme bemerkt. Übergeben Sie es einem billigen Modell wie Sonnet oder Haiku zur Klassifizierung. Wenn es einen ausreichenden Schwellenwert überschreitet, übergeben Sie es einer intelligenteren KI zur Zusammenfassung. Ich würde sagen, aktuelle Modelle sind nicht einmal gut genug, um ohne menschliche Beteiligung automatisch zu debuggen, aber ich denke, das hängt von der Risikobereitschaft des Benutzers für außer Kontrolle geratene Prozesse ab. Sie können immer Nutzungslimits als Stoppmaßnahme vor der KI setzen.

Agentenorchestrierung wird ein wachsendes Feld sein, wenn sich Agenten als wertvoll erweisen und in großem Maßstab betrieben werden. Ich habe persönlich keine verwendet, aber ich habe von Leuten in verschiedenen Laboren gehört, die sie aufgreifen und praktizieren. In diesen Fällen ist es ihnen jedoch egal, Geld zu verbrennen, sie kümmern sich darum, Ergebnisse zu finden.

Für Hintergrund-Agenten ist ein praktikables Muster eher ein langweiliger Worker-Dienst als ein Chat-Agent. Verwenden Sie explizite Auslöser, begrenzte Aufträge und eine separate Überwachung.

Eine funktionierende Form:

Warteschlange/Ereignis/Zeitplan erstellt einen Auftrag mit einem Idempotenzschlüssel

Agent erhält eine kleine Tool-Whitelist und ein hartes Budget pro Auftrag

Jede Entscheidung schreibt ein append-only Ereignis mit Eingaben, Tool-Aufrufen, Ausgabezusammenfassung

Überwachung außerhalb des Modells prüft maximale Laufzeit, Ausgaben, Wiederholungsanzahl und Heartbeat-Alter und leitet fehlgeschlagene Aufträge an eine Dead-Letter-Warteschlange mit der erfassten Ereignisspur für die Wiederholung weiter

Ausgaben, die den Zustand ändern können, durchlaufen entweder Trockentest, Diff oder menschliche Genehmigung, bis diese Aufgabenklasse als risikoarm erwiesen ist

Das hält den Agenten nützlich für unstrukturierte Arbeit, während die tatsächliche Zuverlässigkeit von normalen Betriebskontrollen kommt: Worker, Warteschlangen, Leases, Dead-Letter-Warteschlangen, Alarme und Kill-Switches.

Die meisten Bedenken bezüglich außer Kontrolle geratener Agenten verschwinden, wenn man den Agenten von seinem Beobachter trennt. Ein billiges Bash-Skript (kein weiteres LLM) überwacht Kosten, Fehlerrate und den Zeitstempel des letzten Laufs und tötet den Agenten, wenn ein Schwellenwert erreicht wird. Das liefert den 3-Uhr-Morgens-Notausschalter, die Sichtbarkeit von stillem Erfolg und ausführlichem Fehlschlag sowie die Budgetbegrenzung aus einem einzigen Prozess. Die laufende Schleife selbst hängt nur Anomalien an.