Budgets für externe Aufrufe, die Agentenschleifen stoppen

Autonome Agenten brauchen keinen unbegrenzten Zugriff auf externe Dienste, um nützlich zu sein. Sie brauchen ein klar definiertes Maß an Berechtigung zum Ausprobieren, Warten, Wiederholen und Ausgeben, bevor sie die Aufgabe zurückgeben. Ohne diese Grenze kann eine kleine Unklarheit, etwa ein leeres Suchergebnis oder ein verzögerter Job, in Hunderte Anfragen, doppelte Seiteneffekte und eine unerwartete Rechnung ausarten.

Ein Budget für externe Aufrufe ist ein Laufzeitvertrag für einen einzelnen Agentenlauf. Es begrenzt die Anzahl der Anfrageversuche, die verstrichene Zeit und das finanzielle Risiko und erzwingt einen sichtbaren Stopp, sobald ein Limit ausgeschöpft ist. Betrachten Sie es als Betriebsgrenze, nicht als Vorschlag im Agentenprompt. Prompts lassen sich leicht neu interpretieren, wenn das Modell eine Aufgabe abschließen will. Die Durchsetzung muss außerhalb des Modells stattfinden.

Ein Budget muss Versuche, Zeit und Geld getrennt zählen

Ein einzelnes Limit kann die verschiedenen Arten, wie ein Agent Ressourcen verbraucht, nicht abdecken. Die Anzahl der Anfragen erkennt Schleifen. Ein Zeitlimit erkennt langsame Statusabfragen und Wartezeiten zwischen Wiederholungen. Ein Ausgabenlimit erkennt wenige, aber teure Aktionen. Jede Kennzahl erfasst einen anderen Fehlerfall, und jede kann den Lauf beenden, während die beiden anderen noch Spielraum haben.

Zählen Sie Versuche, nicht erfolgreiche Antworten. Eine Anfrage, die wegen eines Timeouts scheitert, kann den Anbieter trotzdem erreicht haben. Sie hat einen Socket, Rechenarbeit beim Anbieter und oft auch einen Eintrag in einer kostenpflichtigen API verbraucht. Wenn Sie nur Erfolge zählen, kann ein Agent unbegrenzt fehlerhafte Anfragen stellen, während er nach einer passenden Antwort sucht.

Verfolgen Sie für jeden Lauf mindestens diese Werte:

• attempts_used und attempts_remaining, einschließlich Wiederholungen und Weiterleitungen, die eine neue externe Anfrage auslösen
• deadline_at, wobei für die verstrichene Dauer eine monotone Uhr statt der Wanduhr verwendet wird
• reserved_spend und settled_spend in der kleinsten praktikablen Abrechnungseinheit des Anbieters
• side_effect_attempts, eine separate Zählung für Aktionen, die schreiben, senden, erstellen oder kaufen
• budget_stop_reason, das das erste Limit festhält, das weitere Arbeit verhindert hat

Führen Sie Anfrageanzahl und Ausgaben nicht zusammen, indem Sie jeder Anfrage einen erfundenen Preis zuweisen. Eine Metadatenabfrage und ein Endpunkt für Modellgenerierung können beide eine Anfrage kosten, während ihre Rechnungen stark voneinander abweichen. Umgekehrt kann eine API für eine Anfrage keinen Preis melden, obwohl sie trotzdem eine kostenpflichtige Cloud-Ressource erstellt. Verwenden Sie auch dann ein Anfrage-Limit, wenn eine Kostenschätzung vorhanden ist.

Ein sinnvolles Anfangsbudget für einen Agenten, der Daten aus einer bekannten Menge von APIs sammelt, könnte 40 Versuche, 10 Minuten Laufzeit und eine kleine feste Reservierung erlauben. Ein Deployment-Agent braucht möglicherweise weniger Anfragen, aber ein strengeres Limit für Seiteneffekte. Ein Rechercheagent, der entdeckte URLs verfolgt, braucht einen deutlich kleineren erreichbaren Bereich, als sein Ersteller zunächst vorschlagen wird. Das sind Ausgangshypothesen, keine universellen Einstellungen. Messen Sie normale Läufe und setzen Sie die Limits so, dass ungewöhnliches Verhalten unterbrochen wird, bevor daraus eine Aufräumarbeit entsteht.

