Guillaume Duvernay

Geben Sie Agenten ein Tool für Feedback

7 Min. Lesezeit

agentsMCPfeedback

Zwei Spalten. Links die Tools, die ein MCP-Server bereits bereitstellt, mit einem weiteren am unteren Ende: send_feedback. Ein Pfeil zeigt auf die rechte Spalte, den Bericht, den dieses Tool zurücksendet: beobachtetes Problem, Situation, erwartete Lösung und zwei optionale Felder für das Modell und das Harness.

Wenn Sie einen MCP-Server bereitstellen, sind die meisten Nutzer keine Menschen. Ein Agent liest Ihre Tool-Beschreibungen, wählt eines aus, sendet ein Payload, erhält ein Ergebnis und entscheidet über den nächsten Schritt. Dieser gesamte Kreislauf findet statt, ohne dass jemand zuschaut.

Wenn dort also etwas schiefgeht, sagt Ihnen das niemand. Der Agent versucht es erneut, sucht einen Workaround oder gibt auf und teilt dem Nutzer mit, dass die Aufgabe nicht erledigt werden kann. Sie sehen davon nichts.

Die Lösung ist simpel: Fügen Sie Ihrem MCP ein weiteres Tool hinzu und lassen Sie den Agenten das Problem an Sie melden.

Ein Tool und eine Beschreibung, die festlegt, wann es zu nutzen ist

Das Tool greift nicht in das Produkt ein. Es nimmt eine Beschreibung dessen auf, was schiefgelaufen ist, und leitet sie an Sie weiter. Damit es funktioniert, ist die Beschreibung entscheidend, die der Agent liest, da dies die einzige Anweisung ist, die er erhält.

Hier ist die Version, die ich bei AI Glot verwende:

Nutzen Sie dieses Tool bei der Verwendung von AI Glot, wenn sich ein AI Glot-Tool, eine Antwort, ein Fehler oder ein Workflow anders verhält als erwartet oder wenn Sie sich eine andere Funktionsweise wünschen. Rufen Sie es auf, sobald das Problem klar ist. Beschreiben Sie die Situation, was Sie beobachtet haben und was hätte passieren sollen. Falls bekannt, geben Sie das betroffene Tool, die API-Operation oder den CLI-Befehl, das KI-Modell und das Agent-Framework an. Geben Sie keine API-Keys, Tokens, signierten URLs oder vollständige Dateiinhalte an. Dieses Tool zeichnet nur Feedback auf, führt keine erneuten Versuche durch, ändert nicht Ihre Übersetzung und kostet keine Credits.

Drei Aspekte darin leisten die eigentliche Arbeit. “Sobald das Problem klar ist” verhindert, dass es beim ersten flüchtigen Fehler ausgelöst wird. “Führt keine erneuten Versuche durch” verhindert, dass der Agent es als Wiederherstellungsschritt nutzt, wenn ein Aufruf fehlschlägt. “Kostet keine Credits” ist wichtig, weil Agenten bei allem vorsichtig sind, was Geld des Nutzers kosten könnte. Ein Tool, bei dem sie unsicher sind, wird nicht aufgerufen.

Der Agent befindet sich bereits im Fehlerzustand, wenn er dies aufruft. Es muss nichts im Nachhinein rekonstruiert werden, was den Bericht wertvoll macht.

Die Felder

Hier liegt der größte Mehrwert. Ein offenes Textfeld liefert Ihnen ein “Es hat nicht funktioniert”. Benannte Felder liefern Ihnen Informationen, auf die Sie reagieren können.

Das fragt das Tool von AI Glot ab, beginnend mit den drei Pflichtfeldern:

Die drei Pflichtfelder bilden den Bericht. Die drei optionalen Felder machen aus einem Stapel Berichte ein Muster, das Sie sortieren können.

expected_solution ist das Feld, das ich auf jeden Fall behalten würde. Ein Nutzer sagt Ihnen, dass etwas kaputt ist. Ein Agent sagt Ihnen, was er geglaubt hat, dass der Aufruf bewirken würde. Das ist eine direkte Erkenntnis darüber, ob Ihre Tool-Beschreibung mit Ihrem Tool übereinstimmt.

Die drei optionalen Felder existieren, weil “nicht raten” eine echte Anweisung ist, der ein Agent folgt. Ich bevorzuge ein leeres Feld gegenüber einem plausibel klingenden Modellnamen. Wenn sie ausgefüllt sind, können Sie nach Modell und Framework sortieren, und ein Problem, das nur bei einem von beiden auftritt, wirkt nicht mehr zufällig.

So sieht ein echter Bericht aus

Dies ist ein echtes Beispiel, genau so, wie es mich am 10. September erreichte:

