Laufzeit serverloser Agenten in Azure Functions

Die serverlose Agentenlaufzeit von Azure Functions ist ein Markdown-zentriertes Programmiermodell zum Erstellen von KI-Agenten als Azure Functions-Apps. Anstatt Hosting, Trigger, Modellclients, Tools, Sitzungsspeicher, Identität und Beobachtbarkeit miteinander zusammenzufügen, definieren Sie Agenten in .agent.md-Dateien und stellen sie als Funktions-App bereit.

Die Laufzeit ist für Agenten ausgelegt, die auf Ereignisse reagieren, Werkzeuge aufrufen und auf serverloser Infrastruktur laufen. Agents können durch HTTP-Anforderungen, Zeitpläne, Warteschlangen, Nachrichten, Datenbankänderungen und andere Ereignisse ausgelöst werden, Remote-MCP-Server, in Connector-Namespaces gehostete MCP-Server, wiederverwendbare Skills und eine isolierte Ausführung in einer Sandbox nutzen und mit denselben Funktionen für Bereitstellung, Identität, Überwachung und Skalierung ausgeführt werden, die auch von anderen Azure Functions-Apps verwendet werden. Für appspezifische Logik können Sie benutzerdefinierte Tools in derselben Funktions-App schreiben.

Warum Agents auf Azure Functions aufbauen?

Produktionsmitarbeiter benötigen mehr als eine Eingabeaufforderung und ein Modell. Sie benötigen zuverlässige Möglichkeiten, um mit der Arbeit zu beginnen, externe Systeme aufzurufen, aufgezeichnete Unterhaltungen beizubehalten, nicht vertrauenswürdigen Code sicher auszuführen, ohne geheime Schlüssel zu authentifizieren, Telemetrie auszustrahlen und bedarfsgesteuert zu skalieren.

Azure Functions stellt bereits ein ereignisgesteuertes Computemodell für diese betrieblichen Bedenken bereit. Die Laufzeit für serverlose Agenten überträgt dieses Modell auf Agenten:

• Agenten sind die Arbeitseinheit. Eine .agent.md Datei definiert den Trigger und die Anweisungen für einen Agent.
• Ereignisse starten Agents. Durch Trigger-Funktionen können Agents nach einem Zeitplan ausgeführt werden, auf Warteschlangen und Ereignisse reagieren oder HTTP-Endpunkte zur Verfügung stellen.
• Funktionen werden zunächst konfiguriert – Code kommt nur bei Bedarf zum Einsatz. Agents können Remote-MCP-Server, in Konnektor-Namespaces gehostete MCP-Server, Skills und die Ausführung von Code in der Sandbox über die Konfiguration nutzen. Verwenden Sie benutzerdefinierte Tools für appspezifische Logik.
• Hosting ist serverlos. Flex Consumption unterstützt das Herunterskalieren auf null, sekundengenaue Abrechnung, verwaltete Identität, die Integration in virtuelle Netzwerke und Application Insights.
• Das operative Plumbing ist integriert. Die Laufzeit übernimmt die Agentenerkennung, die Trigger-Registrierung, die Tool-Zusammenstellung, den Sitzungsverlauf und optionale integrierte Endpunkte.

Projektstruktur

Eine serverlose Agents-App ist eine Python Azure Functions-App mit agentspezifischen Dateien neben den normalen Funktionen-Projektdateien.

Ein minimales Projekt hat function_app.py, host.json, requirements.txtund mindestens eine .agent.md Datei. Fügen Sie hinzu agents.config.yaml , wenn die App appweite Laufzeitstandardwerte benötigt.

Agent-Dateien

Eine Agentdatei verwendet YAML-Front-Matter gefolgt von Markdown-Anweisungen. In diesem Beispiel wird ein zeitgesteuerter Agent definiert:

---
name: Daily Tech News Email
description: Fetches top tech news and emails a summary daily.

trigger:
  type: timer_trigger
  args:
    schedule: "0 0 15 * * *"
---

You are a news assistant. When triggered, do the following:

1. Gather today's top technology news from reputable sources.
1. Summarize the stories in a concise HTML email body.
1. Email the summary to $TO_EMAIL with the subject "Daily Tech News Summary".

Der Vorspann legt fest, wie der Agent aufgerufen wird. Der Markdown-Body ist der Anweisungsblock, den die Runtime während der Ausführung an das Modell weitergibt. Die Ersetzung von Umgebungsvariablen ermöglicht es Anweisungen und Konfigurationswerten, auf App-Einstellungen wie $TO_EMAIL zu verweisen.

Jede .agent.md Datei definiert einen Agent. Der Dateiname wird verwendet, um den Azure Funktionsnamen und das Routensegment für integrierte Endpunkte abzuleiten. Das name Feld ist ein Anzeigename, der in Protokollen, Bezeichnungen und Dokumentationen verwendet wird.

Verwenden Sie diese Front-Matter-Felder, um einen Agent zu konfigurieren:

Laufzeitstandardwerte in agents.config.yaml

Verwenden Sie agents.config.yaml für app-weite Standardwerte für die Laufzeit, die von jedem Agenten geerbt werden können. Die Laufzeit kann eine App ohne diese Datei laden. Fügen Sie sie hinzu, wenn Sie gemeinsame Einstellungen wie eine Modellbereitstellung, ein Timeout oder einen Sandbox-Ausführungsendpunkt benötigen.

Diese Datei ist eine Eingabe auf App-Ebene. Die Runtime ermittelt außerdem MCP-Server von mcp.json, Skills von skills/ und angepasste Python-Tools von tools/. Diese Funktionen sind standardmäßig für Agents aktiviert. Das Front Matter des Agent kann die Standardeinstellungen der Runtime überschreiben oder geerbte MCP-Server, Skills und Tools filtern.

system_tools:
  dynamic_sessions_code_interpreter:
    endpoint: $ACA_SESSION_POOL_ENDPOINT

model: $FOUNDRY_MODEL
timeout: 900

Einzelne Agents können die unterstützten Runtime-Einstellungen in ihrem eigenen Front Matter überschreiben.

Verwenden Sie diese Felder auf oberster Ebene in agents.config.yaml:

Die Runtime löst zuerst Werte aus dem Front Matter der Agent auf, dann agents.config.yaml, dann App-Einstellungen und Runtime-Standardwerte. Zeichenfolgenwerte in agents.config.yaml können auf Appeinstellungen verweisen, wie $AZURE_OPENAI_DEPLOYMENT oder $ACA_SESSION_POOL_ENDPOINT.

Modell-, Timeout- und Standardwerte für Systemtools in agents.config.yaml beibehalten. Speichern Sie Definitionen für Remote-MCP-Server, einschließlich MCP-Serverendpunkten aus Connector-Namespaces, in mcp.json.

Variablenersetzung

Die Runtime kann App-Einstellungen und Umgebungsvariablen durch Zeichenfolgen im Front Matter, im Body der Agents, agents.config.yaml und mcp.json ersetzen. Verwenden Sie $SETTING_NAME oder %SETTING_NAME%. Variablennamen müssen mit einem Buchstaben oder Unterstrich beginnen und können Buchstaben, Zahlen und Unterstriche enthalten.

model: $FOUNDRY_MODEL
system_tools:
  dynamic_sessions_code_interpreter:
    endpoint: %ACA_SESSION_POOL_ENDPOINT%

Email the summary to $TO_EMAIL.

{
  "servers": {
    "office365": {
      "type": "http",
      "url": "$O365_MCP_SERVER_URL"
    }
  }
}

Die Ersetzung gilt für Zeichenfolgenwerte, einschließlich Zeichenfolgen, die in Objekten oder Listen geschachtelt sind. Sie gilt nicht für Objektschlüssel. Abgegrenzte Codeblöcke in Anweisungstexten für Agenten werden nicht ersetzt, sodass Beispiele den Literaltext $VALUE oder %VALUE% enthalten können.

Verwenden Sie $$SETTING_NAME oder %%SETTING_NAME%%, wenn Sie einen wörtlichen Platzhalter in ersetztem Inhalt benötigen. Fehlende Umgebungsvariablen bleiben unverändert, leere Werte werden in leere Zeichenfolgen aufgelöst, und die Ersetzung ist ein einzelner Durchlauf. Die ${SETTING_NAME} Syntax wird nicht unterstützt.

Um die Ersetzung für das Front Matter und die Anweisungen eines Agents zu deaktivieren, legen Sie substitute_variables: false in der Agent-Datei fest. Diese Einstellung deaktiviert keine Ersetzung in agents.config.yaml oder mcp.json.

So startet die Laufzeit eine App

Wenn der Azure Functions Host die App importiert, erstellt create_function_app() eine konfigurierte FunctionApp aus den Projektdateien:

1. Auflösen des Stammverzeichnisses der App.
2. agents.config.yaml laden.
3. Laden Sie jede .agent.md Datei.
4. Entdecken Sie MCP-Server, Fähigkeiten und benutzerdefinierte Tools.
5. Verfassen von appweiten Standardeinstellungen und Konfigurationen pro Agent.
6. Überprüfen Sie die konfiguration des aufgelösten Agents.
7. Erstellen Sie die endgültigen Tools und Fähigkeiten für jeden Agent.
8. Registrieren Sie Azure Functions Trigger und optionale integrierte Endpunkte.

Nach dem Start indiziert der Azure Functions Host die registrierten Trigger genau wie für andere Funktions-Apps. Wenn ein Trigger ausgelöst wird, erstellt die Laufzeit den Agent mit seinen Anweisungen, Modelleinstellungen, Tools, Fähigkeiten und Sitzungsverlauf, und führt ihn dann über Microsoft Agent Framework aus.

Triggern von Agents durch Ereignisse

Serverlose Agents sind nützlich, wenn das Ereignis, das die Arbeit startet, so wichtig ist wie der Modellaufruf. Die Laufzeit unterstützt einen Trigger pro Agentdatei.

Eine Triggerdefinition weist ein type Und ein args Objekt auf. Die type Triggerbindung identifiziert und args enthält die triggerspezifischen Einstellungen, die konfigurieren, welches Ereignis den Agent startet.

trigger:
  type: timer_trigger
  args:
    schedule: "0 0 15 * * *"

Zu den allgemeinen Triggertypen gehören http_trigger, timer_trigger, queue_trigger, blob_trigger, event_grid_trigger und service_bus_trigger. Verwenden Sie für integrierte Azure Functions-Trigger die Python v2-Dokumentation zu Triggern und Bindungen sowie die Bindungsreferenz für den jeweiligen Trigger, um die Einstellungen zu finden, die in args aufzunehmen sind. Ein Timertrigger verwendet beispielsweise eine schedule Einstellung, ein Warteschlangentrigger verwendet Einstellungen wie queue_name und connection, und ein BLOB-Trigger verwendet Einstellungen wie path und connection. Die Laufzeit stellt den Einstiegspunkt der generierten Funktion bereit, sodass die Agentdatei nur die Triggereinstellungen benötigt, die die Ereignisquelle identifizieren.

Zu den gängigen Triggermustern gehören:

Da jeder Agent als Azure Function registriert ist, kann die App Hostingfunktionen von Functions wie Skalierungsregeln, verwaltete Identität, Netzwerkfunktionen und Überwachung nutzen.

Agents-Tools bereitstellen

Agenten werden nützlich, wenn sie handeln können. Beginnen Sie mit konfigurierten Funktionen: Remote-MCP-Server, MCP-Server, die in Connectornamespaces, Fähigkeiten und Sandkastenausführung gehostet werden. Verwenden Sie benutzerdefinierte Python Tools für app-spezifische Funktionen, die nicht zu diesen Optionen passen.

Fern-MCP-Server

Wenn eine App Remote-MCP-Server verwendet, fügen Sie mcp.json dem Stammverzeichnis des Funktions-App-Projekts hinzu. Die Laufzeit erkennt entfernte HTTP- oder per HTTP streambare MCP-Server aus dieser Datei und stellt deren Werkzeuge Agenten zur Verfügung, vorbehaltlich etwaiger agentenspezifischer Filter.

Verwenden Sie diese Felder in jedem servers Eintrag:

Verwenden Sie Remote-MCP-Server, wenn Agents Tools aufrufen müssen, die von einem anderen Dienst gehostet werden, oder verfassen Sie Agents und Tools über App-Grenzen hinweg.

Azure-Konnektoren

Connectors ermöglichen Agents das Arbeiten mit externen Diensten ohne benutzerdefinierten API-Clientcode. Beispielsweise kann ein Microsoft 365 Outlook Connector E-Mails senden, ein Teams-Connector kann mit Nachrichten arbeiten, und andere Connectors können Aktionen in Systemen wie Salesforce, SAP oder SQL aufrufen. Ein Connectornamespace hostet die Verbindungen, Trigger und MCP-Server, die diese Integrationen für Ihre App verfügbar machen.

Um Connectorfunktionen in einer serverlosen Agents-App zu verwenden, erstellen Sie zuerst einen Connectornamespace, erstellen Sie eine Verbindung mit dem Dienst, und autorisieren Sie diese Verbindung. Wählen Sie dann aus, wie der Agent die Verbindung verwendet:

• Connectorauslöser starten Agents, wenn in einem verbundenen Dienst etwas passiert, z. B. eine neue E-Mail, eine Teams-Nachricht oder ein Kalenderereignis. Um einen zu verwenden, erstellen Sie einen Trigger im Connector-Namespace, der die autorisierte Verbindung verwendet, und konfigurieren Sie dann den Agent mit dem Triggernamen und den Argumenten aus dieser Connectortriggerdefinition.
• Connector MCP-Tools ermöglichen es Agenten, Dienstaktionen aufzurufen, beispielsweise E-Mails zu senden oder einen Datensatz zu aktualisieren. Um sie zu verwenden, erstellen Sie einen MCP-Server im Connector-Namespace, der die autorisierte Verbindung verwendet, und fügen Sie dann den MCP-Serverendpunkt hinzu mcp.json.

Bei Connector-MCP-Tools speichert ein MCP-Servereintrag in mcp.json den Endpunkt- und verwalteten Identitätsauthentifizierungseinstellungen. Verwenden Sie den Azure API Hub-Bereich, wenn der Agent einen verwalteten MCP-Server aus einem Connectornamespace nutzt. Speichern Sie keine geheimen Benutzerschlüssel in mcp.json.

{
  "servers": {
    "office365-outlook": {
      "type": "http",
      "url": "$O365_MCP_SERVER_URL",
      "auth": {
        "scope": "https://apihub.azure.com/.default",
        "client_id": "$O365_MCP_CLIENT_ID"
      }
    }
  }
}

Die auth.client_id Einstellung wählt aus, welche verwaltete Identität beim MCP-Server authentifiziert wird. Legen Sie sie auf die Client-ID einer vom Benutzer zugewiesenen verwalteten Identität fest. Lassen Sie sie aus, um die vom System zugewiesene verwaltete Identität der Funktions-App in Azure zu verwenden. Die ausgewählte Identität oder Ihre lokale Entwickleridentität bei lokaler Ausführung müssen den MCP-Server aufrufen dürfen.

Fähigkeiten

Skills sind wiederverwendbare Prompt-Ressourcen, die unter skills/ gespeichert sind. Sie helfen dabei, die Basis-Agent-Anweisungen klein zu halten, während sie bei Bedarf domänenspezifische Anweisungen zur Verfügung stellen. Die Laufzeitumgebung verwendet das Agent Skills-Format.

Die Laufzeit durchsucht skills/ im Stammverzeichnis des Function-App-Projekts und ermittelt rekursiv Ordner, die SKILL.md enthalten:

skills/
  incident-response/
    SKILL.md
    triage-checklist.md
    escalation-policy.md

Die SKILL.md Datei enthält YAML-Front-Matter gefolgt von Markdown-Anweisungen:

---
name: incident-response
description: Triage production incidents, summarize impact, and recommend next steps. Use when the task mentions incidents, outages, alerts, or severity levels.
---

Follow the incident response checklist in [triage-checklist.md](triage-checklist.md).

Verwenden Sie die folgenden Regeln zum Erstellen von Skills:

• Jeder Qualifikationsordner muss eine SKILL.md Datei enthalten.
• Die Felder name und description sind erforderlich.
• Qualifikationsnamen müssen Kleinbuchstaben, Zahlen und einzelne Bindestriche verwenden. Verwenden Sie keine Leerzeichen, Unterstriche, Großbuchstaben, führende Bindestriche, nachfolgende Bindestriche oder wiederholte Bindestriche.
• Qualifikationsnamen müssen in der gesamten App eindeutig sein.
• Die Beschreibung sollte sowohl erklären, was die Fähigkeit tut als auch wann der Agent es verwenden sollte. Die Laufzeit lädt zuerst Qualifikationsnamen und Beschreibungen, damit der Agent entscheiden kann, wann die volle Fähigkeit geladen werden soll.
• Fähigkeiten können mehrere Markdowndateien im selben Qualifikationsordner enthalten. Verweisen Sie von SKILL.md aus mithilfe relativer Links auf zugehörige Markdown-Dateien.
• In der Laufzeit serverloser Agenten werden nur Markdown-Dateien als Skill-Inhalte unterstützt. Wenn eine Fähigkeit ausführbare Funktionalität benötigt, packen Sie diesen Code in ein benutzerdefiniertes Python-Tool und verweisen Sie in den Anweisungen für die Fähigkeit unter seinem Namen auf das Tool.

Agents erben standardmäßig alle ermittelten Fähigkeiten. Deaktivieren oder Ausschließen von Fähigkeiten in einer Agentdatei, wenn ein bestimmter Agent sie nicht verwenden sollte:

skills: false

skills:
  exclude:
    - incident-response

Ausführung in einer Sandbox

Für die Codeausführung oder Browserautomatisierung kann die Laufzeit Azure Container Apps dynamische Sitzungen verwenden. Dynamische Sitzungen stellen isolierte Umgebungen aus Sitzungspools bereit. Die Laufzeit verwendet Code-Interpreter-Sitzungen, um Agenten ein execute_python-Tool bereitzustellen.

Konfigurieren der Sandkastenausführung in agents.config.yaml:

system_tools:
  dynamic_sessions_code_interpreter:
    endpoint: $ACA_SESSION_POOL_ENDPOINT

Verwenden Sie die folgenden Sandkastenanforderungen:

• Der Sitzungspool muss ein Sitzungspool für den Python-Code-Interpreter sein, beispielsweise ein mit --container-type PythonLTS erstellter Pool.
• Der endpoint Wert ist der Sitzungspoolverwaltungsendpunkt.
• In Azure muss die von der Funktions-App verwendete verwaltete Identität über die Rollenzuweisungen verfügen, die zum Ausführen von Code im Sitzungspool erforderlich sind. Azure Container Apps Code-Interpreter-Sitzungen erfordern die Rollen Azure ContainerApps Session Executor und Contributor für den Sitzungspool.
• Wenn Sie lokal ausgeführt werden, muss Ihre Entwickleridentität über den gleichen erforderlichen Zugriff auf den Sitzungspool verfügen.
• Wenn Sie eine vom Benutzer zugewiesene verwaltete Identität für die Sandkastenausführung verwenden möchten, legen Sie diese auf die Client-ID der Identität fest system_tools.dynamic_sessions_code_interpreter.client_id , die über die erforderlichen Rollenzuweisungen verfügt. Wenn diese Einstellung nicht festgelegt ist, verwendet die Runtime AZURE_CLIENT_ID, also die Standard-Anmeldeinformationenkette.

Das Sandbox-Tool führt Python in einer isolierten Sitzung aus. Variablen, Importe und Dateien können über Toolaufrufe in derselben Agentsitzung hinweg beibehalten werden. Wenn keine Sitzungs-ID des Agents verfügbar ist, verwendet die Runtime eine frische Sandbox-Sitzung, damit nicht verwandte Ausführungen keinen gemeinsamen Status haben.

Agenten erben die Ausführung in einer Sandbox, wenn diese global konfiguriert ist. Deaktivieren Sie ihn für einen bestimmten Agent, wenn dieser Agent keinen Code ausführen sollte:

system_tools:
  dynamic_sessions_code_interpreter: false

Benutzerdefinierte Python-Tools

Verwenden Sie benutzerdefinierte Python-Tools für anwendungsspezifische Funktionen, die nicht zu MCP-Servern, in Connector-Namespaces gehosteten MCP-Servern, Skills oder isolierter Ausführung passen. Mit benutzerdefinierten Tools können Sie Azure Functions- und Python Pakete aus derselben Funktions-App verwenden.

Hinzufügen von Tooldateien zum tools/ Ordner im Stammverzeichnis des Funktions-App-Projekts:

tools/
  submit_ticket.py
  lookup_customer.py

Die Laufzeit findet die .py Dateien in tools/, deren Dateinamen nicht mit _ beginnen. In der aktuellen Vorschau registriert die Laufzeit das erste unterstützte Tool aus jeder Datei. Verwenden Sie ein Tool pro Datei, um die Ermittlung vorhersagbar zu halten.

Sie können ein Tool definieren, indem Sie eine Funktion mit @tool aus dem Laufzeitpaket dekorieren:

from azure_functions_agents import tool


@tool(name="submit_ticket", description="Create a support ticket with a title and summary.")
async def submit_ticket(title: str, summary: str) -> str:
    return f"Created ticket for {title}: {summary}"

Verwenden Sie für umfangreichere Parameterbeschreibungen und Validierung ein Pydantisches Modell als Toolschema:

from pydantic import BaseModel, Field
from azure_functions_agents import tool


class LookupCustomerParams(BaseModel):
    customer_id: str = Field(description="Customer identifier from the CRM system.")


@tool(schema=LookupCustomerParams, description="Look up customer details by customer ID.")
async def lookup_customer(params: LookupCustomerParams) -> str:
    return f"Customer details for {params.customer_id}"

Sie können auch eine einfache Python-Funktion ohne den Dekorator definieren. Die Laufzeit umschließt die erste einfache Funktion, die sie in der Datei findet, verwendet den Funktionsnamen als Toolnamen und verwendet die Docstring als Toolbeschreibung.

def summarize_order(order_id: str) -> str:
    """Summarize an order by order ID."""
    return f"Summary for order {order_id}"

Toolnamen, Beschreibungen, Typhinweise und Pydantische Feldbeschreibungen helfen dem Modell zu entscheiden, wann und wie das Tool aufgerufen werden soll. Fügen Sie alle Paketabhängigkeiten, die von benutzerdefinierten Tools verwendet werden, zu requirements.txt hinzu, so wie bei anderem Python-Code in einer Azure Functions-App.

Agents übernehmen standardmäßig erkannte benutzerdefinierte Tools. Deaktivieren oder Ausschließen von benutzerdefinierten Tools in einer Agentdatei, wenn ein bestimmter Agent sie nicht verwenden sollte:

tools: false

tools:
  exclude:
    - submit_ticket

Konfigurieren von Modellanbietern

Die Laufzeit verwendet Microsoft Agent Framework zum Aufruf von Modellanbietern. Die Vorschauunterstützung umfasst Azure OpenAI, Azure AI Foundry und OpenAI.

Die Anbieterauswahl basiert auf Den App-Einstellungen. Sie können den Anbieter mit AZURE_FUNCTIONS_AGENTS_PROVIDER festlegen oder die Runtime den Anbieter aus Einstellungen wie z. B. AZURE_OPENAI_ENDPOINT, FOUNDRY_PROJECT_ENDPOINT oder OPENAI_API_KEY ableiten lassen.

Die Modellauswahl verwendet diese allgemeine Rangfolge:

1. Das vom Agenten oder Runtime-Aufruf angeforderte Modell.
2. Anbieterspezifische Einstellungen, wie z. B. AZURE_OPENAI_DEPLOYMENT oder FOUNDRY_MODEL.
3. AZURE_FUNCTIONS_AGENTS_MODEL.
4. Die Standardeinstellung des Anbieters.

Für Produktions-Apps bevorzugen Sie verwaltete Identität, sofern unterstützt. Wenn eine App eine vom Benutzer zugewiesene verwaltete Identität verwenden soll, legen Sie diese Identität so fest AZURE_CLIENT_ID , dass Modellanbieter und Sandkastenausführung diese Identität verwenden.

Konfigurieren verwalteter Identitäten

Die Laufzeit verwendet verwaltete Identität für Azure Ressourcen, die Microsoft Entra Authentifizierung unterstützen. Verwenden Sie AZURE_CLIENT_ID als Standard-Identitätsauswahl der App. MCP-Server, die in Connector-Namespaces gehostet werden, und blobgestützter Sitzungsverlauf können spezifischere Identitätseinstellungen verwenden.

Legen Sie für Modellanbieter und Sandkastenausführung fest AZURE_CLIENT_ID , wann die Laufzeit eine vom Benutzer zugewiesene verwaltete Identität verwenden soll. Wenn AZURE_CLIENT_ID nicht festgelegt ist, verwendet die Laufzeit das Standardverhalten für Azure SDK-Anmeldeinformationen, das die vom System zugewiesene verwaltete Identität einschließen kann, wenn eine solche verfügbar ist.

Verwenden Sie diese Einstellungen, um verwaltete Identitäten auszuwählen:

Bei Azure OpenAI gelten diese Identitätseinstellungen nur, wenn AZURE_OPENAI_API_KEY nicht festgelegt ist. Wenn ein API-Schlüssel konfiguriert ist, verwendet der Modellanbieter den Schlüssel anstelle der verwalteten Identität.

Der Sitzungsverlauf verwendet dieselbe Speicheridentitätskonfiguration wie der Azure Functions-Host. Verwenden Sie AzureWebJobsStorage, AzureWebJobsStorage__blobServiceUri und AzureWebJobsStorage__clientId, um identitätsbasierten Speicher für den Blob-gestützten Verlauf zu konfigurieren. Die Laufzeit verwendet keine separate agentspezifische Identitätseinstellung für den Sitzungsverlauf.

Sitzungen und Status

Die Interaktionen von Agents mit mehreren Turns erfordern eine Sitzungshistorie. In Azure speichert die Runtime die Sitzungshistorie in Blob Storage, indem sie das AzureWebJobsStorage-Konto der Function App verwendet. Dieses Design vermeidet eine separate Sitzungsdatenbank für viele Apps und funktioniert mit der Verbindungszeichenfolgen- oder identitätsbasierten Speicherkonfiguration.

Bei der lokalen Entwicklung ohne Azure-Speicherkonfiguration kann die Laufzeit auf einen dateibasierten Sitzungsverlauf unter dem lokalen Agentenkonfigurationsverzeichnis zurückgreifen.

