Manuell angepasst#

Exploration agentischer LLM-Systeme: Entwicklung eines Präsentationsvorbereitungs-Tools#

Zusammenfassung#

Dieser Artikel dokumentiert die Entwicklung eines Multi-Agent-Systems zur KI-gestützten Präsentationsvorbereitung. Das Experiment hatte zum Ziel, Methoden und Möglichkeiten agentischer LLM-Architekturen zu erkunden. Über einen Zeitraum von einer Woche entstand ein funktionsfähiges Tool mit etwa 3000 Zeilen Code, das auf einer Zwei-Agenten-Architektur basiert. Die methodischen Erkenntnisse aus diesem Projekt – insbesondere zur Bedeutung von Prompt-Following-Fähigkeiten, strukturierten Agent-Protokollen und detaillierten Spezifikationen – sind über das spezifische Projekt hinaus relevant für weitere LLM-gestützte Softwareentwicklung.

1. Experimenteller Kontext und Motivation#

1.1 Lernziele#

Das primäre Lernziel dieses Experiments war die Exploration des Umgangs mit agentischen LLM-Systemen. Im Fokus stand die Frage, wie mehrere spezialisierte Agenten koordiniert werden können, um eine komplexe Aufgabe zu lösen. Konkret sollte untersucht werden, inwieweit ein Agent nutzergenerierte Chat-Konversationen auf strukturrelevante Inhalte analysieren und ein zweiter Agent diese Informationen in ein strukturiertes Artefakt überführen kann.

1.2 Wahlentscheidung für ein Präsentationsvorbereitungs-Tool#

Die Wahl fiel auf ein Präsentationsvorbereitungs-Tool aus zwei Gründen. Zum einen bestand ein praktischer Bedarf an einer Lösung, die bei der Strukturierung von Präsentationen unterstützt – nicht bei der Erstellung vollständiger Präsentationen mit erfundenen Inhalten, wie viele existierende Tools dies tun. Zum anderen repräsentierte diese Aufgabe eine geeignete Komplexität für die Exploration agentischer Systeme: Sie erforderte Dokumentenverarbeitung, State-Management über mehrere Interaktionsrunden, strukturierte Ausgaben und die Koordination zwischen Konversations- und Strukturierungslogik.

1.3 Entwicklungsansatz#

Der Entwicklungsprozess folgte einer strukturierten Methodik. Zunächst wurde eine funktionale Spezifikation in iterativen Diskussionen entwickelt, bis diese den Anforderungen entsprach. Anschließend entstand eine detaillierte technische Spezifikation. Beide Dokumente lagen als Grundlage für die LLM-gestützte Code-Implementierung vor. Die Gesamtentwicklungszeit inklusive Spezifikation und Deployment betrug etwa 2-3 Stunden, verteilt über eine Woche.

1.4 Funktionsweise des Tools im Detail#

Um die methodischen Learnings richtig einordnen zu können, ist es wichtig zu verstehen, was das Tool konkret macht und wie es funktioniert.

Grundprinzip: Das Tool nimmt Dokumente als Input und strukturiert diese in eine präsentierbare Form, ohne eigene Inhalte zu erfinden. Es arbeitet ausschließlich mit vorhandenem Material und organisiert dieses nach den Wünschen der Nutzenden (z.B. Zielgruppe, Dauer, Kontext).

Workflow aus Nutzersicht:

1. Dokumenten-Upload: Die Nutzenden laden ein oder mehrere Dokumente hoch – beispielsweise ein wissenschaftliches Paper (PDF), ein Konzeptdokument (DOCX) oder eine bestehende Präsentation (PPTX). Das System verarbeitet diese Dokumente mit der Unstructured-Bibliothek und konvertiert sie intern in Markdown-Format.

2. Initiale Strukturierung: Der Artefakt-Agent analysiert die hochgeladenen Dokumente und erstellt ein initiales Präsentations-Artefakt. Dabei identifiziert er Hauptthemen, strukturiert diese als Folien und extrahiert relevante Stichpunkte. Falls wichtige Informationen fehlen (z.B. Zielgruppe, Vortragsdauer), generiert er Fragen.

