Erstellung von KI-Agenten auf der Grundlage Ihrer bestehenden .NET-Dienste und APIs
C#-Teams können bestehende .NET-Dienste als gesteuerte Tools für KI-Agenten über Funktionsaufrufe bereitstellen, wobei die erforderlichen Regeln für Kontext, Sicherheit und Überwachbarkeit eingehalten werden.
Quellen: AI Agents Are Changing C# Development: 10 Things Every .NET Developer Should Know
Die meisten .NET-Teams verfügen bereits über die wesentlichen Komponenten eines KI-Agenten: typisierte Dienste, HTTP-APIs, Authentifizierungssysteme, Datenbanken sowie Hintergrundaufgaben. Neu ist ein Sprachmodell, das entscheiden kann, welche dieser Funktionen in welcher Reihenfolge aufgerufen werden sollen, um ein von einem Benutzer in einfachen Worten beschriebenes Ziel zu erreichen. Diese Anleitung führt durch die Konzepte, die ein C#-Entwickler benötigt, um einen Agenten in eine bestehende Anwendung einzubinden, ohne die Kontrolle über das tatsächliche Verhalten der Anwendung zu verlieren.
Von der Beantwortung von Fragen zur Erledigung von Aufgaben
Ein klassischer Chatbot führt nur einen einzigen Kommunikationsaustausch durch: Ein Benutzer stellt eine Frage und das Modell antwortet mit Text. Ein Agent hingegen arbeitet an einem Ziel. Er überlegt, was für dieses Ziel erforderlich ist, ruft Tools auf, um Informationen abzurufen oder Aktionen auszuführen, prüft die Ergebnisse und gibt erst danach ein Endergebnis zurück.
Betrachten wir einen Benutzer, der wissen möchte, wie viele Bestellungen heute eingegangen sind. Ein Chatbot kann nur raten oder erklären, wie man dies herausfinden könnte. Ein Mitarbeiter mit den richtigen Werkzeugen kann auf die Bestelldaten zugreifen, eine Abfrage für den heutigen Tag durchführen, die Zahlen interpretieren, einen kurzen Zusammenfassungstext verfassen und diesen als Bericht liefern. Der praktische Unterschied ist einfach: Chatbots liefern Antworten, Mitarbeiter erledigen Arbeit.
Werkzeuge machen ein Modell nützlich
Ein Sprachmodell allein hat keine Ahnung, wie Ihre Anwendung funktioniert. Es kann weder Ihre Kundenliste lesen noch eine Bestellung aufgeben. Werkzeuge bilden die Brücke: benannte Aktionen, die das Modell anfordern darf. Ein typisches Set für einen E-Commerce-Backend könnte wie folgt aussehen:
GetCustomer()
CreateOrder()
SearchProducts()
GetWeather()
SendEmail()
QueryDatabase()
Das Modell entscheidet, wann eines davon benötigt wird; Ihr Code bestimmt, wie es ausgeführt wird. In C# muss ein Tool nichts Exotisches sein – es kann eine gewöhnliche asynchrone Methode in einem bereits vorhandenen Service sein, beispielsweise eine Methode, die einen Kunden über seine ID über einen injizierten Service lädt:
public async Task<Customer> GetCustomer(int id)
{
return await customerService.GetByIdAsync(id);
}
Sobald diese Methode als Tool registriert ist, kann der Agent die Funktion nutzen, während die Implementierung weiterhin innerhalb Ihrer normalen Service-Schicht bleibt und von derselben Abhängigkeitsinjektion, den Tests sowie dem Logging wie der Rest des Codebases abgedeckt wird. An diesem Punkt treffen die alltägliche Anwendungsentwicklung auf die KI-Entwicklung.
Wie Funktionsaufrufe in der Praxis funktionieren
Funktionsaufrufe sind das Mechanismus hinter Tools. Das Modell führt selbst nichts aus; es sendet einen strukturierten Anfrage, um eine Funktion mit spezifischen Argumenten aufzurufen, und Ihre Anwendung führt den Aufruf aus.
Nehmen wir an, ein Benutzer fragt nach dem Status der Bestellung 12345. Intern kommt das Modell zu dem Schluss, dass es über keine Informationen verfügt:
I need order information.
Deshalb bittet es die Host-Anwendung, eine Funktion mit der Bestellnummer als Argument aufzurufen:
GetOrderStatus(12345)
Ihr Code führt diese Anfrage aus, gibt das Ergebnis an das Modell zurück, und dieses wandelt die Rohdaten in eine verständliche Antwort um. Für einen C#-Entwickler sollte das vertraut wirken: Man stellt einen kleinen Teil der Anwendung zur Verfügung, ähnlich wie eine öffentliche API, deren Aufrufer ein Modell ist. Klar formulierte Namen, präzise Parametertypen und gute Beschreibungen erhöhen die Wahrscheinlichkeit korrekter Aufrufe erheblich.
Wiederverwendung der bereits vorhandenen APIs
Die Einführung von Agenten erfordert keine Neuimplementierung des Backends. Wenn Ihre Anwendung bereits Endpunkte bereitstellt, können diese zu den Werkzeugen des Agenten werden. Ein Service könnte bereits eine Abfrage nach Kunden bereitstellen:
GET /api/customers/{id}
Neben Endpunkten zum Lesen einer Bestellung, Erstellen von Bestellungen und Auflisten von Produkten (die untenstehende Auflistung führt die drei Routen in einer Zeile aus; betrachten Sie sie als separate Endpunkte):
GET /api/orders/{id}POST /api/ordersGET /api/products
Sobald diese vorhanden sind, wird eine Anfrage wie das Finden des Kunden, der diesen Monat die meisten Bestellungen aufgegeben hat, zu einer Abfolge, die der Agent selbst planen kann: Kundendaten abrufen, Bestellinformationen holen, die Zahlen vergleichen und den Gewinner melden. Der Agent ist im Grunde nur ein weiterer Client, der auf den bereits erstellten und gesicherten Funktionen basiert.
Kontext: Geben Sie dem Modell nur das, was es benötigt – nicht alles, was Sie haben
Stellen Sie sich eine halbstündige Arbeitssession mit einem Agenten vor, der Ihr Anwendungsprojekt, dessen Datenbankschema, die Codierkonventionen des Teams, Geschäftsregeln, offene Fehler sowie Entscheidungen aus früheren Teilen des Gesprächs abdeckt. Um weiterhin nützlich zu sein, muss der Agent alle relevanten Aspekte davon im Auge behalten. Deshalb spielen Konversationshistorie, Kontextverwaltung, Speicherung, Abrufmechanismen, Embeddings sowie Vektordatenbanken bei der Gestaltung von Agenten eine immer wichtigere Rolle.
Es gibt eine Fallstrick, der leicht übersehen wird: Mehr Kontext bedeutet nicht automatisch etwas Besseres. Jedes zusätzliche Element kostet Geld und verursacht Verzögerungen, und irrelevante Informationen schwächen das Signal ab, wodurch die Antworten weniger zuverlässig werden. Eine gute Agentenkonzeption besteht darin, genau den richtigen Kontext zum richtigen Zeitpunkt bereitzustellen – beispielsweise indem nur die Dokumente abgerufen werden, die zum aktuellen Schritt passen, anstatt eine ganze Wissensdatenbank in jede Anfrage einzufügen. Für einen tieferen Einblick in die Unterschiede dieser Speichermechanismen siehe unsere Erklärung zu KI-Speicher, Embeddings und RAG.
Ermöglichen von sicheren Datenabfragen durch Agenten
Datenzugriff ist der Bereich, in dem Agenten für .NET-Unternehmen besonders attraktiv werden. Ein Geschäftsnutzer könnte beispielsweise fragen, welche Produkte im letzten Monat den stärksten Verkaufsrückgang verzeichnet haben. Anstatt für jede solche Frage einen speziellen Bericht zu erstellen, kann ein von Agenten unterstütztes System die Frage interpretieren, herausfinden, welche Daten relevant sind, diese abfragen, die Ergebnisse analysieren und erklären, was gefunden wurde.
Die damit verbundene Warnung ist unverhandelbar: Geben Sie niemals einem Modell uneingeschränkten Zugriff auf Ihre Datenbank. Wenn es erlaubt wird, willkürliche SQL-Anfragen zu generieren und auszuführen, können zerstörerische Befehle, Datenlecks zwischen verschiedenen Nutzern sowie Abfragen entstehen, die Tabellen blockieren. Stattdessen sollten eng definierte, speziell entwickelte Operationen mit validierten Parametern sowie eigenen Berechtigungsprüfungen bereitgestellt werden:
GetSalesReport()
GetProductSales()
GetCustomerOrders()
Jede dieser Lösungen kann eine Sicherheit auf Zeilenebene gewährleisten, die Größe der Ergebnisse begrenzen und eine nur zum Lesen geeignete Verbindung verwenden – wodurch man etwas an Flexibilität opfert, um viel Vorhersehbarkeit zu erlangen.
Agenten ersetzen keine Architektur
Eine häufige Fehlvorstellung ist, dass das Hinzufügen eines Modells es ermöglicht, die Grundprinzipien zu vernachlässigen. Tatsächlich ist das Gegenteil der Fall. Dependency Injection, SOLID-Design, Logging, Testing, Authentifizierung, Autorisierung, Fehlerbehandlung, Observabilität sowie eine saubere Schichtung sind umso wichtiger, je mehr ein nicht-deterministischer Komponente entscheidet, was aufgerufen werden soll.
Das nützliche mentale Modell ist eine Trennung der Rollen: Der Agent kann eine Aktion vorschlagen, doch Ihre Anwendung entscheidet, ob diese Aktion erlaubt ist. Kurz gesagt: Die KI entscheidet, Ihre Anwendung regelt. Autorisierungsprüfungen gehören in die Implementierungen der Tools sowie die dahinterliegenden Dienste – niemals in den Prompt, denn ein Prompt ist lediglich ein Vorschlag an das Modell und keine verbindliche Regel.
Sicherheitsrisiken nehmen mit jedem Tool zu
Jedes Tool, das Sie bereitstellen, erhöht die Anzahl möglicher Fehler. Ein Agent kann beispielsweise folgende Aktionen ausführen:
Read customer data
Send emails
Create orders
Delete records
Call external APIs
Drei Fragen folgen. Was passiert, wenn das Modell einfach einen Fehler macht, wie zum Beispiel eine falsche Datenspur löscht? Was geschieht, wenn ein bösartiger Benutzer versucht, den Agenten dazu zu bringen, ein Tool missbräuchlich einzusetzen? Und was passiert, wenn externe Inhalte, die der Agent liest – wie ein E-Mail oder eine Webseite – versteckte Anweisungen enthalten? Dieses letzte Szenario, das üblicherweise als indirekte Prompt-Injektion bezeichnet wird, ist eine reale und gut dokumentierte Angriffsklasse – kein Gedankenexperiment.
Die Schutzmaßnahmen sind größtenteils solche, die Sie bereits kennen und bewusst anwenden:
- Authentifizierung und Autorisierung bei jedem Toolaufruf, ausgerichtet auf den Endbenutzer und nicht auf den Agenten.
- Eingabenauswertung aller Argumente, die das Modell bereitstellt.
Für hochwirksame Vorgänge wie Rückerstattungen, Löschungen oder Ausgangsnachrichten an Kunden ist in der Regel ein Bestätigungsprozess, bei dem eine Person die Aktion freigibt, die günstigste Absicherungsmöglichkeit.
Überwachbarkeit für nicht-lineare Anfragenflüsse
Die herkömmliche Anfrageverarbeitung ist leicht nachvollziehbar, da sie einen geraden Weg verfolgt:
Request → Service → Database → Response
Ein laufender Agent kann sich vor der Erstellung einer Antwort hin- und herbewegen zwischen dem Modell, mehreren Tools sowie verschiedenen Backend-Systemen:
User
↓
AI Model
↓
Tool
↓
API
↓
Database
↓
AI Model
↓
Another Tool
↓
Final Response
Diese Struktur ist weitaus schwieriger zu debuggen. Wenn etwas schiefgeht, muss man herausfinden, welche Tools aufgerufen wurden, warum das Modell sie ausgewählt hat, wie lange jede Aufruf dauerte, was fehlschlug, wie viele Modellaufrufe die Ausführung benötigte und wie viel die gesamte Operation kostete. Betrachten Sie jede Ausführung als Trace mit Zeitintervallen für Modell- und Toolaufrufe, wobei Argumente sowie Tokenzahlen zusammen mit den Zeiten aufgezeichnet werden müssen; andernfalls ist es fast unmöglich, ein falsches Ergebnis nachzuvollziehen.
Warum C#-Entwickler einen Vorsprung haben
Entwickler, die mit C# und .NET vertraut sind, starten nicht von vorne. Schnittstellen und Klassen, HTTP-APIs, DI-Container, asynchrone Codeblöcke, Datenbanken, Authentifizierungssysteme, gehostete Hintergrunddienste sowie Cloud-Deployment bilden genau die Grundlagen von Agentensystemen. Es bleibt nur eine kurze Liste neuer Konzepte, die sich in etwa in dieser Reihenfolge aufeinander beziehen:
LLMs
↓
Prompting
↓
Function Calling
↓
Tools
↓
RAG
↓
Agents
↓
Multi-Agent Systems
Es ist nicht notwendig, alles auf einmal zu übernehmen; beginnen Sie mit kleinen Schritten.
Eine Referenzarchitektur
In einem minimalen Design befindet sich der Agent in der Mitte, wobei einige Tools zu Ihren eigenen Diensten, zur Datenbank und zu einer externen Such-API führen, wobei die Ergebnisse über den Agenten wieder an den Benutzer zurückgegeben werden:
User
↓
AI Agent
↓
┌───────┼────────┐
↓ ↓ ↓
API Tool DB Tool Search Tool
↓ ↓ ↓
.NET Database External API
└───────┼────────┘
↓
Agent Result
↓
User
Die entscheidende Eigenschaft dieser Struktur ist, dass der Agent niemals direkt auf Ihre Systeme zugreift. Jeder Pfad führt über ein Tool, das von Ihrer .NET-Anwendung gesteuert wird, sodass Zugriffskontrolle, Validierung und Protokollierung an einem Ort stattfinden, den Sie bereits bewältigen können.
Ein praktischer Lernweg
Für einen C#-Entwickler, der in den Bereich KI wechseln möchte, sieht ein sinnvoller Fortschrittsweg wie folgt aus:
- Lernen Sie LLMs kennen. Erfahren Sie, wie große Sprachmodelle funktionieren, worin sie gut sind und wo sie versagen, beispielsweise bei zuversichtlichen, aber falschen Antworten.
Ein Kundenservice-Mitarbeiter ist ein guter erster echter Projekttyp, da er alle Aspekte berücksichtigt. Dabei kann er den Kunden ausfindig machen, die Bestellung überprüfen, den Lieferstatus prüfen, ein Ticket erstellen und antworten:
Search customer
↓
Check order
↓
Check delivery status
↓
Create support ticket
↓
Respond to customer
Jeder Schritt entspricht einem spezifischen Tool, und die Schritte mit Nebeneffekten sind klare Kandidaten für Genehmigungsregeln.
Wichtige Erkenntnisse
- Ein Agent ist ein Softwaresystem: ein Modell in Kombination mit Tools, Daten, Anwendungslogik, Sicherheitsmaßnahmen und Überwachung – kein Ersatz für eines dieser Elemente.
- Stellen Sie Funktionen als spezifische, validierte Tools zur Verfügung; gewähren Sie niemals direkten Zugriff auf die Datenbank oder uneingeschränkten API-Zugang.
- Bewahren Sie die Autorisierungen im Code auf, sodass die Anwendung bestimmen kann, was der Agent vorschlägt.
- Kuratieren Sie den Kontext pro Schritt anstatt ihn zu maximieren.
- Verfolgen Sie jeden Ablauf von Anfang bis Ende, damit Fehler und Kosten nachvollziehbar sind.