Das Ökosystem der KI-Agenten und Harnesses

In unseren letzten Blog-Beiträgen haben wir intensiv beleuchtet, wie KI die Software-Entwicklung verändert. Wir haben untersucht, warum uns das Model Context Protocol (MCP) neue Wege für saubere Schnittstellen eröffnet, wie KI-Config-Dateien Prompts strukturieren und warum der Weg von experimentellem „Vibe Coding“ hin zu diszipliniertem „Agentic Engineering“ führt.

Doch während die Modelle selbst immer leistungsfähiger werden, hat sich im Hintergrund eine neue Architektur-Ebene aufgetan: Agenten-Frameworks und KI-Harnesses.

In diesem Beitrag ordnen wir dieses neue Ökosystem ein. Was verbirgt sich dahinter? Wofür brauchte man bisher eigene Agenten-Frameworks? Wie verändert sich dieser Bedarf durch Werkzeuge wie Claude Code oder Cursor? Und worauf kommt es in Zukunft an, wenn man als Software-Partner im öffentlichen Verkehr kritische Infrastruktur entwickelt?

Was sind Agenten-Frameworks und Harnesses? Ein Blick in die Werkstatt

Stellen wir uns zwei Wege vor, wie KI beim Programmieren helfen kann.

Der klassische Weg (Prompting): Ein Entwickler kopiert eine Fehlermeldung aus der Konsole in ein Chatfenster. Das Sprachmodell antwortet mit einem korrigierten Code-Schnipsel, und der Entwickler fügt diesen manuell wieder in sein Projekt ein. Das Modell ist hier ein passiver Ratgeber.

Der agentische Weg: Der Entwickler gibt eine Aufgabe vor: „Der Export für die Haltestellen-Geodaten bricht bei Umlauten ab. Finde den Fehler, schreibe einen Test dafür und behebe ihn.“

Damit die KI diesen Auftrag eigenständig ausführen kann, braucht sie mehr als nur Sprachverständnis. Sie benötigt Werkzeuge, Regeln und eine geschützte Umgebung:

• Das Agenten-Framework (Die Regie): Es ist die Logik, die der KI sagt, wie sie vorgehen soll. Es zerlegt die Aufgabe in Schritte: Erst Fehler suchen, dann Test schreiben, dann Code anpassen, dann Test ausführen.
• Das Agent Harness (Die Werkbank): Das ist die reale Laufzeitumgebung um die KI herum. Das Harness erlaubt dem Modell, Dateien auf der Festplatte zu lesen, Befehle im Terminal auszuführen, Git-Commits zu erstellen und das eigene „Gedächtnis“ (den Kontext) aufzuräumen, damit der Speicher nicht überläuft.

Wofür brauchte man eigene Frameworks? Drei Szenarien aus der Praxis

Bis vor kurzem mussten Entwicklerteams solche Agenten-Abläufe noch komplett selbst programmieren. Welches Framework man wählte, hing stark vom konkreten Anwendungsfall ab.

Das Fließband mit Kontrollschranken (State-Graph Frameworks)

Angenommen, MENTZ entwickelt ein Modul, das automatisch neue GTFS-Fahrplandaten von Verkehrsunternehmen einliest und auf Vollständigkeit prüft. Ein Fehler hier könnte dazu führen, dass Fahrgästen falsche Abfahrtszeiten angezeigt werden.

Hier kommen Frameworks wie LangGraph oder das Microsoft Agent Framework zum Einsatz. Sie steuern Agenten wie ein Schienennetz: Jeder Schritt ist strikt definiert. Ein Agent darf die Daten analysieren und Korrekturen vorschlagen. Bevor diese aber in die Datenbank geschrieben werden, erzwingt der Graph einen Stop-Punkt für die menschliche Freigabe (Human-in-the-loop). Es gibt kein unkontrolliertes „Einfach-Mal-Ausprobieren“ der KI.

