agency-agents-zh: 277 Rollenprofile als Prompt-Bibliothek für Coding-Agents

Ein Rollenverzeichnis, kein ausführbares System

Das Repository beschreibt sich selbst als Sammlung von 277 sofort einsetzbaren KI-Expertenrollen, verteilt auf 20 Abteilungen. Der Anspruch grenzt sich ausdrücklich gegen generische Prompt-Vorlagen ab: Jede Rolle soll eine eigene Persona, einen Fachprozess und definierte Ergebnisse mitbringen. Genau dort liegt der Nutzen. Ein Team, das in Cursor, Claude Code und Copilot arbeitet, bekommt mit einer gemeinsamen Rollenbibliothek dieselbe Erwartung an Format und Tiefe einer Antwort, unabhängig davon, welches Werkzeug der einzelne Entwickler geöffnet hat. Das Problem, das gelöst wird, ist also nicht fehlende Modellfähigkeit, sondern Streuung: Jeder schreibt seine eigenen System-Prompts, Ergebnisse sind nicht vergleichbar, und Wissen über gute Rollenbeschreibungen bleibt in privaten Notizen. Die Zielgruppe sind entsprechend Teams, die bereits mehrere Coding-Agents im Einsatz haben und deren Ausgaben vereinheitlichen wollen, nicht Einzelpersonen, die zum ersten Mal ein Modell ansteuern.

Was der Fork gegenüber dem Upstream verändert

Laut README basiert das Projekt auf dem Repository msitarzewski/agency-agents und ist dessen chinesische Community-Version. Die Zahlen im README sind konkret: 277 Agenten insgesamt, davon 213 Übersetzungen aus der englischen Fassung und 64 eigenständige Neuzugänge für den chinesischen Markt. Die Aufteilung ist der interessanteste Teil, weil sie zeigt, wo der Fork echten Zusatzwert hat und wo er nur Sprachfassade ist. Die 213 übersetzten Rollen sind inhaltlich vom Upstream abhängig: Ändert sich dort eine Definition, muss der Fork nachziehen, sonst laufen die Sprachversionen auseinander. Die 64 Originalrollen decken Bereiche ab, die es im englischen Original nicht gibt: Betrieb auf Xiaohongshu, Douyin, WeChat, Bilibili, Feishu und DingTalk, dazu Cross-Border-E-Commerce, ToG-Vertrieb für Behörden, Medizin-Compliance, Qt-basierte industrielle HMI-Software, Maschinenbaukonstruktion und sogar die Prüfung von Viehzucht-Aufzeichnungen. Diese Rollen sind der eigentliche Grund, den Fork statt des Upstreams zu wählen. Wer nur englischsprachige Softwareentwicklung betreibt, findet im Original dieselben Inhalte ohne die doppelte Pflegelast.

Installation: npm-Paket, keine Laufzeit

Das README nennt ein npm-Paket unter dem Namen agency-agents-zh, und die Sprache des Repositories ist Shell. Daraus folgt: Der Kern ist eine Sammlung von Textdateien, die ein Installationsschritt in die Verzeichnisse der jeweiligen Werkzeuge kopiert. Für Claude Code sind das die Projekt- oder Benutzerverzeichnisse, in denen Agenten-Definitionen erwartet werden, für Cursor die Regeldateien, für Copilot die entsprechenden Agent-Konfigurationen. Das README führt 20 unterstützte Werkzeuge auf, benennt aber in der vorliegenden Fassung keine einzelnen Installationsbefehle, keine Konfigurationsschlüssel und keine Verzeichnispfade. Wer das Projekt einsetzen will, muss diese Angaben aus dem npm-Paket selbst oder aus den Dateien im Repository ableiten. Das ist eine echte Lücke in der Dokumentation und kein Detail: Ohne bekannten Zielpfad lässt sich nicht prüfen, ob eine Rolle in einem bestimmten Werkzeug überhaupt geladen wird. Die einzige im README konkret benannte Bezugsquelle jenseits des npm-Pakets ist die Desktop-Anwendung aus dem Repository agency-orchestrator, die als native App für macOS, Windows und Linux ohne Node-Installation angeboten wird.