Das Budget gehört zu einem Lauf, nicht zum Modellprozess für den ganzen Tag. Wenn ein Agent eine neue Aufgabe erhält, bekommt er eine neue Lauf-ID und eine neue, ausdrücklich festgelegte Zuteilung. Ein gemeinsamer Tageszähler versteckt den teuren Lauf zwischen der normalen Arbeit. Außerdem kann eine Aufgabe Kapazität verbrauchen, die für eine andere vorgesehen war.

Die Zuteilung muss vor dem ersten teuren Aufruf reserviert werden

Ausgabenlimits scheitern, wenn ein System den Preis erst erfährt, nachdem es etwas gekauft hat. Reservieren Sie vor dem Aufruf die höchstmögliche plausible Gebühr, verringern Sie das verbleibende Budget sofort und gleichen Sie später die tatsächliche Nutzung ab, sobald der Anbieter sie meldet. Passt die Reservierung nicht, lehnen Sie den Aufruf ab, bevor er Ihre Grenze verlässt.

Stellen Sie sich einen Agenten vor, der einen gehosteten Build erstellen darf. Die Anfrage des Anbieters akzeptiert eine Maschinenklasse, eine Region, ein Timeout und eine Artefaktgröße, aber die genaue Gebühr erscheint erst nach Abschluss. Das Gateway des Agenten braucht eine Preistabelle oder eine konservative Schätzung. Eine perfekte Abrechnung ist nicht nötig, um eine sichere Entscheidung zu treffen.

Ein Reservierungsdatensatz kann so aussehen:

{
  "run_id": "run_7c1f",
  "budget": {
    "attempts_remaining": 18,
    "deadline_at": "2025-04-21T14:42:00Z",
    "spend_remaining_cents": 1200
  },
  "reservation": {
    "action": "create_build",
    "maximum_cents": 850,
    "provider_reference": "build-request-41"
  },
  "decision": "allow"
}

Nach dieser Reservierung bleiben dem Lauf für alle anderen Aktionen 350 Cent. Wird die tatsächliche Rechnung mit 620 Cent abgerechnet, geben Sie 230 Cent frei. Beläuft sie sich auf 910 Cent, protokollieren Sie die Überschreitung, verweigern Sie spätere Ausgaben und untersuchen Sie, warum die Schätzung danebenlag. Lassen Sie einen Agenten nicht frei aus einem künftigen Budget leihen, nur weil die endgültige Zahl unbequem war.

Einige Anbieter nennen den Preis bereits in der Anfrage oder liefern vor Beginn der Arbeit eine Nutzungsschätzung. Verwenden Sie diese Angaben. Andere tun das nicht. Klassifizieren Sie bei solchen Diensten Aktionen nach Risiko. Erlauben Sie einen günstigen Lesevorgang innerhalb des normalen Anfragebudgets. Fordern Sie eine ausdrückliche Genehmigung für Aktionen, die eine unbegrenzte Ressource erstellen, kostenpflichtige Nachrichten versenden, eine Bestellung auslösen oder Arbeit anstoßen können, deren Kosten sich nicht begrenzen lassen.

Teams lehnen Reservierungen oft ab, weil Schätzungen ungenau sind. Das verwechselt Abrechnungsgenauigkeit mit Kontrolle. Eine Brandschutztür muss die genaue Hitze des Feuers nicht berechnen, bevor sie schließt. Eine konservative Reservierung kann eine Aufgabe ablehnen, die eigentlich gepasst hätte. Der Agent kann jedoch mit einer Begründung um eine größere Zuteilung bitten. Das ist besser, als eine unbegrenzte Abbuchung zu entdecken, nachdem der Agent verschwunden ist.

Halten Sie Anbieter-Guthaben und organisationsweite Kontingente außerhalb des Laufbudgets. Sie sind Notfallnetze, kein Ersatz. Ein Monatskontingent erlaubt einem einzelnen Lauf meist, deutlich mehr zu verbrauchen, als seine Aufgabe rechtfertigt.

Wiederholungen brauchen eine kleinere Zuteilung als erste Versuche

Wiederholungen sollten selten, begrenzt und danach klassifiziert sein, ob eine erneute Anfrage den Seiteneffekt wiederholen kann. Eine allgemeine Anweisung, Fehler zu wiederholen, verwandelt einen vorübergehenden Ausfall in ein teures Anfrageverhalten.

RFC 9110 definiert idempotente Methoden wie GET, PUT und DELETE anhand ihrer beabsichtigten Wirkung auf dem Server. Der RFC sagt auch, dass ein Client eine nicht idempotente Anfrage nicht automatisch wiederholen sollte, sofern er nicht weiß, dass eine Wiederholung sicher ist. Dieser Vorbehalt ist bei Agenten wichtiger als bei gewöhnlichem Anwendungscode: Der Agent kann seinen Inhalt zwischen Versuchen ändern, eine frühere Antwort als unvollständig bewerten und eine Anfrage senden, die wie ein neuer Aufruf aussieht.

RFC 6585 definiert HTTP 429, Too Many Requests, und erklärt, dass eine Antwort Retry-After enthalten kann. Respektieren Sie diesen Header, wenn er vorhanden ist. Betrachten Sie ihn nicht als Erlaubnis, bis zu seinem Ablauf zu schlafen und danach für immer weiterzumachen. Die Wiederholung verbraucht weiterhin das Zeitbudget des Laufs, und die ursprüngliche Aufgabe rechtfertigt das Warten möglicherweise nicht mehr.

Verwenden Sie ein Wiederholungsprotokoll, das vor jeder Wiederholung vier Fragen beantwortet: Was ist fehlgeschlagen? Kann die Aktion beim entfernten Dienst trotzdem stattgefunden haben? Wie lange soll gewartet werden? Welches Budget bezahlt den nächsten Versuch? Eine praktikable Richtlinie sieht so aus:

request_classes:
  read:
    max_attempts: 3
    retry_on: [408, 429, 502, 503, 504]
    backoff_seconds: [2, 8]
  idempotent_write:
    max_attempts: 2
    require_idempotency_token: true
    retry_on: [408, 429, 503]
  non_idempotent_write:
    max_attempts: 1
    retry_on: []

Diese Richtlinie verhindert einen bekannten Fehler. Ein Agent sendet POST /invoices und verliert die Verbindung, bevor er eine Antwort erhält. Eine unbedachte Wiederholung kann eine zweite Rechnung erstellen. Ein Idempotenz-Token ermöglicht es einem kooperativen Anbieter, das Duplikat zu erkennen, aber nur, wenn der Agent dasselbe Token und exakt dieselbe logische Operation erneut verwendet. Ändert der Agent beim zweiten Versuch den Betrag, den Kunden oder das Token, greift der Schutz nicht mehr.

Bei einer nicht idempotenten Aktion sollten Sie eine Statusabfrage mit einer vom Client erzeugten Operations-ID bevorzugen. Kann der Anbieter weder Idempotenz noch eine Statusabfrage unterstützen, behandeln Sie ein unklar gebliebenes Timeout als Fall für eine menschliche Prüfung. Das wirkt langsamer als eine automatische Wiederholung, bis jemand doppelte Überweisungen, Bestellungen oder Nachrichten rückgängig machen muss.

Jitter ist wichtig, wenn viele Agenten denselben Ausfall erleben. Verwenden Sie zufällige Wartezeiten, damit sie nicht alle gleichzeitig wiederholen. Halten Sie den Zeitplan kurz genug, damit die Frist des Laufs sinnvoll bleibt. Eine exponentielle Wartezeit von sechs Stunden kann den Anbieter schützen und gleichzeitig eine Agentensitzung noch lange offenhalten, nachdem die Aufgabe keine Bedeutung mehr hat.

Polling-Schleifen brauchen ein eigenes Limit

Ein Agent, der auf asynchrone Arbeit wartet, sollte ein ausdrücklich festgelegtes Abfragelimit erhalten, denn normale Anfragegrenzen verbergen dieses Muster, bis es bereits teuer geworden ist. Statusabfragen können sinnvoll sein, müssen aber ein Intervall, eine maximale Anzahl von Prüfungen und eine Frist für den Vorgang haben.