Die virtuelle Taskforce (Rollenbasierte Systeme)

Ein anderes Beispiel: Für ein neues Projekt soll ein erster Prototyp einer Benutzeroberfläche entstehen. Frameworks wie CrewAI simulieren dafür ein ganzes Team.

Ein Agent bekommt die Rolle „Produkt-Manager“ und schreibt die Anforderungen. Der zweite Agent agiert als „Senior Developer“ und setzt den Code auf. Der dritte Agent übernimmt die Rolle „QA-Engineer“ und sucht nach Fehlern. Die Agenten „unterhalten“ sich untereinander, bis das Ergebnis steht. Für schnelles Prototyping ist das ideal, für hochkritische Produktivsysteme dagegen oft zu unberechenbar.

Der Datentresor (Typsichere Frameworks)

Wenn ein KI-System Schnittstellen bedient (etwa eine Abfrage von Live-Verspätungsdaten), darf die Antwort niemals unstrukturierter Fließtext sein. Frameworks wie Pydantic AI zwingen das Sprachmodell dazu, Antworten in exakt vorgegebene Datenstrukturen zu gießen. Stimmt das Datenformat nicht, verwirft das Framework die Antwort sofort und lässt die KI korrigieren, bevor der Code überhaupt ausgeführt wird.

Der Wandel: Wie sich der Bedarf durch „Super-Harnesses“ verändert

Mit dem Aufkommen hochintegrierter Ausführungsumgebungen wie Claude Code, Cursor oder Codex hat sich das Kräfteverhältnis verschoben. Die Frage lautet heute: Wie viel eigenen Agenten-Code muss ein Entwicklerteam überhaupt noch schreiben?

Die Antwort hängt stark vom Einsatzzweck ab:

+-----------------------------------------------------------------+
|                       Enterprise Products                       |
|           (Propriitäre Komplettlösungen: Claude Code)           |
+-----------------------------------------------------------------+
                                |
                                v
+-----------------------------------------------------------------+
|                    Agentic Harness Layer                        |
|  (Protokolle, Sandboxing, Context-Windows, MCP, System Prompts) |
+-----------------------------------------------------------------+
                                ^
                                |
+-----------------------------------------------------------------+
|                    Custom Agent Frameworks                      |
|                 (LangGraph, Pydantic AI, etc.)                  |
+-----------------------------------------------------------------+

Der Bedarf an eigenen Frameworks für Standard-Code SINKT

Für alltägliche Programmieraufgaben (Bugs beheben, Unit-Tests ergänzen, Refactoring) bauen wir heute kaum noch eigene Agenten-Skripte. Werkzeuge wie Claude Code bringen ihr eigenes Harness bereits mit. Sie verwalten das Kontextfenster selbstständig (z. B. durch automatische Verdichtung via /compact), starten bei Bedarf isolierte Sub-Agenten im Hintergrund und führen Terminal-Befehle sicher aus.

Der Bedarf an Custom-Frameworks für Produkt-Logik STEIGT

Wenn wir jedoch KI-Funktionen direkt in unsere Kundenprodukte integrieren (etwa ein autonomes Analysetool für EFA-Schnittstellen oder KI-gestützte Prüfroutinen in der Dienstplanung), stoßen generische Entwickler-Harnesses an ihre Grenzen. Hier sind maßgeschneiderte Graphen-Frameworks nach wie vor unverzichtbar, um:

1. Spezifische Richtlinien und Governance einzuhalten: KI darf im ÖPNV keine plausibel klingenden, aber falschen Fahrplandaten erfinden.
2. Kosten und Tokens zu kontrollieren: Unendliche Diskussionen zwischen autonomen Agenten erzeugen hohe Betriebskosten.
3. Unabhängig von Anbietern zu bleiben: Frameworks erlauben den flexiblen Wechsel zwischen verschiedenen Sprachmodellen.

