Symfony AI: Was im Stack drinsteckt und wann wir was davon einsetzen

TECHTALK KI/AI

Symfony ist eines der etabliertesten PHP-Frameworks — die Basis unzähliger Geschäftsanwendungen, auch bei vielen Schweizer KMU. Wer eine ernsthafte Web-App in PHP baut, baut sie sehr wahrscheinlich auf Symfony oder einer seiner Komponenten.

Direkt zum Thema /
Plötzlich gibt es einen Symfony-Weg für AI
Die sieben Bauteile auf einen Blick
Der unterschätzte Hauptwert: Provider-Abstraktion
Reifegrad: experimental ist kein Etikett, das ist die Realität
Decision-Guide: Was brauchst du wirklich?
Wann wir es heute einsetzen würden. Wann nicht.
Was bleibt
Kontakt

Symfony hat im Juli 2025 eine eigene AI-Initiative gestartet. Juni 2026, Version 0.9, immer noch experimental. Wer reinschaut, sieht eine ganze Komponenten-Familie. Wir haben den Stack auf seine Bestandteile zerlegt und sortiert: was reif ist, was wackelt, und was du je nach Use-Case brauchst.

Plötzlich gibt es einen Symfony-Weg für AI

Bis vor ein paar Monaten hiess "AI in einer Symfony-App" entweder einen eigenen HTTP-Wrapper um die OpenAI-API bauen oder eine Drittpartei-Library wie php-llm einbinden. Funktional, aber jeder hat sein eigenes Süppchen gekocht.

Im Juli 2025 hat Fabien Potencier die offizielle Symfony AI Initiative angekündigt. Aus dem PHP-LLM-Projekt heraus, das danach in das Mono-Repo symfony/ai gewandert ist. Heute, Juni 2026, sind wir bei v0.9 des AI-Bundles. Status weiterhin: experimental.

Wir haben den Stack in einem kleinen Demo-Projekt durchgespielt, nur um die Komponenten kennenzulernen. Dieser Artikel ist die Karte, die dabei entstanden ist.

Wer den konkreten Bauteil-Deep-Dive sucht, findet ein Schwester-Artikel von uns: Paavo zeigt, wie wir mit AI B2B-Scam stoppen. Hier geht es um die Karte darüber.

Die sieben Bauteile auf einen Blick

Symfony AI besteht heute aus sieben Bauteilen. Wir gehen sie in der Reihenfolge durch, in der du sie typischerweise zusammensteckst.

1. Platform. Das Fundament. Eine einheitliche Schnittstelle zu praktisch allen relevanten LLM-Providern — von OpenAI, Anthropic und Google bis Mistral, AWS Bedrock und einem lokalen Ollama. Insgesamt über ein Dutzend Anbieter. Du schreibst deinen Code gegen PlatformInterface, welcher Provider antwortet, ist reine Konfigurationssache.

2. Agent. Der Layer darüber. Hier wohnen Tool-Calling, Subagents, Memory und RAG-Orchestrierung. Wenn dein LLM nicht nur antworten, sondern auch Aktionen auslösen oder Daten holen soll, baust du einen Agent.

3. Store. Vector-Datenbank-Abstraktion. Inzwischen über ein Dutzend Bridges: Postgres mit pgvector, SQLite (sqlite-vec), MariaDB, ChromaDB, Pinecone, Weaviate, Qdrant, Milvus, MongoDB Atlas, Meilisearch, Typesense, Azure AI Search, OpenSearch, Neo4j und weitere. Plus eine InMemoryStore-Variante für Tests. Das ist die Grundlage für RAG, also Retrieval Augmented Generation.

4. Chat. API für Konversationen mit Verlauf. Wenn dein Use-Case mehr ist als ein Frage-Antwort-Aufruf, sondern Sessions und Kontext über mehrere Turns, hilft dir Chat.

5. Mate. Ein eigenständiger MCP-Dev-Server, der AI-Assistenten wie Claude Desktop oder Cursor direkt mit deiner Symfony-App reden lässt. Eher Werkzeug für Entwickler:innen als Production-Komponente.

6. AI Bundle. Die Symfony-Integration, die Platform, Agent und Store unter einen YAML-Hut bringt. Dependency Injection, Profiler-Toolbar, Console-Commands, Service-Aliasing. Das ist das Bundle, das du in den meisten Projekten installierst.

7. MCP Bundle. Macht deine App selbst zum MCP-Server oder -Client.