Die schlechte Variante ist in Protokollen leicht zu erkennen:

14:00:03 POST /exports                 202 accepted
14:00:04 GET  /exports/ea91            202 running
14:00:05 GET  /exports/ea91            202 running
14:00:06 GET  /exports/ea91            202 running
...
14:11:58 GET  /exports/ea91            202 running

Der Agent hat «läuft noch» als Aufforderung verstanden, erneut zu fragen. Das ist keine Beharrlichkeit, sondern eine fehlende Richtlinie.

Orientieren Sie sich zunächst an den dokumentierten Empfehlungen des Anbieters. Gibt ein Endpunkt Retry-After zurück, halten Sie sich innerhalb der verbleibenden Frist daran. Liefert er eine geschätzte Abschlusszeit, fragen Sie nicht vorher ab. Bietet er einen Webhook oder Callback an, verwenden Sie diesen, statt einen Agentenlauf offen zu halten. Ein externer Callback kann einen kontrollierten Workflow später fortsetzen. Er sollte jedoch keinen abgelaufenen Lauf mit seinen alten Berechtigungen wiederbeleben.

Ein Abfragebudget sollte außerdem Jobstatus und Transportfehler unterscheiden. 202 running sagt, dass der Job existiert. Ein Timeout sagt nichts darüber aus, ob Ihre Statusanfrage angekommen ist. Wenden Sie nicht dieselbe Wiederholungszuteilung auf beide Fälle an. Im ersten Fall kann bis zur nächsten geplanten Prüfung gewartet werden. Der zweite kann eine Wiederholung rechtfertigen, vorbehaltlich des normalen Wiederholungslimits.

Legen Sie für ein ausgeschöpftes Abfragelimit eine Abschlussaktion fest: Speichern Sie den zuletzt bekannten Jobstatus, bewahren Sie die Operations-ID des entfernten Vorgangs auf und geben Sie eine Anweisung zum Fortsetzen zurück. Brechen Sie nicht automatisch ab, sofern die ursprüngliche Aufgabe den Abbruch nicht als sicher bezeichnet hat. Manche Jobs hinterlassen ein nutzbares Ergebnis, nachdem der Agent das Warten aufgegeben hat, und manche Abbruchanfragen haben eigene Seiteneffekte.

So wird verzögerte Arbeit für eine Person sichtbar. «Export nach sechs Prüfungen noch nicht abgeschlossen; Vorgang ea91 kann später geprüft werden» ist eine brauchbare Übergabe. «Agent abgeschlossen» nach einer verborgenen Hintergrundschleife ist es nicht.

Eine Frist muss Wartezeiten, Tools und Warteschlangenzeit abdecken

Die Frist eines Laufs sollte den gesamten Zeitraum messen, in dem der Agent externe Arbeit auslösen kann. Sie muss die Überlegungen des Modells zwischen Aufrufen, die Wartezeit bei Wiederholungen, die lokale Toolausführung, Verzögerungen in Warteschlangen, DNS-Blockaden und die Wartezeit auf eine Genehmigung einschließen. Ein Timer, der nur den HTTP-Client umfasst, lässt große Lücken, in denen eine Schleife weiterlaufen kann.

Verwenden Sie zur Durchsetzung dieses Limits einen monotonen Timer für die verstrichene Zeit. Wanduhren können springen, wenn ein Laptop in den Ruhezustand geht, wieder aufwacht oder eine Zeitkorrektur erhält. Speichern Sie Zeitstempel der Wanduhr für Auditdatensätze, berechnen Sie den Ablauf jedoch anhand einer verstrichenen Dauer, die nicht rückwärts läuft.

Geben Sie die verbleibende Zeit an jeden Vorgang weiter. Wenn ein Lauf noch 40 Sekunden hat, sollte er keine HTTP-Anfrage mit einem Client-Timeout von 90 Sekunden starten und auch keinen SSH-Befehl ohne Timeout ausführen. Der untergeordnete Vorgang erhält den kleineren Wert aus seinem lokalen Limit und der verbleibenden Laufzeit.

remaining = run_deadline_monotonic - now_monotonic
if remaining \u003c= 0:
    deny("run_deadline_exhausted")
