Ich habe der Falle des glänzenden neuen Agentenframeworks entkommen.

Alright, Leute, Leo Grant hier, zurück mit einer weiteren tiefen Erkundung der wilden Welt der Agentenentwicklung. Heute möchte ich über etwas sprechen, das mich schon eine Weile beschäftigt, etwas, das in Forum um Forum auftaucht und ehrlich gesagt, etwas, mit dem ich vor ein paar Monaten selbst zu kämpfen hatte: Die „Shiny New Agent Framework“-Falle. Wir waren alle schon mal dort, oder?

Es ist 2026, und es fühlt sich an, als würde alle paar Wochen ein neues Agenten-SDK oder Framework auftauchen. Jedes verspricht, schneller, intelligenter, skalierbarer oder einfach nur einfacher zu sein, um autonome Agenten zu erstellen. Und als jemand, der für diese Sachen lebt und atmet, ist meine erste Reaktion immer eine Mischung aus Aufregung und FOMO. „Ist das der eine? Ist das das Tool, das mein Herzensprojekt endlich ohne wochenlange Boilerplate zur Realität macht?“

Ich erinnere mich, dass ich im Oktober an einem persönlichen finanziellen Assistenz-Agenten gearbeitet habe. Die Idee war einfach: ein Agent, der meine Ausgaben überwachen, Abonnementdienste identifizieren könnte, die ich vielleicht nicht nutze, und sogar bessere Konditionen in meinem Namen aushandelt. Ich hatte ein einfaches Python-Skript am Laufen, das einen benutzerdefinierten Nachrichtenbus und viele `if/else`-Anweisungen verwendete. Es war klobig, sicher, aber es funktionierte.

Dann sah ich die Ankündigung für “Aether,” ein neues, Rust-basiertes Agenten-Framework, das unglaubliche Parallelität und eine deklarative Agentendefinitionssprache versprach. Mein Reptiliengehirn schrie sofort: „Schreib es neu! Rust ist die Zukunft! Mein Python-Chaos ist eine Peinlichkeit!“ Also verbrachte ich solide zwei Wochen damit, mein gesamtes Projekt auf Aether zu portieren. Und rate mal? Während Aether tatsächlich performant und elegant war, endete ich mit einem Projekt, das funktional identisch mit meiner Python-Version war, aber jetzt musste ich ein ganz neues Ökosystem von Build-Tools, Abhängigkeitsmanagement und Fehlerbehandlung, das spezifisch für Aether war, lernen.

Es war eine wertvolle Lektion, und eine, die ich heute mit dir teilen möchte. Das größte Hindernis in der Agentenentwicklung ist nicht immer, das „beste“ Framework zu finden; es ist zu verstehen, wann man ein Framework einsetzen sollte und, noch wichtiger, wann man einfach bei dem bleiben sollte, was man kennt und von den Grundprinzipien ausbauen sollte. Heute werden wir darüber sprechen, wie man die „Build“-Denkweise annehmen kann, insbesondere wenn es um die Kernkommunikation und das Zustandsmanagement deiner Agenten geht, anstatt blind das neueste SDK zu übernehmen.

Das Kernproblem: Überengineering der Kommunikation

Die meisten Agentenframeworks versuchen im Kern, zwei Hauptprobleme zu lösen:

1. Inter-Agenten-Kommunikation: Wie kommunizieren Agenten miteinander? Nachrichtenschlangen, RPC, geteilter Zustand?
2. Agenten-Zustandsmanagement: Wie behält ein Agent im Blick, was er weiß, was er getan hat und was er als Nächstes tun muss?

Und das sind zweifellos kritische Probleme. Aber oft bieten die Frameworks eine so umfassende, meinungsstarke Lösung, dass es für einfachere Projekte übertrieben wird oder unnötige Komplexität einführt. Mein finanzieller Agent benötigte beispielsweise nur die Kommunikation mit einem anderen „Agenten“ (einer Mock-Bank-API) und seinem eigenen internen Zustand. Ein vollwertiger Nachrichtenbus mit komplexem Routing war wie mit einem Raketenwerfer eine Fliege zu verjagen.

