.claude<\/code>-Verzeichnis innerhalb des Projektordners organisiert:<\/p>\n\n\n\n.claude\/\n agents\/\n orchestrator.md\n blog-scanner.md\n trend-analyst.md\n blog-writer.md\n commands\/\n scan-ai-news.md\ndata\/\n seen-posts.json\n scan-result-*.json\n trend-analysis-*.json\noutput\/\n posts\/*.md\n<\/pre>\n\n\n\nDie Struktur gliedert sich in drei funktional getrennte Bereiche. .claude\/agents\/<\/code> enth\u00e4lt die Subagent-Definitionen und bildet damit die eigentliche Programmlogik des Systems. data\/<\/code> fungiert als Kommunikationsschicht zwischen den einzelnen Verarbeitungsphasen: Jede Phase persistiert ihr Ergebnis als JSON-Datei, welche von der nachfolgenden Phase eingelesen wird. output\/posts\/<\/code> enth\u00e4lt die fertiggestellten Blogbeitrags-Dateien als Endprodukt der Pipeline.<\/p>\n\n\n\nAbbildung 1 stellt die Komponenten des Systems und ihre Abh\u00e4ngigkeiten schematisch dar:<\/p>\n\n\n\n
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<\/pre>\n\n\n\nAbbildung 1: Komponenten des Systems, gegliedert nach Steuerungs-, Subagent- und Persistenzebene. Gestrichelte Pfeile kennzeichnen lesenden bzw. nachgelagerten Zugriff.<\/em><\/p>\n\n\n\nDie Entscheidung, Zwischenergebnisse dateibasiert zu persistieren statt sie ausschlie\u00dflich innerhalb des Konversationskontextes zu \u00fcbergeben, beruht auf zwei \u00dcberlegungen. Erstens wird dadurch die Nachvollziehbarkeit der Pipeline sichergestellt: Die Ergebnisse jeder Phase lassen sich unabh\u00e4ngig vom weiteren Verlauf einsehen und \u00fcberpr\u00fcfen. Zweitens erh\u00f6ht sich die Robustheit gegen\u00fcber Abbr\u00fcchen, 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\u00f6mmlichen Software-Systemen, findet bei der Konzeption von KI-gest\u00fctzten Pipelines jedoch vergleichsweise selten Anwendung.<\/p>\n\n\n\n
<\/span>3. Die Agenten<\/span><\/h2>\n\n\n\nDas System umfasst vier Subagenten, denen jeweils eine einzelne, klar abgegrenzte Zust\u00e4ndigkeit zugewiesen ist.<\/p>\n\n\n\n
Orchestrator.<\/strong> Der orchestrator<\/code>-Agent \u00fcbernimmt ausschlie\u00dflich koordinierende Funktionen; er f\u00fchrt selbst keine Recherche durch und erstellt keine Inhalte. Seine Aufgabe besteht darin, die \u00fcbrigen drei Agenten in der korrekten Reihenfolge zu delegieren, deren Zwischenergebnisse auf Plausibilit\u00e4t zu pr\u00fcfen und nach Abschluss der Pipeline eine Zusammenfassung bereitzustellen. Ihm sind die Werkzeuge Task<\/code> (zur Delegation an andere Subagenten), Read<\/code>, Write<\/code> und Bash<\/code> zugeordnet.<\/p>\n\n\n\nBlog-Scanner.<\/strong> Der blog-scanner<\/code>-Agent ruft die drei Hersteller-Blogs mittels WebFetch<\/code> ab und erg\u00e4nzt dies bei Bedarf durch gezielte WebSearch<\/code>-Anfragen. Jeder ermittelte Beitrag wird gegen eine Tracking-Datei bereits verarbeiteter URLs abgeglichen; lediglich neu identifizierte Beitr\u00e4ge flie\u00dfen in das Ergebnis ein. Dem Agenten ist kein Schreibzugriff auf andere Bereiche des Projekts gew\u00e4hrt; er verf\u00fcgt \u00fcber kein Edit<\/code>-Werkzeug.<\/p>\n\n\n\nTrend-Analyst.<\/strong> Der trend-analyst<\/code>-Agent verarbeitet die vom Blog-Scanner identifizierten Beitr\u00e4ge und sucht nach Mustern, die \u00fcber einzelne Hersteller hinausreichen. Ver\u00f6ffentlichen mehrere Hersteller innerhalb desselben Zeitraums zu einem verwandten Thema \u2014 etwa im Bereich agentenbasierter Programmierung oder reasoning-f\u00e4higer Modelle \u2014 wird dies als st\u00e4rkeres Relevanzsignal gewertet als eine isolierte Einzelmeldung. Der Agent priorisiert abschlie\u00dfend genau ein Thema f\u00fcr den nachfolgenden Blogbeitrag; eine Mehrthemigkeit wird aus redaktionellen Gr\u00fcnden ausgeschlossen.<\/p>\n\n\n\nBlog-Writer.<\/strong> Der blog-writer<\/code>-Agent verfasst auf Grundlage der Themenpriorisierung einen ver\u00f6ffentlichungsfertigen Beitrag in Markdown mit Frontmatter, Zwischen\u00fcberschriften und einer abschlie\u00dfenden Quellenliste. Der Agent ist berechtigt, die Originalquellen mittels WebFetch<\/code> erneut abzurufen, um Details zu verifizieren; eine w\u00f6rtliche \u00dcbernahme von Textpassagen ist hierbei ausgeschlossen, s\u00e4mtliche Inhalte sind in eigener Formulierung wiederzugeben.<\/p>\n\n\n\nAllen Agenten ist jeweils nur die f\u00fcr ihre Aufgabe erforderliche Werkzeugmenge zugewiesen, entsprechend dem Prinzip minimaler Berechtigungen. Dies dient nicht ausschlie\u00dflich Sicherheitserw\u00e4gungen, sondern begrenzt auch den funktionalen Wirkungsbereich jedes Agenten auf seine vorgesehene Aufgabe.<\/p>\n\n\n\n
Abbildung 2 fasst die Rollenverteilung, die zugeordneten Werkzeuge sowie die jeweils ausgeschlossenen Zust\u00e4ndigkeiten zusammen:<\/p>\n\n\n\n
Phase 1Phase 2Phase 3orchestrator+Werkzeuge: Task, Read, Write, Bash+Delegiert an alle Subagenten+Pr\u00fcft Zwischenergebnisse-F\u00fchrt 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\u00e4ge thematisch+Priorisiert genau ein Thema-Erstellt keinen Beitragstextblog_writer+Werkzeuge: Read, Write, WebFetch+Verfasst den Beitragstext+Verifiziert Details an der Quelle-F\u00fchrt keine eigene Themenwahl durch<\/pre>\n\n\n\nAbbildung 2: Rollenmodell der vier Subagenten. Mit +<\/code> gekennzeichnete Eintr\u00e4ge bezeichnen zugewiesene F\u00e4higkeiten, mit -<\/code> gekennzeichnete Eintr\u00e4ge bewusst ausgeschlossene Zust\u00e4ndigkeiten.<\/em><\/p>\n\n\n\n<\/span>4. Ablauf<\/span><\/h2>\n\n\n\nDie Verarbeitungspipeline ist strikt sequenziell konzipiert; eine Parallelisierung der Phasen ist aufgrund bestehender Abh\u00e4ngigkeiten nicht vorgesehen. Die Trend-Analyse ben\u00f6tigt die Ergebnisse des Scans als Eingabe, der Blog-Writer ben\u00f6tigt wiederum die Ergebnisse der Trend-Analyse. Eine gleichzeitige Ausf\u00fchrung der Phasen w\u00e4re demnach mit dem Risiko inkonsistenter Zwischenzust\u00e4nde verbunden.<\/p>\n\n\n\n
Abbildung 3 zeigt den zeitlichen Ablauf eines vollst\u00e4ndigen Pipeline-Durchlaufs einschlie\u00dflich der Abbruchbedingung in Phase 1:<\/p>\n\n\n\n
data\/ (Dateisystem)blog-writertrend-analystblog-scannerorchestratorNutzerdata\/ (Dateisystem)blog-writertrend-analystblog-scannerorchestratorNutzeralt[keine neuen Beitr\u00e4ge][neue Beitr\u00e4ge vorhanden]\/scan-ai-newsdelegiert Phase 1 (Scan)liest seen-posts.jsonruft Google, OpenAI, NVIDIA abschreibt scan-result-*.jsonZusammenfassung (Anzahl neuer Beitr\u00e4ge)Abbruch, kein neuer Inputdelegiert Phase 2 (Trendanalyse)liest scan-result-*.jsongruppiert, gewichtet, priorisiertschreibt trend-analysis-*.jsonZusammenfassung (Thema + Begr\u00fcndung)delegiert Phase 3 (Texterstellung)liest trend-analysis-*.jsonverfasst Beitragschreibt output\/posts\/*.mdDateipfad + Titelaktualisiert seen-posts.jsonAbschlussbericht<\/pre>\n\n\n\nAbbildung 3: Zeitlicher Ablauf der Pipeline. Die Aktualisierung der Tracking-Datei erfolgt erst nach erfolgreichem Abschluss von Phase 3.<\/em><\/p>\n\n\n\nPhase 1 \u2014 Scan.<\/strong> Der Orchestrator delegiert an den blog-scanner<\/code> unter \u00dcbergabe des Pfads zur Tracking-Datei. Der Scanner pr\u00fcft s\u00e4mtliche drei Quellen, gleicht die Ergebnisse mit bereits erfassten URLs ab und dokumentiert neu identifizierte Beitr\u00e4ge in strukturierter Form. Werden keine neuen Beitr\u00e4ge ermittelt, wird die Pipeline an dieser Stelle abgebrochen, da eine Fortsetzung ohne neuen Eingabedaten nicht sinnvoll w\u00e4re.<\/p>\n\n\n\nPhase 2 \u2014 Trendanalyse.<\/strong> Der Orchestrator \u00fcbergibt das Scan-Ergebnis an den trend-analyst<\/code>. Dieser gruppiert die Beitr\u00e4ge thematisch, gewichtet hersteller\u00fcbergreifende Signale st\u00e4rker als Einzelmeldungen und priorisiert ein Thema unter Angabe einer Begr\u00fcndung.<\/p>\n\n\n\nPhase 3 \u2014 Texterstellung.<\/strong> Der Orchestrator \u00fcbergibt die Themenpriorisierung an den blog-writer<\/code>, welcher daraus den abschlie\u00dfenden Beitrag erstellt.<\/p>\n\n\n\nAbschluss.<\/strong> Die Tracking-Datei wird vom Orchestrator erst nach erfolgreichem Abschluss der dritten Phase aktualisiert. Eine fr\u00fchere Aktualisierung \u2014 etwa unmittelbar nach dem Scan \u2014 w\u00fcrde bei einem Abbruch in Phase 2 oder 3 dazu f\u00fchren, dass die betreffenden Beitr\u00e4ge als verarbeitet gelten, obwohl kein Beitrag aus ihnen entstanden ist.<\/p>\n\n\n\nEin f\u00fcr die Funktionsweise des Systems relevanter Aspekt betrifft den Umfang der R\u00fcckmeldungen an den Orchestrator: Jeder Agent \u00fcbermittelt lediglich eine knappe Zusammenfassung seines Ergebnisses \u2014 etwa die Anzahl neu gefundener Beitr\u00e4ge sowie den Dateipfad des vollst\u00e4ndigen Ergebnisses \u2014 anstatt den gesamten Inhalt der jeweiligen Ergebnisdatei in den Konversationskontext zu \u00fcbertragen. Dies begrenzt den Kontextverbrauch des Orchestrators auch \u00fcber mehrere aufeinanderfolgende Durchl\u00e4ufe hinweg.<\/p>\n\n\n\n
<\/span>5. Nutzung<\/span><\/h2>\n\n\n\nDie Inbetriebnahme erfordert das Einbringen des .claude<\/code>-Verzeichnisses in das Projektverzeichnis sowie den Start von Claude Code. \u00dcber den Befehl \/agents<\/code> l\u00e4sst sich verifizieren, dass alle vier Agenten unter dem Geltungsbereich “Project” registriert sind. Der Ausf\u00fchrung der Pipeline dient anschlie\u00dfend ein einzelner Befehl:<\/p>\n\n\n\n\/scan-ai-news\n<\/pre>\n\n\n\nDieser Befehl initiiert den Orchestrator, welcher die drei beschriebenen Phasen selbstt\u00e4tig durchl\u00e4uft. Im Anschluss wird eine Zusammenfassung ausgegeben, die die Anzahl neu gefundener Beitr\u00e4ge je Hersteller, das priorisierte Thema samt Begr\u00fcndung sowie den Speicherort des fertigen Beitrags umfasst \u2014 \u00fcblicherweise unter dem Pfad output\/posts\/{datum}-{thema}.md<\/code>.<\/p>\n\n\n\nF\u00fcr wiederkehrende Ausf\u00fchrungen 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.<\/p>\n\n\n\n
<\/span>6. Schlussbetrachtung<\/span><\/h2>\n\n\n\nDas beschriebene System ist bewusst auf einen minimalen Funktionsumfang beschr\u00e4nkt: vier Agenten, eine Tracking-Datei, ein Befehl. Vor der Heranziehung komplexerer Koordinationsmechanismen \u2014 etwa Agent-Teams mit geteilten Aufgabenlisten oder externer Orchestrierungs-Frameworks \u2014 erscheint die Pr\u00fcfung angezeigt, ob sich die zugrundeliegende Aufgabe nicht bereits als Abfolge klar abgegrenzter, sequenzieller Schritte modellieren l\u00e4sst. Im vorliegenden Fall traf dies zu. Jeder Agent erf\u00fcllt eine einzelne Funktion, verf\u00fcgt \u00fcber die daf\u00fcr erforderlichen Werkzeuge und \u00fcbergibt sein Ergebnis dateibasiert an die nachfolgende Phase. Eine dar\u00fcber hinausgehende architektonische Komplexit\u00e4t w\u00e4re f\u00fcr die gestellte Aufgabe nicht erforderlich gewesen.<\/p>\n","protected":false},"excerpt":{"rendered":"
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\u00f6ffentlichungen im Bereich k\u00fcnstlicher Intelligenz. Das System wird ausschlie\u00dflich mit den nativen Subagent-Funktionen von Claude Code realisiert, ohne R\u00fcckgriff auf externe Orchestrierungs-Frameworks wie LangGraph oder…<\/p>\n","protected":false},"author":1,"featured_media":0,"parent":0,"menu_order":0,"comment_status":"closed","ping_status":"closed","template":"","meta":{"footnotes":""},"class_list":["post-1463","page","type-page","status-publish","hentry"],"_links":{"self":[{"href":"https:\/\/programmier-workshops.de\/blog\/wp-json\/wp\/v2\/pages\/1463","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/programmier-workshops.de\/blog\/wp-json\/wp\/v2\/pages"}],"about":[{"href":"https:\/\/programmier-workshops.de\/blog\/wp-json\/wp\/v2\/types\/page"}],"author":[{"embeddable":true,"href":"https:\/\/programmier-workshops.de\/blog\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/programmier-workshops.de\/blog\/wp-json\/wp\/v2\/comments?post=1463"}],"version-history":[{"count":1,"href":"https:\/\/programmier-workshops.de\/blog\/wp-json\/wp\/v2\/pages\/1463\/revisions"}],"predecessor-version":[{"id":1481,"href":"https:\/\/programmier-workshops.de\/blog\/wp-json\/wp\/v2\/pages\/1463\/revisions\/1481"}],"wp:attachment":[{"href":"https:\/\/programmier-workshops.de\/blog\/wp-json\/wp\/v2\/media?parent=1463"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}