Was ist ein KI-Agent?

Ein KI-Agent ist ein LLM-gesteuertes System, das ein Ziel in einer Schleife verfolgt: schlussfolgern, ein Tool aufrufen, das Ergebnis beobachten, wiederholen. Ein reiner LLM-Aufruf antwortet und hört auf; ein Agent legt um diesen Aufruf eine Kontrollschleife mit Tools (Funktionen, die er aufrufen kann), Gedächtnis (Zustand über Schritte hinweg) und genug Autonomie, um die Reihenfolge seiner Aktionen selbst zu wählen. Die tragende Verschiebung für Backend-Entwickler ist die schlichteste und am seltensten ausgesprochene Tatsache über Agenten: die “Tools” eines Agenten sind Ihre Backend-Endpoints – wenn ein Agent “ein Tool benutzt”, ruft er eine API auf, die Sie geschrieben haben, und damit ist Ihr Backend und nicht der Prompt der Ort, an dem Sicherheit tatsächlich entsteht.

Das Wichtigste in Kürze

Wie die Reasoning-Schleife (ReAct) eines KI-Agenten funktioniert

ZIEL: "Erstatte meine letzte Bestellung und schicke mir die Bestätigung"

  ┌───────────────────────────────────────────────────────────┐
  │ 1 REASON   Modell: "ich brauche die letzte Bestellung"    │
  │ 2 ACT      Tool aufrufen: find_orders(user, last=1)       │
  │ 3 OBSERVE  Ergebnis: Bestellung #1187, 42 US-$, geliefert │
  │ 4 REASON   "berechtigt – erstatten"                       │
  │ 5 ACT      Tool aufrufen: refund_order(1187)              │◄─ jedes ACT trifft
  │ 6 OBSERVE  Ergebnis: erstattet                            │   IHR Backend
  │ 7 REASON   "jetzt die E-Mail an den Benutzer senden"      │
  │ 8 ACT      Tool aufrufen: send_email(...)                 │
  │ 9 REASON   "fertig" → finale Antwort                      │
  └───────────────────────────────────────────────────────────┘

Das Modell führt ein Tool nie selbst aus. Es FORDERT eines an (Name + Argumente);
Ihr Code führt es aus und gibt das Ergebnis in den nächsten Reason-Schritt zurück.

Die Tools aus dieser Schleife, auf dem Backend – eng begrenzt, berechtigungsgeprüft, unter der Identität des Benutzers ausgeführt:

// JavaScript — Cloud Code (cloud/main.js)
// An agent's "tool" is a backend function — scoped, permissioned, auditable
Parse.Cloud.define('refundOrder', async (req) => {
  // Runs under the CALLING USER's session — ACLs gate everything.
  // A hijacked agent can't exceed what this user may already do.
  const asUser = { sessionToken: req.user.getSessionToken() };
  const order = await new Parse.Query('Order').get(req.params.orderId, asUser);
  // ACLs apply via the session token: not your order → this throws, agent or not
  if (order.get('amount') > 100) throw 'Refunds over $100 need human approval';
  order.set('status', 'refunded');
  await order.save(null, asUser);
  return { refunded: order.id }; // the tool result the model reasons over next
});
// The backend, not the prompt, is the security boundary.

// Flutter / Dart — Back4app Flutter SDK
// The agent loop runs server-side; the tools it may call are YOUR functions
final result = await ParseCloudFunction('runAgent')
    .execute(parameters: {'goal': 'Refund my last order and email me'});
print(result.result);
// The agent reasoned, chose the refundOrder tool, and called it —
// but the ACLs on Order decided whether it was ALLOWED to succeed.

// iOS / Swift — Back4app Swift SDK
// The agent loop runs server-side; the tools it may call are YOUR functions
let result: [String: Any] = try await Cloud.run(
    name: "runAgent",
    parameters: ["goal": "Refund my last order and email me"])
print(result)
// The agent reasoned, chose the refundOrder tool, and called it —
// but the ACLs on Order decided whether it was ALLOWED to succeed.

// Android / Kotlin — Back4app Android SDK
// The agent loop runs server-side; the tools it may call are YOUR functions
val params = mapOf("goal" to "Refund my last order and email me")
val result = ParseCloud.callFunction<Map<String, Any>>("runAgent", params)
println(result)
// The agent reasoned, chose the refundOrder tool, and called it —
// but the ACLs on Order decided whether it was ALLOWED to succeed.

