Delphi, KAI und ExeWatchMCP: Was, wenn dein KI-Assistent die Fehler deiner Kunden liest und behebt?

Montagmorgen öffnest du das Projekt in Delphi oder C++Builder, schreibst KAI eine Zeile zum Fehler von Kunde XYZ, und KAI liest ihn selbst nach. Ich erzähle dir, wie du mit ExeWatchMCP dahin kommst und warum sich dadurch die Arbeit in RAD Studio ändert.

TL;DR: ExeWatch hat einen MCP-Server, ExeWatchMCP. Du registrierst ihn in KAI, dem KI-Assistenten von RAD Studio, und KAI liest selbst die Fehler und langsamen Stellen, die deine Kunden in Produktion haben. Du öffnest das Delphi- oder C++Builder-Projekt, sagst “fix the error client XYZ had” und KAI setzt bei dem an, was wirklich passiert ist. Unten findest du dazu eine echte Sitzung. Es funktioniert auch mit Claude Code, Codex und den anderen MCP-Agenten, am Ende des Artikels.

Das ist die Revolution

Ein Kunde sagt dir, er habe einen Fehler gesehen. Du schreibst KAI eine Zeile, und KAI erledigt den Rest: Er liest die Produktion, findet die Stelle im Code, korrigiert sie, kompiliert. Alles in der IDE, im selben Chat.

Das ist eine echte Sitzung an einem meiner Delphi-13-Projekte (RecommenderPro, ein REST-Server). Die Screenshots sind auf Englisch, weil KAI und meine Sitzung auf Englisch laufen. Ich habe weder Kunde noch Version genannt, nur diesen Satz: “A client told me they saw an error in this app this afternoon. Check ExeWatch.”

KAI ruft exewatch_guide, exewatch_apps und exewatch_groups auf (der erste Aufruf von groups schlägt fehl und KAI wiederholt ihn) und sagt mir, dass es in den letzten 24 Stunden zwei verschiedene Probleme gibt: eine ungültige Lizenz, viermal, und einen fehlgeschlagenen CSV-Import, einmal. Er sagt auch, was er nicht weiß: “I haven’t read any code yet”, und dass er die Ortszeit des Kunden bräuchte, um zu klären, welcher der beiden Fehler der des Kunden ist. Er rät nicht.

Ich antworte ihm: “OK, check it and fix it!”

KAI liest die Logs des fehlgeschlagenen Imports, durchsucht das Projekt, öffnet RPServices.BulkU.pas und findet die Ursache: Erwartet wird das Semikolon als Trennzeichen, die empfangene Datei war aber durch Kommas getrennt. Der Parser sah also nur eine Spalte und meldete “1 value per row”, eine Meldung, die niemandem hilft. Er ändert die Meldung, die jetzt die Zeile und das geforderte Trennzeichen nennt, und kompiliert mit der IDE.

Vom Satz “ein Kunde hat einen Fehler gesehen” bis zum geänderten und kompilierten Code: ein Chat, in der IDE, ohne dass ich einen Stack Trace in einen Prompt kopiert habe. Beim Lizenzfehler hat KAI den Code nicht angefasst: Das Log zeigt eine ungültige Lizenzdatei, es ist also ein Problem der Datei und der Konfiguration. Ihm ist auch aufgefallen, dass ExeWatch für diese beiden Fehler keinen Stack Trace hat, weil das Projekt nicht mit der detaillierten Map-Datei kompiliert ist: Wie das geht, steht weiter unten.

Der Code ist nicht mehr der Mittelpunkt

Bisher war der Code der Mittelpunkt und die Produktion ein Ort, den du besucht hast. Ein Kunde rief an, du hast das Dashboard geöffnet, den Stack kopiert und in den Prompt des Agenten eingefügt. Der Agent kannte den Quellcode und sonst nichts: Er fand drei verdächtige Stellen, wählte eine aus, und wenn sie falsch war, blieb der Crash und du hattest eine Änderung mehr zu prüfen.

Jetzt ist der Mittelpunkt das, was in Produktion passiert, und der Code richtet sich danach. Der Agent liest den Fehler, die Version, wie oft er aufgetreten ist, bei welchen Kunden, nach welchen Aktionen, und erst dann öffnet er die Datei. Der Ablauf ist dieser: Der Code geht in Produktion, ExeWatch sammelt, was passiert, der Agent liest es, während er den Code ändert, die Änderung geht zurück in Produktion, und ExeWatch zeigt dir, ob der Fehler verschwunden ist. Du änderst nicht mehr blind. Das ist ein Game Changer.

Was du ihn fragen kannst

Du schreibst die Anfragen so, wie du sie einem Kollegen sagen würdest, auf Deutsch oder auf Englisch. Zum Beispiel:

Customer XYZ got an error last night on version 2.3.
Look it up in ExeWatch, find where it happens in the code and fix it.

Check in ExeWatch where this program is slow
when opening the customer master data, explain why and optimize it.

Im ersten Fall sucht KAI den Fehler, liest den Stack Trace, geht zurück zu Unit und Zeile, schaut in die Breadcrumbs, um zu verstehen, was der Benutzer gerade tat, und schlägt dir die Korrektur an deinem Code vor. Im zweiten startet er bei den echten Timings, nicht bei seiner Idee, wo der Flaschenhals sein könnte. Oft sind das zwei verschiedene Stellen.

Warum es in RAD Studio etwas anderes ist

Einem Agenten Einblick in das zu geben, was in Produktion passiert, ist eine Superkraft. Bugfixing wird viel schneller, weil der Agent beim echten Fehler beginnt und ihn nicht suchen muss, und du reagierst auf das, was bei den Kunden passiert, innerhalb eines Gesprächs statt eines Tickets.

KAI sitzt dort, wo du sitzt, in der IDE, mit dem geöffneten Projekt. Mit ExeWatchMCP fragst du genau dort, wo du den Code schreibst, auch nach dem, was bei den Kunden passiert ist: ohne Browser, ohne Copy-and-paste, ohne das Werkzeug zu wechseln. Delphi und C++Builder arbeiten mit KAI und mit der Produktion vor Augen besser, und genau das will ich der Embarcadero-Community zeigen.

Was ist ExeWatchMCP

Es ist ein Python-Paket, ExeWatchMCP auf PyPI: Mit pip install ExeWatchMCP hast du den Server (exewatch-mcp) und die Kommandozeile exewatch. MCP ist das Protokoll, mit dem ein KI-Agent externe Tools entdeckt und ausführt; darüber habe ich in Nicht nur MCP. Ein echter KI-Agent, eingebettet in deine Delphi-Anwendung. und in MCP Server für Delphi: Verbinden Sie Ihre Anwendungen mit KI über DMVCFramework geschrieben. Diese Tools findet dein Agent vor:

So verbindest du ihn mit KAI

Den API-Schlüssel erstellst du in ExeWatch, er ist schreibgeschützt. In RAD Studio gehst du zu Tools > Options > Kai > Chat > MCP Servers > Custom, fügst einen Server hinzu und füllst vier Felder aus: den Namen (exewatch-mcp), den Typ (Local), den Startbefehl (exewatch-mcp) und eine Umgebungsvariable EXEWATCH_API_KEY mit deinem Schlüssel. Der Schlüssel liegt dort, nicht im Prompt.

Wenn die IDE exewatch-mcp nicht im PATH findet, trägst du den vollständigen Pfad des Befehls ein oder nutzt python -m exewatch_cli mcp.

Etwas für alle, die mit Delphi arbeiten: Der Stack Trace kommt nur an, wenn du das Programm mit der detaillierten Map-Datei und aktiven Stack Frames kompilierst. Wenn du schon madExcept oder EurekaLog nutzt, kannst du ExeWatch deren Stack Trace mit einer kleinen Verbindungs-Unit weitergeben: Ich habe das in ExeWatch in Delphi-Projekte integrieren, die bereits madExcept nutzen erklärt, und dasselbe Schema gilt für EurekaLog.

Was er kann und was nicht

