Agenten auf Azure Databricks bereitstellen

Um einen Agenten in der Produktion auszuführen, deployen Sie dessen Code in Managed Compute, die Anfragen von Ihren Benutzern und Anwendungen bedient. Ein bereitgestellter Agent besteht aus drei Schichten: Ihrem Framework oder Harness, einem Agentenserver und einer Agentenlaufzeit. Agent Bricks bietet auf jeder Ebene Optionen, von DurableAgentServer bis zu Agent Runtime auf Databricks Apps.

Der Compute-Stack des Agenten

Ein eingesetzter Agent besteht aus drei Schichten. Jede Schicht umhüllt die über ihr liegende.

Der Agent Compute Stack: Ihr Framework oder Harness, umgeben von einem Agentenserver, der die Aufruf-API bereitstellt und auf Agent Runtime läuft.

Ebene Was es bewirkt Optionen in Azure Databricks
Framework oder Harness Führt die Agentenschleife aus: ruft Modelle und Tools auf und entscheidet, was als Nächstes zu tun ist. Jedes Framework oder Harness, wie LangGraph oder das OpenAI Agents SDK, oder ein Meta-Harness wie Omnigent.
Agent-Server Kapselt die Agentenschleife in einen HTTP-Server. Der Agent-Server stellt die Aufruf-API bereit, verwaltet Client-Verbindungen und sorgt für Persistenz. DurableAgentServer (empfohlen), Legacy-Agent-Servern oder deinem eigenen Server.
Agentenlaufzeit Betreibt den Agentenserver auf verwalteter Rechenleistung und übernimmt Hosting, Identität und Skalierung. Agent Runtime auf Databricks Apps.

Die folgenden Begriffe beschreiben, wie die Schichten zusammenarbeiten:

Begriff Was dies bedeutet
Invocation API Die HTTP-API, die Clients aufrufen, um den Agenten auszuführen. Siehe Abfrageagenten, die auf Azure Databricks bereitgestellt werden.
Bereitstellen Der Agent-Runtime betreibt den Agent-Server, der deinen Agenten über die Invocation-API bedient.
Deploy Stellen Sie Ihren Agentencode auf der Agent Runtime bereit.

Note

Databricks Sandbox ist keine Schicht des Compute-Stacks. Es ist ein Tool, das dein Agent aufruft, um Code in einer isolierten Umgebung auszuführen, getrennt vom Agenten-Runtime, mit begrenztem Zugriff auf deine verwalteten Daten. Verwenden Sie eine Sandbox, wenn Ihr Agent Code schreibt und ausführt, wie zum Beispiel Datenanalyse-Skripte. Um einem CLI-Projekt ein Sandbox-Tool zu geben, führe agentbricks tools add sandbox.

Framework oder Harness

Das Framework oder das Harness ist dein Agentencode. Es führt die Schleife aus, die mit einem Modell Schlussfolgerungen zieht, Werkzeuge aufruft und entscheidet, wann es reagiert. Agent Bricks benötigt kein spezielles Framework.

Framework oder Harness Wann verwenden?
Templates Neuer Agent wird gestartet. Das Agent Bricks CLI erstellt Projektgrundgerüste für LangGraph und das OpenAI Agents SDK. Die Templates halten Ihren Framework-Code von dem Code getrennt, der ihn mit dem Agent-Server verbindet.
Bestehende Agenten Einen Agenten mitzubringen, den du bereits mit LangGraph oder dem OpenAI Agents SDK gebaut hast. Führe agentbricks init --existing in dessen Verzeichnis aus. Siehe Vorhandenen Agenten mitbringen.
Meta-harness Mehrere Frameworks, wie Codierungsagenten, in einem Agenten mit Omnigent zusammenzusetzen.

Agent-Server

Der Agent-Server ist eine Bibliothek, die deine Agent-Schleife umwickelt und in einen Service umwandelt. Es definiert die API, die die Clients aufrufen, verfolgt jede Ausführung und bestimmt, was passiert, wenn eine Ausführung unterbrochen wird.

Agent-Server Wann verwenden?
DurableAgentServer (empfohlen) Neue Agenten, die mit der Agent Bricks CLI gebaut wurden.
Legacy-Agent-Server Agenten pflegen, die aus den App-Vorlagen gebaut wurden. Um DurableAgentServer mit den alten Agentenservern zu vergleichen, siehe Agent-Server auf Databricks.
Dein eigener Server Agenten, die benutzerdefinierte Endpunkte, Anfrageformate oder Protokolle benötigen. Führe dies agentbricks init --server custom aus, oder behalte deinen bestehenden Server.

Agent-Laufzeit

Die Agent-Laufzeit ist die verwaltete Rechenumgebung, die deinen Agent-Server betreibt. Du deployest Code darauf, anstatt Server selbst bereitzustellen.

Agent-Laufzeit Wann verwenden?
Agent-Runtime Neue Agenten. Führt deinen Agenten auf Databricks Apps aus. agentbricks deploy stellt die Ressourcen bereit, die Ihr Agent benötigt, gewährt dem Agenten Zugriff darauf und stellt ihn an einem stabilen, authentifizierten Endpunkt bereit.
Model Serving (Legacy) Vorherige Agenten wurden auf Model-Serving-Endpunkten eingesetzt. Siehe Bereitstellen eines Agents für KI-Anwendungen (Model Serving). Um sie zu Databricks Apps zu verschieben, siehe Einen Agent von Model Serving zu Databricks Apps migrieren.

Mit der Agent Bricks CLI bereitstellen

Die Agent Bricks CLI verbindet die drei Schichten. Es erstellt das Grundgerüst für deinen Framework-Code, führt ihn lokal auf DurableAgentServer aus und stellt ihn in Agent Runtime bereit:

agentbricks init my-agent --framework langgraph
cd my-agent
agentbricks dev
agentbricks deploy my-agent

Um Ihren ersten Agenten zu erstellen und einzusetzen, finden Sie unter Agent Bricks quickstart.

Berechtigungen zur Bereitstellung eines Agenten

Der Benutzer oder der Dienstprinzipal, der agentbricks deploy ausführt, benötigt Berechtigungen, Folgendes zu tun:

  • Erstellen Sie Databricks-Apps oder verwalten Sie die bestehende App für eine erneute Bereitstellung. Siehe Konfigurieren von Berechtigungen für eine Databricks-App.
  • Erstelle die in agent.toml deklarierten Speicher- und Sitzungsspeicher oder verwalte die bestehenden Stores, damit Agent Bricks dem Service-Principal der App Zugriff darauf gewähren kann.
  • Erstellen Sie das MLflow-Experiment, das das Projekt zum Nachverfolgen verwendet, oder bearbeiten Sie es, falls es bereits existiert.
  • Gewähren Sie dem Service Principal der App Zugriff auf Ressourcen, die Tools mit --auth appdeklarieren, zum Beispiel EXECUTE auf einer Unity-Catalog-Funktion, CAN RUN auf einem Genie-Agent oder SELECT auf einer Tabelle in einem Sandbox-Scope.

Agent Bricks gewährt nur Zugang zu Ressourcen, die agent.toml direkt deklariert. Wenn ein Tool andere Ressourcen verwendet, wie die Tabellen hinter einem Genie Agent oder die Objekte, die eine Unity Catalog-Funktion aufruft, gewähren Sie dem Service-Principal der App selbst Zugriff darauf. Wenn Deploy keinen erforderlichen Grant anwenden kann, stoppt es, bevor es deinen Code hochlädt, und lässt das aktuelle Deployment laufen.

Weitere Ressourcen

  • Zuletzt aktualisiert um