--- type: types/concept.md concept_type: workflow tags: [multi-agent, collaboration, sync, coordination] created: 2026-07-26 modified: 2026-08-29 related: [LLM Wiki Pattern, Memory Lifecycle, Mesh Sync, Shared vs Private, Work Coordination] sources: [Source - LLM Wiki v2] confidence: 0.85 confidence_base: 0.85 provenance: sourced summary: Wissensmanagement mit mehreren Agenten; erweitert das LLM-Wiki-Muster um Mesh Sync, die Trennung von geteiltem und privatem Wissen und leichtgewichtige Arbeitskoordination. --- # Multi-Agent Collaboration **Typ:** Workflow (Multi-Agent Knowledge Management) ## Definition Multi-Agent Collaboration behandelt die Realität, dass viele praktische Anwendungsfälle **mehrere Agenten oder mehrere Menschen** beinhalten, die zur gleichen Knowledge Base beitragen. Das ursprüngliche LLM-Wiki-Pattern ist Single-User, Single-Agent; v2 erweitert es auf Kollaborationsszenarien. ## Kernpunkte ### Das Problem Single-Agent-Annahmen scheitern, wenn: - Mehrere Agenten parallel arbeiten (verschiedene Coding-Sessions, Recherchethreads) - Mehrere Menschen zur gleichen Knowledge Base beitragen - Wissen über Sessions oder Benutzer hinweg geteilt werden muss - Koordination erforderlich ist, um doppelte Arbeit zu verhindern ### Die Lösung: Drei Komponenten **1. Mesh Sync** Wenn mehrere Agenten parallel arbeiten, müssen ihre Beobachtungen in ein gemeinsames Wiki zusammengeführt werden: - **Standardstrategie:** Last-Write-Wins in den meisten Fällen - **Konfliktauflösung:** Zeitstempel-basiert mit manueller Anpassung - **Merge-Strategie:** - Kein Konflikt: Beide Aktualisierungen akzeptieren - Konflikt: Neuere bevorzugen oder zur menschlichen Überprüfung kennzeichnen - Semantischer Konflikt: [[Contradiction Resolution]] auslösen **Implementierung:** ``` Agent A writes: "API rate limit is 100 req/min" (timestamp: 10:00:00) Agent B writes: "API rate limit is 100 req/min" (timestamp: 10:00:05) Result: Accept B (last-write-wins, no conflict) Agent A writes: "API rate limit is 100 req/min" (timestamp: 10:00:00) Agent B writes: "API rate limit is 200 req/min" (timestamp: 10:00:05) Result: Flag for human review (conflict) ``` **2. Shared vs. Private Knowledge** Nicht alles Wissen sollte gleichermaßen geteilt werden: | Bereich | Beschreibung | Beispiel | |-------|-------------|---------| | **Private** | Persönliche Beobachtungen, Vorlieben, Workflows | "Mein bevorzugter Editor ist VS Code" | | **Shared** | Team-/Projektwissen, Entscheidungen, Architektur | "Projekt X verwendet Redis zum Caching" | **Promotionsmodell:** - Mit privaten Beobachtungen beginnen - Zu Shared promovieren, wenn: - Information über mehrere Agenten überprüft ist - Information allgemein nützlich ist (nicht persönlich) - Mensch explizit als Shared markiert **3. Work Coordination** Einfache Koordination, um doppelte Arbeit zu verhindern und Fortschritt zu verfolgen: **Verfolgung:** - Wer arbeitet an was - Was ist blockiert (und warum) - Was ist fertig - Was braucht Überprüfung **Implementierung:** - Statusfeld auf Seiten: `in-progress`, `blocked`, `done`, `needs-review` - Zuständigkeitsfeld: Welcher Agent/welche Person ist verantwortlich - Blockierungsbeziehungen: Seite A blockiert Seite B **Kein vollständiges Task-Management-System** - nur genug, um doppelte Arbeit zu verhindern. ## Implementierung Basierend auf [[Agent Memory]]-Erfahrung: 1. **Mesh Sync aktivieren** mit Konfliktauflösung 2. **Scoping implementieren** (privat vs. geteilt) 3. **Einfache Koordinationsfelder** zu Seiten hinzufügen 4. **Mit [[Event-Driven Automation]]** für Sync-Trigger integrieren 5. **Alle Multi-Agent-Operationen** in [[Audit Trail]] protokollieren ## Vorteile - **Kollaboration:** Mehrere Agenten können zur gleichen Knowledge Base beitragen - **Effizienz:** Verhindert doppelte Arbeit - **Flexibilität:** Unterstützt sowohl persönliches als auch Team-Wissen - **Skalierbarkeit:** Funktioniert mit beliebig vielen Agenten - **Transparenz:** Klare Sicht darauf, wer was tut ## Wann zu verwenden - Team-Umgebungen mit mehreren Benutzern - Multi-Agent-Setups (parallele Recherche, Coding, etc.) - Gemeinsame Knowledge Bases - Situationen, die Koordination erfordern ## Wann NICHT zu verwenden - Single-User, Single-Agent-Szenarien - Situationen, in denen Einfachheit wichtiger ist als Kollaboration - Sehr kleine Knowledge Bases ## Verwandte Concepts - [[LLM Wiki Pattern]] - Gesamtmuster - [[Mesh Sync]] - Der Synchronisationsmechanismus - [[Shared vs Private]] - Der Scoping-Mechanismus - [[Work Coordination]] - Der Koordinationsmechanismus - [[Event-Driven Automation]] - Für Sync-Trigger - [[Audit Trail]] - Zur Verfolgung von Multi-Agent-Operationen ## Siehe auch - [[Privacy and Governance]] (für Zugriffskontrolle) - [[Quality and Self-Correction]] (zur Aufrechterhaltung der Qualität in kollaborativen Einstellungen)