3. Iterative Verfeinerung: Im Chat klärt der Nutzer Details: “Die Präsentation ist für Führungskräfte, 20 Minuten Vortragsdauer, Fokus auf Business-Implikationen” oder “Methodik kann knapp gehalten werden, ausführlicher bei den Ergebnissen”. Nach jeder Nutzer-Eingabe analysiert der Artefakt-Agent, ob strukturrelevante Informationen enthalten sind, und passt die Präsentationsstruktur entsprechend an.

4. Export: Das finale Artefakt kann in drei Formaten exportiert werden: als Markdown-Datei, als PowerPoint-Präsentation (PPTX) mit Folien und Sprechernotizen, oder als Word-Dokument (DOCX).

Das Artefakt – Herzstück des Systems:

Das Artefakt ist ein Markdown-Dokument mit klarer Struktur. Ein Beispiel:

# Meta
- Dauer: 15 Minuten
- Zielgruppe: Projektteam & Betreuer
- Veranstaltung: Zwischenpräsentation Masterarbeit

# Einleitung: Projektstand
- Erhebung abgeschlossen (n=120 Teilnehmer)
- Erste Auswertungen liegen vor
- Timeline: Woche 8 von 12

> Sprechernotiz: Hier Grafik der Verteilung zeigen

# Hauptergebnisse
- Deutlicher Zusammenhang zwischen ...
- Kontrollgruppe zeigt ...
- Drei interessante Ausreißer identifiziert
  - Fall 1: ...
  - Fall 2: ...

# Methodik (kurz)
- Online-Befragung mit standardisiertem Fragebogen
- Statistische Auswertung mit R
- Qualitative Interviews zur Vertiefung (n=12)

# Nächste Schritte
- Detailanalyse der Ausreißer
- Diskussion der Ergebnisse mit Literatur abgleichen
- Beginn des Schreibprozess (Kapitel 3-4)

Jede #-Überschrift repräsentiert eine Folie. Bulletpoints werden als Stichpunkte auf der Folie dargestellt, Unterpunkte mit Einrückung. Blockquotes (>) werden zu Sprechernotizen. Die erste “Meta”-Folie ist optional und dient der internen Dokumentation von Kontext-Informationen.

Zwei-Agenten-Koordination in der Praxis:

Wenn der Nutzer beispielsweise schreibt “Bitte mehr Details zu Aspekt X”, antwortet der Chat-Agent zunächst: “Ich ergänze die Informationen zu den neuen Kunden aus Ihren Dokumenten. Soll ich für jeden Aspekt eine separate Folie erstellen oder alle auf einer Folie zusammenfassen?”

Parallel dazu analysiert der Artefakt-Agent den Chat-Turn. Er erkennt, dass Details zu Einzelaspekten gewünscht sind, durchsucht die hochgeladenen Dokumente nach entsprechenden Informationen und erweitert die Struktur. Falls Details fehlen, generiert er eine Frage wie “Welche spezifischen Aspekte sollen präsentiert werden? (A, B, C, strategische Bedeutung?)”, die der Chat-Agent im nächsten Turn stellt.

Diese Koordination ermöglicht es, dass Nutzende eine natürliche Konversation führen, während im Hintergrund kontinuierlich die Präsentationsstruktur verfeinert wird.

Praktischer Nutzen:

Tests mit realen Dokumenten (bis 60 Seiten Umfang) zeigten, dass das Tool besonders wertvoll ist bei:

• Zeitlicher Planung: Automatische Anpassung der Folienanzahl an die Vortragsdauer
• Zielgruppenanpassung: Priorisierung und Detaillierung nach Publikum
• Strukturfindung: Identifikation einer logischen Präsentationsabfolge aus unstrukturierten Dokumenten
• Sprechernotizen: Zuordnung relevanter Details und Quellenverweise zu Folien

2. Technische Umsetzung#

2.1 Architekturentscheidung: Zwei-Agenten-System#

Die Entscheidung für eine Zwei-Agenten-Architektur war von Beginn an gesetzt, um mit einem einfachen Szenario zu starten. Die Aufgabenteilung folgte einer klaren Logik:

Chat-Agent: Verantwortlich für die Konversation mit den Nutzern. Dieser Agent stellt klärende Fragen zu Präsentationsparametern (Zielgruppe, Vortragsdauer, Veranstaltungskontext, Schwerpunkte) und empfängt Informationsanfragen vom Artefakt-Agent, die er transparent in die Konversation integriert.

Artefakt-Agent: Verantwortlich für die Pflege der Präsentationsstruktur. Nach jedem Chat-Turn wird dieser Agent getriggert und entscheidet autonom, ob der letzte Konversationsaustausch strukturrelevante Informationen enthält. Falls ja, aktualisiert er das Artefakt – ein Markdown-Dokument, das die Folienstruktur repräsentiert. Falls Informationen fehlen, generiert er Fragen, die der Chat-Agent an den Nutzer weitergibt.

Diese sequenzielle Orchestrierung erwies sich als praktikabel, erforderte jedoch eine spätere konzeptionelle Erweiterung (siehe Abschnitt 3.2).

2.2 Technologie-Stack#

Die Auswahl der Technologien basierte auf bewährten Komponenten aus vorherigen Projekten:

• Framework: Gradio wurde gewählt, da es in der Organisation bereits für viele Anwendungen etabliert ist und eine schnelle Prototyp-Entwicklung ermöglicht.
• LLMs: Für die Produktiv-Agenten kam Mistral Small 2506 zum Einsatz. Für die Code-Entwicklung wurden verschiedene LLMs genutzt.
• Dokumentenparsing: Unstructured hatte sich in vorherigen Projekten bewährt und unterstützt diverse Formate (PDF, DOCX, TXT, Markdown, PPTX).
• Export-Bibliotheken: python-pptx und python-docx für PowerPoint- bzw. Word-Export waren bereits bekannt.
• Token-Management: Tiktoken mit cl100k_base-Encoding für bessere Token-Abschätzung.

2.3 Modulstruktur und LLM-Wartbarkeit#

Die Projektstruktur wurde iterativ mit dem LLM entwickelt, wobei ein zentrales Prinzip die LLM-Wartbarkeit war. Nach den Vorerfahrungen können Code-Dateien unter 1000 Zeilen deutlich besser von LLMs gewartet werden. Dies ist keine harte Grenze, sondern ein Richtwert, der mehr Modularisierung erfordert, aber die Entwicklungsgeschwindigkeit und Wartbarkeit erhöht.

Die resultierende Struktur umfasst:

presentation-prep-tool/
├── app.py (~400 Zeilen)
├── config.py
├── core/
│   ├── document_processor.py
│   ├── llm_client.py
│   └── state_manager.py
├── agents/
│   ├── chat_agent.py (~400 Zeilen)
│   ├── artefakt_agent.py (~900 Zeilen)
│   └── prompts.py
└── export/
    ├── markdown_parser.py
    ├── pptx_exporter.py
    └── docx_exporter.py

Die größte Komponente ist der Artefakt-Agent mit etwa 900 Zeilen – nahe am Richtwert, aber noch gut handhabbar. Die Modularisierung nach Verantwortlichkeitsbereichen (core/, agents/, export/) ermöglichte es, einzelne Module isoliert weiterzuentwickeln.

2.4 State-Management#

Eine bewusste Vereinfachung war die vollständige Session-basierte Datenhaltung im Arbeitsspeicher ohne Persistierung. Dies reduziert die technische Komplexität erheblich und vereinfacht Datenschutzaspekte, da keine Nutzerdaten gespeichert werden. Der Application State umfasst:

• Hochgeladene Dokumente (Rohtexte und Metadaten)
• Chat-Historie
• Aktuelles Artefakt und Version-History (letzte 5 Versionen)
• Meta-Informationen (Zielgruppe, Dauer, Veranstaltung)
• Pending Questions vom Artefakt-Agent

3. Besonderheiten der Implementierung#

3.1 Sequenzielle Agent-Orchestrierung#

Die Koordination zwischen den Agenten folgt einem sequenziellen Muster: Nach jeder Eingabe antwortet zunächst der Chat-Agent. Anschließend wird der Artefakt-Agent getriggert, der den letzten Chat-Turn analysiert. Diese Architektur hat sich als praktikabel erwiesen, erforderte jedoch eine konzeptionelle Erweiterung.