• Nur lesen. Der Schlüssel ist schreibgeschützt: Der Agent schreibt nichts in ExeWatch.
• Schlüssel mit Geltungsbereich. Beim Erstellen des Schlüssels wählst du, was er lesen darf: eine einzelne Anwendung, eine Gruppe von Anwendungen oder alle. Ein externer Berater bekommt einen Schlüssel für die eine App, an der er arbeitet, und sieht die anderen nicht.
• Pläne PRO und BUSINESS. API-Schlüssel gibt es in den Plänen PRO und BUSINESS, in der Cloud und On-Premises. Wenn ExeWatch dich beim Erstellen des Schlüssels zum Upgrade auffordert, enthält dein Plan sie nicht.
• Der Text aus dem Feld gehört nicht dir. Meldungen und Stack Traces schreibt die Software der Kunden, und theoretisch jeder, der sie zum Reden bringt. Deshalb trägt jede Antwort "untrusted_content": true, und der Agent behandelt sie als Daten zum Lesen, nie als Anweisungen zum Ausführen.
• Zeitfenster. Ohne Filter deckt eine Abfrage bis zu 90 Tage ab (24 Stunden, wenn du nichts angibst). Wenn du nach Text, Tag, Version oder Sitzung filterst, sind es maximal 7 Tage, und dasselbe gilt für die Timings.
• Die Version ist ein exakter Text. 2.3 findet nicht 2.3.0.145. Wenn nichts gefunden wird, startet der Agent die Abfrage ohne Filter neu und liest die Version aus den Ergebnissen.
• Den Code prüfst du. Das ist gute Praxis: Der Agent schlägt die Codeänderung vor, du machst das Review wie bei jeder anderen Änderung.

Es funktioniert auch mit Claude Code, Codex und den anderen

ExeWatchMCP ist ein Standard-MCP-Server und deshalb nicht an KAI gebunden. Mit Claude Code:

claude mcp add exewatch --env EXEWATCH_API_KEY=<your key> -- exewatch-mcp

Mit Codex ist es dasselbe mit codex mcp add, oder du nutzt einen Eintrag [mcp_servers.exewatch] in ~/.codex/config.toml. Jeder andere Agent oder Assistent, der MCP spricht, wird auf die gleiche Weise konfiguriert. Du entscheidest.

In diesem Artikel ging es um Delphi und C++Builder, weil ExeWatch dort entstanden ist und die Integration mit KAI dort am meisten Sinn ergibt. Die ExeWatch-SDKs decken auch .NET, Python und JavaScript ab, und der Server ist derselbe.

Willst du es live sehen?

Ich zeige es live auf der ITDevCon in Rom am 19. und 20. November: KAI geöffnet an einem Delphi-Projekt, ein echter Fehler aus ExeWatch, und der Agent, der ihn vor deinen Augen löst. Danach spreche ich darüber in einigen Webinaren und auf weiteren Konferenzen, darunter Ekon. Die Termine trage ich hier ein, sobald ich sie bestätigt habe.

Um zu verstehen, was ExeWatch heute sammelt, lies ExeWatch 1.35: Nested Timing Traces für Delphi & .NET und ExeWatch: Proactive Software Monitoring from Passive Security to Observability. Der Rest steht auf exewatch.com.

Häufige Fragen

Was ist ExeWatchMCP? Es ist der MCP-Server von ExeWatch. Er erlaubt einem Coding-Agenten, Fehler, Stack Traces, Breadcrumbs, Versionen und Timings der überwachten Anwendungen zu lesen, während er an deinem Code arbeitet.

Mit welchen Agenten funktioniert er? Mit KAI, dem KI-Assistenten von RAD Studio für Delphi und C++Builder, und mit jeder anderen Umgebung, die das Model Context Protocol unterstützt, wie Claude Code und Codex.

Wie installiere ich ihn? pip install ExeWatchMCP (Python 3.9 oder neuer), dann registrierst du exewatch-mcp in deinem Agenten, mit dem API-Schlüssel in der Umgebung.

Kann der Agent Daten in ExeWatch ändern? Nein. Der Schlüssel ist schreibgeschützt.

Brauche ich einen kostenpflichtigen Plan? Ja. API-Schlüssel gibt es in den Plänen PRO und BUSINESS, Cloud und On-Premises.

Kann ich einem Berater Zugriff auf nur eine App geben? Ja. Der Schlüssel lässt sich auf eine Anwendung, eine Gruppe von Anwendungen oder alle beschränken.

Funktioniert er nur mit Delphi und KAI? Nein, aber dieser Artikel geht von dort aus. ExeWatch hat SDKs für Delphi, C++Builder, .NET, Python und JavaScript, und der MCP-Server ist für alle derselbe.

Wo sehe ich ihn in Aktion? Auf der ITDevCon in Rom am 19. und 20. November 2026.