Foundry Agent Web-Apps: Cosmos oder Azure SQL für den Backend-Zustand, und wann?

In Community-Threads wird immer wieder gefragt, warum die RAG-Chatbot-Beispiele von Microsoft Cosmos für den Chatverlauf empfehlen, obwohl eine kleine Azure-SQL-Datenbank die Nachrichten genauso speichern könnte. Berechtigte Frage. Dokumentspeicher passen gut zu Nachrichtenbeuteln, Walkthroughs auf Learn sind schnell umgesetzt, und Cosmos taucht in den Diagrammen auf, die alle kopieren.

Diese Frage ist Kontext, nicht die ganze These für eine Agent-Web-App mit Microsoft Foundry. Veröffentlichte Agent-Shells überlassen die dauerhafte Produkthistorie oft deinem Backend. Die Datensätze, die dein Backend für das Produkt schreibt, sind deine Tabellen. Agents, Threads, Dateien, Wissen/Search und der Plattformspeicher bleiben in Foundry. Die eigentliche Entscheidung ist, welche Engine die App-eigene Ebene hinter einer einzigen Produkt-API trägt.

Abbildung 1. Benanntes Modell: API bleibt, Speicher zieht um. Friere den Vertrag auf der Leitung ein. Verschiebe nur App-eigene Sammlungen. Lass die Speicher der Foundry-Plattform in Ruhe.

Zwei Ebenen vor einer Engine

Die meisten Diskussionen über Cosmos oder SQL scheitern, weil sie zwei Ebenen vermischen.

App-eigener Backend-Zustand ist das, was die API deiner Agent-Web-App für das Produkt speichert: die Sammlungen A bis D (Datensätze mit id als Schlüssel, ein Index und ein Log, an das nur angehängt wird). Diese Ebene gehört dir, und du kannst sie auf Cosmos, Azure SQL oder etwas anderes legen. Aufrufer interessieren sich für Routen und JSON, nicht dafür, welche Azure-SKU unter dem Repository liegt.

Speicher der Foundry-Plattform sind das, was der Service besitzt: Agent-Definitionen und Tools, Threads und Runs, Dateien und Wissen (einschließlich Grounding über Search) und der Plattformspeicher. Die bleiben in Foundry. Eine Umstellung von Cosmos auf SQL für die App-eigenen Sammlungen der Shell heißt nicht, dass du Plattform-Threads in die Datenbank deines App Service umziehst.

Abbildung 2 zieht die Grenze. Die Engine-Debatte gilt nur für die linke Spalte.

Abbildung 2. Zwei Speicherebenen. Cosmos oder Azure SQL ist eine Entscheidung über den App-eigenen Backend-Zustand. Wer die Ebenen vermischt, sorgt dafür, dass Forendebatten aneinander vorbeilaufen.

Warum die Beispiele standardmäßig Cosmos nehmen (und warum das unvollständig ist)

Stell die Reddit-Frage laut und grenz sie dann ein.

1. Wo legen Beispiel-Demos für RAG ihre Nachrichtendokumente ab?
2. Wo legt deine Agent-Web-App auf Basis von Foundry den Produktzustand ab, den die SPA und die Support-Tools abfragen müssen?

Cosmos ist oft die Antwort auf (1). Nachrichtendokumente sind naheliegend, Tutorials zur Partitionierung liegen bereit, und das Architekturdiagramm sieht aus wie der Walkthrough auf Learn. Teams behandeln diesen Standard dann wie ein Gesetz der Plattform.

Microsoft Foundry ändert die zweite Hälfte. Wenn eine veröffentlichte Agent-Erfahrung die Produkthistorie über mehrere Runden deinem Backend überlässt, wird die Shell-API zur Ebene der Produkthistorie, ob du Cosmos magst oder nicht. Deployment-Notizen aus der Community beschreiben bereits, wie Threads und Nachrichten in Cosmos oder Postgres/SQL hinter der Web-App-API gespeichert werden. Die Verantwortung ist nicht optional. Die Engine schon.

Behalte den Standard der Beispiele also als Kontext. Nutze ihn, um zu erklären, warum Cosmos in Diagrammen auftaucht. Nutze ihn nicht als ADR für jede App-eigene Tabelle.

Wann Cosmos, wann Azure SQL

Abbildung 3 ist die Entscheidungskarte für die App-eigene Ebene.

Abbildung 3. Wann Cosmos, wann Azure SQL. Dokumentbeutel und das Tempo der Beispiele sprechen für Cosmos. Relationaler Produktzustand und eine HTTP-Umstellung mit eingefrorenem Vertrag sprechen für Azure SQL + EF Core.

Nimm lieber Cosmos, wenn

• die Nutzlast ein flexibler Beutel mit Chat- oder RAG-Nachrichten ist und sich die Form noch von Woche zu Woche ändert.
• der Zugriff meist nach Gespräch oder Nutzerpartition erfolgt und kaum über Sammlungen hinweg gejoint wird.
• du einem Beispiel folgst und der Support selten Fragen in SQL-Form stellt.
• Tempo beim Prototyp für diesen Teil des Zustands wichtiger ist als Migrationen als Code.

Nimm lieber Azure SQL (+ EF Core), wenn

• App-eigene Sammlungen sauber miteinander gejoint werden müssen.
• du Constraints, EF-Migrationen und einen einzigen Verdrahtungsweg für Repositories über lokal, Staging und Prod willst.
• der SPA-Vertrag stabil bleiben muss, während die Speicher-Engine wechselt (API bleibt, Speicher zieht um).
• Support- und Audit-Teams relationale Fragen stellen (wer hat was geändert, über welche Datensätze, für welche Nutzer).

Niemals

