Blog · Anleitung · 28. Oktober 2026

Einen geplanten Agenten mit AEGIS ausführen: Zeitpläne, Läufe und was Sie sehen, wenn einer scheitert

Auch auf: English, Español, Português, 日本語, Français, 한국어, 简体中文, Italiano, हिन्दी · Alle Anleitungen auf Deutsch

Offenlegung: 100monkeys.ai entwickelt AEGIS, lesen Sie diese Anleitung also als Bericht des Herstellers. Einer unserer KI-Agenten hat sie aus der öffentlichen AEGIS-Dokumentation entworfen, vor allem der Seite Schedules und der Referenz Schedule Tools, und das Unternehmen hat sie geprüft; diese deutsche Ausgabe ist eine Übersetzung der englischen Originalanleitung. Jedes Feld, jede Route und jede Meldung unten ist aus diesen Seiten zitiert, auf Englisch mit der Übersetzung daneben. Für diese Anleitung haben wir die Aufrufe nicht ausgeführt, und wo die Doku einen Schritt offenlässt, sagen wir es.

AEGIS by 100monkeys.ai, in beta, ist ein selbst gehosteter Orchestrator, der autonome Agenten in isolierten, richtliniengesteuerten Laufzeiten ausführt. Diese Anleitung setzt einen Ihrer Agenten auf einen Zeitplan, liest zurück, was jede Auslösung getan hat, und zeigt die vier möglichen Ergebnisse, damit ein Lauf, der nicht stattfand, so sichtbar ist wie einer, der stattfand.

Was ein Zeitplan ist

Die Doku definiert ihn in einem Satz: "A schedule starts one of your agents or workflows as you, either once at a time you choose or again and again on a recurrence." (Ein Zeitplan startet einen Ihrer Agenten oder Workflows in Ihrem Namen, entweder einmal zu einer gewählten Zeit oder wiederholt nach einem Rhythmus.) Daraus folgen drei Dinge, und jedes prägt die Schritte unten.

• Ein Zeitplan ist Ihr eigenes Objekt, "never a field of the agent or workflow it runs" (nie ein Feld des Agenten oder Workflows, den er ausführt).
• Er läuft als Person. "A schedule always runs as a person. A service account, or an operator acting for no person, cannot make, change, pause, resume, run or delete one." (Ein Zeitplan läuft immer als Person. Ein Dienstkonto oder ein Operator, der für keine Person handelt, kann keinen anlegen, ändern, pausieren, fortsetzen, ausführen oder löschen.)
• Jede Auslösung ist ein gewöhnlicher Lauf. "At each fire the orchestrator starts the run exactly as aegis.task.execute or aegis.workflow.run would for you, with the schedule's intent, input and connections." (Bei jeder Auslösung startet der Orchestrator den Lauf genau so, wie es aegis.task.execute oder aegis.workflow.run für Sie täten, mit Absicht, Eingabe und Verbindungen des Zeitplans.)

Schritt 1. Agent und Zeitpunkt wählen

Nehmen Sie einen Agenten, den Sie schon einmal von Hand mit aegis task execute <AGENT> ausgeführt haben, damit Sie wissen, wie ein guter Lauf aussieht.

Wählen Sie dann eine von zwei Zeitangaben. Sie geben genau eine an.

• Einmalig: at, eine RFC-3339-Zeit "at least one minute from now and at most a year ahead" (mindestens eine Minute ab jetzt und höchstens ein Jahr im Voraus).
• Wiederkehrend: recurrence mit cron, timezone und jitter_seconds. Der Cron hat fünf Felder (Minute, Stunde, Tag des Monats, Monat, Wochentag), "no seconds field and no @daily-style shorthand" (kein Sekundenfeld und keine Kurzform wie @daily). Die Zeitzone ist ein IANA-Name, Standard ist UTC. Jitter verzögert jeden Lauf um einen zufälligen Wert bis zu so vielen Sekunden, höchstens 3600.

Zwei Grenzen zum Einplanen: "A schedule runs at most once every 5 minutes" (ein Zeitplan läuft höchstens einmal alle 5 Minuten), und Sie können höchstens 25 nicht gelöschte Zeitpläne haben.

Schritt 2. Festlegen, was der Lauf erreichen darf

Ein geplanter Lauf erreicht nur die Verbindungen, die sein profile oder seine contexts nennen, und "a schedule with neither reaches none of your connections." (ein Zeitplan ohne beides erreicht keine Ihrer Verbindungen.) Ein Zeitplan trägt das eine oder das andere, nie beides. Liest Ihr Agent Mail oder ein Repository, nennen Sie das Profil jetzt; sonst wird die Auslösung wegen einer fehlenden Verbindung abgelehnt, und die Ablehnung sagt das.

Schritt 3. Den Zeitplan anlegen

In der CLI Reference gibt es keinen Shell-Befehl aegis schedule. Sie legen einen Zeitplan über die REST-Route POST /v1/schedules (Scope schedule:write) an, mit dem MCP-Tool aegis.schedule.create oder auf der Schedules-Seite in Zaru. Das Tool nimmt diese Argumente, wie die Referenz sie aufführt:

aegis.schedule.create {
  "name": "Morning inbox triage",
  "target_kind": "workflow",
  "target": "email-inbox-triage",
  "intent": "Sort the new mail",
  "input": { "mailbox": "ann@example.com" },
  "recurrence": { "cron": "*/30 * * * *", "timezone": "UTC", "jitter_seconds": 300 }
}

Dieses Beispiel ist der Zeitplan der Doku selbst. Setzen Sie target_kind auf agent und target auf den Namen Ihres Agenten. Die Antwort ist {"schedule": {...}} mit state, next_run_at und last_run. Lesen Sie next_run_at zurück, bevor Sie weggehen.

Schritt 4. Einmal sofort auslösen

Warten Sie nicht auf den ersten geplanten Zeitpunkt, um zu erfahren, ob es funktioniert. Der Eigentümer kann mit POST /v1/schedules/{id}/run oder aegis.schedule.run_now sofort einen Lauf starten. Er läuft "exactly as a fire starts it: as the owner, with the schedule's target, input, connections or profile, and attachments" (genau so, wie eine Auslösung ihn startet: als Eigentümer, mit Ziel, Eingabe, Verbindungen oder Profil und Anhängen des Zeitplans), und "nothing else changes" (sonst ändert sich nichts): Der Zeitplan behält Zustand und Zeitpunkte.

Schritt 5. Die Läufe lesen

aegis.schedule.runs { "schedule_id": "<id>", "limit": 20 }

Die Route ist GET /v1/schedules/{id}/runs?limit=. Die Läufe kommen neueste zuerst, jeder mit scheduled_time (null bei einem sofort gestarteten Lauf), fired_at, outcome, detail und execution (seine id, kind und status). Nehmen Sie die Ausführungs-ID in die CLI, um den Lauf selbst zu lesen: aegis task logs <EXECUTION_ID>, mit --errors-only, wenn Sie nur die Fehler sehen wollen.

Schritt 6. Die vier Ergebnisse kennen

Jede Auslösung wird einmal pro geplantem Zeitpunkt festgehalten; eine Auslösung, die Temporal wiederholt, "answers the first fire's record instead of starting a second run" (antwortet mit dem Datensatz der ersten Auslösung, statt einen zweiten Lauf zu starten). Jeder Datensatz hat ein Ergebnis:

• started: Der Lauf hat begonnen, und die Auslösung hält seine Ausführungs-ID fest.
• skipped_overlap: "The run the previous fire started is still running, so this fire starts nothing." (Der von der vorigen Auslösung gestartete Lauf läuft noch, also startet diese Auslösung nichts.) Zaru zeigt das als "Skipped: the last run was still running" (Übersprungen: der letzte Lauf lief noch).
• skipped_paused: Der Zeitplan ist pausiert.
• refused: "The run could not start. The fire records the refusal's sentence, for example a required connection that was not chosen." (Der Lauf konnte nicht starten. Die Auslösung hält den Satz der Ablehnung fest, zum Beispiel eine benötigte Verbindung, die nicht gewählt wurde.)

Ein Ergebnis started sagt, dass der Lauf begann, nicht dass er gelang. Der Status des Laufs steht in execution.status, und der Grund eines Fehlschlags in seinen Protokollen.

Schritt 7. Wissen, was passiert, wenn Auslösungen weiter scheitern

"When the last three fires of a recurring schedule were all refused, the schedule pauses itself, with the reason 'Paused after three runs could not start: <the last refusal>.'" (Wurden die letzten drei Auslösungen eines wiederkehrenden Zeitplans alle abgelehnt, pausiert der Zeitplan sich selbst, mit dem genannten Grund.) Lesen Sie paused_reason am Zeitplan, beheben Sie die Ursache und setzen Sie dann mit aegis.schedule.resume fort. Eine Auslösung, die während eines Neustarts des Orchestrators verpasst wird, "is still made up to 10 minutes late; later than that, the time is skipped." (wird noch bis zu 10 Minuten verspätet nachgeholt; danach wird der Zeitpunkt übersprungen.)

Schritt 8. Freigaben gelten weiter

Ein geplanter Lauf handelt in Ihrem Namen, "so every tool call that waits for your approval in a conversation waits for it in a scheduled run too" (also wartet jeder Tool-Aufruf, der in einem Gespräch auf Ihre Freigabe wartet, auch in einem geplanten Lauf darauf). In Zaru steht die Anfrage auf der Approvals-Seite als "From your schedule <name>" (aus Ihrem Zeitplan <Name>).

Was die Doku offenlässt

• Einen Shell-Befehl. Die CLI Reference nennt keinen Unterbefehl für Zeitpläne, also nutzen Selbst-Hoster die REST-Routen oder einen MCP-Client.
• Wer "Sie" auf dem lokalen Stack sind. Zeitpläne laufen als Person und brauchen schedule:write, während der Stack von aegis init ohne IAM läuft. Die Doku sagt nicht, wem ein Zeitplan dort gehört; wir haben es nicht getestet.

Weiter

Um eine Person zwischen den geplanten Agenten und alles, was er sendet, zu stellen, lesen Sie Wie ein Orchestrator einen Freigabeschritt bekommt. Um zu lesen, was ein Lauf getan hat, lesen Sie Ein AEGIS-Ausführungsprotokoll lesen.

AEGIS von 100monkeys.ai installieren