FIM One: eine Agentenplattform für Unternehmen, die globale SaaS- und China-Systeme parallel betreiben

Welches Problem FIM One adressiert

Das README beschreibt die Ausgangslage mit einem Satz, der die Zielgruppe festlegt: Global enterprises run a sprawl of systems that don't talk to each other. Genannt werden ERP, CRM, OA, HR, Finanzen, Datenbanken und IM-Plattformen, verteilt über Regionen. FIM One setzt nicht bei einem dieser Systeme an, sondern darüber: ein Agentenkern, der alle angeschlossenen Systeme als Werkzeuge sieht. Die Zielgruppe sind damit Unternehmen, die auf der einen Seite globale SaaS-Dienste nutzen und auf der anderen Seite den im README so bezeichneten China-Stack, also Feishu, WeCom, DingTalk, DM und Kingbase. Wer nur eine einzelne API an einen Chatbot hängen will, braucht dieses Projekt nicht.

Drei Betriebsmodi mit demselben Kern

Das README unterscheidet Standalone, Copilot und Hub. Standalone ist ein allgemeiner Assistent mit Suche, Code und Wissensbasis über ein Portal. Copilot bettet den Agenten per iframe, Widget oder Embed in die Oberfläche eines Wirtssystems ein. Hub ist die zentrale Orchestrierung über alle verbundenen Systeme, erreichbar über Portal oder API. Der Anspruch ist, dass alle drei Modi denselben Agentenkern verwenden. Für die Einführung heißt das: die Entscheidung für einen Modus ist keine Architekturentscheidung, sondern eine Frage der Oberfläche. Ein Team kann mit Copilot in einer bestehenden Anwendung beginnen und später auf Hub wechseln, ohne die Anbindung der Systeme neu zu bauen.

Wie Werkzeuge registriert und ausgeführt werden

Das Muster ist im README klar benannt: Connect APIs, databases, MCP servers. Actions auto-register as agent tools with auth injection. Eine angeschlossene Aktion wird also nicht pro Agent neu verdrahtet, sondern als Werkzeug registriert, wobei die Authentifizierung beim Aufruf injiziert wird. Dazu kommt ein Mechanismus, den das README progressive disclosure meta-tools nennt und mit einer Token-Ersparnis von über 80 Prozent über alle Werkzeugtypen beziffert. Diese Zahl stammt aus der Projektdokumentation, nicht aus einer unabhängigen Messung. Die dahinterliegende Idee ist nachvollziehbar: bei vielen angeschlossenen Systemen wächst die Werkzeugliste schneller als das Kontextfenster, also werden Werkzeuge stufenweise sichtbar gemacht statt alle auf einmal. Für die Planung gibt es zwei Wege. Der ReAct-Agent führt einen strukturierten Reasoning-and-Acting-Zyklus mit Fehlerbehebung aus. Die DAG-Planung zerlegt ein Ziel zur Laufzeit in einen Abhängigkeitsgraphen, führt unabhängige Schritte über asyncio parallel aus und plant laut README bis zu drei Runden neu. Eine Auto-Routing-Komponente klassifiziert Anfragen und wählt zwischen beiden Modi, konfigurierbar über den Schlüssel AUTO_ROUTING.

Hooks, Guardrails und die Grenze des Modells

Das Hook-System ist der interessanteste Teil der Beschreibung, weil es die Entscheidung aus dem Modell herausnimmt. Hooks laufen deterministisch außerhalb der LLM-Schleife. Als erster Hook ist FeishuGateHook dokumentiert: sensible Werkzeugaufrufe werden hinter eine Freigabekarte gestellt, die in einer Feishu-Gruppe erscheint. Der Mensch entscheidet, nicht das Modell. Das README nennt als geplante Erweiterungen Audit-Logging, Read-only-Modus und Ratenbegrenzungen, ausdrücklich für v0.9, also noch nicht ausgeliefert. Die Inhaltsfilter arbeiten dreischichtig: Werkzeugberechtigungen auf der Aktionsebene, Prüfungen auf Zugangsdaten, SSRF und MCP-Authentifizierung auf der Protokollebene sowie Filter auf Ein- und Ausgabetexte. Der Standard-Jailbreak-Erkenner bricht den Durchlauf ab, bevor das Modell aufgerufen wird, was Token spart und im Chat einen Hinweis anzeigt. Ausgabefilter sind optional und werden über FIM_GUARDRAILS_OUTPUT aktiviert. Wer glaubt, damit sei das Modell abgesichert, irrt: die Filter prüfen Text und Aufrufe, nicht die inhaltliche Richtigkeit einer Antwort.

