Personas Übersicht

Erfahren Sie, wie KI-Personas in CodeCourier es Ihnen ermöglichen, spezialisierte, wiederverwendbare Agentenidentitäten mit individuellen Tools, Modellen, Anweisungen, Skills, Commands, Scripts und Kontext-Bindungen für jede Phase Ihres Entwicklungs-Workflows zu konfigurieren.

8 min Lesezeit
personasai-agentsconfiguration

Personas sind eines der mächtigsten Konzepte in CodeCourier. Eine Persona ist eine benannte, wiederverwendbare KI-Agentenkonfiguration, die exakt definiert, wie sich ein Agent verhält, wenn er an einer Workflow-Ausführung oder Sandbox-Sitzung teilnimmt. Jede Persona legt das zu verwendende CLI-Tool, das Modell, die Denkleistung, benutzerdefinierte Anweisungen, verfügbare Skills, eingespielte Commands und Scripts sowie optional ein gebundenes Kontext-Dokument fest. Durch das Erstellen zweckgebauter Personas wechseln Sie von Ad-hoc-Prompting zu einem systematischen, wiederholbaren Ansatz für KI-gestützte Entwicklung.

Warum Personas wichtig sind

Ohne Personas startet jede Workflow-Ausführung bei null. Sie müssten jedes Mal manuell das Modell festlegen, System-Prompts schreiben und Tools konfigurieren. Personas lösen dies, indem sie all diese Entscheidungen in einer wiederverwendbaren Identität kapseln, auf die projektweit per Name verwiesen werden kann.

Stellen Sie sich ein reales Szenario vor: Ihr Team hat einen Coding-Standard, der gründliche Typsicherheit fordert, funktionale Muster bevorzugt und vor dem Commit stets ESLint ausführt. Statt diese Vorgaben in jedem Prompt zu wiederholen, erstellen Sie eine “Senior TypeScript Designer”-Persona mit diesen Regeln in den Anweisungen. Jeder Workflow, der diese Persona verwendet, erbt automatisch dasselbe Verhalten.

Projektbezogen

Personas sind auf ein Projekt beschränkt. Jedes Projekt führt eigene Personas, sodass verschiedene Projekte vollständig unterschiedliche Agentenkonfigurationen besitzen können, ohne sich gegenseitig zu beeinflussen.

Persona-Typen

Jede Persona hat einen Typ, der ihre Rolle innerhalb einer Workflow-Pipeline bestimmt. CodeCourier definiert zehn Persona-Typen, jeder für eine bestimmte Phase des Entwicklungsprozesses ausgelegt:

Designer

Der primäre Coding-Agent. Designer erhalten einen Task-Prompt und setzen ihn direkt in der Sandbox-Umgebung um. Sie schreiben Code, erstellen Dateien, installieren Abhängigkeiten und liefern das eigentliche Ergebnis. Die meisten Workflows beginnen mit einem Designer-Schritt.

Checker

Ein verdiktbasierter Review-Agent, der die Ausgabe des Designers bewertet. Checker prüfen Code-Änderungen, führen ggf. Tests aus und erstellen ein Pass/Fail-Verdikt mit Feedback. Schlägt ein Checker die Arbeit ab, kann der Designer in eine neue Iteration zurückkehren und basierend auf dem Feedback nachbessern - eine Design-Check-Schleife, die die Qualität automatisch verbessert.

Optimizer

Ein spezialisierter Agent für Refactoring und Performance-Verbesserungen. Optimizer nehmen bestehenden Code und verbessern ihn, ohne die Funktionalität zu verändern. Sie suchen nach Möglichkeiten, Duplikate zu reduzieren, die Lesbarkeit zu erhöhen, die Bundle-Größe zu optimieren und Best Practices anzuwenden.

Prompter

Ein Prompt-Engineering-Agent, der vage, informelle Anweisungen in klare, strukturierte Prompts mit expliziten Akzeptanzkriterien überführt. Einen Prompter vor einem Designer-Schritt laufen zu lassen, kann die Qualität der resultierenden Umsetzung erheblich verbessern, indem der Designer eindeutige Anweisungen erhält.