else:
    operation_timeout = min(remaining, endpoint_timeout)
    execute(operation_timeout)

Behandeln Sie Wartezeiten auf Genehmigungen sorgfältig. Eine Person kommt vielleicht in fünf Minuten zurück, aber der Lauf des Agenten hat möglicherweise nur noch 30 Sekunden. Trifft die Genehmigung nach Ablauf ein, lehnen Sie die Aktion ab und zeigen Sie den Grund. Wenn eine Genehmigung einen abgelaufenen Lauf wiederbeleben darf, entsteht eine Lücke: Der Agent kann vor Ablauf beliebig viele teure Aktionen in die Warteschlange stellen und sie später ausführen, während jemand die Karten nacheinander bestätigt.

Lange Aufgaben brauchen eine andere Struktur. Teilen Sie sie in Prüfpunkte mit neuen Budgets und einem aufgezeichneten Zustandswechsel auf. Ein Agent kann beispielsweise in einem Lauf einen Export absenden. Ein späterer Lauf prüft dann den abgeschlossenen Export und entscheidet, was damit geschehen soll. Jeder Lauf erhält einen Zweck, einen kleinen Berechtigungssatz und ein klares Ende. Das ist weniger magisch als eine unsterbliche Agentensitzung und gerade deshalb leichter zu prüfen.

Bereichsgrenzen verhindern Ausgaben am falschen Ziel

Ein Budget beantwortet die Frage, wie viel externe Aktivität ein Lauf ausführen darf. Der Geltungsbereich beantwortet, wo und worauf er zugreifen darf. Ohne diese Begrenzung kann ein Agent ein durchaus angemessenes Anfragebudget für fremde Hosts, einen manipulierten Link oder einen teuren Endpunkt ausgeben, der nie Teil der Aufgabe war.

Definieren Sie den Geltungsbereich konkret: zugelassene Hosts, Identitäten für Zugangsdaten, HTTP-Methoden, SSH-Ziele, erlaubte Pfade oder Befehlsfamilien und die maximale Größe des Anfrageinhalts. Die Definition sollte so eng sein, dass ein Prüfer sie versteht. Versuchen Sie nicht, für jede mögliche Bedingung eine kleine Programmiersprache zu schreiben. Komplexe Richtliniensysteme sammeln Ausnahmen, bis niemand ihr Verhalten unter Druck vorhersagen kann.

Der Unterschied zwischen einer Zugangsdaten- und einer Budgetgrenze ist wichtig. Eine Grenze für Zugangsdaten entscheidet, ob ein Agent ein Geheimnis für den Aufruf eines Dienstes verwenden darf. Eine Budgetgrenze entscheidet, ob dieser Lauf nach erteilter Berechtigung noch einen weiteren Aufruf machen darf. Teams richten oft die erste Grenze ein und nehmen an, sie liefere automatisch die zweite. Das tut sie nicht. Ein perfekt geschütztes API-Token kann trotzdem tausend unnötige Anfragen finanzieren.

Lehnen Sie bei HTTP Weiterleitungen ab, die die zugelassene Hostmenge verlassen, sofern eine Person das Ziel nicht ausdrücklich erlaubt hat. Weiterleitungen werden leicht übersehen, weil viele Clients ihnen automatisch folgen. Eine Anfrage, die bei einer zugelassenen URL beginnt, kann bei einem anderen Host enden, dabei Header mitführen oder Budget auf einem Dienst verbrauchen, den die Aufgabe nie genannt hat.

Geben Sie einem Agenten für SSH keine allgemeine Shell, nur weil seine erste Aufgabe einen einzelnen Befehl umfasst. Beschränken Sie Ziel und Befehlsschnittstelle, wo das möglich ist. Setzen Sie ein Befehls-Timeout und zählen Sie jeden Verbindungsversuch. Eine Schleife fehlgeschlagener Verbindungen ist weiterhin externe Aktivität, selbst wenn keine Authentifizierung gelingt.

Trennen Sie Lesebereiche von Schreibbereichen. Eine Datensammlungsaufgabe kann viele Leseendpunkte und keinerlei Möglichkeit zum Erstellen von Datensätzen brauchen. Eine Änderungsaufgabe kann einen Schreibendpunkt und eine eng begrenzte Vorabprüfung benötigen. Diese Aufteilung macht das Budget aussagekräftiger, weil eine Anfrageanzahl allein nicht zwischen harmloser Wiederholung und wiederholten Seiteneffekten unterscheiden kann.