Was wäre also, wenn wir es vereinfachen? Was, wenn wir über das absolute Minimum nachdenken, das du brauchst, um Agenten miteinander reden und sich Dinge merken zu lassen? Es geht nicht darum, Frameworks für immer zu meiden, sondern darum, zuerst eine solide Grundlage zu schaffen, die zugrunde liegenden Mechanismen zu verstehen und dann zu entscheiden, ob ein Framework tatsächlich einen Mehrwert bietet, anstatt nur zusätzlichen Aufwand.

Einfache Nachrichtenübermittlung: Die HTTP/JSON-Baseline

Lass uns brutal ehrlich sein: Für eine Vielzahl von Anwendungsfällen von Agenten, insbesondere für solche, die mit Webdiensten oder anderen externen Systemen interagieren, sind HTTP und JSON deine besten Freunde. Sie sind allgegenwärtig, gut verstanden und unglaublich flexibel. Du benötigst kein benutzerdefiniertes Protokoll oder einen komplexen Nachrichtenbroker, wenn deine Agenten hauptsächlich Anfragen senden und Antworten empfangen.

Stell dir ein Szenario vor, in dem du einen „Scraper-Agenten“ hast, der Daten von einer Website abruft und einen „Processor-Agenten“, der diese bereinigt und analysiert. Wie kommunizieren sie?

# scraper_agent.py (vereinfacht)
import requests
import json

def scrape_data(url):
 response = requests.get(url)
 if response.status_code == 200:
 return response.text
 return None

def send_to_processor(data):
 headers = {'Content-Type': 'application/json'}
 payload = {'raw_data': data}
 try:
 response = requests.post('http://localhost:8001/process', headers=headers, data=json.dumps(payload))
 response.raise_for_status() # Ausnahme für HTTP-Fehler auslösen
 print(f"Data sent to processor: {response.json()}")
 except requests.exceptions.RequestException as e:
 print(f"Error sending data to processor: {e}")

if __name__ == "__main__":
 url_to_scrape = "https://example.com/some_data" # Ersetze durch eine echte URL
 raw_content = scrape_data(url_to_scrape)
 if raw_content:
 send_to_processor(raw_content)

# processor_agent.py (vereinfacht mit FastAPI)
from fastapi import FastAPI, Request
from pydantic import BaseModel
import uvicorn

app = FastAPI()

class DataPayload(BaseModel):
 raw_data: str

@app.post("/process")
async def process_data(payload: DataPayload):
 # In einem echten Szenario würdest du hier die tatsächliche Verarbeitung vornehmen
 print(f"Received raw data for processing: {payload.raw_data[:50]}...")
 processed_result = f"Processed: {payload.raw_data.upper()}" # Beispielverarbeitung
 return {"status": "success", "processed_data": processed_result}

if __name__ == "__main__":
 uvicorn.run(app, host="0.0.0.0", port=8001)

Das ist einfach, ich weiß. Aber es ist auch unglaublich mächtig. Du hast zwei Agenten, die als separate Dienste laufen und miteinander sprechen. Kein spezielles SDK, kein benutzerdefiniertes Nachrichtenformat. Nur Standards im Web. Die Schönheit dabei ist, dass du diese unabhängig skalieren, überall bereitstellen und mit Standard-HTTP-Tools debuggen kannst. Dieser Ansatz deckt eine überraschende Menge an Kommunikation zwischen Agenten ab, ohne dass es zu einer Abhängigkeit von einem Framework kommt.

Zustandsmanagement: Persistenz annehmen

Das zweite große Thema ist der Zustand. Ein Agent ist nicht viel wert, wenn er zwischen den Durchläufen alles vergisst. Viele Frameworks bieten In-Memory-Zustände oder komplexe Zustandsmaschinen an. Aber oft ist das, was du wirklich brauchst, einfache, zuverlässige Persistenz.

Für meinen finanziellen Agenten musste ich Dinge speichern wie:

• Meine aktuellen Abonnements (Name, Kosten, Erneuerungsdatum)
• Meine Ausgabenkategorien
• Historische Verhandlungsversuche

Anfangs versuchte ich, einige In-Memory-Zustandsmechanismen zu nutzen, die von einem Framework bereitgestellt wurden, aber sobald der Agent neu gestartet wurde (was während der Entwicklung passiert, glaub mir), waren all diese wertvollen Daten weg. Frustrierend!

Die Lösung? Eine einfache Datenbank. Für viele persönliche Projekte oder sogar kleinere Produktionssysteme ist SQLite eine fantastische Wahl. Sie ist dateibasiert, benötigt keinen separaten Server und Python bietet hervorragende integrierte Unterstützung.

# agent_state.py
import sqlite3
import json

class AgentState:
 def __init__(self, db_path='agent_data.db'):
 self.conn = sqlite3.connect(db_path)
 self._create_table()

 def _create_table(self):
 cursor = self.conn.cursor()
 cursor.execute('''
 CREATE TABLE IF NOT EXISTS agent_knowledge (
 key TEXT PRIMARY KEY,
 value TEXT
 )
 ''')
 self.conn.commit()

 def set(self, key, data):
 cursor = self.conn.cursor()
 value = json.dumps(data) # Komplexe Objekte als JSON-Strings speichern
 cursor.execute('INSERT OR REPLACE INTO agent_knowledge (key, value) VALUES (?, ?)', (key, value))
 self.conn.commit()

 def get(self, key):
 cursor = self.conn.cursor()
 cursor.execute('SELECT value FROM agent_knowledge WHERE key = ?', (key,))
 row = cursor.fetchone()
 if row:
 return json.loads(row[0])
 return None

 def close(self):
 self.conn.close()

# Beispielverwendung:
if __name__ == "__main__":
 state = AgentState()

 # Abonnement speichern
 state.set('subscription:netflix', {'name': 'Netflix', 'cost': 15.99, 'renewal': '2026-04-01'})
 state.set('subscription:spotify', {'name': 'Spotify', 'cost': 10.99, 'renewal': '2026-03-25'})

 # Abonnement abrufen
 netflix_sub = state.get('subscription:netflix')
 print(f"Netflix subscription: {netflix_sub}")

 # Abonnement aktualisieren
 if netflix_sub:
 netflix_sub['cost'] = 16.99 # Preiserhöhung!
 state.set('subscription:netflix', netflix_sub)
 
 print(f"Updated Netflix subscription: {state.get('subscription:netflix')}")

 # Liste der Ausgabenkategorien speichern
 state.set('spending_categories', ['Lebensmittel', 'Unterhaltung', 'Versorgungsunternehmen'])
 print(f"Spending categories: {state.get('spending_categories')}")

 state.close()

Diese `AgentState`-Klasse ist super einfach, bietet aber einen Schlüssel-Wert-Speicher, der über Neustarts des Agenten hinweg persistiert. Du kannst Dictionaries, Listen, Strings – alles, was JSON-serialisierbar ist – speichern. Für komplexere Beziehungen würdest du weitere Tabellen definieren, aber für viele Agenten ist ein einfacher Schlüssel-Wert-Speicher alles, was sie für ihr „Gedächtnis“ benötigen.

Alles zusammenführen: Der „Bare Bones“-Agent

Wenn wir also diese Ideen kombinieren, wie sieht ein „bare bones“-Agent aus? Es ist ein Prozess, der:

1. Kommandos empfangen kann (z. B. über einen HTTP-Endpunkt oder eine einfache Nachrichtenwarteschlange).
2. Aktionen durchführen kann (z. B. HTTP-Anfragen stellen, lokale Skripte ausführen).
3. Sich Dinge merken kann (z. B. mithilfe eines persistenten Zustandspeichers wie SQLite).
4. Eine Hauptschleife oder einen Scheduler hat, um zu entscheiden, was als Nächstes zu tun ist.