3.2 Der “Rückkanal” – Eine iterative Verfeinerung#

Initial wurde davon ausgegangen, dass die Prompt-Following-Fähigkeiten der LLMs ausreichen würden, um die Agenten implizit zu koordinieren. In der Praxis zeigten sich jedoch Abstimmungsprobleme. Der Artefakt-Agent benötigte manchmal Informationen, die im Chat noch nicht geklärt waren, konnte dies aber nicht direkt kommunizieren.

Die Lösung war ein strukturiertes Kommunikationsprotokoll – ein “Rückkanal”. Der Artefakt-Agent gibt in seinem JSON-Response nicht nur das aktualisierte Artefakt zurück, sondern auch:

{
  "update_required": true/false,
  "artefakt": "# Meta\n- Dauer: 20min\n\n# Folie 1\n...",
  "diff_summary": "Folie 'Methodik' erweitert um 2 Stichpunkte",
  "needs_clarification": true/false,
  "clarification_questions": ["Frage 1", "Frage 2"]
}

Die clarification_questions werden vom System in den State des Chat-Agents geschrieben, der sie in der nächsten Interaktion an den Nutzer stellt. Nach Implementierung dieses Rückkanals verbesserten sich die Ergebnisse signifikant. Dies zeigt, dass strukturierte Protokolle robuster sind als Freitext-Kommunikation zwischen Agenten.

3.3 JSON-Response-Parsing und Fehlertoleranz#

Die JSON-basierte Schnittstelle zwischen System und Artefakt-Agent stellte die Frage, wie zuverlässig Mistral Small diese Struktur befolgt. In der Praxis erwies sich die Vorgabe als ausreichend deterministisch. Die Implementierung enthält dennoch robuste Fallback-Logik: Bei Parsing-Fehlern oder fehlenden Keys wird das Artefakt nicht verändert und eine Fehlermeldung in die Diff-Summary geschrieben. Diese Fehlertoleranz war in der Praxis selten notwendig, gibt dem System aber zusätzliche Stabilität.

3.4 Version-History und Undo-Funktionalität#

Von Beginn an war eine Undo-Funktion geplant, um bei Fehlern in der Strukturierung auf alte Arbeitsstände zurückkehren zu können. Die Implementierung speichert die letzten 5 Artefakt-Versionen mit jeweiliger Diff-Summary und Timestamp. Die Undo-Funktion ersetzt das aktuelle Artefakt mit der vorherigen Version. Diese Funktionalität wurde vom LLM problemlos umgesetzt und erwies sich in der Praxis als wertvoll.

4. Entwicklungsprozess mit LLM#

4.1 Strukturierte Spezifikations-Methodik#

Der Entwicklungsprozess folgte einer klaren dreistufigen Struktur:

Phase 1: Funktionale Spezifikation (ca. 2 Stunden): In 4-5 Iterationen über mehrere Tage wurde die funktionale Spezifikation entwickelt. Typische Diskussionsgegenstände waren:

• Wie genau sollte die Interaktion zwischen Artefakt und Chat organisiert werden?
• Welche Mechanismen ermöglichen es dem Artefakt-Agent, Nachfragen einzusteuern?
• Welche alternativen Architekturen gibt es und welche sind schlanker?

Bereits in dieser Phase wurden technische Machbarkeitsaspekte diskutiert, um unrealistische Features zu vermeiden und Komplexität zu reduzieren.

Phase 2: Technische Spezifikation (Teil der 2 Stunden): Nach Abschluss der funktionalen Spec entstand eine detaillierte technische Spezifikation mit exakten Datenstrukturen, Schnittstellendefinitionen, Modulaufteilung und Error-Handling-Strategien.

Phase 3: Implementierung (30-60 Minuten): Die fertigen Spezifikationen wurden den LLMs zur Umsetzung gegeben. Aufgrund der Klarheit der Specs war keine weitere Prompt-Iteration notwendig. Die LLMs generierten die Module direkt in verwendbarer Form.

4.2 Minimale Nacharbeit am Code#