Randnotiz: die CLI-Bridges. Seit Kurzem gibt es zwei Platform-Bridges, die aus dem Rahmen fallen, weil sie nicht über eine HTTP-API sprechen, sondern lokal installierte Agenten-CLIs ansteuern: ai-claude-code-platform (Anthropics Claude Code) und ai-codex-platform (OpenAIs Codex CLI). Sie authentifizieren über das Login des jeweiligen CLI statt über einen API-Key und bringen dessen agentische Fähigkeiten mit, also Code lesen und ändern oder Tools in einer Sandbox ausführen. Das ist ein Werkzeug für Entwickler- und CI-Szenarien, nicht für Endnutzer-Features in der Live-App, weil ein eingeloggtes CLI auf dem ausführenden Host vorausgesetzt wird. Konzeptionell näher bei Mate als bei den klassischen Inferenz-Providern.

Der unterschätzte Hauptwert: Provider-Abstraktion

Wenn wir den ganzen Stack heute auf einen Punkt eindampfen müssten, wäre es der hier: Du wechselst den LLM-Provider per YAML, nicht per Code.

Dein Service injiziert PlatformInterface. Welche der drei Plattformen er aufruft, entscheidet die Konfiguration. Wenn morgen Anthropic 30 Prozent günstiger pro Token wird, wechselst du eine Zeile. Wenn der Datenschutzbeauftragte sagt, das Modell muss on-premises laufen, hängst du ein lokales Ollama dran.

Seit v0.2 gibt es zusätzlich FailoverPlatform. Du listest mehrere Provider in einer Reihenfolge, der erste der antwortet, gewinnt. Falls Anthropic gerade hustet, übernimmt Azure.

Für Tests gibt es InMemoryPlatform. Du gibst eine fixe Antwort vor, dein Test läuft ohne externe API-Calls, ohne Tokens, ohne Latenz.

Und im Symfony Profiler bekommst du eine eigene AI-Toolbar mit Token-Counts pro Request, Modell-Auswahl, Antwortzeit. Ein kleiner Komfort, der in der Praxis viel ausmacht, weil du Token-Kosten direkt im Browser siehst.

Das ist alles nicht spektakulär. Aber es ist die Grundinfrastruktur, die du sonst Stück für Stück selber baust. Und es ist der Grund, warum es sich heute schon lohnt einzusteigen, auch bei v0.9.

Und der Datenschutz? Genau hier zahlt die Abstraktion doppelt. Wer Daten nicht in eine US-Cloud geben will, hängt per Konfiguration ein lokales Ollama oder einen Schweizer beziehungsweise europäischen Anbieter an — derselbe Code, anderer Provider. Sogar das offene Schweizer Sprachmodell Apertus (von ETH, EPFL und CSCS) lässt sich so einbinden: nicht als eigener „Apertus-Knopf“, aber self-hosted via Ollama oder über die HuggingFace-Bridge. Wie wir Datenschutz und KI in der Schweiz grundsätzlich einordnen, haben wir hier zusammengefasst.

Reifegrad: experimental ist kein Etikett, das ist die Realität

Auf Packagist hat das AI-Bundle aktuell rund 538'000 Installs. Die Doku auf symfony.com/doc/current/ai ist umfangreich. Es gibt eine offizielle Demo-App. Die Geschwindigkeit, mit der das Projekt sich entwickelt, ist hoch.

Trotzdem steht auf jeder Komponente das Wort @experimental. Das ist kein Marketing, das hat eine konkrete Bedeutung im Symfony-Universum: Diese Komponenten sind explizit vom Backward-Compatibility-Versprechen ausgenommen. BC-Breaks zwischen 0.x-Releases sind erlaubt und kommen vor.

Was das in der Praxis heisst:

Pinne deine Versionen exakt im composer.json. Ein ^0.9 reicht nicht, das holt dir bei jedem Update potenziell Brüche rein.
Plane bei jedem Update Anpassungszeit ein. Ein, zwei Stunden für eine kleine Komponente, einen halben Tag für einen grösseren Refactor sind realistische Erwartungen.
Reifegrad ist ungleich verteilt. Platform, Agent und Store fühlen sich erwachsen an. Chat und Mate sind jünger und sehen entsprechend roher aus. Provider-Bridges sind unterschiedlich gepflegt: OpenAI und Anthropic sind komplett, kleinere Provider haben Lücken.
v1.0 hat kein Datum. Das Symfony-Team trackt die Roadmap im Issue #1301 transparent, hat aber keinen Termin gesetzt. Wenn alle Items abgehakt sind, gibt es einen Feature-Freeze von vier Wochen, dann v1.0.