Die Methodik der Zukunft: Spec-Driven Development (GSD)

Selbst die besten Ausführungsumgebungen leiden bei sehr langen Arbeits-Sessions unter dem Phänomen der Kontext-Degradierung (Context Rot): Das Sprachmodell liest Hunderte Zeilen Chatverlauf, verliert feine Details aus dem Blick und weicht vom ursprünglichen Plan ab.

Um dem entgegenzuwirken, gewinnt eine methodische Schicht an Bedeutung: das Prinzip des Spec-Driven Developments (SDD), wie es etwa das GSD-Framework (Get Shit Done), das wir bei uns in der EFA gerade testen, vorgelebt hat.

GSD ist kein eigenes Tool-Paket, das als Software installiert werden muss. Es ist eine Arbeitsmethodik, die Entwickler bei der Nutzung moderner KI-Tools anwenden. Anstatt ein Harness wie Claude Code mit einer vagen Anweisung loszulaufen zu lassen, erzwingt ein strukturierter Ablauf Ordnung:

+-----------------------------------------------------------------+
|                        Entwickler (Human)                       |
+-----------------------------------------------------------------+
                                |
                                v
+-----------------------------------------------------------------+
|               GSD Framework (Spezifikation & Plan)              |
|        Orchestrierung: Phasen, Kontext-Hygiene, Akzeptanz       |
+-----------------------------------------------------------------+
                                |
                                v
+-----------------------------------------------------------------+
|                 Harness / Execution Layer                       |
|                 (Claude Code, Terminal, etc.)                   |
+-----------------------------------------------------------------+

• Discuss: Vor der ersten Zeile Code stellt das System gezielte Fragen zu Architekturentscheidungen und dokumentiert die Rahmenbedingungen.
• Plan: Die Gesamtaufgabe wird in kleine, isolierte Arbeitspakete unterteilt.
• Execute & Verify: Das Harness arbeitet das Paket ab. Ein automatischer Prüfschritt bewertet das Ergebnis gegen die Spezifikation, bevor der Stand in Git committet und der Kontext für das nächste Paket leergemacht wird.

Die Faustregel für die Praxis lautet: Die Muskeln (Terminal-Zugriff, Code-Editierung) stellt das Harness bereit – die Disziplin (GSD-Muster, klare Regeln) steuert der Entwickler bei.

Fazit: Kein Patentrezept – Der richtige Ansatz ist immer fallspezifisch

Die Evolution von einfachen Prompts hin zu autonomen Agenten-Harnesses zeigt, wie schnell sich die Werkzeuglandschaft dreht. Eines wird in der Praxis jedoch übersteht deutlich: Es gibt nicht die eine KI-Entwicklungsmethodik, die für jedes Projekt passt.

Ansätze wie Spec-Driven Development (SDD) im Zusammenspiel mit GSD-Mustern bieten hervorragende Leitplanken, wenn es um komplexe, hochgradig strukturierte Codebasen geht. Für kleinere Bugfixes, schnelle Prototypen oder explorative Aufgaben können sie jedoch zu starr sein und den Entwicklungsfluss eher ausbremsen als beschleunigen.

Ob man auf vorgefertigte Super-Harnesses wie Claude Code setzt, eigene LangGraph-Pipelines baut oder strikte SDD-Prozesse durchzieht, bleibt eine Einzelfallentscheidung. Sie hängt vom Sicherheitsbedarf des Moduls, den Qualitätsanforderungen und der Teamstruktur ab.

Bei MENTZ verstehen wir diese Werkzeuge genau als das: Optionen in einem modernen Werkzeugkasten. Wir beobachten die rasante Entwicklung rund um Agenten, Harnesses und Prozess-Methodiken weiterhin sehr aufmerksam, testen neue Ansätze in der Praxis und setzen jeweils genau die Kombination ein, die für die Verlässlichkeit unserer Mobilitätssysteme den größten Mehrwert bringt.