Fünf Arten von “Planung” in der KI-Tooling-Landschaft
Das Wort “Planung” ist überladen. Heute existieren mindestens fünf unterschiedliche Ansätze, und sie lösen verschiedene Probleme:| Ansatz | Planformat | Ausführung | Genehmigung | Kernwert |
|---|---|---|---|---|
| Implizite Modellplanung | Interne Chain-of-Thought | Einzelner Inferenzdurchlauf | Keine | Das Modell durchdenkt Schritte selbstständig |
| Claude Code Planmodus | Markdown-Dokument | Seriell | Mensch überprüft vor Ausführung | Einigung auf Ansatz vor Code-Änderungen |
| Claude Code Teams | Aufgabenliste mit Abhängigkeitskanten | Parallel (Multi-Agent) | Mensch genehmigt Plan, dann autonom | Dynamischer Agent-Pool + parallele Ausführung |
| Kiro spec-driven dev | Strukturierte Spezifikation (Anforderungen + Design + Aufgaben) | Seriell | Mensch überprüft Spezifikation | Nachverfolgbare Anforderungen, Akzeptanzkriterien |
| FIM One DAG | JSON-Abhängigkeitsgraph | Parallel (einzelner Orchestrator) | Automatisch (PlanAnalyzer) | Parallele Ausführung + Laufzeit-Scheduling |
Dreischichtige Verschachtelung: Die Vollleistungs-Architektur
Sowohl Claude Code Teams als auch FIM One DAG zeigen in voller Kapazität eine dreischichtige verschachtelte Architektur:- Layer 1 — Human Gate: Der Benutzer überprüft den Plan und genehmigt ihn vor Beginn der Ausführung.
- Layer 2 — DAG-Orchestrierung: Der genehmigte Plan wird in Aufgaben mit Abhängigkeitskanten zerlegt. Unabhängige Aufgaben laufen parallel; nachgelagerte Aufgaben warten auf die Auflösung ihrer Blocker.
- Layer 3 — ReAct-Innenschleife: Jede Aufgabe wird von einem Agenten ausgeführt, der einen vollständigen ReAct-Zyklus durchläuft (Perceive → Reason → Act → Observe), mit Fähigkeit zu mehrstufigem Reasoning, Tool-Nutzung und autonomem Retry.
Full-Power Runtime: FIM One vs Claude Code Teams
Beide sind echte Agenten — die Kernschleife ist identisch: Wahrnehmen → Reasoning → Handeln → Feedback. Der Unterschied liegt darin, wie sie parallele Arbeit mit voller Kapazität orchestrieren.| Dimension | Claude Code Teams | FIM One DAG |
|---|---|---|
| Parallelmodell | Leader spawnt SubAgenten, weist Aufgaben über Nachrichten zu | Topologische Sortierung parallelisiert unabhängige Schritte automatisch |
| Aufgabengraph | TaskList mit blockedBy / blocks Kanten (dynamischer DAG) | Statischer JSON DAG mit depends_on Kanten |
| Koordination | Explizite Nachrichtenübergabe (SendMessage / Broadcast) | Implizite Abhängigkeitskanten — keine Nachrichten, nur Datenfluss |
| Agenten-Lebenszyklus | Dynamischer Pool — Agenten bei Bedarf erzeugt, beendet wenn fertig | Feste Schritt-Executoren — ein LLM-Aufruf pro Schritt |
| Feedback & Korrektur | Jeder SubAgent versucht autonom erneut; Leader weist bei Fehler neu zu | PlanAnalyzer bewertet Ergebnisse → Re-Planning-Schleife (bis zu 3 Runden) |
| Menschliche Beteiligung | Plan-Modus-Genehmigung, dann autonome Ausführung | Vollautomatisch — PlanAnalyzer entscheidet über Bestätigung/Neuplanung |
| Kontextverwaltung | Jeder SubAgent erhält isoliertes Kontextfenster (keine Kreuzkontamination) | Gemeinsamer DbMemory + LLM Compact über alle Schritte |
| Token-Ökonomie | N Agenten × Token pro Agent — Zeit↓ Token↑ (multiplikativer Kostenfaktor) | Sequenziell oder flache Parallelität — niedrigere Gesamttoken |
| Skalierungsmuster | Mehr SubAgenten hinzufügen (horizontal, nachrichtengekoppelt) | Mehr DAG-Branches hinzufügen (horizontal, abhängigkeitsgekoppelt) |
| Am besten geeignet für | Vielfältige, lose verwandte Aufgaben (Recherche + Code + Test) | Strukturierte Workflows mit klaren Datenabhängigkeiten |
Real-World Benchmark: v0.5 RAG System
Claude Code Teams built FIM One’s entire v0.5 RAG subsystem in a single session:- 8 phases: Embedding → Reranker → Loaders → Chunking → VectorStore → Retrieval → KB Backend → Frontend + Docs
- 46 tests passing, frontend build clean
- Wall time: ~5 minutes
- Token cost: ~100k tokens per Agenten-Aufgabe × 8+ tasks ≈ 800k+ total tokens
- Dependency edges: Phase 5 depends on Phase 4 + 1b; Phase 6 depends on Phase 5 + 2 + 3 — a genuine DAG
Konvergenz, nicht Konkurrenz
Die Grenze zwischen „Team-Zusammenarbeit” und „Pipeline-Planung” verschwimmt:- Claude Code Teams’
blockedBy/blocksIST ein DAG — Aufgaben haben explizite Abhängigkeitskanten, und der Leader verteilt neu freigegebene Aufgaben, wenn Vorgänger abgeschlossen sind. Dies ist topologische Planung mit zusätzlichen Schritten (Nachrichten). - FIM One’s DAG könnte von Agent-Autonomie profitieren — statt einzelner LLM-Aufrufe pro Schritt würde es, wenn jeder Schritt eine vollständige ReAct-Schleife ausführt, komplexe Teilaufgaben besser bewältigen.
Strukturierte Ausgabeverschlechterung
Alle strukturierten LLM-Aufruforte in der DAG-Pipeline (Planner, Analyzer, Tool Selection) verwenden ein einheitlichesstructured_llm_call()-Dienstprogramm, das eine 3-stufige Verschlechterungskette implementiert:
| Stufe | Bedingung | Funktionsweise |
|---|---|---|
| Native FC | llm.abilities["tool_call"] | Erzwingt einen virtuellen Tool-Aufruf; extrahiert aus tool_calls[0].arguments |
| JSON Mode | llm.abilities["json_mode"] | Setzt response_format={"type":"json_object"}; analysiert mit extract_json() |
| Klartext | immer verfügbar | Analysiert Freiforminhalt mit extract_json(), dann optional regex_fallback() |
StructuredCallResult, das den analysierten Wert, die erfolgreiche Extraktionsstufe und die kumulierte Token-Nutzung enthält.
Dieses Design bedeutet, dass die gleiche Aufforderung zuverlässig über GPT-4 (native FC), Claude (JSON Mode) und lokale Modelle (Klartext) funktioniert, mit konsistenter Fehlerbehandlung und Wiederholungslogik an einer Stelle statt verstreut über vier Aufruforte.