Einen n8n-Workflow für Codeänderungen mit menschlicher Freigabe und Testprüfung erstellen

Der Workflow im Überblick

Mit n8n kann ein AI Agent eine Repository-Änderung vorschlagen, während der Schreibvorgang eine menschliche Freigabe erfordert. Führen Sie nach einem freigegebenen Schreibvorgang Tests für den genau daraus entstandenen Commit aus und melden Sie das Ergebnis. Ein Merge oder Deployment bleibt eine separate Entscheidung.

Entscheidend ist die Unterscheidung zwischen Tool-Freigabe und Freigabe der Ausgabe. In n8n kann ein Schritt zur menschlichen Prüfung einen AI Agent anhalten, bevor ein ausgewähltes Tool ausgeführt wird. Die prüfende Person sieht das vorgeschlagene Tool und dessen Parameter. Bei einer Freigabe wird der Aufruf ausgeführt; bei einer Ablehnung wird er abgebrochen und der Agent darüber informiert. Dieses Verhalten ist im n8n-Leitfaden zu Human-in-the-Loop dokumentiert.

OneMux bietet Zugriff auf KI-Modelle über eine OpenAI-kompatible API. Für diesen Entwurf ist das ein möglicher Weg zum Modellzugriff, aber keine überprüfte n8n-Integration. Gleichen Sie die OneMux-API-Dokumentation und die Konfiguration Ihres n8n-Nodes mit dem Endpunkt und den Parametern ab, die Sie verwenden möchten.

Voraussetzungen für die Umsetzung

• Eine n8n-Instanz mit einem AI Agent, einer geeigneten Chatmodell-Verbindung und Zugang zu einem Kanal für die menschliche Prüfung, etwa Slack oder n8n Chat.
• Eine Repository-Integration oder ein eigener Dienst, der eine angegebene Revision lesen und einen Patch auf einen Nicht-Produktionsbranch anwenden kann. Geben Sie dessen Schreibzugangsdaten nur die für dieses Repository und diesen Branch erforderlichen Berechtigungen.
• Ein von Produktionszugangsdaten und -systemen isolierter Test-Runner. Er muss eine exakte Commit-ID annehmen und einen Status sowie einen Link oder eine Referenz auf seine Ergebnisse zurückgeben.
• Ein OneMux-Konto und API-Zugriff, falls Sie OneMux für Modellaufrufe wählen. Aktuelle Verbindungsdetails finden Sie im Quickstart; zur Auswahl eines verfügbaren Modells dient der Modellkatalog.
• Ein Repository mit einem bekannten Testbefehl, einem geschützten Standardbranch und einer Person, die zur Prüfung vorgeschlagener Änderungen berechtigt ist.

Dies ist ein Implementierungsmuster, kein importierbarer Workflow. Repository-Tools, Runner-Integration, Modellwahl und die genauen n8n-Felder hängen von Ihrer Umgebung ab. Insbesondere belegt die bereitgestellte Dokumentation nicht, dass ein bestimmtes OneMux-Modell das von einem n8n AI Agent benötigte Tool-Calling-Verhalten unterstützt. Prüfen Sie diese Unterstützung, bevor Sie sich auf den Entwurf verlassen.

Den Workflow auf eine exakte Revision ausrichten

Eine praktikable Abfolge sieht so aus:

1. Anfrage entgegennehmen. Erfassen Sie Repository, Problembeschreibung, Ziel-Arbeitsbranch, Basis-Commit und erlaubten Testbefehl aus einer vertrauenswürdigen Workflow-Konfiguration.
2. Lesen und vorschlagen. Lassen Sie den Agenten die relevanten Dateien am Basis-Commit untersuchen und einen Patch vorbereiten. Der Lesezugriff darf das Repository nicht ändern können.
3. Schreibvorgang prüfen. Leiten Sie das Tool zum Anwenden des Patches durch die menschliche Prüfung in n8n. Die prüfende Person gibt den vorgeschlagenen Tool-Aufruf frei oder lehnt ihn ab.
4. Anwenden und identifizieren. Nach der Freigabe prüft der Schreibdienst, ob der Branch noch auf den freigegebenen Basis-Commit zeigt, wendet den freigegebenen Patch an und gibt die neue Commit-ID zurück. Hat sich die Basis geändert, brechen Sie den Vorgang sicher ab und fordern Sie einen neuen Vorschlag samt Freigabe an.
5. Überprüfen. Führen Sie die konfigurierten Tests für genau diesen neuen Commit in einem isolierten Runner aus. Halten Sie Befehl, Commit, Status und Ergebnisreferenz fest.
6. Ergebnis melden. Senden Sie der prüfenden und der anfragenden Person den Commit und das Testergebnis. Ein fehlgeschlagenes, abgebrochenes oder fehlendes Testergebnis gilt nicht als bestanden.

