rechtes Gehirn“ verpasst

(github.com/sleeplesshan)

3 Punkte von sleeplesshan 17 시간 전 | Noch keine Kommentare. | Auf WhatsApp teilen

Hallo. Während ich Codex oder Claude Code in letzter Zeit praktisch im Arbeitsalltag einsetze, möchte ich Dual-Brain vorstellen, ein als Open Source entwickeltes Erweiterungs-Skill-Protokoll, das Probleme reduzieren soll, bei denen ein LLM beim Schreiben komplexen Codes leicht überlastet wird oder frühere Entscheidungen wieder zurücknimmt.

Dual-Brain verteilt der AI nicht einfach Rollen wie „PM / Entwickler / QA“, sondern trennt eher die Denkfunktionen, mit denen ein Problem betrachtet wird.

Ein einzelner Agent gibt nicht sofort eine Antwort aus, sondern wird dazu gezwungen, nacheinander ein kontextuelles Hinterfragen in der Rolle des rechten Gehirns und eine logische Prüfung in der Rolle des linken Gehirns zu durchlaufen; danach setzt der Orchestrator das Endergebnis zusammen.

1. Drei Fehlermodi bei der Ausführung eines einzelnen herkömmlichen Agenten

Wenn man einem LLM im Terminal komplexes Architekturdesign oder Refactoring auf einmal überträgt, begegnet man meist häufig den folgenden Problemen.

Die Falle, den Wortlaut wörtlich zu nehmen
Mehrdeutige Anforderungen werden unverändert akzeptiert, und anschließend wird selbstbewusst völlig unpassender Code gebaut.
Die Hölle der Details
Man vergräbt sich in mikroskopischer Codesyntax und Edge Cases und verpasst dadurch einen einfacheren und besseren architektonischen Weg.
Die Amnesie-Schleife
Nach dem Ende einer Sitzung geht der vorherige Kontext verloren, sodass eine bereits letzte Woche getroffene Architekturrichtung in der nächsten Sitzung wieder umgestoßen wird.

2. Die Lösung: zwei Denkfunktionen

Wenn Dual-Brain geladen wird, übernimmt der Haupt-Agent die Rolle des Orchestrators und antwortet nicht sofort. Stattdessen führt er in einer festgelegten Reihenfolge zwei interne Prüfschritte aus.

Rechtes Gehirn, Right Brain: Kontext / Muster / Hinterfragen
Die Anforderungen des Nutzers werden nicht sofort umgesetzt, sondern zunächst angezweifelt. Es wird gefragt: „Was ist der blinde Fleck dieser Anforderung?“, „Steht sie im Konflikt mit früheren Entscheidungen?“, „Sind die Begriffe nicht mehrdeutig?“.
Linkes Gehirn, Left Brain: Logik / Validierung / Code
Die vom rechten Gehirn erarbeitete Problemdefinition wird mit der tatsächlichen Codebasis, offizieller Dokumentation und dem Projektgedächtnis abgeglichen. Halluzinierte APIs, veraltete Annahmen und nicht implementierbare Entwürfe werden herausgefiltert und in eine umsetzbare Form gebracht.

Am Ende setzt der Orchestrator beide Ergebnisse zusammen und führt dies bis zu Codeänderungen, Dokumentation und Aktualisierung des Speichers fort.

3. Ein System mit Gedächtnis-Stufen

Das Skill speichert Langzeitgedächtnis in .dual-brain/MEMORY.md im Projekt-Root.

Je größer ein Projekt wird, desto eher kann jedoch das Problem entstehen, dass alte Entscheidungen und die aktiven Randbedingungen der letzten Woche mit demselben Gewicht vermischt werden. Um das zu lösen, wird memory nicht als flaches Dokument, sondern als gestuftes memory behandelt.

Hot Memory
Warm Memory
Cold Memory
Archived Decisions

Hot Memory enthält aktive Entscheidungen und Einschränkungen, die die aktuelle Arbeit stark beeinflussen.

Warm Memory ist nützlicher Kontext, der nur bei verwandten Arbeiten gelesen wird.

Cold Memory und Archived Decisions werden standardmäßig nicht vollständig gelesen, sondern nur dann abgefragt, wenn eine Stichwortsuche oder eine Konfliktprüfung nötig ist.

refs erhöht sich nicht einfach dadurch, dass etwas gelesen wurde, sondern nur dann, wenn es tatsächlich Einfluss auf Fragen, Validierung, Synthese oder Implementierung hatte.

Alte oder doppelte Erinnerungen werden automatisch komprimiert, und widersprüchliche oder verworfene Entscheidungen werden nach Archived verschoben.

Sensible Informationen, Tokens, Schlüssel und personenbezogene Daten werden weder gespeichert noch zusammengefasst, sondern als zu entfernende bzw. nicht zu speichernde Inhalte behandelt.

Wichtig ist, dass memory nicht die Quelle der Wahrheit ist. In Dual-Brain ist memory ein advisory context, und aktueller Code sowie offizielle Dokumentation haben Vorrang vor stale memory.

4. Benchmark

Im Repo ist auf Basis von Codex ein kleines Benchmark-Harness enthalten, das den Single-Agent-Ansatz mit dem Dual-Brain-Ansatz vergleicht.

Dual-Brain ist kein schneller Ansatz. Im Gegenteil: Es soll dazu bringen, am Anfang mehr nachzudenken, mit dem Ziel, die Schleife zu verkleinern, in der Menschen später erneut nachbessern und erklären müssen.

5. Installation

Mit SkillsGate kann man das Skill in Codex-CLI- und Claude-Code-Umgebungen installieren und verwalten.

npx skillsgate add sleeplesshan/dual-brain -g  
Eine manuelle Installation ist ebenfalls möglich.  
 - Codex  
Bash  
git clone [https://github.com/sleeplesshan/dual-brain.git](https://github.com/sleeplesshan/dual-brain.git) ~/.codex/skills/dual-brain  
 - Claude Code  
Bash  
git clone [https://github.com/sleeplesshan/dual-brain.git](https://github.com/sleeplesshan/dual-brain.git) ~/.claude/skills/dual-brain  
Nach der Installation kann es wie gewohnt per natürlicher Sprache aufgerufen werden.  
  
6. Wann ist es sinnvoll?  
Für einfache Änderungen ist Dual-Brain überdimensioniert. Für Umbenennungen von Variablen, Ein-Zeilen-Bugfixes oder klares Boilerplate muss man es nicht extra verwenden.  
Stattdessen passt es gut zu folgenden Situationen.  
- Refactorings mit unklaren Anforderungen  
- Architekturentscheidungen  
- Integration unbekannter APIs oder SDKs  
- Änderungen, die mit früheren Entscheidungen kollidieren könnten  
- Arbeiten, bei denen halluzinierte APIs zu realen Störungen führen könnten  
- Arbeiten, bei denen man denkt: „Ich weiß nicht einmal, ob ich gerade die richtige Frage stelle“  
  
Als Open Source (MIT-Lizenz) habe ich das vollständige `SKILL.md` und das Benchmark-Harness veröffentlicht.  
 Ich würde mich über Feedback von Menschen freuen, die sich für LLM orchestration, prompt engineering und das Design von agent memory interessieren.