Installation: Docker als Standardweg

Das README empfiehlt Docker. Die Befehlsfolge ist vollständig angegeben: git clone https://github.com/fim-ai/fim-one.git, dann cd fim-one, dann cp example.env .env. In der .env ist LLM_API_KEY zu setzen, optional LLM_BASE_URL und LLM_MODEL. Danach docker compose up --build -d, und die Oberfläche ist unter http://localhost:3000 erreichbar, wo beim ersten Start ein Administratorkonto angelegt wird. Für den Alltag nennt das README docker compose up -d, docker compose down und docker compose logs -f. Wer lokal entwickeln will, braucht Python 3.11 oder neuer, uv, Node.js 18 oder neuer und pnpm. Dann uv sync --all-extras, im frontend-Verzeichnis pnpm install, und ./start.sh dev startet Python mit --reload und Next.js mit HMR. Die Varianten sind in einer Tabelle aufgeführt: ./start.sh für beide Dienste, dev:api nur für die API auf Port 8000, dev:ui nur für das Frontend auf Port 3000, api für einen headless Betrieb unter localhost:8000/api. Für Produktionsbetrieb verweist das README auf einen Deployment Guide außerhalb des Repositorys.

Was das Material nicht beantwortet

Die Lizenzangabe ist der schwächste Punkt. Das Repository trägt die Kennzeichnung NOASSERTION, das README zeigt ein Badge mit der Aufschrift Source Available. Source Available ist keine anerkannte Lizenzkategorie, sondern eine Sammelbezeichnung. Ob kommerzielle Nutzung, Weitergabe oder das Betreiben als Dienst erlaubt sind, lässt sich daraus nicht ableiten. Wer FIM One produktiv einsetzen will, muss die Lizenzdatei selbst prüfen und im Zweifel rechtlichen Rat einholen; eine Einordnung kann dieser Text nicht liefern. Auch die Versionierung bleibt unklar: Es wurden keine Releases abgerufen, und im README tauchen Versionsangaben wie v0.9 nur als Ausblick auf künftige Hook-Erweiterungen auf. Der jüngste Push auf master datiert auf den 6. September 2026, was auf aktive Arbeit hindeutet, aber nichts über die Stabilität einer bestimmten Version sagt. Wer auf einen festen Stand angewiesen ist, muss selbst einen Commit auswählen und diesen pinning betreiben, weil das Projekt keine Release-Artefakte bereitstellt, aus denen sich das ableiten ließe.

Abgrenzung zu einem schlanken Agenten-Framework

Der naheliegende Vergleich ist ein schlankes Agenten-Framework wie LangChain oder LangGraph, bei dem ein Team die Werkzeuganbindung, die Authentifizierung und die Ausführungsschleife selbst schreibt. FIM One geht den umgekehrten Weg: Die Plattform bringt Konnektoren, Schema-Introspektion, einen Hook-Layer und eine Oberfläche mit, und das Team konfiguriert statt zu programmieren. Der Preis dafür ist Bindung. Ein selbstgebauter Agent läuft in jeder Umgebung, die die Bibliothek unterstützt; FIM One läuft dort, wo Docker oder Python 3.11 mit den genannten Abhängigkeiten verfügbar sind, und die Anbindung folgt den Konventionen des Projekts. Der Gewinn liegt bei den Datenbanken: PostgreSQL, MySQL, Oracle und SQL Server sind gängig, aber DM, KingbaseES, GBase und Highgo sind es nicht. Das README nennt sie ausdrücklich als Systeme, die die meisten globalen Plattformen nicht erreichen. Wer genau diese Datenbanken anbinden muss, spart mit FIM One erhebliche Arbeit. Wer sie nicht braucht, zahlt für Konnektoren, die er nie verwendet.

Redaktionelles Fazit

Wer ERP, CRM, OA oder Datenbanken aus dem China-Stack über einen gemeinsamen Agentenkern anbinden will und Python 3.11 sowie Docker selbst betreiben kann, findet hier ein zusammenhängendes System statt einzelner Skripte. Wer nur einen Chatbot auf einer SaaS-API braucht, ist mit einem schlanken Client besser bedient, weil FIM One den gesamten Stack inklusive Datenbanktreibern mitbringt. Vor dem Einsatz zu klären sind zwei Punkte: die genauen Bedingungen der als Source Available gekennzeichneten Lizenz und die Frage, ob der Stand von master mit den unter docs.fim.ai beschriebenen Funktionen übereinstimmt.

Offizielle Quellen

1. fim-ai/fim-one on GitHub
2. Issues
3. Project website
4. README