AI Server stellt eine OpenAI-kompatible API für Anwendungen auf einer von der Organisation kontrollierten Infrastruktur bereit. Eine Agenten-Integration benötigt einen spezifischeren Akzeptanztest als eine erfolgreiche Chat-Antwort: Das gewählte Modell muss die beabsichtigte Operation vorschlagen, und die Host-Anwendung muss diesen Vorschlag korrekt verarbeiten. Unsere Produktseite AI Server beschreibt die Bereitstellungsrolle; das folgende Verfahren erläutert, wie wir empfehlen, eine einzelne Integration zu überprüfen.
Die Dokumentation des MLCommons Edge Agentic Benchmark vom Juli 2026 verdeutlicht den Unterschied. Deren Beispiele senden Tool-Definitionen an einen Chat Completions-Endpunkt und prüfen strukturierte Aufrufe, die vom Modell zurückgegeben werden.[1] Ein Endpunktname allein garantiert nicht, dass jede Kombination aus Modell, Laufzeit und Framework denselben Workflow abschließt.
Beginnen Sie mit einer Anfrage, die keine Geschäftsdaten ändert
Wählen Sie einen entbehrlichen Testarbeitsbereich und ein für die Aufgabe vorgesehenes Modell. Dokumentieren Sie die Server-Build-Version, Laufzeit, Modellkennung und Agent-Framework-Version. Fügen Sie die effektiven Endpunkt- und Transport-Einstellungen hinzu, aber lassen Sie Zugangsdaten aus dem Bericht heraus. Die Aufzeichnung sollte die getestete Installation von einem ähnlich benannten Modell oder einem älteren Server, der noch anderswo läuft, unterscheiden.
Starten Sie mit einer gewöhnlichen Textanfrage. Bestätigen Sie, welcher Endpunkt sie erhielt, welches Modell sie bearbeitete und ob der Aufrufer eine vollständige Antwort erhielt. Wiederholen Sie dies über das Framework, das im Pilotprojekt verwendet wird. Ein direkter HTTP-Erfolg und ein Framework-Erfolg sind getrennte Beobachtungen; bewahren Sie beide Ergebnisse auf.
Verwenden Sie eine kurze Eingabe mit vorhersehbarer Antwort, damit Verbindungsfehler leicht von der Aufgabenschwierigkeit unterschieden werden können. Eine generierte Begrüßung sagt wenig über einen Einkaufsworkflow aus, ist aber eine nützliche erste Überprüfung der Route. Fügen Sie keine Geschäftsdaten hinzu, nur um diesen ersten Test realistischer zu machen.
Prüfen Sie einen harmlosen Tool-Vorschlag vor der Ausführung
Definieren Sie eine enge Testoperation, z. B. das Nachschlagen eines Artikels in einem erfundenen Inventar. Geben Sie ein kleines Schema mit Pflichtfeldern und einer expliziten Menge erlaubter Werte vor. Erfassen Sie an dieser Stelle die vom Modell vorgeschlagene Operation, ohne sie auszuführen. Prüfen Sie den Operationsnamen, die geparsten Argumente und die Behandlung fehlender oder unerwarteter Felder durch das Framework.
Halten Sie das Testobjekt so einfach, dass eine Person jedes Ergebnis prüfen kann. Ein Modell, das plausiblen Text über einen Artikel zurückgibt, hat nicht unbedingt einen nutzbaren Tool-Aufruf erzeugt. Umgekehrt kann ein wohlgeformter Aufruf dennoch den falschen Artikel benennen. Dokumentieren Sie Formatakzeptanz und Aufgabenkorrektheit getrennt.
Wenn die Produktionsanwendung Antworten streamt, führen Sie dieselbe Prüfung über Streaming durch. Vergewissern Sie sich, dass der Verbraucher wartet, bis der relevante strukturierte Wert vollständig ist, bevor er ihn interpretiert. Behandeln Sie jede Abweichung zwischen Streaming- und Nicht-Streaming-Verarbeitung als Integrationsbefund, der gelöst werden muss, anstatt anzunehmen, der erfolgreiche Pfad decke beide ab.
Schließen Sie den Rundweg mit einem kontrollierten Ergebnis ab
Nachdem der Vorschlag die Validierung besteht, erlauben Sie dem Host, das erfundene Inventar aufzurufen und dessen Ergebnis an das Modell zurückzugeben. Prüfen Sie die anschließende Antwort. Sie sollte das gelieferte Ergebnis verwenden und die Identität des angeforderten Artikels bewahren. Fügen Sie eine Abfrage hinzu, die keinen Treffer liefert, damit die Anwendung das Fehlen ehrlich darstellen muss.
Führen Sie dann eine kurze Sequenz durch, die eine zweite Abfrage erfordert. Überprüfen Sie, wie das Framework jedes Ergebnis mit dem ursprünglichen Aufruf verknüpft und wie die nächste Anfrage das Gespräch fortführt. Speichern Sie eine bereinigte Spur, die die Sequenz zeigt, ohne echte Kundendokumente zu behalten.
An diesem Punkt wird eine Demonstration mit einem einzelnen Durchlauf zu einem Workflow-Test. Die Spur sollte eine falsche Zuordnung, eine unnötige Wiederholung oder eine abgebrochene Aufgabe aufdecken. Der Benchmark-Artikel vom Oktober erklärt, warum Arbeitslastgrenzen bei der Bewertung dieser längeren Interaktionen wichtig sind.
Belassen Sie Berechtigungsprüfungen außerhalb der Beurteilung des Modells
OWASP identifiziert übermäßige Funktionalität, Berechtigungen und Autonomie als Ursachen für übermäßige Handlungsvollmacht. Die Empfehlungen platzieren Autorisierungsprüfungen in den Systemen, die Aktionen ausführen, und empfehlen eine menschliche Genehmigung für Operationen mit hoher Auswirkung.[2] Für diese Integration testen Sie diese Kontrollen unabhängig davon, ob das Modell üblicherweise nach sinnvollen Aktionen fragt.
Erweitern Sie die erfundene Inventar-Fixierung um eine Operation, die der Aufrufer nicht ausführen darf. Verifizieren Sie, dass der Host oder der nachgelagerte Dienst diese ablehnt, selbst wenn die vorgeschlagenen Argumente gültig erscheinen. Die Ablehnung sollte für den Benutzer verständlich bleiben und nicht dazu führen, dass das Framework eine höher privilegierte Berechtigung ersetzt.
Fügen Sie ein abgerufenes Testdokument mit einer irrelevanten Anweisung ein. OWASP beschreibt indirekte Prompt-Injektion durch externe Inhalte und stellt fest, dass Retrieval-augmented Generation die Verwundbarkeit nicht vollständig beseitigt.[3] Das Akzeptanzkriterium hier ist konkret: Abgerufene Prosa darf der Anwendung keine zusätzlichen Berechtigungen gewähren. Dieser Test ist eine nützliche Überprüfung, kein Beweis dafür, dass jeder Injektionsversuch blockiert wird.
Beenden Sie mit Unterbrechung und aufgezeichnetem Umfang
Unterbrechen Sie das Testwerkzeug, brechen Sie eine Anfrage ab und machen Sie eine Abhängigkeit vorübergehend nicht verfügbar. Beobachten Sie, was der Benutzer sieht und was das Framework erneut versucht. Bevor Sie ein Werkzeug einführen, das Datensätze ändert, stimmen Sie ab, wie ein erneuter Versuch eine bereits abgeschlossene Aktion nicht dupliziert. Diese Entscheidung gehört in das Anwendungsdesign und den Vertrag des nachgelagerten Dienstes.
Unser vorgeschlagenes Akzeptanzprotokoll listet die genau getesteten Operationen, die erlaubten Identitäten und etwaiges ungeklärtes Verhalten auf. Eine erfolgreiche Inventarabfrage sollte nur den vereinbarten Pilotumfang autorisieren. Ein neuer Connector, erweiterte Berechtigungen oder ein anderes Modell sollten eine Überprüfung der betroffenen Prüfungen auslösen.
Für eine Bereitstellungsdiskussion bringen Sie dieses Protokoll zu einer Software Tailor-Integrationsprüfung, zusammen mit einem geschwärzten fehlerhaften Beispiel, falls vorhanden. Der nützliche nächste Schritt ist eine reproduzierbare Lücke mit einem Verantwortlichen. Die betriebliche Übergabe sollte diese Verantwortlichen auch nach Abschluss der anfänglichen Integrationsarbeit bewahren.
Quellen
[1] MLCommons. Call for Submission: Edge Agentic Inference Benchmark for MLPerf Inference v6.1. Juli 2026. Zugriff am 26.09.2026.
[2] OWASP Gen AI Security Projekt. LLM06:2025 Übermäßige Agentur. Ausgabe 2025. Zugriff am 26.09.2026.
[3] OWASP Gen AI Security Projekt. LLM01:2025 Prompt Injection. Ausgabe 2025. Zugriff am 26.09.2026.
Verwandte Artikel
- MLPerf Inference 6.1 und der Übergang zu Workflow-Benchmarks
- Das Übergabeprotokoll für einen privaten AI-Dienst
- Vor der Installation eines lokalen Modells