Die Nacharbeit bestand weniger aus Debugging von Code-Fehlern, sondern aus konzeptionellen Anpassungen. Die Notwendigkeit des “Rückkanals” wurde erst in der Nutzung sichtbar. Diese konzeptionelle Iteration erforderte dann eine weitere Runde mit dem LLM, um die entsprechende Funktionalität zu implementieren.

4.3 Vermeidung von Overengineering#

Ein bewusstes Ziel war die Beachtung des KISS-Prinzips (Keep It Small and Simple). Dies wurde erreicht, indem bereits im Spezifikationsprozess interaktiv nach möglichen Vereinfachungen gesucht wurde – sowohl funktional als auch technisch. Die Diskussion alternativer Ansätze half, die schlankeste Lösung zu identifizieren. LLMs tendieren dazu, komplexe Lösungen vorzuschlagen, wenn die Spezifikation dies zulässt. Klare Constraints und die explizite Aufforderung zu Einfachheit halfen, dies zu vermeiden.

4.4 Wahl verschiedener LLMs#

Interessanterweise wurden für die Code-Entwicklung andere LLMs verwendet als für die Produktiv-Agenten. Dies ermöglichte eine Trennung zwischen Entwicklungs- und Runtime-Umgebung. Die genaue Auswahl der Code-generierenden LLMs war dabei weniger kritisch als die Wahl des Runtime-Modells (siehe Abschnitt 5.4).

5. Methodische Erkenntnisse#

5.1 Zentrale Bedeutung von Prompt-Following#

Eine wichtige Erkenntnis dieses Experiments betrifft die Prompt-Following-Fähigkeiten von LLMs in agentischen Systemen. Initial wurde angenommen, dass präzise Systemprompts ausreichen würden, um die Agenten zu koordinieren. In der Praxis zeigten sich jedoch “Unschärfen” – die Agenten interpretierten ihre Anweisungen teilweise inkonsistent oder ignorierten bestimmte Constraints.

Prompt-Following ist deshalb ein kritischer Faktor. Bei der Auswahl von Modellen für agentische Anwendungen sollte daher die Fähigkeit, strukturierten Anweisungen präzise zu folgen, höher gewichtet werden als etwa kreative Textgenerierung oder allgemeines Reasoning.

5.2 Strukturierte Protokolle statt Freitext-Kommunikation#

Der Übergang von impliziter Koordination zu einem expliziten JSON-basierten Protokoll hat wesentliche Verbesserungen ermöglicht. Freitext-Kommunikation zwischen Agenten mag natürlicher erscheinen, ist aber fehleranfälliger. Ein strukturiertes Protokoll bietet mehrere Vorteile:

• Parsing-Sicherheit: JSON kann robust validiert werden.
• Explizite Semantik: Jedes Feld hat eine definierte Bedeutung.
• Debugging: Fehler in der Agent-Kommunikation sind leichter zu identifizieren.
• Prompt-Stabilität: Strukturierte Outputs sind einfacher zu erzwingen als Freitext mit impliziten Konventionen.

Weitere Projekt werden zeigen, ob dieser Ansatz übertragbar auch auf andere Aufgaben übertragbar ist.

5.3 Notwendigkeit bidirektionaler Kommunikation#

Die nachträgliche Implementierung des Rückkanals zeigt, dass unidirektionale Datenflüsse in Multi-Agent-Systemen hier weniger gut funktioniert haben. Es wurden Mechanismen benötigt, um:

• Fehlende Informationen anzufordern
• Zweifel oder Unklarheiten zu signalisieren
• Die Arbeit des anderen Agenten zu beeinflussen

Diese Erkenntnis hätte möglicherweise in der Spezifikationsphase vorhergesehen werden können, wurde aber erst in der praktischen Nutzung offensichtlich. Für zukünftige Projekte werden solche Rückkopplungsmechanismen von Beginn an untersucht.

5.4 Modellwahl: Kleine Modelle mit gutem Prompt-Following#

Mistral Small 2506 erwies sich für die Agenten als ausreichend. Größere Modelle hätten vermutlich präziser gearbeitet, die hohe Inferenzgeschwindigkeit des kleineren Modells (Response-Zeiten von wenigen Sekunden) sorgte jedoch für ein gutes Nutzererlebnis.

