Ein Open-Source PR-Review-Bot: LangGraph, Node.js und GitHub Webhooks

Pull-Requests häufen sich in fast jedem Team. Senior-Ingenieure sind in der Regel die Einzigen, die subtile Probleme erkennen: die N+1-Abfrage, den hardcodierten Geheimcode oder Randfälle, die niemand behandelt hat. Zudem sind sie am beschäftigtsten, wodurch Reviews eilig durchgeführt oder verschoben werden – auf jeden Fall gelangt etwas durch.

Kommerzielle AI-Review-Tools sind in der Regel Closed-Source oder teuer, oft beides. Eine Alternative ist ein Bot, den ein kleines Team in seinen eigenen Repositorien betreiben kann, ohne dass Code an eine Black-Box gesendet wird. Das unten beschriebene Design ist ein Open-Source-Bot, der nach neuen Pull-Requests auf GitHub Ausschau hält, jeden davon mit einem mehrstufigen LangGraph-Agenten prüft und spezifische, zeilenweise Feedbacks als PR-Kommentare veröffentlicht.

Was passiert, wenn ein PR eröffnet wird

1. Ein GitHub-Webhook übermittelt das Ereignis.
2. Durch Octokit wird die GitHub-API verwendet, um den Diff abzurufen.

Ein LangGraph-Agent prüft die einzelnen Phasen der Diff-Überprüfung auf Sicherheitsprobleme, Leistungsprobleme und architektonische Mängel.

Der Bot veröffentlicht einen Kommentar zur Pull Request mit Feedback, das auf spezifische Zeilen hinweist.

Die Überprüfung wird in einer Datenbank gespeichert, sodass sich im Laufe der Zeit ein Historienverlauf ansammelt.

Der schrittweise Ansatz ist entscheidend. Ein einziger Prompt, der ein LLM bittet, „diesen Code zu überprüfen“, liefert in der Regel vage, allgemeine Bemerkungen. Die Aufgabe in eine Sicherheitsprüfung, eine Leistungsprüfung und eine Architekturprüfung aufzuteilen, ergibt präzisere Ergebnisse, da jede Phase genau eine Aufgabe hat.

Die Technologie-Stack

Datenbank PostgreSQL für die Überprüfungshistorie Integration mit GitHub Octokit Webhooks Express-Middleware mit Signaturverifikation

Der Technologiestack bleibt nah an dem, was die meisten Node.js-Teams bereits nutzen. Es ging nicht darum, ein neues Framework zu präsentieren, sondern vielmehr um etwas, das ein Team hosten und vertrauen kann.

Ablauf und Struktur

Der Pipeline läuft von der geöffneten PR über einen verifizierten Webhook zum Agenten und gibt anschließend als Kommentar wieder aus:

GitHub PR opened
        │
        ▼
 Webhook (signed, verified)
        │
        ▼
 Express API ──► Fetch diff (Octokit)
        │
        ▼
 LangGraph Agent
   ├── Security check
   ├── Performance check
   └── Architecture check
        │
        ▼
 Post PR comment + save to PostgreSQL

Jeder Check im LangGraph-Fluss ist ein eigenes Knoten. Ein Team kann einen Check testen, anpassen oder deaktivieren, ohne die anderen zu beeinflussen – was hilft, wenn sich die Leute nur für Sicherheitsfindungen interessieren und keine Architekturmeinungen zu jedem PR möchten.

Zwei Code-Beispiele, die gezeigt werden sollten

Zuerst die Verifizierung der Webhook-Signatur. Ohne sie könnte jeder, der die Webhook-URL kennt, falsche Ereignisse senden und betrügerische Überprüfungen auslösen:

function verifySignature(payload: string, signature: string) {
  const hmac = crypto.createHmac("sha256", process.env.GITHUB_WEBHOOK_SECRET!);
  const digest = "sha256=" + hmac.update(payload).digest("hex");
  return crypto.timingSafeEqual(Buffer.from(digest), Buffer.from(signature));
}