Dies sind empfohlene Kontrollmaßnahmen, keine Funktionen, die der Schritt zur menschlichen Prüfung in n8n garantiert. Insbesondere muss Ihr Repository-Dienst die Prüfung des Basis-Commits durchsetzen und sicherstellen, dass der freigegebene Patch auch tatsächlich angewendet wird.

Die Modellverbindung konfigurieren

Wählen Sie in n8n eine Chatmodell-Konfiguration, die einen konfigurierbaren OpenAI-kompatiblen Endpunkt und das Tool-Calling-Verhalten unterstützt, das Ihr AI Agent benötigt. Verwenden Sie den Endpunkt, die Authentifizierungsmethode und die Modellkennung aus der aktuellen OneMux-Dokumentation. Speichern Sie Zugangsdaten im Zugangsdaten-System von n8n statt in Prompts oder Workflow-Nachrichten.

Senden Sie vor dem Einrichten des Repository-Zugriffs eine kleine Testanfrage und prüfen Sie, ob die Antwort im vom n8n-Node erwarteten Format eintrifft. Testen Sie anschließend einen harmlosen Tool-Aufruf. OpenAI-kompatibel bedeutet nicht, dass jeder Endpunkt, jeder Parameter oder jedes Tool-Aufrufformat austauschbar ist: Die Kompatibilität setzt hier voraus, dass beide Seiten die benötigten Anfragen und Antworten unterstützen. Diese Konfiguration wurde für diesen Artikel nicht getestet.

Falls Ihre verfügbare Modellverbindung die Tool-Aufrufe des Agenten nicht unterstützt, umgehen Sie die Freigabe nicht, indem Sie dem Modell direkte Schreibzugangsdaten geben. Verwenden Sie eine kompatible Konfiguration oder richten Sie eine separate, ausdrücklich geprüfte Übergabe an den Schreibdienst ein.

Eine menschliche Freigabe für den Repository-Schreibvorgang einrichten

Öffnen Sie im AI Agent-Node den Anschluss Tools und suchen Sie im Tools Panel nach Human review. Wählen Sie einen Freigabekanal und konfigurieren Sie dessen Zugangsdaten. Verbinden Sie das Repository-Schreibtool mit dem Tool-Anschluss des Prüfschritts. Halten Sie reine Lesetools gegebenenfalls getrennt und sichern Sie alle weiteren Tools, die externen Zustand verändern können, durch eine eigene Prüfung oder eine gleichwertige Kontrolle ab.

Laut der n8n-Dokumentation kann die prüfende Person den Tool-Namen und die von der KI gelieferten Parameter erhalten. Konfigurieren Sie die Prüfnachricht zum Beispiel mit:

Proposed tool: {{ $tool.name }}
Proposed parameters:
{{ JSON.stringify($tool.parameters, null, 2) }}

Verwenden Sie ein Schreibtool, dessen prüfbare Eingaben das Repository, den Branch, den Basis-Commit und den vollständigen Patch oder eine unveränderliche Patch-Referenz mit einem Digest enthalten. Ist der Patch für den Kanal zu groß, stellen Sie einen sicheren, zugänglichen Prüfablageort bereit und überprüfen Sie, dass der Schreibdienst denselben Inhalt anwendet. Eine vage Anweisung wie „die Tests reparieren“ reicht nicht aus, um eine bestimmte Repository-Änderung freizugeben.

Die dokumentierten Werte von $tool.parameters umfassen Felder, die mit $fromAI()-Ausdrücken konfiguriert wurden. Gehen Sie nicht davon aus, dass die Nachricht alle fest hinterlegten Zugangsdaten, verborgenen Konfigurationswerte oder nachgelagerten Auswirkungen offenlegt. Begrenzen Sie feste Einstellungen und geben Sie den Prüfenden eine separate Möglichkeit, diese einzusehen. Vermeiden Sie Geheimnisse in Tool-Parametern, da Parameter in Freigabenachrichten erscheinen können.

Fügen Sie eine Systemanweisung hinzu, die das freigabepflichtige Tool benennt und dem Agenten vorgibt, was er bei einer Ablehnung tun soll. Zum Beispiel:

Repository writes require human approval. Propose a patch against the
specified base commit and request the write tool only for that patch.
If approval is denied, do not retry the write or use another tool to make
the change. Tell the requester it was denied and ask for clarification.
Report test results only when supplied by the test runner.

Diese Anweisung hilft dem Agenten beim Umgang mit der Prüfung; sie ist keine Sicherheitsgrenze. Setzen Sie Berechtigungen und Branch-Einschränkungen außerhalb des Prompts durch.

Die freigegebene Änderung überprüfen

Starten Sie den Test-Runner erst, nachdem der Schreibdienst eine Commit-ID zurückgegeben hat. Konfigurieren Sie den Runner so, dass er diese ID auscheckt und nicht den aktuellen Branch-Head. Er soll einen von Ihrem Team definierten Befehl aus einer Allowlist ausführen. Für ein Repository, dessen Verantwortliche diesen Befehl gewählt haben, könnte ein Beispiel so aussehen:

npm test

Dieser Befehl dient nur zur Veranschaulichung; verwenden Sie die tatsächlichen Testanweisungen des Projekts. Behandeln Sie Repository-Code, Installationsskripte für Abhängigkeiten und Testausgaben als nicht vertrauenswürdig. Führen Sie sie mit eingeschränktem Netzwerk- und Dateisystemzugriff, ohne Produktionsgeheimnisse sowie mit Zeit- und Ressourcenlimits aus. Eine bestandene Testsuite zeigt lediglich, dass die ausgewählten Prüfungen in dieser Umgebung bestanden wurden; sie beweist nicht, dass die Änderung sicher oder korrekt ist.

Geben Sie ein knappes Ergebnis mit der freigegebenen Basis, dem neuen Commit, dem Testbefehl, dem Bestanden-/Fehlgeschlagen-Status und einem Link zu den Logs zurück. Schlagen Tests fehl, kann der Agent einen überarbeiteten Patch vorschlagen; ein weiterer Schreibvorgang benötigt jedoch eine eigene Freigabe. Führen Sie keinen automatischen Merge durch, nur weil eine prüfende Person den früheren Tool-Aufruf freigegeben hat.

Fehlerbehebung und Betriebsgrenzen

Der Freigabeanfrage fehlt hilfreicher Kontext

Prüfen Sie, welche Eingaben von der KI stammen und in $tool.parameters sichtbar sind. Nehmen Sie die Patch-Identität, den Branch und die Basisrevision in die prüfbare Tool-Eingabe auf oder stellen Sie ein sicheres, unveränderliches Prüfartefakt bereit. Kann die prüfende Person den exakten Schreibvorgang nicht identifizieren, lehnen Sie ihn ab.

Der Agent kann das Tool nicht aufrufen

Testen Sie zunächst ein harmloses Tool unabhängig von den Repository-Berechtigungen. Prüfen Sie den n8n-Node, den OneMux-Endpunkt, das gewählte Modell und die erforderlichen Tool-Call-Parameter anhand der jeweiligen aktuellen Dokumentation. Die bereitgestellten Quellen bestätigen keine bestimmte Kombination aus Modell und Node.

Der Branch hat sich geändert oder die Tests wurden nicht abgeschlossen

Lehnen Sie einen veralteten Schreibvorgang ab, statt einen Patch auf eine andere Basis anzuwenden. Melden Sie die Überprüfung bei einem Timeout, Runner-Fehler oder fehlendem Log als unvollständig. Führen Sie sie gegebenenfalls erneut für denselben Commit aus; fordern Sie eine neue Freigabe an, wenn sich der vorgeschlagene Schreibvorgang ändert.

Fazit

Die sinnvolle Abgrenzung ist eng: Eine Person gibt einen bestimmten Repository-Schreibvorgang frei, und ein isolierter Runner überprüft den daraus entstandenen Commit. n8n stellt die dokumentierte Unterbrechung auf Tool-Ebene und den Freigabeablauf bereit; Ihr Repository-Dienst, Runner, Ihre Berechtigungen und Ihr Prüfprozess liefern die übrigen Schutzmaßnahmen. Nutzen Sie OneMux erst dann als Modellzugriffsschicht, wenn Sie bestätigt haben, dass der gewählte Endpunkt und die Parameter mit Ihrer n8n-Konfiguration funktionieren.

Quellen

• n8n: Human-in-the-loop for tools — Verhalten und Einrichtung der Tool-Freigabe, Prüfkanäle und Variablen für Prüfnachrichten.
• OneMux-Dokumentation — aktuelle Details zur API-Verbindung.