Claude Code: Multi-Agenten-Systems

Multi-Agenten-Systems zur automatisierten Branchenbeobachtung mittels Claude Code

Zusammenfassung

Der vorliegende Beitrag beschreibt die Architektur eines Multi-Agenten-Systems zur automatisierten Beobachtung herstellerseitiger Blog-Veröffentlichungen im Bereich künstlicher Intelligenz. Das System wird ausschließlich mit den nativen Subagent-Funktionen von Claude Code realisiert, ohne Rückgriff auf externe Orchestrierungs-Frameworks wie LangGraph oder CrewAI. Im Folgenden werden der strukturelle Aufbau, die Rollenverteilung der beteiligten Agenten, der sequenzielle Ablauf der Verarbeitungspipeline sowie die praktische Nutzung des Systems dargestellt.

1. Einleitung

Gegenstand der Untersuchung ist die Frage, ob sich ein funktionsfähiges Multi-Agenten-System allein mit den in Claude Code integrierten Mitteln realisieren lässt. Als Anwendungsfall dient die automatisierte Überwachung der Blogs dreier AI-Hersteller — Google, OpenAI und NVIDIA — mit dem Ziel, neue Veröffentlichungen zu identifizieren, herstellerübergreifende Trends abzuleiten und daraus einen redaktionellen Blogbeitrag zu erstellen.

Das resultierende System besteht aus vier Subagent-Definitionen und einem Slash-Command, jeweils als Markdown-Dateien implementiert. Es kommen weder externe Bibliotheken noch ein separater Scheduler-Prozess oder eine Vektordatenbank zum Einsatz. Die folgenden Abschnitte behandeln den Aufbau des Systems (Abschnitt 2), die Funktion der einzelnen Agenten (Abschnitt 3), den Ablauf der Verarbeitungspipeline (Abschnitt 4) und die praktische Anwendung (Abschnitt 5).

2. Aufbau

Das System ist in einem .claude-Verzeichnis innerhalb des Projektordners organisiert:

.claude/
  agents/
    orchestrator.md
    blog-scanner.md
    trend-analyst.md
    blog-writer.md
  commands/
    scan-ai-news.md
data/
  seen-posts.json
  scan-result-*.json
  trend-analysis-*.json