Die kurze Version: einsteigen ja, aber mit den Augen offen. Wer heute baut, geht den Weg mit Symfony mit, statt auf den fertigen Pfad zu warten.

Decision-Guide: Was brauchst du wirklich?

Du brauchst nicht den ganzen Stack. Hier eine Sortierung nach Use-Case, vom einfachen zum komplexen.

Du willst nur LLM-Calls absetzen. Klassifizierer für eingehende Tickets, Texte zusammenfassen, Übersetzungen. Du brauchst nur Platform über das AI Bundle. Drei Zeilen YAML, ein Service-Inject, fertig. Kein Agent nötig, kein Store nötig.

Du willst, dass das LLM eigene Funktionen aufrufen kann. Daten aus deiner Datenbank holen, eine Aktion auslösen, eine API anfragen. Du brauchst Platform + Agent. Das Tool-Calling-Modell mit dem #[AsTool]-Attribut ist der Hebel. Der Agent kümmert sich darum, dass das LLM die richtigen Tools in der richtigen Reihenfolge aufruft.

Du willst eigenes Wissen einbinden. Doku, Produktkatalog, Wissensbasis. Das LLM soll auf Daten antworten, die nicht in seinem Trainings-Set waren. Du brauchst Platform + Agent + Store. Das ist klassisches RAG. Für die meisten KMU-Cases reicht SQLite (sqlite-vec) oder Postgres mit pgvector vollständig. Eine separate Vector-Datenbank wie Pinecone oder Qdrant wird erst dann interessant, wenn du Millionen Dokumente hast oder spezielle Index-Strategien brauchst.

Du willst Konversationen mit Verlauf. Ein Chatbot, der sich an die letzten zehn Nachrichten erinnert. Du nimmst zusätzlich Chat dazu, oder löst Memory innerhalb des Agents.

Du willst deine App für AI-Assistenten zugänglich machen. Claude Desktop oder Cursor sollen mit deinem System reden. Du brauchst das MCP Bundle.

Wann wir es heute einsetzen würden. Wann nicht.

Setzen wir ein: Interne Tools, Prototypen und kleine produktive Features in bestehenden Symfony-Apps. Klassifizierer, Backoffice-Helfer, interne Knowledge-Tools. Wenn dein Stack PHP 8.2+ und Symfony 7.3 oder neuer fährt, ist Symfony AI heute der Weg mit der geringsten Reibung. Du arbeitest in deinem bestehenden Stack, deine Tests funktionieren, dein Profiler zeigt dir was passiert.

Würden wir warten: Geschäftskritische Features mit fünf Jahren Lebenszyklus und grosser Investition. Bis v1.0 ist es kein Drama, mit einem dünnen Adapter um die LLM-Calls zu arbeiten und die heisse Phase abzuwarten. Wenn die API stabil ist, migrierst du in zwei Tagen.

Würden wir abraten: Wenn dein Use-Case sehr provider-spezifische Funktionen braucht, die in der Symfony-Abstraktion noch nicht abgebildet sind. Wenn dein Team kein PHP 8.2+ und keinen aktuellen Symfony fährt. Oder wenn du eigentlich gar keine Symfony-App hast. Dann ist Symfony AI heute nicht der richtige Hebel — aber das heisst nicht, dass du auf KI verzichten musst. In solchen Fällen starten wir lieber mit einem schlanken Proof of Concept über eine AI-Automatisierung: unabhängig von deinem Stack, schnell aufgesetzt, und du siehst am konkreten Fall, was KI dir bringt, bevor du tief in eine Architektur investierst.

Was bleibt

Symfony AI ist nicht der grosse Wurf, der alles ändert. Es ist auch nicht die Spielerei, die in einem Jahr wieder weg ist. Es ist der konsequente Schritt, AI-Features in den Symfony-typischen Werkzeugkasten zu integrieren: YAML-Konfiguration, Dependency Injection, Profiler, Test-Doubles. Wer Symfony seit Jahren kennt, fühlt sich sofort zuhause.

Heute steckt der Stack in v0.9. Das heisst: einsteigen ja, aber mit Augen auf. Pinne deine Versionen, plane Update-Zeit ein, wähle bewusst aus, welche Komponenten du brauchst. Für Pilot-Features und interne Tools reicht das heute schon. Für die fünfjährige Geschäftslogik schaust du nochmal hin, wenn v1.0 da ist.

Noch mehr von uns /