Tmux für KI-Agenten: Vorlagen 2026

Tmux für die Orchestrierung von KI-Agenten: Parallele Entwicklungsmodelle 2026

Tmux, ursprünglich 2007 als Client-Server-Terminal-Multiplexer veröffentlicht, ist heute das Tool der Wahl für mittlere bis erfahrene Entwickler, die 4–8 parallele KI-Agenten wie Claude Code, Codex CLI oder Gemini CLI verwalten. Anstatt auf GUI-Wrappers zu setzen, nutzen Teams reine Bash-Skripte und Tmux-Fenster – jeweils einem Agent oder Git-Worktree gewidmet. Dieser Ansatz vermeidet Kontextverlust, Git-Konflikte und kognitive Überlastung. Wir untersuchen drei bewährte Muster aus Hacker News: Feature-Designs, Agent-Forking und Worktree-Integration.

Das Feature-Designs-Muster: Markdown-Pläne + Executor-Agenten

Manuel Schipper (Senior AI Engineer, Snowflake) delegiert 90 % seiner Programmierarbeit an KI-Agenten mithilfe strukturierter Markdown-Spezifikationen namens Feature-Designs (FD). Jedes Tmux-Fenster übernimmt eine spezifische Rolle:

• Planer: erstellt FDs aus Problemformulierungen.
• Arbeiter: implementiert Funktionen basierend auf FDs.
• PM: verwaltet die Aufgabenliste.

FDs werden nummeriert (z. B. FD-001…), in docs/features/ gespeichert und folgendermaßen strukturiert:

• Problem: klare Beschreibung der Herausforderung.
• Lösungen: mehrere Optionen mit Trade-offs (Vor- und Nachteile).
• Ausgewählte Lösung: Implementierungsplan und Dateiliste.
• Verifikation: Schritte zur Validierung der Korrektheit.

Beispiel FD-051:

FD-051: Mehrfachlabel-Klassifikation von Dokumenten
Status: Offen
Priorität: Mittel
Aufwand: Mittel
Wirkung: Bessere Erinnerung

## Problem
Eingehende Dokumente erhalten nur eine Kategorie, obwohl viele mehrere Themen abdecken.

## Lösung
1. LLM-Vertrauenswerte für jede Kategorie.
2. Akzeptiere >0,90.
3. Zweitdurchlauf für 0,50–0,90.
4. Speicher mit Scores.

## Dateien
- src/classify/multi_label.py
- src/classify/prompts.py
- sql/01_schema.sql

## Verifikation
1. Testlauf im Staging.
2. Gesundheitschecks.
3. Spot-Check.

Lebenszyklus: Geplant → Design → Offen → In Bearbeitung → Auf Verifikation wartend → Abgeschlossen. Automatisierung durch sechs Slash-Befehle:

• /fd-new: erstellt ein neues FD.
• /fd-status: zeigt eine Übersicht aller FDs.
• /fd-explore: lädt den Kontext in die aktuelle Sitzung.
• /fd-deep: startet vier parallele Agenten (Algorithmen/Struktur/Increment/Umgebung).
• /fd-verify: überprüft und committet Änderungen.
• /fd-close: archiviert abgeschlossene FDs.

/fd-deep nutzt Prinzipien des Testzeit-Computings, indem vier Agenten gleichzeitig laufen, um Ideen zu generieren. Über Monate entstehen so über 300 FDs. Initialisierung: /fd-init setzt die gesamte Infrastruktur auf.

Gegenüber: Agenten komprimieren den Kontext und verlieren feine Details – Schipper schreibt manuell Checkpoints in Markdown, um Klarheit zu bewahren.

Agent-Forking-Muster: Kontextspezifische Forks

Kaushik Gopal (Principal Engineer, Instacart) schlägt ein Planlos-Fork-Modell vor. In der aktuellen Sitzung fängt man den Pane-Buffer (tmux capture-pane), umschließt ihn mit <context> und startet ihn in einem neuen Fenster.

Das Bash-Skript ist minimal und tool-agnostisch: Fork von Claude zu Gemini zur Diagrammerstellung. Interaktiv kopiert man benötigte Inhalte manuell zurück.

Vorteile:

• Geringer Overhead – nur bei Bedarf forken.
• Cross-Agent-Workflow: Codex → Claude → Gemini.

Nachteile:

• Keine Auto-Merge-Funktion.
• Lange Forks (>1 Stunde) bergen Risiko einer Desynchronisation mit dem Hauptbranch.

Anwendungsfall: Exploration von Nebenhypothese oder parallele Tests. Skript verfügbar auf Gist – nur 20 Zeilen.

Git Worktree + Tmux: Verzeichnisisolierung

Syo Ito löst Git-Konflikte, indem er jedem Agenten ein eigenes Git-Worktree zuweist und jedem Worktree ein Tmux-Fenster. Die Fensternamen entsprechen den Worktree-Namen.

Pane-Chaos vermeiden: keine Pane-Splitting nach Worktree. Ein Fenster pro Worktree, mit Pane für Shell und Vim.

Werkzeug kage: kage feat-x erstellt ein Worktree, ein Tmux-Fenster und startet Claude Code.

Beispiel agent-worker-Skript:

#!/usr/bin/env bash
set -euo pipefail
WORKTREE_NAME="${1:?}"
FD_NUMBER="${2:?}"
WT_PATH="$(git rev-parse --show-toplevel)/../${WORKTREE_NAME}"

git worktree add "$WT_PATH" -b "feat/${WORKTREE_NAME}"
tmux new-window -n "$WORKTREE_NAME" -c "$WT_PATH" \
  "claude --permission-mode acceptEdits 'implement FD-${FD_NUMBER}'"

Minimaler tmux.conf für Agenten

# Präfix C-a
unbind C-b
set -g prefix C-a
bind C-a send-prefix

# Nummerierung beginnt bei 1
set -g base-index 1
setw -g pane-base-index 1

# Mausunterstützung
set -g mouse on

# Historielänge
set -g history-limit 50000

# Vim-Stil-Pane-Navigation
bind h select-pane -L
bind j select-pane -D
bind k select-pane -U
bind l select-pane -R

set -g renumber-windows on

Wichtige Erkenntnisse

• Maximal 4–8 Agenten: Mehr führt zu sinkender Konzentration und schlechterer Ausgabequalität.
• Git-Worktree zwingend erforderlich: Unverzichtbar bei mehr als drei Agenten.
• Ein Fenster pro Agent: Vermeidet Pane-Ausdehnung, die Navigation stört.
• Manuelle Markdown-Checkpoints: Kompenstieren Verlust an Kontextdetail.
• Bash + Tmux: Keine Abhängigkeiten, vollständig tool-agnostisch.

— Editorial Team