Chemenu 2.1.0 - deterministischer Wissenskompiler
CI / verify (push) Failing after 32s
Release / release (push) Successful in 38s

Chemenu kompiliert Rohnotizen zu einem verlinkten, quellengebundenen Wiki:
raw/ -> types/ + tools/ -> kb/ -> reports/. Was mechanisch ist, macht
tools/wikitool; was Urteil braucht, macht ein Agent unter Contracts, deren
Grenzen in Code durchgesetzt sind statt im Prompt.

Dieser Commit ist der Startpunkt der oeffentlichen Historie. Die vorherige
Entwicklung fand in einer privaten Instanz statt und ist nicht Teil dieses
Repositorys; ihre Erzaehlung steht vollstaendig in CHANGES.md, das mit 44
Eintraegen von 0.1.0 bis 2.1.0 erhalten geblieben ist.

Der mitgelieferte Korpus ist ein Testbett und eine Demo: 170 Seiten ueber den
Stack selbst - Gates, Lint, Versionierung, Suche, das Wiki-Muster. Er
dokumentiert das Werkzeug mit den eigenen Mitteln des Werkzeugs.

Lizenz: AGPL-3.0 fuer den Stack (tools/, types/), CC-BY-4.0 fuer die Inhalte.
Die Grenze zwischen beiden ist der Dateiplan, den dist export berechnet -
siehe NOTICE.
This commit is contained in:
2026-09-01 16:24:34 +02:00
commit 18ae28f918
368 changed files with 50628 additions and 0 deletions
+129
View File
@@ -0,0 +1,129 @@
---
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)