output/
  posts/*.md

Die Struktur gliedert sich in drei funktional getrennte Bereiche. .claude/agents/ enthält die Subagent-Definitionen und bildet damit die eigentliche Programmlogik des Systems. data/ fungiert als Kommunikationsschicht zwischen den einzelnen Verarbeitungsphasen: Jede Phase persistiert ihr Ergebnis als JSON-Datei, welche von der nachfolgenden Phase eingelesen wird. output/posts/ enthält die fertiggestellten Blogbeitrags-Dateien als Endprodukt der Pipeline.

Abbildung 1 stellt die Komponenten des Systems und ihre Abhängigkeiten schematisch dar:

Externe QuellenPersistenzebeneSubagent-EbeneSteuerungsebenedelegiertdelegiertdelegiertliestschreibtliestschreibtliestschreibtaktualisiert nach Abschluss/scan-ai-news
(Slash-Command)orchestrator
(Task, Read, Write, Bash)blog-scanner
(WebFetch, WebSearch)trend-analyst
(Read, Write, WebSearch)blog-writer
(Read, Write, WebFetch)data/seen-posts.jsondata/scan-result-*.jsondata/trend-analysis-*.jsonoutput/posts/*.mdGoogle AI BlogOpenAI NewsNVIDIA AI Blog

Abbildung 1: Komponenten des Systems, gegliedert nach Steuerungs-, Subagent- und Persistenzebene. Gestrichelte Pfeile kennzeichnen lesenden bzw. nachgelagerten Zugriff.

Die Entscheidung, Zwischenergebnisse dateibasiert zu persistieren statt sie ausschließlich innerhalb des Konversationskontextes zu übergeben, beruht auf zwei Überlegungen. Erstens wird dadurch die Nachvollziehbarkeit der Pipeline sichergestellt: Die Ergebnisse jeder Phase lassen sich unabhängig vom weiteren Verlauf einsehen und überprüfen. Zweitens erhöht sich die Robustheit gegenüber Abbrüchen, da der Verarbeitungsstand bei einem vorzeitigen Ende der Pipeline anhand der vorhandenen Dateien rekonstruierbar bleibt. Dieses Prinzip entspricht im Grundsatz dem Logging-Verfahren in herkömmlichen Software-Systemen, findet bei der Konzeption von KI-gestützten Pipelines jedoch vergleichsweise selten Anwendung.

3. Die Agenten

Das System umfasst vier Subagenten, denen jeweils eine einzelne, klar abgegrenzte Zuständigkeit zugewiesen ist.

Orchestrator. Der orchestrator-Agent übernimmt ausschließlich koordinierende Funktionen; er führt selbst keine Recherche durch und erstellt keine Inhalte. Seine Aufgabe besteht darin, die übrigen drei Agenten in der korrekten Reihenfolge zu delegieren, deren Zwischenergebnisse auf Plausibilität zu prüfen und nach Abschluss der Pipeline eine Zusammenfassung bereitzustellen. Ihm sind die Werkzeuge Task (zur Delegation an andere Subagenten), Read, Write und Bash zugeordnet.

Blog-Scanner. Der blog-scanner-Agent ruft die drei Hersteller-Blogs mittels WebFetch ab und ergänzt dies bei Bedarf durch gezielte WebSearch-Anfragen. Jeder ermittelte Beitrag wird gegen eine Tracking-Datei bereits verarbeiteter URLs abgeglichen; lediglich neu identifizierte Beiträge fließen in das Ergebnis ein. Dem Agenten ist kein Schreibzugriff auf andere Bereiche des Projekts gewährt; er verfügt über kein Edit-Werkzeug.

Trend-Analyst. Der trend-analyst-Agent verarbeitet die vom Blog-Scanner identifizierten Beiträge und sucht nach Mustern, die über einzelne Hersteller hinausreichen. Veröffentlichen mehrere Hersteller innerhalb desselben Zeitraums zu einem verwandten Thema — etwa im Bereich agentenbasierter Programmierung oder reasoning-fähiger Modelle — wird dies als stärkeres Relevanzsignal gewertet als eine isolierte Einzelmeldung. Der Agent priorisiert abschließend genau ein Thema für den nachfolgenden Blogbeitrag; eine Mehrthemigkeit wird aus redaktionellen Gründen ausgeschlossen.

Blog-Writer. Der blog-writer-Agent verfasst auf Grundlage der Themenpriorisierung einen veröffentlichungsfertigen Beitrag in Markdown mit Frontmatter, Zwischenüberschriften und einer abschließenden Quellenliste. Der Agent ist berechtigt, die Originalquellen mittels WebFetch erneut abzurufen, um Details zu verifizieren; eine wörtliche Übernahme von Textpassagen ist hierbei ausgeschlossen, sämtliche Inhalte sind in eigener Formulierung wiederzugeben.

Allen Agenten ist jeweils nur die für ihre Aufgabe erforderliche Werkzeugmenge zugewiesen, entsprechend dem Prinzip minimaler Berechtigungen. Dies dient nicht ausschließlich Sicherheitserwägungen, sondern begrenzt auch den funktionalen Wirkungsbereich jedes Agenten auf seine vorgesehene Aufgabe.

Abbildung 2 fasst die Rollenverteilung, die zugeordneten Werkzeuge sowie die jeweils ausgeschlossenen Zuständigkeiten zusammen:

Phase 1Phase 2Phase 3orchestrator+Werkzeuge: Task, Read, Write, Bash+Delegiert an alle Subagenten+Prüft Zwischenergebnisse-Führt keine eigene Recherche durch-Erstellt keine Inhalteblog_scanner+Werkzeuge: WebFetch, WebSearch+Ruft Hersteller-Blogs ab+Gleicht gegen seen-posts.json ab-Kein Edit-Zugriff-Keine Bewertung der Relevanztrend_analyst+Werkzeuge: Read, Write, WebSearch+Gruppiert Beiträge thematisch+Priorisiert genau ein Thema-Erstellt keinen Beitragstextblog_writer+Werkzeuge: Read, Write, WebFetch+Verfasst den Beitragstext+Verifiziert Details an der Quelle-Führt keine eigene Themenwahl durch

Abbildung 2: Rollenmodell der vier Subagenten. Mit + gekennzeichnete Einträge bezeichnen zugewiesene Fähigkeiten, mit - gekennzeichnete Einträge bewusst ausgeschlossene Zuständigkeiten.

4. Ablauf

Die Verarbeitungspipeline ist strikt sequenziell konzipiert; eine Parallelisierung der Phasen ist aufgrund bestehender Abhängigkeiten nicht vorgesehen. Die Trend-Analyse benötigt die Ergebnisse des Scans als Eingabe, der Blog-Writer benötigt wiederum die Ergebnisse der Trend-Analyse. Eine gleichzeitige Ausführung der Phasen wäre demnach mit dem Risiko inkonsistenter Zwischenzustände verbunden.

Abbildung 3 zeigt den zeitlichen Ablauf eines vollständigen Pipeline-Durchlaufs einschließlich der Abbruchbedingung in Phase 1:

data/ (Dateisystem)blog-writertrend-analystblog-scannerorchestratorNutzerdata/ (Dateisystem)blog-writertrend-analystblog-scannerorchestratorNutzeralt[keine neuen Beiträge][neue Beiträge vorhanden]/scan-ai-newsdelegiert Phase 1 (Scan)liest seen-posts.jsonruft Google, OpenAI, NVIDIA abschreibt scan-result-*.jsonZusammenfassung (Anzahl neuer Beiträge)Abbruch, kein neuer Inputdelegiert Phase 2 (Trendanalyse)liest scan-result-*.jsongruppiert, gewichtet, priorisiertschreibt trend-analysis-*.jsonZusammenfassung (Thema + Begründung)delegiert Phase 3 (Texterstellung)liest trend-analysis-*.jsonverfasst Beitragschreibt output/posts/*.mdDateipfad + Titelaktualisiert seen-posts.jsonAbschlussbericht

Abbildung 3: Zeitlicher Ablauf der Pipeline. Die Aktualisierung der Tracking-Datei erfolgt erst nach erfolgreichem Abschluss von Phase 3.

Phase 1 — Scan. Der Orchestrator delegiert an den blog-scanner unter Übergabe des Pfads zur Tracking-Datei. Der Scanner prüft sämtliche drei Quellen, gleicht die Ergebnisse mit bereits erfassten URLs ab und dokumentiert neu identifizierte Beiträge in strukturierter Form. Werden keine neuen Beiträge ermittelt, wird die Pipeline an dieser Stelle abgebrochen, da eine Fortsetzung ohne neuen Eingabedaten nicht sinnvoll wäre.

Phase 2 — Trendanalyse. Der Orchestrator übergibt das Scan-Ergebnis an den trend-analyst. Dieser gruppiert die Beiträge thematisch, gewichtet herstellerübergreifende Signale stärker als Einzelmeldungen und priorisiert ein Thema unter Angabe einer Begründung.

Phase 3 — Texterstellung. Der Orchestrator übergibt die Themenpriorisierung an den blog-writer, welcher daraus den abschließenden Beitrag erstellt.

Abschluss. Die Tracking-Datei wird vom Orchestrator erst nach erfolgreichem Abschluss der dritten Phase aktualisiert. Eine frühere Aktualisierung — etwa unmittelbar nach dem Scan — würde bei einem Abbruch in Phase 2 oder 3 dazu führen, dass die betreffenden Beiträge als verarbeitet gelten, obwohl kein Beitrag aus ihnen entstanden ist.

Ein für die Funktionsweise des Systems relevanter Aspekt betrifft den Umfang der Rückmeldungen an den Orchestrator: Jeder Agent übermittelt lediglich eine knappe Zusammenfassung seines Ergebnisses — etwa die Anzahl neu gefundener Beiträge sowie den Dateipfad des vollständigen Ergebnisses — anstatt den gesamten Inhalt der jeweiligen Ergebnisdatei in den Konversationskontext zu übertragen. Dies begrenzt den Kontextverbrauch des Orchestrators auch über mehrere aufeinanderfolgende Durchläufe hinweg.

5. Nutzung

Die Inbetriebnahme erfordert das Einbringen des .claude-Verzeichnisses in das Projektverzeichnis sowie den Start von Claude Code. Über den Befehl /agents lässt sich verifizieren, dass alle vier Agenten unter dem Geltungsbereich “Project” registriert sind. Der Ausführung der Pipeline dient anschließend ein einzelner Befehl:

/scan-ai-news

Dieser Befehl initiiert den Orchestrator, welcher die drei beschriebenen Phasen selbsttätig durchläuft. Im Anschluss wird eine Zusammenfassung ausgegeben, die die Anzahl neu gefundener Beiträge je Hersteller, das priorisierte Thema samt Begründung sowie den Speicherort des fertigen Beitrags umfasst — üblicherweise unter dem Pfad output/posts/{datum}-{thema}.md.

Für wiederkehrende Ausführungen kann derselbe Befehl mittels Cron in Verbindung mit dem nicht-interaktiven Modus von Claude Code automatisiert werden. Da sich die entsprechende Syntax zwischen Versionen unterscheiden kann, wird vor einem produktiven Einsatz die Konsultation der aktuellen CLI-Dokumentation empfohlen.

6. Schlussbetrachtung

Das beschriebene System ist bewusst auf einen minimalen Funktionsumfang beschränkt: vier Agenten, eine Tracking-Datei, ein Befehl. Vor der Heranziehung komplexerer Koordinationsmechanismen — etwa Agent-Teams mit geteilten Aufgabenlisten oder externer Orchestrierungs-Frameworks — erscheint die Prüfung angezeigt, ob sich die zugrundeliegende Aufgabe nicht bereits als Abfolge klar abgegrenzter, sequenzieller Schritte modellieren lässt. Im vorliegenden Fall traf dies zu. Jeder Agent erfüllt eine einzelne Funktion, verfügt über die dafür erforderlichen Werkzeuge und übergibt sein Ergebnis dateibasiert an die nachfolgende Phase. Eine darüber hinausgehende architektonische Komplexität wäre für die gestellte Aufgabe nicht erforderlich gewesen.