Machen Sie aus einem Agenten einen Dienst, kein vergessenes Terminal.

Den Worker paketieren

Verwenden Sie eine unterstützte Laufzeitumgebung, festgelegte Abhängigkeiten und einen Dienstmanager oder Container. Konfigurieren Sie Neustartlimits und einen dedizierten Dienstbenutzer. Bewahren Sie private Anbieter-Anmeldedaten in geschützter Konfiguration außerhalb der öffentlichen Dateien der Anwendung auf.

Fortschritt speichern, bevor Aktionen wichtig werden

Verwenden Sie eine dauerhafte Warteschlange oder Datenbank für Aufträge. Vergeben Sie eine eindeutige Vorgangskennung, zeichnen Sie externe Anfragen auf und gleichen Sie unklare Ergebnisse ab. Ein Neustart sollte keine zweite E-Mail senden, keine zweite Bestellung anlegen und nicht doppelt berechnen.

Fügen Sie nützliche Observability hinzu

Überwachen Sie den Abschluss von Aufgaben, das Alter der Warteschlange, die Fehlerrate und die Kosten, statt nur zu prüfen, ob ein Prozess existiert. Halten Sie Protokolle klein genug zur Überprüfung und schwärzen Sie Token, Prompts und Dokumente, die nicht aufbewahrt werden müssen.

Setzen Sie eine klare Obergrenze

Begrenzen Sie Modellausgaben, Browser-Parallelität, Laufzeit und Wiederholungsanzahl. Halten Sie einen einfachen Pausenschalter und einen menschlichen Prüfpfad für folgenreiche Aktionen bereit. Ein kleinerer, gut überwachter Worker ist leichter zu vertrauen als ein uneingeschränkter.

Einen Supervisor und einen bewussten Zeitplan verwenden

Systemd und Docker sind gängige Wege, damit ein Prozess eine Terminal-Trennung übersteht. Bei einem systemd-Dienst kann Type=exec einen Ausführungsfehler direkter melden als ein einfacher Hintergrundstart, und Restart=on-failure kann Fehler mit einer begrenzten Richtlinie neu starten. Geplante Aufgaben sollten überlappende Läufe vermeiden. Halten Sie das Arbeitsverzeichnis, den Dienstbenutzer und die Umgebung explizit. Das Beispiel setzt voraus, dass der Benutzer koala-agent, die virtuelle Umgebung, das Worker-Modul und die private Umgebungsdatei bereits existieren; passen Sie sie an, bevor Sie eine Unit installieren.

• Verwenden Sie ein dediziertes Dienstkonto
• Legen Sie eine Neustartverzögerung und eine Fehlergrenze fest
• Prüfen Sie den vorherigen Auftragsstatus, bevor Sie einen geplanten Lauf starten

[Unit]
Description=Example agent worker
After=network-online.target

[Service]
Type=exec
User=koala-agent
WorkingDirectory=/opt/koala-agent
EnvironmentFile=/etc/koala-agent.env
ExecStart=/opt/koala-agent/.venv/bin/python -m worker
Restart=on-failure
RestartSec=10
NoNewPrivileges=true

[Install]
WantedBy=multi-user.target

Offizielle Dokumentation: Semantik von Systemd-Diensten

Legen Sie ein Tagesbudget und eine Duplikatgrenze fest

Legen Sie für den Worker eine maximale Anfrageanzahl, ein Ausgabenlimit und ein Ausführungs-Timeout fest. Verwenden Sie einen dauerhaften Idempotenz-Datensatz für Aktionen, die die Außenwelt betreffen. Ein erfolgreicher Browser-Klick kann erfolgen, bevor der Prozess eine Antwort erhält; prüfen Sie den externen Zustand, bevor Sie es erneut versuchen. Docker-Compose-Secret-Mounts können ein Secret aus dem Image heraushalten, aber Berechtigungen und die nutzende Anwendung müssen dennoch überprüft werden.

Offizielle Dokumentation: Docker-Compose-Secrets

Geben Sie einem periodischen Job eine explizite Aufholrichtlinie

Verwenden Sie einen langlaufenden Dienst für einen persistenten Queue-Worker und einen timer-ausgelösten Oneshot-Dienst für eine begrenzte geplante Aufgabe. Mit einem systemd-Kalender-Timer kann Persistent=true eine verpasste Aktivierung nach einer Ausfallzeit auslösen; es stellt keinen gesamten Geschäftsrückstand wieder her. Entscheiden Sie, ob dieses Nachholen wünschenswert ist. RandomizedDelaySec kann Starts verteilen, während eine Lease auf Anwendungsebene verhindert, dass zwei Replikate dieselbe geplante Arbeit verarbeiten.

• Notieren Sie die vorgesehene Zeitzone und prüfen Sie die nächsten Ausführungszeiten, bevor Sie den Zeitplan aktivieren.
• Halten Sie die Ausführungsfrist der Aufgabe kürzer als ein Intervall, das sich nicht überschneiden darf, oder verwenden Sie eine dauerhafte Lease mit Ablauf und Eigentümerschaft.
• Lassen Sie den Job ausstehende Arbeit aus dem gespeicherten Zustand auswählen, statt anzunehmen, dass jedes vorherige Timer-Ereignis ausgeführt wurde.
• Prüfen Sie die installierte systemd-Version, bevor Sie eine Direktive aus dem neuesten Handbuch verwenden.

# Read-only checks after creating your own matching units.
systemctl list-timers --all
systemctl status koala-agent.service
journalctl -u koala-agent.service --since today --no-pager

Offizielle Dokumentation: systemd: Timer-Planung

Unterscheiden Sie eine Crash-Schleife von einem hängenden Worker

Eine Neustartrichtlinie kann einen fehlgeschlagenen Prozess wiederherstellen, aber das Wiederholen ungültiger Anmeldedaten oder einer fehlerhaften Migration alle paar Sekunden macht einen Fehler lauter. Begrenzen Sie Dienststarts und warnen Sie bei wiederholtem Fehlschlag. Ein laufender Prozess kann auch hängen: Messen Sie das Alter des ältesten Auftrags und der zuletzt abgeschlossenen Operation. Testen Sie einen API-Ausfall, eine leere Festplatte und einen Prozessstopp mit Wegwerf-Aufträgen und prüfen Sie dann, ob der dauerhafte Zustand doppelte externe Aktionen verhindert.

• Legen Sie im Anwendungscode ein Anbieterbudget und ein Anfrage-Timeout sowie eine CPU/Speicher-Grenze in der Laufzeitumgebung fest.
• Docker-Container haben nicht allein deshalb ein sinnvolles arbeitslastspezifisches Speicherlimit, weil sie Container sind; konfigurieren und testen Sie Limits bewusst.
• Speichern Sie ein Geheimnis außerhalb des Images und des öffentlichen Verzeichnisbaums und testen Sie dann, ob Absturzprotokolle und Diagnosedaten es redigieren.
• Halten Sie einen manuellen Stoppweg bereit und verlangen Sie eine angemessene Prüfung für Ausgaben, Produktionsschreibvorgänge oder externe Nachrichten.

Offizielle Dokumentation: systemd: Dienstüberwachung · Docker: Ressourcenbeschränkungen für Container