Ihr KI-Agent muss nicht intelligenter sein. Er muss idempotent sein.

Die meisten KI-Agenten in der Produktion scheitern nicht an mangelhafter Logik. Sie scheitern an Netzwerkfehlern.

Das Modell wählt das richtige Tool aus. Es füllt die richtigen Details aus. Dann belastet es einen Kunden doppelt.

Dies geschieht, weil schreibfähige Agenten in unzuverlässigen Netzwerken agieren.

  • Anfragen laufen in ein Timeout.
  • Verbindungen brechen ab.
  • Frameworks wiederholen Schritte, die bereits abgeschlossen wurden.

Bei einem schreibgeschützten Agenten ist ein Retry kostenlos. Bei einem schreibfähigen Agenten ist ein Retry eine zweite, irreversible Aktion.

Die Lösung ist Idempotenz.

Betrachten Sie dieses häufige Problem:

  1. Der Agent ruft eine Funktion zum Versenden einer Rechnung auf.
  2. Der Dienst erstellt die Rechnung.
  3. Die Verbindung bricht ab, bevor die Antwort den Agenten erreicht.
  4. Der Agent registriert ein Timeout und führt einen Retry durch.
  5. Jetzt haben Sie zwei Rechnungen.

Ein intelligenteres Modell wird das nicht lösen. Ein intelligenteres Modell könnte es sogar noch verschlimmern, indem es bei Retries aggressiver vorgeht.

Man kann von Zahlungssystemen wie Stripe lernen. Diese verwenden einen Idempotency-Key. Der Server speichert das Ergebnis der ersten Anfrage. Wenn der Client denselben Key erneut sendet, gibt der Server das gespeicherte Ergebnis zurück, anstatt die Aktion ein zweites Mal auszuführen.

Für einen KI-Agenten müssen Sie diesen Key aus der Intention ableiten.

Verwenden Sie keine zufälligen IDs. Verwenden Sie einen Hash aus dem Tool-Namen und seinen stabilen Parametern.

Beispiel:

  • Tool: charge_customer
  • Params: {customer_id: 42, amount: 500}
  • Key: hash(tool + params)

Wenn der Agent genau dieselbe Abbuchung wiederholt, bleibt der Key gleich. Das System erkennt dies und verhindert eine doppelte Abbuchung.

Ein Wort der Warnung: Ihr Key ist nur so gut wie Ihre Definition einer einzelnen Aktion.

  • Wenn Sie einen Zeitstempel in Ihren Hash aufnehmen, erhält jeder Retry einen neuen Key. Ihr Schutz schlägt fehl.
  • Wenn Sie einen von einem LLM geschriebenen Nachrichtentext einbeziehen, könnte das Modell ein einziges Wort ändern. Dies erzeugt einen neuen Key und eine doppelte Aktion.

Verwenden Sie immer stabile Daten wie Kunden-IDs oder Rechnungs-IDs als Key. Schließen Sie alles aus, was das Modell ändern könnte.

Hören Sie auf, die Zuverlässigkeit von Agenten durch bessere Prompts zu verbessern.

Bei Zuverlässigkeit geht es darum, die Kosten einer wiederholten Entscheidung auf Null zu senken. Wenn Ihr Agent dieselbe Aktion zweimal ausführt, sollte nichts schiefgehen.

Quelle: https://dev.to/gs_sanjana_3e822112e14f8/your-ai-agent-doesnt-need-to-be-smarter-it-needs-to-be-idempotent-2736

Optionale Lern-Community: https://t.me/GyaanSetuAi