Alejandro Rioja.
AI Agents

Warum Ihr KI-Agent in der Produktion immer wieder versagt (Und wie man es behebt)

Alejandro Rioja
Alejandro Rioja
6 Min. Lesezeit
TL;DR

Die meisten Agenten-Ausfälle in der Produktion haben fünf Ursachen: brüchige Prompts, die Randfälle nicht behandeln, fehlende Wiederholungslogik für transiente API-Fehler, keine Observierbarkeit, um zu sehen, was kaputt geht, unkontrollierte Schleifen ohne Austrittsbedingung und Tooldefinitionen, die mehrdeutig genug sind, damit das Modell die falsche auswählt. Alle fünf sind ohne Modell- oder Framework-Wechsel behebbar.

Kostenloser Newsletter

Jeden Mittwoch. 28.400+ Experten. Kein Füllstoff.

Inhaltsverzeichnis

Aktualisiert Juni 2026.

TL;DR: Die meisten Agenten-Ausfälle in der Produktion haben fünf Ursachen: brüchige Prompts, die Randfälle nicht behandeln, fehlende Wiederholungslogik für transiente API-Fehler, keine Observierbarkeit, um zu sehen, was kaputt geht, unkontrollierte Schleifen ohne Austrittsbedingung und Tooldefinitionen, die mehrdeutig genug sind, damit das Modell die falsche auswählt. Alle fünf sind ohne Modell- oder Framework-Wechsel behebbar.

[Betreiber-Lektüre] Ich betreibe mehr als 30 Agenten in der Produktion. Ich hatte all diese Ausfälle. Die, die am meisten Zeit verbrannten, waren nicht die exotischen — es waren die langweiligen Infrastrukturausfälle, von denen ich dachte, ich hätte sie gehandhabt.

Ausfall 1: Brüchige Prompts, die bei Randfällen versagen

Ein Prompt, der bei Ihren Testfällen funktioniert, wird bei Eingaben versagen, die Sie nicht antizipiert haben. Das ist keine Modellbeschränkung — es ist ein Anweisungsschreibproblem.

Symptome: Der Agent produziert unsinnige Ausgaben, ruft das falsche Tool auf oder gibt malformatiertes JSON aus, wenn die Eingabe geringfügig anders ist als das, was Sie getestet haben.

Ursache: Ihr System-Prompt beschreibt nur den Glückspfad. Er sagt dem Modell nicht, was zu tun ist, wenn Daten fehlen, malformatiert oder mehrdeutig sind.

Behebung: Fügen Sie explizite Randfall-Behandlung zu Ihrem System-Prompt hinzu:

code
If the input data is missing a required field, return:
{ "status": "error", "reason": "missing_field", "field": "<fieldname>" }
Do NOT attempt to infer or hallucinate missing values.

If you are uncertain which tool to call, call no tool and return:
{ "status": "clarification_needed", "question": "..." }

Das Modell folgt expliziten Anweisungen für Randfälle zuverlässig. Der Fehler ist anzunehmen, dass es die Glückspfad-Anweisungen auf die unordentlichen Fälle verallgemeinern wird.

Ausfall 2: Keine Wiederholungslogik für transiente API-Fehler

Jede externe API, die Ihr Agent aufruft, wird irgendwann versagen. Die Claude-API, die Meta Graph API, Ihre Datenbank — sie alle geben 5xx-Fehler zurück, laufen ab oder begrenzen die Rate. Wenn Ihr Agent keine Wiederholungslogik hat, tötet ein transienter Fehler den gesamten Lauf.

Symptome: Agenten-Läufe schlagen zufällig bei verschiedenen Schritten fehl. Die Logs zeigen einen 503 oder 429 ohne Folgeversuche.

Behebung: Wickeln Sie jeden externen Aufruf in eine Wiederholung mit exponentiellem Backoff ein:

typescript
async function withRetry<T>(fn: () => Promise<T>, retries = 3, baseDelayMs = 500): Promise<T> {
  for (let attempt = 0; attempt <= retries; attempt++) {
    try {
      return await fn();
    } catch (err: any) {
      const isTransient = err.status === 429 || err.status >= 500 || err.code === "ECONNRESET";
      if (!isTransient || attempt === retries) throw err;
      const delay = baseDelayMs * Math.pow(2, attempt) + Math.random() * 100;
      await new Promise((r) => setTimeout(r, delay));
    }
  }
  throw new Error("unreachable");
}

// Usage
const result = await withRetry(() => client.messages.create({ ... }));

Drei Wiederholungen mit exponentiellem Backoff behandeln ~99% der transienten Ausfälle. Fügen Sie dies jedem externen Aufruf hinzu und die Hälfte Ihrer zufälligen Ausfälle verschwindet.

Ausfall 3: Keine Observierbarkeit — Sie können nicht sehen, was kaputt geht

Dies ist der häufigste Ausfallmodus in der Produktion und der, der am meisten Zeit zum Debuggen kostet: der Agent versagt still oder produziert falsche Ausgaben, und Sie haben keine Ahnung, wo in der Kette es schiefging.

Symptome: Sie wissen, dass etwas nicht stimmt, aber können den Schritt nicht identifizieren. Sie fügen console.log-Anweisungen hinzu und führen manuell erneut aus, um zu versuchen zu reproduzieren.

Behebung: Strukturiertes Logging bei jedem Schritt, mit einer Ausführungs-ID, die die gesamte Ausführung verfolgt:

typescript
function createLogger(runId: string, agentName: string) {
  return {
    step: (step: string, data: object) =>
      console.log(JSON.stringify({ runId, agent: agentName, step, ts: new Date().toISOString(), ...data })),
    error: (step: string, err: unknown) =>
      console.error(JSON.stringify({ runId, agent: agentName, step, error: String(err), ts: new Date().toISOString() })),
  };
}

const log = createLogger(crypto.randomUUID(), "newsletter-agent");
log.step("fetch_topic", { topicId: topic.id, topic: topic.name });
// ... do work ...
log.step("draft_complete", { subject: draft.subject, wordCount: draft.body.split(" ").length });

Wenn Sie auf Cloudflare Workers sind, gehen diese Logs an Logpush oder Workers Tail. Wenn Sie lokal oder auf einem VPS laufen, leiten Sie sie an einen Log-Aggregator weiter. Das strukturierte JSON bedeutet, dass Sie nach runId filtern können, um genau zu sehen, was in einem einzelnen Lauf passiert ist.

Ausfall 4: Unkontrollierte Schleifen ohne Austrittsbedingung

Agentische Schleifen — wo das Modell Tools aufruft und iteriert, bis eine Bedingung erfüllt ist — können ewig laufen, wenn diese Bedingung nie erfüllt wird oder das Modell sie falsch identifiziert.

Symptome: Der Agent gibt Hunderte von Dollar an API-Kosten aus, bevor er abläuft. Oder er führt immer wieder denselben Tool-Aufruf aus, ohne Fortschritte zu machen.

Behebung: Haben Sie immer eine harte Iterationsobergrenze und eine Fortschrittsprüfung:

typescript
const MAX_ITERATIONS = 10;
let iterations = 0;
let lastToolCallName = "";
let sameToolCallCount = 0;

while (true) {
  iterations++;
  if (iterations > MAX_ITERATIONS) {
    log.error("loop", { reason: "exceeded_max_iterations" });
    break;
  }

  const response = await client.messages.create({ ... });

  // Detect stuck loops: same tool called 3x in a row
  const toolCall = response.content.find(b => b.type === "tool_use");
  if (toolCall?.name === lastToolCallName) {
    sameToolCallCount++;
    if (sameToolCallCount >= 3) {
      log.error("loop", { reason: "stuck_loop", tool: toolCall.name });
      break;
    }
  } else {
    sameToolCallCount = 0;
    lastToolCallName = toolCall?.name ?? "";
  }

  if (response.stop_reason === "end_turn") break;
}

Dies fängt sowohl die “zu lange gelaufen” als auch die “an Ort und Stelle gedreht” Ausfallmodi. Die Obergrenze sollte großzügig genug für den Glückspfad, aber eng genug sein, um den Explosionsradius zu begrenzen.

Ausfall 5: Mehrdeutige Tooldefinitionen, die das Modell falsch auflöst

Wenn Sie dem Modell zwei Tools mit überlappenden Beschreibungen geben, wird es manchmal das falsche aufrufen. Dies ist besonders häufig bei Tools wie search_database vs get_record oder send_email vs create_draft.

Symptome: Das Modell ruft die richtige Kategorie von Tool auf, aber wählt das falsche spezifische. Oder es ruft ein Tool im falschen Kontext auf (verwendet ein Schreib-Tool, wenn nur Lesen angemessen war).

Behebung: Machen Sie Tooldefinitionen gegenseitig exklusiv und fügen Sie explizit “wann NICHT zu verwenden” hinzu:

typescript
const tools = [
  {
    name: "get_subscriber",
    description: "Fetch a single subscriber record by email. Use ONLY when you have a specific email address. Do NOT use for searching or listing subscribers.",
    input_schema: { ... }
  },
  {
    name: "search_subscribers",
    description: "Search subscribers by tag, segment, or status. Use when you need to find subscribers matching a criteria — NOT when you have a specific email address.",
    input_schema: { ... }
  }
];

Die “NICHT verwenden wenn X”-Klausel ist der Teil, den die meisten Leute überspringen. Es ist der wichtigste Teil. Modelle sind besser darin, explizite negative Einschränkungen zu befolgen, als sie aus positiven Beschreibungen zu inferieren.

Noch eine Sache: Testen Sie Ihre Agenten mit schlechten Eingaben

Die meisten Agenten werden nur auf sauberen Glückspfad-Eingaben getestet. Die Produktion hat schmutzige Eingaben: leere Zeichenketten, null-Felder, Unicode-Randfälle, API-Antworten, die 200 zurückgeben, aber mit einem unerwarteten Schema.

Fügen Sie eine Testsuite hinzu, die explizit ausübt:

Wenn Ihr Agent bei einem davon bricht, beheben Sie es, bevor es live geht. Die Produktionsumgebung wird jede Annahme finden, die Sie gemacht haben.

Das Fazit des Betreibers

Die meisten Agenten-Ausfälle in der Produktion sind Infrastrukturprobleme, die sich als Modellprobleme tarnen. Bevor Sie das Modell wechseln, fügen Sie Wiederholungen, strukturiertes Logging, Schleifencaps und explizite Randfall-Behandlung zu Ihren Prompts hinzu. Beheben Sie die mehrdeutigen Tooldefinitionen. Dann testen Sie auf schlechten Eingaben. Tun Sie all das, bevor Sie das Modell beschuldigen — in meiner Erfahrung ist das Modell normalerweise das Letzte, was geändert werden muss.

Weiterlesen

Holen Sie sich das KI-Playbook in Ihr Postfach

Jeden Mittwoch. 28.400+ Experten. Kein Füllstoff.

↵ alle Ergebnisse anzeigen esc esc zum Schließen