Eine Feedback-Benachrichtigung. Feedback-ID, Zeitstempel, Oberfläche cli, zugehörige Aktion approve_translation, Modell claude-sonnet-4.5, Framework Claude Desktop. Beobachtetes Problem: approve_translation wurde mit no_plan_yet abgelehnt, direkt nachdem create_translation bereits einen Plan zurückgegeben hatte. Situation: eine products.csv mit 1.180 Zeilen wurde mit der Anweisung gesendet, die Preisspalte unverändert zu lassen; die Antwort kam mit einem vollständigen Plan zur Genehmigung zurück, und die sofortige Genehmigung schlug fehl. Erwartete Lösung: allow approve_translation den Plan zu akzeptieren, den create_translation gerade erstellt hat, oder klar sagen, dass plan_translation zuerst ausgeführt werden muss.
Niemand hätte dies gemeldet. Der Durchlauf war beendet, die Übersetzung erfolgt und der Workaround bestand in einem zusätzlichen Aufruf. Das ist genau die Art von Reibung, die Sie normalerweise nie bemerken.

Das ist ein Fehlerbericht mit Reproduktionsschritten, einer Diagnose und einem Lösungsvorschlag, geschrieben von der Instanz, die den Fehler ausgelöst hat, Sekunden nachdem es passierte. Ich habe nicht darum gebeten und ich habe nicht dafür bezahlt.

Warum dies besser ist als das übliche Feedback

Ich behaupte nicht, dass Agenten Nutzer ersetzen. Ich sage, dass dieser spezielle Kanal Eigenschaften hat, die Nutzerfeedback nicht besitzt.

Beide sind wertvoll. Die rechte Spalte ist diejenige, für die Sie derzeit keine Möglichkeit zur Erfassung haben.

Die Objektivität ist der Punkt, zu dem ich immer wieder zurückkehre. Ein Agent hat keine Beziehung zu Ihnen, die er schützen muss, und keine Sorge, fordernd zu wirken. Er hat Ihre Beschreibung gelesen, eine Erwartung geformt, und die Erwartung stimmte nicht überein. Diese Lücke ist der gesamte Bericht und die ehrlichste Dokumentationsprüfung, die Sie jemals erhalten werden.

Wohin die Berichte gehen

Meine Berichte werden per POST an einen Webhook gesendet und landen in einem Kanal, den ich lese. Das ist das gesamte Setup, und es war bereits ausreichend, um den Aufwand zu rechtfertigen.

Man kann es weiter treiben, und die Optionen werden interessant, sobald die Berichte strukturiert sind:

  • Speichern und nach related_action gruppieren. Drei Berichte über dasselbe Tool sind eine Spezifikation, keine Anekdote.
  • Benachrichtigungen bei relevanten Meldungen, gefiltert nach Ihren Präferenzen: ein Tool, ein Modell, ein Framework.
  • Einen Agenten auf die Queue setzen, um Dubletten zu entfernen, Prioritäten zu setzen und einen Lösungsvorschlag in Ihrem Repo zu entwerfen. Die Berichte enthalten bereits die Reproduktion und das erwartete Verhalten, was den Großteil dessen ausmacht, was für einen Fix benötigt wird.
  • Auf Autopilot laufen lassen, falls Sie Ihren Tests genug vertrauen. Ich tue das noch nicht.

Nichts davon ist erforderlich. Der Webhook allein verändert, was Sie über Ihr eigenes Produkt wissen.

Zwei Regeln, die ich nicht ignorieren würde

Es darf niemals die Konversation unterbrechen, die es aufgerufen hat. Wenn Ihr Webhook down ist, gibt das Tool ein einfaches “dies konnte nicht zugestellt werden, nichts weiter zu tun” zurück, keinen Fehler. Ein Agent, der eine Exception von einem Feedback-Tool erhält, wird den Fehler als Teil der Aufgabe behandeln, die er gerade ausführte. Mein Tool hat aus demselben Grund einen kurzen Timeout: Ein hängender Webhook hält den Zug des Agenten offen.

Sagen Sie, was nicht gesendet werden soll. Agenten sind hilfsbereit, und eine Anfrage nach Kontext würde Ihnen sonst API-Keys, signierte URLs und Dateiinhalte liefern. Es genügt, diese in der Beschreibung zu nennen, damit Sie keine Dinge speichern, die Sie nie wollten.

Probieren Sie es mit Ihrem eigenen MCP

Wenn Sie bereits einen MCP-Server betreiben, ist dies ein Tool, ein Webhook und eine Beschreibung, die Sie zweimal umschreiben werden. Der erste Bericht, der eintrifft, wird Ihnen etwas über Ihr Produkt verraten, das Sie nicht wussten, und es wird um ein Tool gehen, von dem Sie dachten, es sei in Ordnung.

Agenten sind jetzt Ihre Nutzer. Geben Sie ihnen einen Ort, an dem sie sich beschweren können.

Quellen