Die Ausführung in einer Sandbox ist ebenfalls sitzungsbezogen. Wenn die Laufzeit Sandbox-Tools ohne eine explizite Sitzungs-ID erstellt, verwendet sie für den Aufruf eine isolierte Sitzung, anstatt den Status über nicht zusammenhängende Agentenläufe hinweg gemeinsam zu nutzen.

Integrierte Endpunkte

Die Laufzeit kann integrierte Debug- und Kompositionsendpunkte ohne zusätzlichen Anwendungscode verfügbar machen. Verwenden Sie die Chat-UI und Chat-APIs für Entwicklung, Tests und Diagnosen, nicht als primäre Produktionsanwendungsschnittstelle.

Jeder Agent kann sich über builtin_endpoints-Einstellungen in seinem Front Matter registrieren. Das <AGENT_NAME> Routensegment wird vom Dateinamen und nicht vom .agent.md Anzeigefeld name abgeleitet. Zum Beispiel verwendet main.agent.md/agents/main/.

Wenn sie in Azure gehostet wird, fordert die Chat-Benutzeroberfläche vor dem Senden von Nachrichten zur Eingabe eines Funktionsschlüssels auf. Sie können diesen Schlüssel auch verwenden, um die HTTP-Chat-APIs direkt aufzurufen:

az functionapp keys list \
  --resource-group <RESOURCE_GROUP> \
  --name <FUNCTION_APP_NAME> \
  --query "functionKeys.default" \
  --output tsv

Übergeben Sie den Schlüssel im x-functions-key-Header oder dem code-Abfragezeichenfolgeparameter. Um einen MCP-Client zu verbinden, rufen Sie stattdessen den MCP-Erweiterungssystemschlüssel ab:

az functionapp keys list \
  --resource-group <RESOURCE_GROUP> \
  --name <FUNCTION_APP_NAME> \
  --query "systemKeys.mcp_extension" \
  --output tsv

Der MCP-Endpunkt erfordert diesen Systemschlüssel, es sei denn, die App konfiguriert anonymen Zugriff.

Wann Sie die Runtime für serverless Agents verwenden sollten

Verwenden Sie die serverlose Laufzeit für Agents, wenn Ihr Agent ereignisgesteuert ist, viele Tools verwendet oder betrieblich eng an Azure-Functions-Workloads angelehnt ist.

Geeignete Optionen sind:

• Geplante Hintergrund-Agenten, die zusammenfassen, überwachen, abgleichen oder Berichte erstellen.
• Ereignisgesteuerte Assistenten, die auf Nachrichten, E-Mails, Warnungen, Warteschlangennachrichten oder Datenänderungen reagieren.
• Systemübergreifende Agenten, die Konnektoren verwenden, um Arbeiten über SaaS- und Unternehmensanwendungen hinweg zu koordinieren.
• Unterhaltungs-Front-Ends, die denselben Agent über HTTP, Chat-UI oder MCP verfügbar machen.
• Agents, die auf Null skalieren und verwaltete Identität, Überwachung, Bereitstellungs-Slots und andere Funktionalitäten des Azure-Hostings nutzen sollen.

Wenn Sie nur deterministische Funktionen als Tools für einen anderen KI-Client verfügbar machen müssen, ist die Azure Functions MCP-Erweiterung möglicherweise ein besserer Ausgangspunkt. Weitere Informationen finden Sie unter Verwenden von KI-Tools und -Modellen in Azure Functions.

Erste Schritte

Beginnen Sie mit der Schnellstartanleitung zum Bereitstellen einer serverlosen Agents-App mit einem Chat-Agent, einem zeitgesteuerten Blogzusammenfassungs-Agent, einer Modellbereitstellung, sandkastenbasierter Ausführung und optionalen MCP-Tools aus einem Connectornamespace:

Verwandte Inhalte

• Nutzung von KI-Tools und -Modellen in Azure Functions
• Builden eines benutzerdefinierten MCP-Remoteservers mit Azure Functions
• Verbinden Eines MCP-Servers auf Azure Functions zum Foundry Agent Service
• Hosting für den Flex Consumption-Plan