Ablehnungen müssen genügend Belege für die Rekonstruktion der Schleife hinterlassen

Ein Budgetstopp ist nur dann nützlich, wenn Sie ihn später erklären können. Zeichnen Sie jede Entscheidung vor Beginn des externen Aufrufs auf, protokollieren Sie das Ergebnis nach dessen Ende und behandeln Sie Ablehnungen ebenso sorgfältig wie erfolgreiche Aufrufe. Andernfalls kann ein fehlendes Ereignis wie eine blockierte Anfrage aussehen.

Verwenden Sie über Modellnachrichten, lokale Tools, HTTP-Anfragen, SSH-Verbindungen, Genehmigungen und Auditdatensätze hinweg eine unveränderliche Lauf-ID. Jeder externe Versuch sollte eine Sequenznummer enthalten. Findet eine Wiederholung statt, verknüpfen Sie sie mit der ursprünglichen logischen Operation und geben Sie an, ob die Aktion idempotent, unklar oder nachweislich nicht erfolgt ist.

Ein kompakter Ereignisdatensatz enthält genug Informationen für eine Untersuchung, ohne vertrauliche Inhalte zu speichern:

{
  "run_id": "run_7c1f",
  "attempt": 17,
  "logical_operation": "fetch_export_status:ea91",
  "channel": "http",
  "destination_class": "approved-export-api",
  "outcome": "denied",
  "reason": "poll_allowance_exhausted",
  "attempts_remaining": 0,
  "elapsed_ms": 598244,
  "reserved_spend_cents": 0
}

Protokollieren Sie Bearer-Tokens, Passwörter, private Schlüssel oder vollständige Anfrageinhalte standardmäßig nicht. Für ein Budgetaudit brauchen Sie Kennungen, Klassen, gegebenenfalls Hashes und den Entscheidungskontext. Sie brauchen keinen zweiten geheimen Speicher voller derselben Zugangsdaten, die Sie eigentlich schützen wollten.

Machen Sie die Ereignisfolge manipulationssicher. Eine Hashkette verknüpft jeden Datensatz mit dem vorherigen, sodass eine Entfernung oder Änderung die Prüfung unterbricht. Bewahren Sie das Material für die Verifikation nach Möglichkeit getrennt vom laufenden Agenten auf. Ein Agent, der seine eigene Historie schreiben kann, darf den Beleg für seine Budgetüberschreitung nicht bearbeiten können.

Sallyport zeichnet sowohl Agentensitzungen als auch einzelne Aufrufe in einem schreibgeschützten, verschlüsselten und hashverketteten Auditprotokoll auf. Der Befehl sp audit verify kann die Kette offline über dem Chiffretext prüfen. Dieses Design ist für die Budgetdurchsetzung nützlich, weil eine abgelehnte Aktion Teil der Belege bleibt, statt als interne Entscheidung zu verschwinden.

Menschliche Genehmigungen gehören zu Ausnahmen, nicht zu jedem Lesevorgang

Eine menschliche Genehmigung sollte Änderungen an Folgen oder Geltungsbereich behandeln, die ein numerisches Budget nicht beurteilen kann. Sie sollte nicht zum Durchwinken routinemäßiger Aufrufe werden. Wenn eine Person für jede Anfrage eine Genehmigungskarte sieht, wird sie die zehnte Aufforderung mit derselben Aufmerksamkeit bestätigen wie die erste.

Fordern Sie eine Genehmigung an, wenn eine Aktion einen neuen Zahlungsempfänger anlegt, über die Reservierung hinaus Geld ausgibt, in ein Produktionssystem schreibt, eine nach außen sichtbare Nachricht sendet, die zugelassene Zielmenge ändert oder nach einer wesentlichen Änderung der Aufgabeneingabe fortgesetzt wird. Die Genehmigung sollte die Aktion in verständlicher Sprache, das Ziel, die Auswirkung auf das Budget und die Identität des anfordernden Prozesses zeigen.