Bei der Modellwahl für agentische Systeme sollte Prompt-Following-Fähigkeit das primäre Auswahlkriterium sein, nicht Modellgröße oder allgemeine Benchmark-Scores. Ein kleineres Modell mit exzellenter Instruktionsbefolgung kann einem größeren Modell mit schwächerer Compliance überlegen sein – insbesondere wenn Latenz eine Rolle spielt.

5.5 Wert detaillierter Spezifikationen#

Der Einsatz von 2 Stunden in funktionale und technische Spezifikationen ermöglichte eine Implementierungszeit von nur 30-60 Minuten für 3000 Zeilen Code. Dieses Verhältnis unterstreicht den Vorteil detaillierter Spezifikationen für LLM-gestützte Entwicklung.

Entscheidend war die Trennung zwischen funktionaler und technischer Ebene. Die funktionale Spezifikation klärte das “Was” und “Warum”, während die technische Spezifikation das “Wie” definierte. Wichtige Details in den Specs waren:

• Angaben zur technischen Struktur
• Exakte Datenstrukturen (z.B. der Application State)
• Schnittstellendefinitionen (z.B. das JSON-Format des Artefakt-Agents)
• Error-Handling-Strategien
• Architektur-Constraints (z.B. die <1000-Zeilen-Regel)

Ohne diese Klarheit wäre die Entwicklung in dieser kurzen Zeit nicht möglich gewesen.

5.6 Kleinere Code-Dateien für LLM-Wartbarkeit#

Der Erfahrungswert, dass Code-Dateien unter 1000 Zeilen besser von LLMs wartbar sind, hat sich erneut bestätigt. Dies ist keine absolute Grenze – die größte Datei in diesem Projekt, der Artefakt-Agent mit ~900 Zeilen, liegt knapp darunter. Der Richtwert zwingt jedoch zu sinnvoller Modularisierung.

Für Architekturentscheidungen erfordert diese Rahmenbedingung möglichst modulare Struktur auch für Projekte, die ggf. auch mit einer Code-Datei möglich wäre. Es erfordert, Verantwortlichkeiten im Code auf mehrere kleinere Einheiten zu verteilen. Dies zahlt sich nicht nur in der LLM-Wartbarkeit aus, sondern auch in der menschlichen Lesbarkeit und Testbarkeit.

5.7 Iterative Vereinfachung im Spezifikationsprozess#

Die 4-5 Iterationen in der Spezifikationsphase dienten nicht nur der Klärung von Details, sondern auch der Prüfung möglicher Vereinfachungen. Durch Diskussion alternativer Ansätze und explizite Suche nach Vereinfachungsmöglichkeiten wurde Overengineering vermieden. Diese iterative Refinement-Phase war wichtig, um am Ende eine implementierbare und wartbare Lösung zu erhalten.

6. Validierung und praktische Nutzung#

6.1 Test-Szenarien und Robustheit#

Das Tool wurde von verschiedenen Stakeholdern aus unterschiedlichen Bereichen mit realen Dokumenten getestet. Die Input-Dokumente reichten von wenigen Seiten bis zu 60 Seiten. Trotz dieser Varianz wurde das Token-Limit von ca. 200k kaum erreicht, was die Dimensionierung als angemessen bestätigt.

Die Tests umfassten diverse Dokumenttypen (wissenschaftliche Papers, Konzeptdokumente, bestehende Präsentationen) und verschiedene Anwendungsfälle (Konferenzvortrag, internes Meeting, Schulungspräsentation). Die Strukturierung funktionierte in allen Szenarien robust.

6.2 Unerwartete Stärken#

Eine überraschende Erkenntnis war die Qualität der Ergebnisse bei zeitlicher Planung und Zielgruppenanpassung. Das Tool erwies sich als besonders wertvoll, um:

• Die Anzahl benötigter Folien basierend auf Vortragsdauer abzuschätzen
• Inhalte nach Relevanz für verschiedene Zielgruppen zu priorisieren
• Eine zeitlich realistische Struktur zu entwickeln

