Einführung: Die Unvermeidliche Realität von Fehlern in der agentischen KI
Da KI-Agenten zunehmend sophistizierter und autonomer werden, ist ihre Fähigkeit, sich in komplexen realen Umgebungen zurechtzufinden, von entscheidender Bedeutung. Der Weg zu einem reibungslosen Betrieb ist jedoch selten ohne Hindernisse. Fehler – egal ob sie aus mehrdeutigen Benutzereingaben, unerwarteten Antworten eines externen Systems, Halluzinationen des Modells oder logischen Defekten im Denken des Agenten resultieren – sind eine unvermeidliche Realität. Ein wahrhaft starker KI-Agent ist nicht derjenige, der nie Fehler macht, sondern derjenige, der sie erkennen, diagnostizieren und elegant damit umgehen kann, wodurch Störungen minimiert und die Aufgabenerledigung maximiert wird.
Dieser fortgeschrittene Leitfaden geht über die grundlegenden try-except-Blöcke hinaus und untersucht ausgeklügelte Strategien und praktische Beispiele zum Aufbau von Fehlerverwaltungsmechanismen für resiliente Agenten. Wir werden proaktive Prävention, reaktive Wiederherstellung und kontinuierliches Lernen ansprechen und Ihnen die notwendigen Werkzeuge an die Hand geben, um Agenten zu entwerfen, die nicht nur intelligent, sondern auch bemerkenswert robust sind.
Den Raum der Agentenfehler Verstehen
Bevor wir Fehler effektiv angehen können, müssen wir sie kategorisieren. Agentenfehler lassen sich häufig in mehrere Schlüssel-kategorien unterteilen:
- Eingabefehler: Fehlformatierte, mehrdeutige, widersprüchliche oder außer dem Anwendungsbereich liegende Benutzereingaben.
- Werkzeug/API-Fehler: Unerreichbarkeit des externen Dienstes, falsche API-Parameter, Frequenzbeschränkung, unerwartete Datenformate, Authentifizierungsfehler.
- Denken/Logik-Fehler: Agent, der sein Ziel falsch interpretiert, Halluzinationen von Fakten, der in Schleifen feststeckt, nicht in der Lage ist, ein passendes Werkzeug zu finden oder falsche Entscheidungen basierend auf seinem internen Zustand trifft.
- Kontextfehler: Agent, der den Faden des Gesprächsverlaufs verliert, die vorherigen Äußerungen falsch interpretiert oder nicht in der Lage ist, relevante externe Informationen zu integrieren.
- Ressourcenfehler: Mangel an Speicher, Überschreitung der Token-Grenzen für LLMs oder Probleme mit der Wartezeit.
- Sicherheits-/Abgleichfehler: Generierung von schädlichem, voreingenommenem oder unangemessenem Inhalt; Versuche, verbotene Maßnahmen zu ergreifen.
Proaktive Fehlerprävention: Resilienz Von Anfang An Aufbauen
Der beste Fehler ist der, der niemals passiert. Proaktive Strategien zielen darauf ab, die Wahrscheinlichkeit von Fehlern durch Design und Validierung zu minimieren.
1. Robuste Validierung und Bereinigung von Eingaben
Bevor ein Agent überhaupt mit der Verarbeitung beginnt, sollten die Benutzereingaben validiert und bereinigt werden. Es geht nicht nur darum, Angriffe durch Injektionen zu verhindern; es geht darum sicherzustellen, dass die Eingabe in einem verwendbaren Format und innerhalb der erwarteten Parameter vorliegt.
Beispiel (Python/Pydantic für strukturierte Eingaben):
from pydantic import BaseModel, Field, ValidationError
from typing import Optional
class CreateTaskInput(BaseModel):
title: str = Field(..., min_length=5, max_length=100, description="Kurzer Titel für die Aufgabe")
description: Optional[str] = Field(None, max_length=500, description="Detaillierte Beschreibung der Aufgabe")
due_date: Optional[str] = Field(None, pattern=r"^\d{4}-\d{2}-\d{2}$", description="Fälligkeitsdatum der Aufgabe im Format JJJJ-MM-TT")
priority: str = Field("medium", pattern=r"^(low|medium|high)$", description="Priorität der Aufgabe")
def process_task_creation(raw_input: dict):
try:
task_data = CreateTaskInput(**raw_input)
# Der Agent fährt mit der Erstellung der Aufgabe mit task_data.title usw. fort
print(f"Aufgabe validiert und bereit: {task_data.title}")
return {"status": "success", "data": task_data.dict()}
except ValidationError as e:
error_details = []
for error in e.errors():
field = ".".join(map(str, error['loc']))
error_details.append(f"Feld '{field}': {error['msg']}")
print(f"Eingabevalidierungsfehler: {'; '.join(error_details)}")
return {"status": "error", "message": f"Ungültige Eingabe. Einzelheiten: {'; '.join(error_details)}"}
# Testfälle
process_task_creation({"title": "Kurz", "due_date": "2023-13-01"})
process_task_creation({"title": "Kick-off-Meeting planen", "description": "Tagesordnung erstellen und wichtige Stakeholder einladen.", "due_date": "2023-11-15", "priority": "high"})
Erklärung: Pydantic ermöglicht es, strenge Schemata für die erwarteten Eingaben zu definieren. Wenn die rohe Eingabe nicht übereinstimmt, wird ein ValidationError ausgelöst, der klare und strukturierte Fehlermeldungen bereitstellt, die an den Benutzer zurückgegeben oder für interne Protokollierung verwendet werden können.
2. Defensive Gestaltung von Werkzeugen mit Vor-/Nachbedingungen
Jedes Werkzeug, das ein Agent nutzen kann, sollte defensiv gestaltet werden. Dazu gehört die Definition klarer Vorbedingungen (was vor dem Aufruf des Werkzeugs wahr sein muss) und Nachbedingungen (was nach erfolgreicher Ausführung des Werkzeugs wahr sein muss).
Beispiel (Python mit expliziten Prüfungen):
class InventoryManager:
def __init__(self, stock: dict):
self.stock = stock
def get_item_quantity(self, item_name: str) -> int:
return self.stock.get(item_name, 0)
def update_item_quantity(self, item_name: str, quantity_change: int) -> dict:
# Vorbedingung: Der Artikel muss existieren, wenn quantity_change negativ ist
if quantity_change < 0 and self.get_item_quantity(item_name) + quantity_change < 0:
raise ValueError(f"Unzureichender Bestand für {item_name}. Kann nicht um {abs(quantity_change)} reduzieren.")
# Vorbedingung: Die Mengenänderung muss ungleich null sein
if quantity_change == 0:
return {"status": "no_change", "message": f"Keine Mengenänderung für {item_name} angefordert."}
initial_quantity = self.get_item_quantity(item_name)
self.stock[item_name] = initial_quantity + quantity_change
# Nachbedingung: Die Menge sollte wie erwartet geändert worden sein
if self.stock[item_name] != initial_quantity + quantity_change:
raise RuntimeError(f"Aktualisierung der Menge für {item_name} fehlgeschlagen. Erwartet {initial_quantity + quantity_change}, erhalten {self.stock[item_name]}")
return {"status": "success", "item": item_name, "new_quantity": self.stock[item_name]}
inventory = InventoryManager({"apple": 10, "banana": 5})
try:
print(inventory.update_item_quantity("apple", -12)) # Sollte einen Fehler auslösen
except ValueError as e:
print(f"Fehler: {e}")
try:
print(inventory.update_item_quantity("banana", 3))
except Exception as e:
print(f"Fehler: {e}")
Erklärung: Die Funktion update_item_quantity prüft explizit, ob der Bestand unzureichend ist, bevor sie versucht, eine Aktualisierung durchzuführen. Nachbedingungen können den Zustand nach einer Operation überprüfen und unerwartete Nebeneffekte oder Fehler erfassen. Diese Gestaltung macht die Werkzeuge robuster, wodurch die Last von der übergeordneten Denkweise des Agenten verringert wird.
3. Umformulierung und semantische Klärung von Eingaben
Manchmal ist eine Eingabe nicht streng ungültig, sondern mehrdeutig. Ein Agent kann versuchen, umzuformulieren oder proaktiv nach Klarstellungen zu fragen.
Beispiel (konzeptionelle Interaktion mit einem LLM):
{
"user_input": "Finden Sie mir gute Restaurants.",
"agent_thought": "Der Benutzer möchte Restaurants, aber 'gut' ist subjektiv und es wurde kein Standort angegeben. Ich benötige mehr Informationen.",
"agent_action": {
"type": "ask_clarification",
"question": "Um Ihnen bei der Suche nach den besten Restaurants zu helfen, könnten Sie mir bitte sagen, welche Art von Küche Sie bevorzugen und in welcher Stadt oder welchem Viertel Sie interessiert sind?"
}
}
Erklärung: Anstatt zu scheitern, erkennt der Agent die Mehrdeutigkeit und führt einen Dialog, um den notwendigen Kontext zu sammeln. Dadurch wird verhindert, dass ein nachgelagertes Suchwerkzeug eine schlecht definierte Anfrage erhält und scheitert.
Reaktive Fehlerbehebung: Strategien für den Fall, dass etwas schiefgeht
Trotz proaktiver Maßnahmen werden Fehler auftreten. Reaktive Strategien konzentrieren sich auf die Erkennung von Fehlern, das Verständnis ihrer Ursachen und die Ergreifung von Korrekturmaßnahmen.
1. Klassifizierung von Kontextfehlern und dynamische Wiederholmechanismen
Nicht alle Fehler sind gleich. Ein API-Rate-Limitfehler benötigt eine andere Antwort als ein ungültiger Parameterfehler. Agenten müssen Fehler klassifizieren und geeignete Wiederhollogik anwenden.
Beispiel (Python mit Backoff und Klassifizierung):
import time
import requests
from requests.exceptions import RequestException, HTTPError
def call_external_api(url, params, max_retries=3, initial_delay=1):
for attempt in range(max_retries):
try:
response = requests.get(url, params=params, timeout=5)
response.raise_for_status() # Raise HTTPError für schlechte Antworten (4xx oder 5xx)
return response.json()
except HTTPError as e:
if e.response.status_code == 429: # Grenzwert
print(f"Frequenzgrenze erreicht. Neuer Versuch in {initial_delay}s...")
time.sleep(initial_delay)
initial_delay *= 2 # Exponentielle Rückoff
continue
elif 400 <= e.response.status_code < 500: # Client-Fehler (z.B. schlechte Anfrage)
print(f"Client-Fehler: {e.response.status_code} - {e.response.text}. Kein neuer Versuch.")
raise # Sofort erneut auslösen, wahrscheinlich eine schlechte Eingabe
elif 500 <= e.response.status_code < 600: # Server-Fehler
print(f"Server-Fehler: {e.response.status_code}. Neuer Versuch in {initial_delay}s...")
time.sleep(initial_delay)
initial_delay *= 2
continue
except RequestException as e:
print(f"Netzwerkfehler oder allgemeiner Anfragefehler: {e}. Neuer Versuch in {initial_delay}s...")
time.sleep(initial_delay)
initial_delay *= 2
continue
except Exception as e:
print(f"Unerwarteter Fehler: {e}. Kein neuer Versuch.")
raise
raise TimeoutError(f"API-Aufruf nach {max_retries} Versuchen fehlgeschlagen.")
# Beispiel für die Nutzung (simuliert eine API mit Ratenbegrenzung)
# class MockResponse:
# def __init__(self, status_code, text):
# self.status_code = status_code
# self.text = text
# def raise_for_status(self):
# if 400 <= self.status_code < 600: raise HTTPError(response=self)
# def json(self): return {"data": "success"}
# # Simuliert requests.get
# def mock_get(*args, **kwargs):
# if mock_get.call_count < 2:
# mock_get.call_count += 1
# return MockResponse(429, "Zu viele Anfragen")
# return MockResponse(200, "OK")
# mock_get.call_count = 0
# requests.get = mock_get # Patch requests.get für die Demonstration
# try:
# result = call_external_api("http://api.example.com/data", {"query": "test"})
# print(f"API-Anruf erfolgreich: {result}")
# except Exception as e:
# print(f"API-Anruf fehlgeschlagen: {e}")
Erklärung: Diese Funktion kategorisiert HTTP-Fehler (Ratenbegrenzungen, Client-Fehler, Server-Fehler) und Netzwerkprobleme. Sie wendet eine exponentielle Rückoff-Strategie bei vorübergehenden Fehlern an (Ratenbegrenzungen, Server-Fehler, Netzwerkprobleme), gibt jedoch sofort Client-Fehler zurück, da angenommen wird, dass die Eingabe des API-Aufrufs selbst fehlerhaft war und ein neuer Versuch das Problem nicht lösen wird.
2. Selbstkorrektur durch Wiederholung und Reflexion von LLM
Wenn ein internes Denken eines Agenten oder die Verwendung von Werkzeugen fehlschlägt, kann das LLM verwendet werden, um zu reflektieren und sich selbst zu korrigieren.
Beispiel (Konzeptioneller Agenten-Schritt mit Reflexion):
def agent_step(agent_state, tools):
try:
# 1. LLM generiert einen Plan/Werkzeugaufruf
action = llm_predict_action(agent_state.current_goal, agent_state.history)
# 2. Aktion ausführen (z.B. Werkzeug aufrufen)
tool_output = execute_tool(action.tool_name, action.tool_args, tools)
# 3. Zustand aktualisieren und fortfahren
agent_state.add_to_history(action, tool_output)
return agent_state
except (ToolError, ReasoningError, TokenLimitExceeded) as e:
error_message = str(e)
print(f"Der Agent hat einen Fehler festgestellt: {error_message}. Reflexion wird eingeleitet...")
# 4. LLM reflektiert über den Fehler
reflection_prompt = f"Der Agent hat gerade eine Aktion versucht und ist mit dem folgenden Fehler gescheitert: '{error_message}'. Das aktuelle Ziel ist '{agent_state.current_goal}'. Überprüfen Sie die Historie des Agenten und den Fehler. Identifizieren Sie die Ursache und schlagen Sie einen neuen Plan oder eine modifizierte Aktion zur Wiederherstellung vor. Seien Sie spezifisch."
reflection_response = llm_reflect(agent_state.history, error_message, agent_state.current_goal)
# 5. LLM generiert eine Wiederherstellungsaktion basierend auf der Reflexion
recovery_action = llm_predict_action_from_reflection(reflection_response, agent_state.current_goal)
# 6. Wiederherstellung versuchen
try:
recovered_tool_output = execute_tool(recovery_action.tool_name, recovery_action.tool_args, tools)
agent_state.add_to_history(recovery_action, recovered_tool_output)
print("Der Agent konnte sich erfolgreich vom Fehler erholen.")
return agent_state
except Exception as recovery_e:
print(f"Der Agent konnte sich nicht erholen: {recovery_e}. Eskalation...")
raise AgentFatalError(f"Fehler nach dem Versuch der Wiederherstellung: {recovery_e}")
class ToolError(Exception): pass
class ReasoningError(Exception): pass
class TokenLimitExceeded(Exception): pass
class AgentFatalError(Exception): pass
def llm_predict_action(goal, history):
# Simulierte Implementierung
if "suchen" in goal and not any("standort" in h for h in history):
raise ReasoningError("Standort fehlt für die Suchanfrage.")
return type('Action', (object,), {'tool_name': 'search_tool', 'tool_args': {'query': goal}})
def execute_tool(tool_name, args, tools):
# Simulierte Implementierung
if tool_name == 'search_tool' and 'standort' not in args['query']:
raise ToolError("Das Suchwerkzeug benötigt einen Standort.")
return {"result": "search_results"}
def llm_reflect(history, error_msg, goal):
# Simulierte Reflexionslogik
if "Standort fehlt" in error_msg:
return "Der vorherige Versuch ist fehlgeschlagen, weil die Suchanfrage einen Standort benötigte. Ich muss zuerst den Benutzer nach einem Standort fragen oder diesen aus dem Kontext ableiten."
return "Unbekannter Fehler. Versuchen Sie, die Anfrage zu vereinfachen."
def llm_predict_action_from_reflection(reflection_response, goal):
# Simulierte Aktion aus der Reflexion
if "den Benutzer nach einem Standort fragen" in reflection_response:
return type('Action', (object,), {'tool_name': 'ask_user', 'tool_args': {'question': 'Welchen Standort interessieren Sie?'}})
return type('Action', (object,), {'tool_name': 'fallback_search', 'tool_args': {'query': goal + ' an einem generischen Standort'}})
# Simuliert die Ausführung des Agenten
class AgentState:
def __init__(self, goal):
self.current_goal = goal
self.history = []
def add_to_history(self, action, output):
self.history.append({"action": action.__dict__, "output": output})
agent_tools = {}
initial_state = AgentState("gute Restaurants suchen")
try:
next_state = agent_step(initial_state, agent_tools)
print("Agentenstatus nach Schritt:", next_state.history)
except AgentFatalError as e:
print(f"Fatales Fehler des Agenten: {e}")
Erklärung: Wenn ein Fehler auftritt, gibt der Agent nicht einfach auf. Er übergibt die Fehlermeldung, sein aktuelles Ziel und seine Interaktionshistorie an ein LLM, das aufgefordert wird, den Fehler zu analysieren, die Hauptursache zu identifizieren und eine korrigierende Strategie vorzuschlagen. Dadurch kann sich der Agent dynamisch an seinen Plan anpassen.
3. Wiederherstellungsmechanismen und sanfte Degradierung
Für kritische Funktionen implementieren Sie Wiederherstellungsoptionen. Wenn ein Hauptwerkzeug oder eine Datenquelle ausfällt, sollte der Agent über eine alternative, aber funktionale Option verfügen.
- Werkzeug-Wiederherstellung: Wenn eine ausgeklügelte Such-API ausfällt, kehren Sie zu einer einfacheren Schlüsselwortsuche oder zu einem internen Wissensdatenbank zurück.
- Datenwiederherstellung: Wenn die Wiederherstellung von Echtzeitdaten fehlschlägt, verwenden Sie zwischengespeicherte oder historische Daten und informieren Sie den Benutzer ausdrücklich über die Aktualität der Daten.
- LLM-Wiederherstellung: Wenn ein leistungsstarkes und teures LLM ausfällt oder Ratenbegrenzungen erreicht, wechseln Sie zu einem kleineren, schnelleren oder lokal gehosteten Modell für einfachere Aufgaben oder zur Fehlerbehandlung.
Beispiel (Konzeptionell):
{
"agent_thought": "Versuche den Echtzeit-Preis der Aktie AAPL über 'FinancialDataAPI' abzurufen.",
"tool_call": {
"name": "FinancialDataAPI.get_stock_price",
"args": {"symbol": "AAPL"}
},
"tool_output": {
"error": "API_UNAVAILABLE",
"message": "Der externe Finanzdatenservice ist derzeit offline."
},
"agent_recovery_thought": "FinancialDataAPI ist fehlgeschlagen. Ich werde versuchen, zwischengespeicherte Daten oder ein einfacheres 'HistoricalDataTool' zu verwenden und den Benutzer über mögliche Verzögerungen oder veraltete Daten zu informieren.",
"recovery_action": {
"type": "tool_call",
"name": "HistoricalDataTool.get_last_known_price",
"args": {"symbol": "AAPL"}
},
"user_message": "Es tut mir leid, der Echtzeit Finanzdatenservice ist vorübergehend nicht verfügbar. Ich kann den zuletzt bekannten Preis von vor 1 Stunde bereitstellen: $X.XX. Ist das für Sie in Ordnung?"
}
Kontinuierliches Lernen und Verbesserung: Fehler in Stärken umwandeln
Fehlerverwaltung sollte kein statischer Prozess sein. Jeder Fehler ist eine Gelegenheit für den Agenten und seine Entwickler, zu lernen und sich zu verbessern.
1. Detaillierte Protokollierung und Beobachtbarkeit
Detaillierte Protokollierung ist das Fundament für das Verständnis des Verhaltens und der Fehler des Agenten. Protokollieren Sie:
- Die Benutzereingaben, die Zwischendenkens des Agenten, die Werkzeugaufrufe und die Werkzeugausgaben.
- Alle Fehler: Typ, Nachricht, Stack-Trace und relevanten Kontext (z.B. aktuelles Ziel, Zustand des Agenten).
- Wiederherstellungsversuche: Welche Strategie wurde versucht und welches Ergebnis hatte sie.
Fortgeschrittene Protokollierung: Verwenden Sie eine strukturierte Protokollierung (z. B. JSON-Protokolle) für eine bessere Analyse und vereinfachtes Parsing. Integrieren Sie Observability-Plattformen (z. B. Datadog, Splunk, benutzerdefinierte Dashboards), um Fehlertrends und die Leistung des Agenten zu visualisieren.
2. Automatisierte Fehlermeldung und -warnung
Kritische Fehler sollten Alerts an menschliche Betreiber auslösen. Dies ermöglicht eine schnelle Intervention und verhindert längere Phasen der Fehlfunktion des Agenten.
- Definieren Sie Schwellenwerte für Fehlerraten oder spezifische Fehlertypen.
- Integrieren Sie mit Slack, PagerDuty, E-Mail usw.
- Stellen Sie sicher, dass ausreichend Kontext in den Alerts enthalten ist, damit Entwickler schnell diagnostizieren können.
3. Post-Mortem-Analyse und Ursachenanalyse
Überprüfen Sie regelmäßig die Protokolle, insbesondere bei häufigen oder kritischen Fehlern. Führen Sie Post-Mortem-Analysen durch, um Folgendes zu verstehen:
- War der Fehler vermeidbar? Wenn ja, wie können wir proaktive Maßnahmen verbessern?
- War der Wiederherstellungsmechanismus effektiv? Könnte er verbessert werden?
- Tauchen neue Fehlerbilder auf, die speziellen Umgang erfordern?
4. Feinabstimmung und Reinforcement Learning mit menschlichem Feedback (RLHF)
Für Fehler, die mit dem Denken des LLM oder der Auswahl von Werkzeugen zusammenhängen:
- Fehlertracing sammeln: Beispiele zusammentragen, bei denen das LLM eine falsche Entscheidung getroffen hat oder sich nicht erholen konnte.
- Human Annotation: Sicherstellen, dass Menschen die richtige Handlung oder das richtige Denken für diese fehlerhaften Fälle bereitstellen.
- Feinabstimmung: Diese korrigierten Beispiele verwenden, um das zugrunde liegende LLM des Agenten abzustimmen, sodass es lernt, frühere Fehler zu vermeiden und die Wiederherstellungsstrategien besser zu verallgemeinern.
- RLHF: Menschliches Feedback zur Qualität der Wiederherstellungsversuche als Belohnungssignal integrieren, um das Verhalten des Agenten weiter zu verfeinern.
Beispiel (konzeptionelles Datenpunkt-RLHF):
{
"context": [
{"role": "user", "content": "Buch mir einen Flug nach London."},
{"role": "agent_thought", "content": "Der Benutzer möchte einen Flug. Need departure city and date."},
{"role": "tool_call", "content": "ask_user(question='Was ist Ihre Abflugstadt und welches Datum bevorzugen Sie?')"}
],
"error": {
"type": "ReasoningError",
"message": "Der Agent konnte die Abflugstadt aus dem Kontext nicht ableiten, obwohl der Benutzer im vorherigen Gespräch 'New York' erwähnt hatte."
},
"human_correction": {
"action": {"type": "tool_call", "name": "FlightBookingTool.search_flights", "args": {"origin": "New York", "destination": "London", "date": ""}},
"reasoning": "Der Agent hätte 'New York' aus dem vorherigen Austausch in der Konversation in Erinnerung behalten sollen. Das LLM benötigt ein besseres Kontextbewusstsein."
},
"reward_signal": -1.0, # Negative Belohnung für das Versagen, den Kontext zu nutzen
"proposed_recovery": {
"action": {"type": "tool_call", "name": "ask_user_clarification", "args": {"question": "Sie haben früher New York erwähnt. Ist das immer noch Ihre Abflugstadt?"}}
}
}
Fazit: Auf dem Weg zu autonomen und resilienten Agenten
Den Aufbau eines fortgeschrittenen Fehlermanagementsystems für Agenten ist keine triviale Aufgabe. Es erfordert einen mehrschichtigen Ansatz, der proaktive Prävention, intelligentes reaktives Wiederherstellen und ein Engagement für kontinuierliches Lernen umfasst. Durch die Implementierung einer soliden Eingangsvalidierung, eines defensiven Tool-Designs, dynamischer Retry-Mechanismen, LLM-gesteuerter Selbstkorrektur und umfassender Observabilität können Sie Ihre KI-Agenten von fragilen Systemen zu autonomen und hochresistenten Entitäten transformieren, die die unvorhersehbaren Komplexitäten der realen Welt navigieren können. Das Ziel ist nicht, Fehler zu eliminieren, sondern den Agenten die Fähigkeit zu geben, sich reibungslos anzupassen, zu lernen und letztendlich selbst im Angesicht von Widrigkeiten erfolgreich zu sein, und dabei die Grenzen dessen, was autonome KI erreichen kann, zu verschieben.
🕒 Published: