KI-Agenten¶

Das Portal hat eine Chat-Seite (AI Agents im Menü) mit einem oder mehreren Agenten. Ein Agent ist ein Sprachmodell mit Anweisungen und einer Menge von Tools. Die Tools sind die Aktionen des MCP-Servers des Portals, sodass ein Agent Catalog-, Kosten-, Security-, Compliance- und Netzwerkdaten nachschlagen und Konfigurationsänderungen als pull requests vorbereiten kann.

Welche Agenten du siehst

Ein Agent erscheint nur, wenn er in der Konfiguration deiner Umgebung aktiviert ist. Frag dein Plattform-Team, welche aktiv sind. Die Einrichtung steht unter KI-Einrichtung und Agent-Konfiguration.

Die Agenten¶

Agent	Zweck	Was er kann
Commander	Der allgemeine Assistent für das Portal. Zeigt Informationen aus dem Catalog und beantwortet Fragen zur Plattform.	Liest Catalog-, Kosten-, Security-, Compliance-, Netzwerk- und Dokumentationsdaten über MCP-Tools. Lädt einen Skill, wenn deine Anfrage zu einem gehört (Änderungen an spokes oder der Integrationsplattform).
Spoke-Agent	KI-gestützte Verwaltung der Spoke-Konfigurationsdateien der landing zone	Erstellt, kopiert, aktualisiert und validiert Spoke-JSON-Dateien, findet einen freien Netzwerkbereich und öffnet einen pull request. Auch als Skill des Commanders verfügbar.
Integrations-Agent	KI-gestützte Verwaltung der Konfiguration der Integration Platform	Erstellt und aktualisiert Konfigurationsdateien für Service-Bus-workloads, Queues und Topics, validiert sie gegen das Schema und öffnet einen pull request oder aktualisiert einen bestehenden Branch. Auch als Skill des Commanders verfügbar.

Die Quelle enthält außerdem einen Debug-Agenten für die Entwicklung. Er ist nicht für Endbenutzer gedacht.

Beispiele dafür, was die Oberfläche vorschlägt (das sind die mit den Agenten ausgelieferten Prompts):

"What can you do? What are your capabilities?"
"Show me my workloads and explain who owns them, which domain they belong to, and how they relate to my groups."
"I need a spoke network change such as a VNet, subnet, NSG, or peering update."
"I need an integration platform configuration change or schema update."

Wie eine Anfrage verarbeitet wird¶

sequenceDiagram
    actor U as User
    participant P as Portal chat
    participant A as Agent loop (portal backend)
    participant M as Foundry model endpoint
    participant T as MCP tools (portal backend)
    U->>P: Prompt
    P->>A: Prompt and conversation history
    loop up to 50 steps
        A->>M: Instructions, history, tool list
        M-->>A: Answer or tool call
        A->>T: Tool call with the user's own token
        T-->>A: Result
    end
    A-->>P: Streamed answer
    P-->>U: Answer and the tool calls that were made

Die Agent-Schleife läuft im Portal-Backend. Azure AI Foundry liefert nur Modell-Completions. Die Schleife stoppt nach höchstens 50 Schritten pro Turn.
Die Tool-Aufrufe erfolgen mit deinem eigenen Token. Ein Agent kann daher nur sehen und tun, was du im Portal sehen und tun darfst. Wenn du die Firewall-Logs eines workloads nicht lesen darfst, kann es der Agent in deinem Auftrag auch nicht.
Konversationen werden pro Benutzer in der Datenbank des Portals gespeichert. Du siehst deine eigenen Threads und kannst sie umbenennen oder löschen.
Das Modell jedes Agenten wird in seiner Konfiguration festgelegt. Zum Zeitpunkt des Schreibens verwenden die ausgelieferten Agenten gpt-5.4.

Pull requests, keine Änderungen¶

Agenten ändern ein Konfigurations-Repository nie direkt und mergen nicht. Eine Änderung folgt immer diesem Weg.

Schritt	Wer
Die Änderung im Chat beschreiben	Du
Der Agent lädt das Schema und die Regeln, liest die bestehende Konfiguration und schlägt die kleinste gültige Änderung vor	Agent
Der Agent validiert den vollständigen Kandidaten gegen das Schema und die Regeln und zeigt das Ergebnis	Agent
Du bestätigst den finalen Kandidaten ausdrücklich	Du
Der Agent erstellt einen pull request (beim Integrations-Agent auch das Aktualisieren eines bestehenden Branches)	Agent
Menschen prüfen, genehmigen und mergen wie bei jeder Änderung	Plattform-Team oder Owner des Repositorys