Investigator

Ein Recherche-Agent, der die Codebasis gründlich analysiert, um ein Problem oder eine Anforderung zu verstehen, bevor mit der Umsetzung begonnen wird. Investigatoren erkunden Dateistrukturen, lesen vorhandenen Code, verfolgen Abhängigkeiten und erstellen eine Zusammenfassung der Erkenntnisse, die nachfolgende Agenten als Kontext nutzen können.

Planner

Ein Architektur-Agent, der Codebasen analysiert und strukturierte Bewertungen erstellt. Der Planner sichtet die Codebasis, identifiziert Probleme und Arbeitspakete und liefert umsetzbare Ergebnisse, die Schritt für Schritt abgearbeitet werden können. Dieser Typ treibt die dedizierten Issue-Sitzungen von CodeCourier an.

Deep-Dive

Ein intensiver Analyse-Agent, ausgelegt für komplexe, vielschichtige Probleme, die ein tiefes Verständnis der Codebasis erfordern. Der Deep-Dive-Typ ähnelt dem Investigator, ist aber umfassender im Umfang - er wird typischerweise für Architekturanalysen, Ursachenforschung über mehrere Subsysteme hinweg oder übergreifende Belange eingesetzt, bei denen ein oberflächlicher Scan kritische Abhängigkeiten übersehen würde. Deep-Dive-Sitzungen laufen in der Regel länger und mit höherer Denkleistung als Standard-Investigator-Sitzungen.

Reviewer

Ein spezialisierter Code-Review-Agent mit Fokus auf Sicherheit, Wartbarkeit und Design-Muster. Der Reviewer unterscheidet sich fundamental vom Checker: Er erzeugt keine Pass/Fail-Verdikte. Stattdessen liefert er detailliertes, nuanciertes Review-Feedback - Beobachtungen, Vorschläge, Bedenken und Lob - auf das ein Mensch oder ein nachfolgender Agent reagieren kann. Verwenden Sie den Reviewer-Typ, wenn Sie reichhaltiges qualitatives Feedback statt eines binären Gates wünschen.

Custom

Ein freier Typ für Personas, die in keine der Standardkategorien passen. Der Custom-Typ stellt keine strukturellen Erwartungen an das Verhalten des Agenten - er verhält sich exakt so, wie es seine Anweisungen, Skills und sein Kontext vorgeben. Verwenden Sie diesen Typ für hochspezialisierte Agenten wie Dokumentations-Autoren, Migrationsassistenten, Changelog-Generatoren oder jede andere Rolle, die maximale Flexibilität ohne Konformität zu einem vordefinierten Archetyp erfordert.

Den richtigen Typ wählen

Wählen Sie im Zweifel den Typ, der dem primären Output Ihres Agenten am nächsten kommt. Schreibt er Code, nehmen Sie designer. Analysiert er tief, nehmen Sie deep-dive oder investigator. Erzeugt er qualitatives Review-Feedback ohne Verdikt, nehmen Sie reviewer. Passt nichts, nehmen Sie custom.

Wie Personas mit Workflows zusammenhängen

Workflows in CodeCourier sind Sequenzen von Schritten, und jeder Schritt kann von einer Persona angetrieben werden. Der Workflow-Typ Persona Pipeline ist genau dafür ausgelegt: Sie wählen eine Sequenz von Personas, und jede führt der Reihe nach in derselben Sandbox-Umgebung aus. Die Ausgabe einer Persona wird zum Kontext der nächsten.

Eine Persona-Pipeline könnte beispielsweise so aussehen:

  1. Investigator-Persona analysiert die Codebasis und dokumentiert die relevante Architektur
  2. Prompter-Persona schreibt die Nutzeranfrage in eine detaillierte technische Spezifikation um
  3. Designer-Persona implementiert das Feature auf Basis des verfeinerten Prompts
  4. Checker-Persona prüft die Umsetzung und genehmigt sie oder fordert Änderungen
  5. Optimizer-Persona räumt den finalen Code auf und refaktorisiert ihn