Die vier Kernkomponenten eines KI-Agenten

Die kanonische Zerlegung lautet Modell + Planung + Gedächtnis + Tool-Nutzung, doch die operative Fassung ist schlichter: Ein Modell schlussfolgert, Tools handeln (und sie sind Backend-Funktionen), das Gedächtnis hält den Zustand – kurzfristig im Context Window, langfristig in einer Datenbank oder einem Vector Store – und die Orchestrierungsschleife verbindet alles, nach dem ReAct-Muster, das Schlussfolgern und Handeln verschränkt.

Agent vs. Chatbot vs. LLM-Aufruf vs. Workflow

Die Unterscheidung, die am meisten zählt und die fast kein Glossar zieht: Ein Workflow ist Orchestrierung entlang vordefinierter Codepfade; ein Agent lässt das Modell seinen Weg selbst bestimmen. Die Empfehlungen von Anthropic sind deutlich in der Konsequenz: Die meisten Aufgaben, die nach einem Agenten aussehen, sind mit einem deterministischen Workflow besser bedient, und Sie fügen Autonomie erst dann hinzu, wenn sich der Weg wirklich nicht in ein Skript fassen lässt.

Zuverlässigkeit: Fehler multiplizieren sich nach unten

Der ehrliche Abschnitt, den Anbieterseiten meiden. Agenten sind pro Schritt beeindruckend und pro Kette zerbrechlich, denn Erfolg multipliziert sich: Gelingt jeder Schritt mit der Wahrscheinlichkeit p, gelingt eine Aufgabe aus n Schritten ungefähr mit pⁿ.

Erfolg pro Schritt   10 Schritte   20 Schritte
       95 %             ~60 %         ~36 %
       90 %             ~35 %         ~12 %
       85 %             ~20 %          ~4 %

Eine Demo, die einen beeindruckenden Schritt trifft, ist kein System, das zwanzig trifft.
Mehrstufige, systemübergreifende Agenten erreichen im Feld häufig nur 20–40 %.

Diese Rechnung diktiert das Vorgehen in Produktion: Ketten kurz halten, Ergebnisse zwischen den Schritten prüfen, statt ihnen zu vertrauen, unumkehrbare Aktionen (senden, löschen, abbuchen, veröffentlichen) hinter menschliche Freigaben legen und die Schleife deckeln – mit Schritt- und Kostengrenzen, damit ein verwirrter Agent billig scheitert statt teuer. Zuverlässigkeit ist keine Eigenschaft des Modells, auf deren Verbesserung Sie warten; sie ist eine Architektur, die Sie durchsetzen.

Die Angriffsfläche

Ein Agent, der handeln kann, kann auch zum Handeln verleitet werden – und das macht ihn zu einer wirklich neuen Angriffsfläche. Prompt Injection verwandelt Anweisungen in der Eingabe des Modells in echte Aktionen, und die gefährliche Variante ist die indirekte: Eine vergiftete Webseite, E-Mail oder ein präpariertes Support-Ticket, das der Agent liest, kann Anweisungen tragen, die er dann mit Ihren Zugangsdaten ausführt. Confused Deputy (der verwirrte Stellvertreter) ist die Gestalt des Schadens: ein Agent mit weitreichenden Berechtigungen, den man dazu bringt, sie im Sinne eines Angreifers zu missbrauchen. Die Gegenmittel sind alte Sicherheitsdisziplin, gerichtet auf einen neuen Akteur – Zugangsdaten nach dem Prinzip der geringsten Rechte, auf den Benutzer beschränkt (geben Sie dem Agenten nie mehr, als der Benutzer der Aufgabe ohnehin hat), standardmäßig verweigernde, eng zugeschnittene Tools, Sandboxing und menschliche Freigaben für alles Unumkehrbare. Die wichtigste Einordnung von allen: Die Sicherheitsgrenze ist das Backend, nicht der Prompt. Ein Prompt lässt sich injizieren; eine serverseitige Berechtigungsprüfung lässt sich nicht davon überreden, sich selbst auszusetzen.

Tools entwerfen, die ein Agent nicht missbrauchen kann