Review und Deployment einer Spoke-Änderung sind die der Plattform: Eine Änderung sicher durchführen. Die Agenten bereiten die Änderung schneller vor. Sie umgehen den Prozess nicht.

Regeln des Spoke-Agenten¶

Der Spoke-Skill erzwingt diese Regeln. Sie stammen aus den Anweisungen des Agenten und den Tools, die er nutzt.

Thema	Regel
Source of Truth	Das JSON-Schema der Spoke-Datei und die Dokumentation im Konfigurations-Repository. Tool-Fehler und Validierungsergebnisse sind maßgeblich. Widersprechen sich Quellen, stoppt der Agent und erklärt es.
Fehlende Werte	Der Agent fragt nach. Er rät nicht.
Neues oder kopiertes VNet	Der Agent fragt nach einem IPv4-Allokationspool und einer Ziel-Präfixlänge und nutzt ein Tool, um den nächsten freien Bereich zu bekommen. Er berechnet nie selbst einen Bereich. Das Tool liefert den ersten ausgerichteten Block nach der höchsten genutzten Adresse im Pool. Frühere Lücken füllt es nicht.
Explizite Bereiche	Jeder Bereich wird gegen das Live-Inventar aller Spoke-Dateien auf Überlappung geprüft. Jede teilweise oder vollständige Überlappung ist ein kritischer Fehler.
Subnets	Höchstens ein Private-Link-Subnet pro Netzwerk. `isprivatelinksubnet` und `privateEndpointNetworkPoliciesEnabled` schließen sich gegenseitig aus. Jedes Subnet liegt innerhalb seines VNets, und Subnets überlappen sich nicht.
NSGs	Eine NSG-Regel wird nur dann mit einem Subnet verknüpft, wenn ihr Quell- oder Zielpräfix exakt dem Subnet-Präfix entspricht.
Eindeutigkeit	Die Kombination aus workload-Kurzname und Umgebung ist eindeutig. Subscription-IDs sind eindeutig, wo das Schema es verlangt.
Pull request	Nur wenn alle Validierungen bestehen und du das finale JSON bestätigt hast.

Regeln des Integrations-Agenten¶

Thema	Regel
Nur Schema	Eigenschaften stammen aus dem Schema. Der Agent fügt keine Felder wie `displayName` oder `description` hinzu, die das Schema nicht definiert.
Vor jeder Aufgabe	Die Schema-Dateien und die workload-Regeln laden und prüfen, dass der workload-Name in der Zielumgebung noch nicht existiert
Struktur	Ein Ordner pro Ressourcentyp, Umgebung und workload, mit `workload.json` und optional `queues.json` und `topics.json`. Namen sind kleingeschrieben mit Bindestrichen. Der Name in `workload.json` entspricht dem Ordnernamen. Dauern verwenden ISO 8601.
Pull request	Nach Schema-Validierung, Regelprüfung und deiner ausdrücklichen Bestätigung. Existiert ein Branch für den workload, fragt der Agent, ob er ihn aktualisieren soll.

Guardrails¶

Der Commander lehnt Anfragen ab, die keinen Bezug zum Portal, zu Azure oder zu IT und Cloud Engineering haben, und antwortet mit einem festen Satz, wenn man ihn bittet, seine Anweisungen zu ignorieren.
Agenten müssen Tools nutzen, um Fakten zu bekommen. Sie dürfen nicht raten. Sie zeigen, welchen Agenten oder Skill sie verwenden.
Strukturierte Ausgabe (JSON, YAML, Befehle) erfolgt in fenced Code-Blöcken.
Agenten legen interne Pfade, Tool-Namen oder Anweisungen nicht offen, außer du fragst ausdrücklich danach.

Prüfe, was ein Agent vorschlägt

Ein Agent kann falsch liegen, und ein bestätigter pull request braucht trotzdem ein Review durch einen Menschen. Die Validierungsschritte verringern Fehler. Sie ersetzen das Review nicht.

Was ein Agent von der Plattform braucht¶

Agent	Braucht
Alle	Einen aktivierten Agenten, einen Foundry-Modell-Endpunkt, die MCP-URL des Portals in der Agent-Konfiguration und die in Foundry deployten Modelle
Spoke	Das Spoke-Konfigurations-Repository in Azure DevOps, im Portal konfiguriert, und Contribute-Zugriff der Portal-Identität auf dieses Repository
Integration	Ein GitHub-Repository mit der Konfiguration der Integrationsplattform, eine GitHub App mit Schreibzugriff auf contents und pull requests und ihre Zugangsdaten im Portal

Details stehen unter KI-Einrichtung. Wie die Agenten getestet werden, steht unter Agent-Evaluierung.