Jeder Schritt in dieser Pipeline nutzt eine andere Persona, potenziell mit anderem Modell, anderen Skills, anderen eingespielten Commands und Scripts sowie auf die Rolle zugeschnittenen Anweisungen.

Wie Personas mit Sandboxes zusammenhängen

Wenn eine Workflow-Ausführung läuft, wird jeder Persona-Schritt einer Sandbox zugewiesen. Die Sandbox stellt eine isolierte E2B-Cloud-Umgebung mit vollem Linux-Dateisystem, Internetzugang und installierten CLI-Tools bereit. Die Konfiguration der Persona bestimmt, welches CLI-Tool in der Sandbox läuft (Claude Code, OpenCode, Codex oder andere) und wie sich dieses Tool verhält (Modell, Anweisungen, Skills, Commands, Scripts und Kontext).

Run-Schritte in der Datenbank protokollieren, welche Persona jeden Schritt ausgeführt hat, und ermöglichen so persona-spezifische Analysen wie Erfolgsraten, durchschnittliche Iterationen, Kostenaufschlüsselungen, Qualitäts-Scores im Zeitverlauf und Aktivitätstimelines.

Fähigkeiten

Personas können konfiguriert werden mit:

  • CLI-Tool-Auswahl - Wahl zwischen Claude Code, OpenCode, Codex oder anderen unterstützten Tools
  • Modellauswahl - Wahl des spezifischen LLM-Modells (z. B. claude-opus-4-6, claude-sonnet-4-6)
  • Denkleistung - Steuerung der Reasoning-Tiefe (low, medium, high, max)
  • Benutzerdefinierte Anweisungen - Freitext zur Steuerung des Agentenverhaltens
  • Skill-Zuweisung - Auswahl der verfügbaren Skills (Domänenwissens-Pakete)
  • Command-Injektion - Auswahl von Shell-Commands und Aliassen, die in die Sandbox eingespielt werden
  • Script-Injektion - Auswahl ausführbarer Scripts, die in die Sandbox eingespielt werden
  • Kontextbindung - Bindung eines Kontext-Dokuments, dessen aktive Version der Sandbox-Konfiguration vorangestellt wird
  • Learnings-Injektion - Umschalten, ob kompilierte Learnings aus vergangenen Runs eingespielt werden
  • Aktivierungs-Toggle - Temporäres Deaktivieren einer Persona ohne sie zu löschen

Personas steuern nicht Sandbox-Infrastrukturparameter wie Speicher, CPU oder Timeout - diese werden auf Workflow- oder Run-Ebene konfiguriert.

Persona-Versionierung

Personas verfügen über ein eingebautes Versionierungssystem. Jedes Mal, wenn Sie wesentliche Änderungen an Konfiguration oder Anweisungen einer Persona speichern, wird eine neue Version erstellt, statt die vorherige zu überschreiben. Jeder Versionsdatensatz enthält eine version-Nummer, eine parentPersonaId, die auf die Vorgängerversion zeigt, und ein isLatest-Flag, das anzeigt, ob es sich um die aktuell aktive Version handelt.

Dadurch können Sie sicher an den Anweisungen einer Persona iterieren und jederzeit auf eine frühere Version zurücksetzen, falls eine Änderung schlechtere Ergebnisse liefert. Der Versionsverlauf ist auf der Persona-Detailseite sichtbar, inklusive Diff-Ansicht zum Seite-an-Seite-Vergleich.

Aktive Version

Nur die Version mit isLatest: true wird in neuen Workflow-Ausführungen verwendet. Ältere Versionen werden zu Audit- und Rollback-Zwecken aufbewahrt, nehmen aber nicht an neuen Sitzungen teil, sofern sie nicht zur aktuellen Version befördert werden.

Nächste Schritte