• den Standard eines Learn-Beispiels als Foundry-Vorgabe für jede Produkttabelle behandeln.
• die Speicher der Foundry-Plattform (Agents, Threads, Dateien, Wissen, Plattformspeicher) in die Datenbank der Shell migrieren.
• nach der Umstellung Cosmos und SQL beide für denselben App-Datenpfad aktiv lassen.

Standards sind kein Schicksal. Anforderungen schon.

Typische Umstellung (allgemein): einfrieren, migrieren, umschalten, löschen

Eine solche Umstellung kann beginnen, wenn der App-eigene Zustand in Cosmos liegt und ein Team relationale Operationen und einen einzigen Verdrahtungsweg will. Die Entscheidung lautet nicht "Cosmos ist für jeden Chat-Beutel falsch". Sie lautet "diese Sammlungen brauchen relationale Operationen und einen einzigen Verdrahtungsweg".

Liefere die Umstellung als API bleibt, Speicher zieht um aus:

1. Die Leitung einfrieren. Behalte für jede App-eigene Sammlung dieselben Routen und dasselbe JSON. Aufrufer sollten den Engine-Wechsel nicht bemerken.
2. Zuerst Schema und Firewall. Führe Azure-SQL-Tabellen und EF-Core-Migrationen ein. Weise den Firewall-Pfad nach (oder ein lokales SQL), damit die Migrationen gelingen, bevor du SPA-Timeouts debuggst.
3. Einmalig migrieren. Verschiebe die Sammlungen A bis D mit Paritätsprüfungen (Anzahlen plus Stichproben der Nutzlasten).
4. Repositories umschalten. SQL wird hinter derselben HTTP-Oberfläche zur Quelle der Wahrheit.
5. Den App-Datenpfad in Cosmos löschen. Entferne Zugangsdaten und Codepfade, damit Umgebungen nicht zu einem zweiten Speicher zurückdriften können.

Eine vorübergehende Brücke kann während der Migration helfen. Ein dauerhaftes Produkt mit zwei Speichern ist der Weg, auf dem die Drift bei der Verdrahtung zurückkehrt. Lass die Speicher der Foundry-Plattform die ganze Zeit in Ruhe.

Häufige Fehler

Cosmos aus dem Beispiel als Foundry-Vorgabe behandeln. Learn-Diagramme sind Lehrmittel. Der Vertrag für deinen Produktzustand ist eine ADR.

Die Speicher der Foundry-Plattform mit der Datenbank der Shell verschieben. Agents, Threads, Dateien, Wissen und Plattformspeicher sind keine weiteren Sammlungen auf deiner Migrations-Checkliste.

JSON-Formen während des Engine-Wechsels ändern. Dann sieht jeder Bug bei den Aufrufern wie ein Datenbankbug aus. Friere zuerst das Format auf der Leitung ein.

Drift zwischen Umgebungen: Cosmos in einer, SQL in einer anderen. Fehler, die nur in einer Umgebung auftreten, sind die Folge. Nach der Umstellung ein einziger Verdrahtungsweg für Repositories.

Die SQL-Firewall blockiert EF vor dem Lauschen. Der lokale Start erreicht nie "API läuft", wenn sich die Migrationen nicht verbinden können. Öffne den Firewall-Pfad, bevor du SPA-Timeouts hinterherjagst.

Für immer doppelt schreiben. Eine vorübergehende Brücke ist in Ordnung. Ein dauerhaftes Produkt mit zwei Speichern öffnet die Drift wieder, die du gerade geschlossen hast.

So übernehmen oder anpassen

So übernehmen

• Ausdrückliche Trennung: App-eigener Backend-Zustand gegenüber den Speichern der Foundry-Plattform.
• Entscheidungsregel: Cosmos für Dokumentbeutel; Azure SQL, wenn relationaler Produktzustand die Aufgabe ist.
• Stabiles HTTP + JSON über eine Umstellung von Cosmos auf SQL hinweg.
• Einmalig migrieren, umschalten, den alten App-Datenpfad löschen.
• Gesunde Firewall und EF-Migrationen, bevor die API als bereit gilt.

Vor dem Einsatz anpassen

Reiß Cosmos nicht aus einem reinen Prototyp mit Nachrichtenbeuteln ohne relationalen Druck heraus, nur damit er zu dieser Notiz passt. "Repariere" den Chatverlauf nicht, indem du Foundry-Threads in deine SQL-Datenbank migrierst. Lass keine Cosmos-Zugangsdaten in der Prod-Konfiguration, wenn der App-Datenpfad weg ist.

Verwandte Notizen

• Microsoft Foundry: Wie speicherst du Agent-Sessions außerhalb der Chat-Shell? (drei Uhren: Auth, UI, Gespräch)
• Microsoft Foundry: Reicht Deploy as Web App, oder brauchst du einen Backend-Proxy? (zuerst Identität und ausgehender Verkehr)
• Agent-Shells: Wie schaltest du Agent-Funktionen per Feature Toggle über Umgebungen hinweg? (standardmäßig offen, mit Overlays)
• Foundry + private Suche: Ist "Name or service not known" ein DNS- oder Auth-Problem? (DNS vor RBAC auf der privaten Ebene)

Quellen (Community): Why does MS recommend Cosmos for RAG chat history vs Azure SQL?, Foundry published app / store behavior and backend-owned multi-turn state, Deploy Foundry agents: persist threads in Cosmos or Postgres/SQL behind your API, Anyone here using Cosmos DB?.

Die Standards der Beispiele erklären Cosmos im Diagramm. Deine Agent-Web-App entscheidet trotzdem, wo der Produktzustand lebt. Halte die zwei Ebenen ehrlich. Halte eine Produkt-API stabil. Verschiebe nur, was dir gehört.