Stellen Sie eine Genehmigung nicht als Heilmittel für ein schwaches Budget dar. Eine abgelenkte Person kann eine schlechte Aktion erlauben, und ein unbeaufsichtigter Lauf erhält möglicherweise nie eine Antwort. Das Budget muss während der Wartezeit trotzdem ablaufen. Eine Person kann für einen neuen Lauf eine neue Zuteilung gewähren, wenn die Aufgabe weiterhin wichtig ist.

Bitten Sie Menschen nicht, ohne Kontext «Fortsetzen» zu genehmigen. Was soll fortgesetzt werden? Gegen welchen Dienst? Zu welchen geschätzten Kosten? Wie viele Aufrufe hat der Lauf bereits ausgeführt? Eine gute Genehmigungsanfrage macht diese Fakten sichtbar. Eine vage Anfrage zwingt den Prüfer, der Zusammenfassung des Agenten zu vertrauen, also genau der Partei, die ein Interesse daran hat, weiterzuarbeiten.

Die Aufgaben lassen sich sinnvoll teilen. Das Gateway setzt feste Grenzen konsistent durch. Die Person entscheidet, ob eine außergewöhnliche Aktion genug Wert hat, um mehr Berechtigungen zu rechtfertigen. Halten Sie diese Zuständigkeiten getrennt, damit keine Seite so tun muss, als könne sie die Aufgabe der anderen lösen.

Die Erschöpfung des Budgets sollte eine fortsetzbare Übergabe erzeugen

Wenn ein Limit einen Lauf stoppt, sollte der Agent einen kurzen Zustandsdatensatz zurückgeben, mit dem eine Person oder ein späterer Lauf sicher weitermachen kann. Eine vage Fehlermeldung verleitet dazu, die gesamte Aufgabe erneut auszuführen. Dadurch werden abgeschlossene Aufrufe wiederholt und möglicherweise auch Seiteneffekte erneut ausgelöst.

Die Übergabe braucht das Aufgabenziel, abgeschlossene Operations-IDs, noch ausstehende externe Arbeit, den genauen Stoppgrund und eine Empfehlung für die nächste Zuteilung. Sie sollte sagen, ob eine Wiederholung sicher ist. Sie darf niemals verbergen, dass eine Aktion in einem unklaren Zustand endete.

Zum Beispiel:

Stopped: elapsed-time budget exhausted.
Completed: submitted export job ea91; downloaded no files.
Last observed state: running at 14:09:58 UTC.
External attempts: 14 of 14; spend reserved: 0 cents.
Safe resume: check status of ea91 once after 14:20 UTC.
Unsafe action: do not submit another export request.

Diese Nachricht verhindert die teuerste Form der Wiederherstellung: einen Neustart, weil niemand weiß, was geschehen ist. Sie macht außerdem eine Anpassung des Budgets möglich. Wenn viele normale Läufe nach nur einer Statusprüfung stoppen, ist die erlaubte Dauer zu kurz. Wenn Läufe ihre gesamte Zuteilung häufig für Suchen ohne Fortschritt verbrauchen, sind die Aufteilung der Aufgabe oder ihr Geltungsbereich falsch.

Füllen Sie ein Budget nach seiner Erschöpfung nicht automatisch wieder auf. Eine Auffüllregel ist nur ein unbegrenztes Budget in kleineren Schritten, sofern keine separate Instanz entscheidet, wann sie gilt. Verlangen Sie einen neuen Lauf oder eine ausdrückliche menschliche Aktion, bewahren Sie den alten Datensatz auf und lassen Sie den nächsten Versuch begründen, warum er mehr Spielraum verdient.

Die erste Richtlinie, die Sie durchsetzen sollten, ist einfach: Jeder autonome Lauf erhält eine endliche Anzahl von Anfragen, eine harte Frist und eine Ausgabenreservierung, bevor er einen externen Dienst erreicht. Fügen Sie unmittelbar danach Bereichsbeschränkungen und gute Protokolle hinzu. Sobald ein Agent gelernt hat, dass er nicht ewig weiterversuchen kann, werden seine Fehler zu begrenzten Arbeitsaufträgen statt zu Vorfällen über Nacht.