Der Orchestrator als eigentliche Abhängigkeit

Das README bewirbt den begleitenden Orchestrator mit dem Satz, ein Satz genüge, damit mehrere Experten nach einem DAG automatisch zusammenarbeiten. Damit verschiebt sich der Schwerpunkt: Die 277 Rollen sind einzeln nützlich, ihr Zusammenspiel entsteht aber erst in einem zweiten Projekt. Das ist eine Architekturentscheidung mit Folgen. Wer nur eine Rolle aufruft, braucht den Orchestrator nicht und kann die Prompt-Dateien direkt verwenden. Wer dagegen einen Ablauf aus mehreren Stationen will, etwa Anforderung, Entwurf, Implementierung und Prüfung, hängt von einem separaten Repository ab, das eigene Release-Zyklen hat. Der DAG ist dabei kein Selbstzweck: Er legt fest, welche Rolle wann welche Ausgabe der vorherigen Rolle sieht. Fehlt diese Steuerung, bleibt nur die manuelle Verkettung, bei der ein Entwickler die Ausgabe des einen Agenten in den nächsten kopiert. Das README benennt keine Details zur Orchestrierung selbst, weder zu Abbruchbedingungen noch zur Fehlerbehandlung einzelner Knoten, sodass die Belastbarkeit des Ablaufs aus dem vorliegenden Material nicht beurteilbar ist.

Grenzen: Prompt-Qualität ist nicht überprüfbar

Die zentrale Einschränkung steckt in der Natur der Sache. Ein Repository mit Rollenbeschreibungen liefert keine Tests, keine Messwerte und keine Zusicherung, dass eine Rolle in einem konkreten Modell das gewünschte Ergebnis produziert. Das README macht dazu auch keine Aussage. Wer 277 Rollen einbindet, erhöht zunächst nur die Zahl möglicher Kontexte, nicht die Qualität der Ausgaben. Ein zweiter Punkt betrifft die genannten 20 Werkzeuge: Deren Agent-Mechaniken unterscheiden sich erheblich. Manche laden Markdown-Dateien mit Frontmatter, andere erwarten Regeldateien mit anderer Struktur, wieder andere kennen nur einen einzigen System-Prompt ohne Rollenwechsel. Eine einheitliche Rolle über 20 Werkzeuge hinweg ist deshalb nur so einheitlich wie der kleinste gemeinsame Nenner der Formate. Schließlich die Sprache: Die 213 übersetzten Rollen sind chinesische Fassungen englischer Originale. Bei Fachbegriffen, Namenskonventionen und Beispielen kann eine Übersetzung Bedeutung verschieben. Für Rollen mit Bezug zu westlichen Compliance-Regimen ist der englische Upstream die verlässlichere Quelle.

Alternative: Subagents im Werkzeug selbst

Der naheliegende Vergleich ist die eingebaute Agenten-Funktion moderner Coding-Werkzeuge, etwa Subagents in Claude Code. Der Unterschied liegt im Ansatz, nicht im Umfang. Eine eingebaute Agenten-Definition ist Teil der Laufzeit: Sie kann Werkzeuge aufrufen, Dateien lesen, Befehle ausführen und Ergebnisse an den Hauptkontext zurückgeben. Eine Rolle aus agency-agents-zh ist ein Textdokument, das beschreibt, wie sich das Modell verhalten soll. Das ist der ganze Unterschied, und er ist praktisch relevant. Wer einen Prüf-Agenten braucht, der eigenständig Tests ausführt und Fehlerausgaben zurückmeldet, braucht Werkzeugzugriff und wird mit einer Prompt-Datei nicht weit kommen. Wer dagegen eine einheitliche Tonalität und Struktur für Textausgaben in mehreren Werkzeugen braucht, für den ist eine portable Textdefinition die robustere Wahl, weil sie nicht an eine Laufzeit gebunden ist. Die beiden Ansätze schließen sich nicht aus: Eine Rolle aus diesem Repository lässt sich als Persona in eine Subagent-Definition des jeweiligen Werkzeugs einbetten und gewinnt dadurch Werkzeugzugriff, ohne die Formulierung neu zu erfinden.