Stellen wir uns unseren vorherigen Scraper-Agenten vor, aber jetzt mit etwas Gedächtnis. Er muss sich merken, welche URLs er bereits abgegriffen hat und wann, um redundant zu arbeiten oder fehlgeschlagene Versuche erneut zu starten.

# smart_scraper_agent.py
import requests
import json
import time
from datetime import datetime, timedelta
from agent_state import AgentState # Angenommen, agent_state.py befindet sich im selben Verzeichnis

# Wir verwenden FastAPI für den Empfang von Befehlen zum Starten des Scraping
from fastapi import FastAPI, BackgroundTasks
from pydantic import BaseModel
import uvicorn

app = FastAPI()
agent_state = AgentState(db_path='scraper_agent_data.db')

class ScrapeRequest(BaseModel):
 url: str
 target_processor_url: str

def _perform_scrape_and_send(url: str, target_processor_url: str):
 """Interne Funktion für das tatsächliche Scraping und Senden."""
 last_scraped_info = agent_state.get(f'last_scraped:{url}')
 if last_scraped_info:
 last_scrape_time = datetime.fromisoformat(last_scraped_info['timestamp'])
 # Nur scrapen, wenn seit der letzten Abfrage mehr als eine Stunde vergangen ist (Beispiel)
 if datetime.now() - last_scrape_time < timedelta(hours=1):
 print(f"Überspringe {url}, zuletzt um {last_scrape_time} abgefragt")
 return

 print(f"Scrape {url}...")
 try:
 response = requests.get(url, timeout=10)
 response.raise_for_status()
 raw_content = response.text

 # Zum Prozessor senden
 headers = {'Content-Type': 'application/json'}
 payload = {'raw_data': raw_content}
 processor_response = requests.post(target_processor_url, headers=headers, data=json.dumps(payload))
 processor_response.raise_for_status()
 print(f"Daten von {url} an den Prozessor gesendet: {processor_response.json()}")

 # Status mit erfolgreichem Scrape aktualisieren
 agent_state.set(f'last_scraped:{url}', {
 'timestamp': datetime.now().isoformat(),
 'status': 'success',
 'processor_response': processor_response.json()
 })

 except requests.exceptions.RequestException as e:
 print(f"Fehler beim Scraping oder Senden für {url}: {e}")
 # Status mit Fehler aktualisieren
 agent_state.set(f'last_scraped:{url}', {
 'timestamp': datetime.now().isoformat(),
 'status': 'failed',
 'error': str(e)
 })
 finally:
 agent_state.close() # Wichtig, um die Verbindung zu schließen, wenn nicht global verwaltet

@app.post("/scrape")
async def start_scrape(request: ScrapeRequest, background_tasks: BackgroundTasks):
 """Endpoint, um eine Scrape-Aktion auszulösen."""
 background_tasks.add_task(_perform_scrape_and_send, request.url, request.target_processor_url)
 return {"message": f"Scraping von {request.url} initiiert."}

if __name__ == "__main__":
 # Sie könnten hier auch eine geplante Aufgabe haben, die den Status nach URLs zum Scrapen abfragt
 # Für jetzt starten wir einfach den FastAPI-Server.
 # Zum Ausführen: uvicorn smart_scraper_agent:app --reload --port 8000
 uvicorn.run(app, host="0.0.0.0", port=8000)

Dieses `smart_scraper_agent.py` kombiniert unsere grundlegende HTTP-Kommunikation mit persistentem Status. Es verhindert redundantes Scraping innerhalb eines definierten Zeitfensters und speichert das Ergebnis jedes Scrapes. Es ist immer noch einfach, zeigt aber bereits einige "agentische" Verhaltensweisen – Erinnern, Entscheiden und Handeln basierend auf seinem internen Zustand und externen Reizen.

Wann man ein Framework in Betracht ziehen sollte (und warum)

Ich sage nicht, dass Frameworks schlecht sind. Ganz im Gegenteil. Sie haben absolut ihren Platz. Sie sollten anfangen, sie in Betracht zu ziehen, wenn:

• Komplexe Koordination: Sie haben Dutzende oder Hunderte von Agenten, die komplexe Aufgaben koordinieren, Teams bilden oder sich dynamisch finden müssen. Hier wird ein solider Nachrichtenbus, Dienstentdeckung und möglicherweise eine Schicht zur Orchestrierung von Agenten unverzichtbar.
• Standardisierte Verhaltensweisen: Ihre Agenten müssen gängige Verhaltensweisen wie Planung, Zielsetzung oder fortgeschrittenes Verständnis natürlicher Sprache implementieren. Frameworks bieten oft Abstraktionen oder Integrationen dafür.
• Skalierungsbedürfnisse: Sie haben es mit sehr hohem Nachrichtendurchsatz oder einer großen Anzahl gleichzeitiger Agenten zu tun und benötigen hochoptimierte Kommunikationsprotokolle oder eine verteilte Zustandsverwaltung "out of the box".
• Gemeinschaft & Ökosystem: Sie möchten eine große Gemeinschaft, bestehende Plugins und erprobte Muster für spezifische Agentenarchitekturen (z.B. FIPA-konforme Agenten) nutzen.

Selbst dann bleiben die Prinzipien klarer Kommunikation und solider Zustandsverwaltung, die wir heute besprochen haben, grundlegend. Ein gutes Framework baut darauf auf, es ersetzt nicht die Notwendigkeit, sie zu verstehen.

Handlungsfähige Erkenntnisse

Meine Hoffnung für Sie heute ist, dass Sie mit einem erneuerten Gefühl der Befähigung und einem kritischen Blick auf die nächste "revolutionäre" Ankündigung eines Agenten-SDKs nach Hause gehen. Das möchte ich, dass Sie sich merken:

1. Einfach anfangen: Bevor Sie sich in ein komplexes Framework stürzen, skizzieren Sie die absolut minimalen Kommunikations- und Zustandsbedürfnisse für Ihren Agenten. Können Sie 80% davon mit HTTP/JSON und einer einfachen Datenbank wie SQLite lösen? Wahrscheinlich.
2. Primitives verstehen: Selbst wenn Sie letztendlich ein Framework verwenden, verbringen Sie etwas Zeit damit, zu verstehen, wie Nachrichtenübertragung und Zustandspersistenz auf fundamentaler Ebene funktionieren. Dieses Wissen wird Sie zu einem besseren Debugger und Architekten machen.
3. Iterieren, nicht neu schreiben: Entwickeln Sie zuerst die Funktionalität Ihres Agenten. Lassen Sie es funktionieren. Wenn Sie auf eine echte Skalierungs- oder Komplexitätsgrenze stoßen, die ein Framework nachweislich löst, ziehen Sie in Betracht, eines zu übernehmen. Vermeiden Sie den Impuls, "alles neu zu schreiben".
4. Fokus auf Agentenlogik: Der wahre Wert Ihres Agenten liegt in seiner Entscheidungsfindung, seinem Denken und den einzigartigen Aufgaben, die er ausführt. Lassen Sie infrastrukturelle Bedenken nicht die Entwicklung dieser Kernlogik überschadowen.
5. Werkzeuge weise wählen: Nur weil ein Framework existiert, bedeutet das nicht, dass es das richtige Werkzeug für Ihren spezifischen Job ist. Bewerten Sie seine Überkopfkosten im Verhältnis zu seinen Vorteilen.

Das nächste Mal, wenn Sie ein Agentenprojekt starten, versuchen Sie, die grundlegende Kommunikation und Zustandsverwaltung selbst aufzubauen, selbst wenn es nur für einen Prototypen ist. Sie werden eine Menge lernen, einen widerstandsfähigeren Agenten entwickeln und sich wahrscheinlich viele Kopfschmerzen in der Zukunft ersparen. Machen Sie weiter, experimentieren Sie und scheuen Sie sich nicht, sich mit den Grundlagen schmutzig zu machen. Leo out.

🕒 Published: March 27, 2026