Diese Aspekte waren nicht als primäre Stärken antizipiert worden, zeigten sich aber in der Nutzung als besonders wertvoll. Das Tool hat derzeit eher “inspirativen Wert” – es liefert strukturierte Vorschläge als Ausgangsbasis, nicht komplette Präsentationen.

6.3 Nutzungsverhalten#

Das Tool wird gelegentlich produktiv genutzt, wäre aber für intensive Nutzung noch weiterzuentwickeln. Weitere Nutzerwünsche müssten integriert werden, was möglicherweise in einer zukünftigen Entwicklungsrunde geschieht. Die aktuelle Version erfüllt jedoch bereits den experimentellen Zweck und zeigt die Machbarkeit des Ansatzes.

7. Quantitative Metriken#

7.1 Codeumfang und Struktur#

• Gesamt: ~3000 Zeilen Code
• Größte Komponenten:
  • Artefakt-Agent: ~900 Zeilen
  • Chat-Agent: ~400 Zeilen
  • Hauptanwendung (app.py): ~400 Zeilen
• Anzahl Dateien: ca. 15 Module

7.2 Entwicklungszeit#

• Spezifikation: 2 Stunden über mehrere Tage
  • Funktionale Spezifikation: 4-5 Iterationen
  • Technische Spezifikation: Teil der 2 Stunden
• Implementierung: 30-60 Minuten
• Deployment und Dokumentation: 30-60 Minuten
• Gesamtdauer: Eine Woche (verteilte Sessions)
• Konzeptionelle Iteration (Rückkanal): Eine zusätzliche LLM-Session

7.3 Runtime-Metriken#

• Response-Zeiten: Wenige Sekunden pro Agent-Turn
• Token-Limit: 200k (praktisch kaum erreicht)
• Getestete Dokumentgrößen: Wenige bis 60 Seiten
• Maximaler State: Nie limitierend

8. Übertragbare Prinzipien für zukünftige Projekte#

Aus diesem Experiment lassen sich folgende Prinzipien für LLM-gestützte Multi-Agent-Entwicklung ableiten:

1. Aufwand für Spezifikationen. Das Verhältnis 2:1 zwischen Spezifikations- und Implementierungszeit ist kein Overhead, sondern Effizienzgewinn.

2. Trennung von funktionaler und technischer Spezifikation. Die saubere Klärung der Fragen zu “Was” und “Wie” erhöhen die Effizienz.

3. Strukturierte Protokolle. JSON-basierte Schnittstellen sind robuster als Freitext-Kommunikation zwischen Agenten.

4. Bidirektionale Kommunikation. In diesem Anwendungsfall hat erst der Rückkanal dafür gesorgt, die Anwendung stabil zu bekommen.

5. Prompt-Following. Dies scheint ein wichter Faktor für agentische Systeme.

6. Modularisierung mit Blick auf LLM-Wartbarkeit. Der <1000-Zeilen-Richtwert zwingt zu sinnvoller Strukturierung.

7. Vereinfachungen. Overengineering vermeiden durch aktive Suche nach schlankeren Alternativen.

8. Konzeptionelle Iterationen ein. Nicht alle Probleme werden in der Spezifikationsphase sichtbar. Auch für die Iterationen braucht es einen möglichst klaren Workflow.

9. Ausblick#

Das strukturierte Vorgehen – funktionale Spezifikation, technische Spezifikation, dann Implementierung – hat sich als reproduzierbarer Workflow etabliert und wird in weiteren Projekten beibehalten. Die Erkenntnisse zu Prompt-Following, strukturierten Protokollen und Agent-Koordination sind womöglich auf komplexere Multi-Agent-Szenarien übertragbar.

Zukünftige Experimente könnten untersuchen:

• Systeme mit mehr als zwei Agenten
• Dynamische Agent-Orchestrierung statt sequenzieller Abarbeitung
• Spezialisierte Modelle für verschiedene Agenten-Rollen
• Formale Verifikation von Agent-Protokollen

Die Dokumentation dieser Ergebnisse dient möglichen Weiterentwicklungen bei der LLM-gestützten Softwareentwicklung und soll reproduzierbare Muster für ähnliche Projekte vermitteln.