Pflegeaufwand und Lizenzlage

Das Repository steht unter der MIT-Lizenz, die kommerzielle Nutzung, Änderung und Weitergabe erlaubt, solange Lizenztext und Urheberrechtshinweis erhalten bleiben. Für ein Unternehmen, das Rollen anpasst und intern verteilt, ist das die einfachste denkbare Ausgangslage. Der Pflegeaufwand liegt woanders: Ein Fork mit 213 übersetzten Rollen erzeugt eine dauerhafte Bringschuld gegenüber dem Upstream. Jede inhaltliche Änderung dort muss übernommen und erneut übersetzt werden, sonst driftet die chinesische Fassung ab. Die Release-Historie zeigt, dass dies aktiv geschieht: Die Versionen v1.2.4 bis v1.2.6 liegen zeitlich dicht beieinander, wobei v1.2.4 ausdrücklich das Nachziehen einer Zählung und eine Zählprüfung nennt. Solche Zählprüfungen sind ein Hinweis darauf, dass die im README genannten Zahlen maschinell abgeglichen werden, was die Konsistenz zwischen Dokumentation und Dateibestand stützt. Ob und wie regelmäßig Übersetzungen nachgeführt werden, lässt sich aus dem Material nicht ableiten. Wer den Fork produktiv einsetzt, sollte vor jedem Update prüfen, welche Upstream-Version er abbildet, und eigene Anpassungen getrennt von den übernommenen Dateien halten, damit ein Update sie nicht überschreibt.

Der Sponsor-Abschnitt als Hinweis auf die Betriebsrealität

Das README enthält einen langen Sponsor-Bereich mit mehreren Anbietern von API-Zugängen zu Modellen wie Claude, GPT, Gemini, Qwen, DeepSeek und GLM, jeweils mit Rabattcodes. Das ist keine technische Information, aber eine über den erwarteten Betrieb: Die Rollensammlung ist nur mit einem Modellzugang nutzbar, und der ist in der Zielregion ein eigener Kosten- und Beschaffungspunkt. Ein Team, das 277 Rollen auf einen Arbeitsablauf mit mehreren Stationen abbildet, multipliziert die Modellaufrufe entsprechend. Das README nennt dazu keine Zahlen, weder zu Token-Verbrauch noch zu Kosten pro Ablauf. Wer die Rollen produktiv in einem mehrstufigen DAG einsetzt, sollte den Verbrauch deshalb selbst messen, bevor er den Ansatz auf breite Teams ausrollt. Der Hinweis auf die Desktop-Anwendung ohne Node-Installation deutet außerdem darauf hin, dass ein Teil der Zielgruppe nicht aus Entwicklern besteht, sondern aus Fachanwendern, die Rollen über eine Oberfläche auswählen statt über das Dateisystem.

Redaktionelles Fazit

Sinnvoll ist agency-agents-zh für Teams, die wiederkehrende Rollen wie Code Review, GIS-Analyse oder Plattform-Content in mehreren Tools einheitlich halten wollen und dafür die Pflege eines Forks akzeptieren. Wer einen einzelnen, tief integrierten Assistenten mit eigenem Tool-Zugriff braucht, sollte nicht hier anfangen, sondern bei einem ausführbaren Agent-Framework. Vor dem Einsatz ist zu prüfen, welche Upstream-Version der Fork abbildet, wie viele der 20 angegebenen Tool-Adapter tatsächlich Dateien im Repository haben und ob der Orchestrator ohne die verlinkte Desktop-Anwendung nutzbar ist. Erst danach lohnt die Entscheidung, ob die Prompt-Sammlung oder ein eigenes Regelwerk die bessere Grundlage ist.

Offizielle Quellen

1. jnMetaCode/agency-agents-zh on GitHub
2. License: MIT
3. Project website
4. README
5. Releases