Ein Subagent ist ein eigener Kontext mit eigenen Anweisungen, eigenen Werkzeugen und oft eigenem Modell — nützlich gerade deshalb, weil das, was er liest, nicht im Hauptgespräch landet. Zwei Felder entscheiden, ob sich diese Trennung lohnt. Die Beschreibung löst die Delegation aus und konkurriert mit allen anderen definierten Agenten, also feuert eine vage entweder nie oder ständig. Die Werkzeugliste ist der billigste Weg, einen engen Agenten eng zu halten: einer, der nur lesen und suchen kann, fängt nicht an zu bearbeiten. Dieser Builder schreibt die Datei und prüft beides, samt der Kombination, die die meisten übersehen — Schreibzugriff ohne Lesezugriff.
Funktionen
Beschreibung auf die Formulierung geprüft, die Delegation auslöst
Werkzeuge aus der echten Liste gewählt statt aus dem Gedächtnis getippt
Nimmt MCP-Werkzeuge mit Namensraum neben den eingebauten an
Warnt, wenn ein Agent Dateien schreiben, aber nicht lesen kann
Die Modellwahl erklärt, wann sich welches lohnt
Projekt- oder persönlicher Geltungsbereich mit passendem Pfad
Ein geerbtes Modell wird weggelassen statt geschrieben
Lädt als fertige .md-Datei herunter
So verwendest du Subagent-Builder
Benennen Sie den Agenten und sagen Sie, wann an ihn delegiert werden soll
Wählen Sie die Werkzeuge, die er braucht — und nur diese
Wählen Sie ein Modell oder lassen Sie das der Sitzung erben
Schreiben Sie den Systemprompt und laden Sie die Datei
Beispiel
Eingabe
tools: [Read, Grep, Glob]
Ausgabe
description: Checks a database migration for problems that only show up in production. Use proactively whenever a migration file is added.
„Proaktiv verwenden, wenn…“ lässt einen Agenten ungefragt anspringen.
Häufige Fehler & Fehlerbehebung
An den Agenten wird nie delegiert. — Die Beschreibung muss sagen wann, nicht nur was. „Verwenden, wenn…“ oder „Proaktiv verwenden nach…“ genügt meist.
Zwei Agenten werden ständig verwechselt. — Ihre Beschreibungen überschneiden sich. Lassen Sie jede eine eigene Situation benennen, nicht ein eigenes Thema.
Ein Werkzeugname gilt als unbekannt. — Werkzeugnamen unterscheiden Groß- und Kleinschreibung und sind großgeschrieben — Read, nicht read. MCP-Werkzeuge nutzen die Form mcp__server__tool und werden so übernommen.
Der Agent bearbeitet Dinge, die ich nicht erwartet habe. — Geben Sie ihm eine engere Werkzeugliste. Ein Agent ohne Write und Edit ändert nichts, egal was sein Prompt sagt.
Häufig gestellte Fragen
Wann ist ein Subagent besser, als die Arbeit direkt zu machen?
Wenn die Arbeit viel Lesen für wenig Ergebnis bedeutet: eine Codebasis durchsuchen, viele Dateien prüfen, recherchieren. Alles Gelesene bleibt in seinem eigenen Kontext. Außerdem ist es der Weg zu einem engeren Werkzeugsatz als dem der Hauptsitzung.
Welches Modell sollte ein Subagent nutzen?
Erben ist ein guter Standard. Ein günstigeres, schnelleres Modell lohnt sich für mechanische Durchgänge, bei denen geprüft statt entschieden wird; ein leistungsfähigeres, wenn Urteilsvermögen gefragt ist. Der Kompromiss steht neben jeder Wahl.
Sollte ich die Werkzeuge immer einschränken?
Einschränken ist billig und umkehrbar und der zuverlässigste Weg, einen fokussierten Agenten fokussiert zu halten — weit zuverlässiger als eine Bitte im Prompt. Eine leere Liste erbt alles, was für Allzweckagenten passt.
Projekt- oder persönlicher Geltungsbereich?
Projektweit legt den Agenten ins Repository, sodass alle denselben haben. Persönlich folgt Ihnen über Projekte hinweg. Der Pfad aktualisiert sich mit der Wahl.
Worin unterscheidet sich das von einer Skill?
Eine Skill ergänzt den aktuellen Kontext um Anweisungen. Ein Subagent läuft anderswo, mit eigenem Kontext und eigenen Werkzeugen, und meldet zurück. Nutzen Sie eine Skill, um zu ändern, wie etwas getan wird; einen Subagenten, um das Tun aus Ihrem Gespräch herauszuhalten.
Verwandte Tools
Skill-Builder — Schreiben Sie eine SKILL.md, deren Frontmatter beim Tippen geprüft wird.
Slash-Befehl-Builder — Bauen Sie einen eigenen Befehl, mit Argumenten und einer Tool-Liste.