Weil die Tools Ihr Backend sind, ist Tool-Design Backend-Sicherheit mit aufgedrehter Lautstärke. Machen Sie jedes Tool nach Möglichkeit idempotent (eine wiederholte Erstattung darf nicht doppelt erstatten), eng zugeschnitten (eine klare Aktion, kein roher Datenbankzugriff), berechtigungsgeprüft (es läuft unter der Identität des Benutzers, und dessen ACLs greifen) und im Schema eindeutig – die Beschreibungen, die das Modell liest, um zu entscheiden, ob und wie es ein Tool aufruft, verdienen so viel Sorgfalt wie Ihre Prompts, denn eine vage Tool-Beschreibung ist ein Fehler, den das Modell finden wird. Stellen Sie Aktionen bereit, keine Tabellen: refund_order(id) mit eigenen Prüfungen, niemals run_sql(query).

Typische Anwendungsfälle

• Kundenbetreuung – ein Agent, der ein Supportziel von Anfang bis Ende über berechtigungsgeprüfte Tools löst, mit menschlicher Freigabe bei Erstattungen und Stornierungen.
• Coding-Assistenten – ein Repository lesen, Tools ausführen und sich einer Änderung nähern, die anschließend geprüft wird.
• Recherche und Synthese – mehrstufiges Retrieval und Zusammenfassen, wenn der Weg im Voraus nicht feststeht.
• Datenabläufe mit Urteilsvermögen – Schritte, zwischen denen geschlussfolgert werden muss, nicht bloß eine starre Pipeline.
• Terminplanung und Koordination – Ziele, die mehrere Systeme umspannen und jeweils über ein eng zugeschnittenes Tool erreicht werden.

Sollten Sie einen Agenten bauen? Eine Entscheidungsmatrix

Grenzen und Trade-offs

• Autonomie tauscht Zuverlässigkeit gegen Fähigkeit. Dieselbe Freiheit, die einen Agenten offene Ziele bewältigen lässt, multipliziert auch die Fehler – begrenzen Sie sie bewusst.
• Schleifen kosten Geld und Zeit. Jede Iteration bedeutet weitere Modellaufrufe; Agenten sind konstruktionsbedingt langsamer und teurer als ein einzelner Aufruf – deckeln und beobachten Sie beides.
• Nichtdeterminismus sperrt sich gegen Tests. Einen Workflow testen Sie per Unit-Test; einen Agenten evaluieren Sie statistisch über viele Läufe, weil dieselbe Eingabe verschiedene Wege nehmen kann.
• Der Schadensradius sind Ihre Zugangsdaten. Ein Agent ist nur so sicher wie die engste Berechtigung, die Sie seinen Tools gegeben haben; zu weiter Zugriff ist der Vorfall, der nur noch auf sein Stichwort wartet.
• Beeindruckend ist nicht verlässlich. Eine überzeugende Demo ist eine glückliche Kette; Produktion ist die unspektakuläre Arbeit an Guardrails, Freigaben und kurzen Wegen.

KI-Agenten mit Back4app

Back4app ist eine Open-Source-Plattform für Backend as a Service (BaaS), die eine verwaltete Datenbank, automatisch generierte REST- und GraphQL-APIs, Authentifizierung, Dateispeicher und Serverless-Funktionen mit Cloud Code kombiniert. Die These “Tools sind Backend-Funktionen” ist die ganze Integration: Die Tools eines Agenten sind Cloud-Code-Funktionen, und weil sie unter der Session des aufrufenden Benutzers laufen, kontrollieren die ACLs und Klassenberechtigungen der Plattform jeden Lese- und Schreibzugriff, den der Agent versucht – wie die Code-Tabs zeigen, kann ein gekaperter oder per Prompt Injection manipulierter Agent die Berechtigungen des Benutzers nicht überschreiten, weil der Schadensradius des verwirrten Stellvertreters von der Zugriffskontrolle gedeckelt wird und nicht vom Wohlverhalten des Modells. Der Rest folgt daraus: eng zugeschnittene Aktionen bereitstellen (refundOrder), keine Rohdaten; den Modellschlüssel serverseitig halten; die Tool-Oberfläche mit MCP standardisieren, wenn mehrere Agenten sie teilen; und das Backend Nein sagen lassen. Der Agent schlägt vor; das Backend entscheidet – und genau dort sollte die Sicherheit eines autonomen Systems liegen.