Es ist winzig, doch sein Auslassen ist ein häufiger Fehler in toolbasierten Webhook-Lösungen.

Zweitens besteht der LangGraph-Fluss aus separaten Knoten statt aus einer einzigen großen Anfrage:

const graph = new StateGraph(ReviewState)
  .addNode("security", securityCheckNode)
  .addNode("performance", performanceCheckNode)
  .addNode("architecture", architectureCheckNode)
  .addEdge("security", "performance")
  .addEdge("performance", "architecture");

Jeder Knoten erhält den Diff und gibt nur seine eigenen Erkenntnisse zurück, die anschließend zu einem einzigen Kommentar zusammengeführt werden. Auf diese Weise wird das Debuggen einfacher. Wenn die Leistungsprüfung ungewöhnliche Ergebnisse liefert, muss nur ein Knoten überprüft werden, anstatt einen riesigen Prompt.

Was funktioniert hat

• Die Aufteilung der Überprüfung in separate Sicherheits-, Leistungs- und Architekturprüfungen lieferte deutlich bessere, spezifischere Rückmeldungen als ein kombinierter Prompt. Das war der größte Qualitätszuwachs im gesamten Projekt.
• Die Überprüfung der webhook-Signaturen von Anfang an bedeutete, dass Sicherheit bereits zum Design gehörte und nicht später hinzugefügt wurde.
• Die Aufbewahrung der Überprüfungshistorie in PostgreSQL, auch wenn sie nur in einfacher Form vorlag, machte später Muster sichtbar – beispielsweise welche Arten von Problemen immer wieder in verschiedenen PRs auftauchten.

Was weiterhin schwierig war

• Falschpositive sind unvermeidlich. Reviews, die auf großen Sprachmodellen basieren, melden manchmal Dinge, die keine Probleme darstellen, und die Dokumentation sollte dies offen erwähnen. Vertrauen ist wichtiger als eine beeindruckende Liste an Funktionen.
• Die Kosten summieren sich. Drei Aufrufe des großen Sprachmodells pro Pull Request sind genauer als ein einziger, kosten aber mehr und dauern länger. Ein kleines Team muss ein Gleichgewicht zwischen der Qualität der Überprüfung und dem erschwinglichen Preis finden.
• Dass die Kommentare wie von einem Menschen verfasst wirken, erforderte mehr Iterationen der Anweisungen als die Logik von LangGraph. Kommentare sollten kurz, präzise und mit einer Zeilennummer versehen sein, denn niemand liest einen fünf Absätze langen AI-Artikel in einem Pull-Request-Thread.

Der Bot ist ein Teil einer Reihe kleiner Open-Source-Experimente, die Orchestrierung von LLMs mit LangChain und LangGraph auf konkrete Arbeitsablaufprobleme anwenden – wie z. B. Dokumenten-FAQs mit RAG, FAQ-Systeme für servicespezifische Anfragen von Bürgern sowie die Umwandlung von Sprachnotizen in Agile User Stories – anstatt allgemeine Demos zu erstellen. Es handelt sich dabei nicht um ein fertiges Produkt, das überall eingesetzt werden kann. Es ist ein funktionsfähiger Ausgangspunkt, auf dem ein Team weiterarbeiten und es für seine eigene Infrastruktur anpassen kann.

Testen Sie es lokal

Das Repository lässt sich schnell ausführen. Klonen Sie es, installieren Sie die Abhängigkeiten und starten Sie den Entwicklungsserver:

git clone https://github.com/Srameshgitnow/agentic-code-reviewer.git
cd agentic-code-reviewer
npm install
npm run dev

Die README-Dokumentation behandelt die vollständige Einrichtung, die Umgebungsvariablen sowie die Verbindung des GitHub Webhooks. Rückmeldungen zu Fehlalarmen oder Ideen für den LangGraph-Workflow sind die Art von Berichten, die am meisten helfen.