Die einheitliche Tool-Abstraktion
Die zentrale Designidee in FIM One ist, dass alles, was der Agent tun kann, ein Tool ist. Ein Rechner, eine Wissensdatenbankabfrage, ein ERP-API-Aufruf und ein MCP-Server eines Drittanbieters implementieren alle das gleicheTool-Protokoll: name, description, parameters_schema, category und run(). Der Agent weiß nicht und kümmert sich nicht darum, ob er eine lokale Python-Funktion aufruft, eine Vektordatenbank abfragt, in ein Legacy-System proxied oder einen Community-MCP-Server aufruft. Er sieht eine flache Liste von aufrufbaren Tools in einer ToolRegistry.
Dies ist eine bewusste architektonische Entscheidung, keine zufällige Vereinfachung. Das bedeutet, dass das Hinzufügen einer neuen Funktionsquelle niemals eine Änderung des Agenten, der Ausführungs-Engines oder der Kontextverwaltungsschicht erfordert. Sie registrieren Tools; der Agent nutzt sie.
Vier Funktionsquellen konvergieren in einer Registry. Der Agent schöpft gleichmäßig aus allen.
Vier Funktionsquellen
Integrierte Werkzeuge
Werden beim Start automatisch überdiscover_builtin_tools() erkannt. Legen Sie eine BaseTool-Unterklasse in core/tool/builtin/ ab, und sie registriert sich ohne Konfiguration. Kategorien umfassen Berechnung (calculator, python_exec), Web (web_search, web_fetch), Dateisystem (file_ops) und allgemein (email_send, json_transform, template_render, text_utils). Dies sind die nativen Fähigkeiten des Agenten — immer verfügbar, keine Einrichtung erforderlich.
Wissensdatenbank
Bedingt. Wenn ein Agentkb_ids gebunden hat, wird das generische kb_retrieve-Tool durch ein spezialisiertes Abruf-Tool ersetzt. Im einfachen Modus führt KBRetrieveTool grundlegende RAG-Abruf durch. Im Grounding-Modus führt GroundedRetrieveTool eine 5-stufige Pipeline aus: Multi-Wissensdatenbank-Abruf, Zitierextraktion, Alignment-Bewertung, Konflikt-Erkennung und Konfidenz-Berechnung. Die Wissensdatenbank ist kein separates Subsystem neben dem Agent – sie wird als spezialisiertes Tool in den Agent integriert und unterliegt demselben Tool-Protokoll wie alles andere.
Connector
ConnectorToolAdapter umhüllt Unternehmensystemaktionen als Tools. Jede Aktion wird zu einem Tool mit dem Namen {connector}__{action}, kategorisiert als connector. Der Adapter fügt HTTP-Proxy mit Auth-Injection (Bearer, API-Schlüssel, Basic), Zugriffskontrolle auf Operationsebene (Lesen/Schreiben/Admin), Antworttrunkierung und Audit-Logging hinzu. Für direkten Datenbankzugriff bietet DatabaseToolAdapter schemaabhängige SQL-Ausführung mit optionaler Schreibschutz-Erzwingung. Konnektoren sind die Brücke zwischen KI und Legacy-Systemen — der Kernunterscheidungsmerkmal. Siehe Connector-Architektur für das vollständige Design.
MCP
Externe MCP-Server stellen Tools von Drittanbietern über das Standardprotokoll bereit. Jeder Server läuft in seinem eigenen Prozess (stdio oder HTTP-Transport) und ist vollständig von der Plattform isoliert. Tools werden in dasTool-Protokoll adaptiert und unter der Kategorie mcp registriert. Administratoren können globale MCP-Server bereitstellen, die automatisch für alle Benutzer geladen werden. MCP ist das Ökosystem-Angebot – jeder MCP-kompatible Server funktioniert ohne benutzerdefinierte Integration.
Werkzeugzusammensetzung pro Anfrage
Jede Chat-Anfrage stellt einen frischen Werkzeugsatz durch eine Filterpipeline in_resolve_tools() zusammen. Dies ist keine statische Konfiguration – sie wird pro Anfrage basierend auf den Einstellungen des Agenten, der Identität des Benutzers und den verfügbaren Konnektoren und MCP-Servern berechnet.
Die sechs Schritte:
- Basis-Erkennung.
discover_builtin_tools()lädt alle integrierten Werkzeuge, begrenzt auf die Sandbox der Konversation. - Agent-Kategoriefilter.
filter_by_category(*agent.tool_categories)beschränkt auf nur die Kategorien, die der Agent verwenden darf. - KB-Injektion. Wenn der Agent
kb_idshat, wird das generische Abruftool durchKBRetrieveTooloderGroundedRetrieveToolbasierend auf dem Abrufmodus ersetzt. - Konnektor-Laden. Die an den Agenten gebundenen Konnektoren werden aus der Datenbank abgefragt. Die Aktionen (oder Datenbankschemas) jedes Konnektors werden als Werkzeugadapter instanziiert und registriert.
- MCP-Laden. Die persönlichen MCP-Server des Benutzers sowie von Administratoren bereitgestellte globale MCP-Server werden geladen, verbunden und ihre Werkzeuge registriert.
- Laufzeit-Auswahl. Wenn die Gesamtzahl der Werkzeuge 12 überschreitet, wählt ein leichter LLM-Aufruf die relevanteste Teilmenge (bis zu 6) für diese spezifische Anfrage aus. Auswahlfehlschlag ist nicht fatal – der Agent fällt auf den vollständigen Satz zurück.
Wann man was verwendet
| Anforderung | Verwenden | Grund |
|---|---|---|
| Allgemeine Berechnungen, Code-Ausführung, Texttransformationen | Integriertes Tool | Immer verfügbar, keine Konfiguration erforderlich |
| Enterprise-Systemintegration (ERP, CRM, OA) | Connector | Auth-Governance, Audit-Trail, Zugriffskontrolle auf Operationsebene |
| Wissensabruf mit Zitaten und Belegen | Knowledge Base | RAG-Pipeline, fundierte Generierung, Konflikterkennung |
| Ökosystem von Drittanbieter-Tools | MCP | Standardprotokoll, Prozessisolation, Community-Server |
| Direkter Datenbankzugriff | Database Connector | Schema-bewusste SQL, optionale Schreibschutz-Erzwingung |
| Benutzerdefinierte interne Tools | MCP oder Integriert | MCP für Prozessisolation; integriert für enge Integration |
Ausführungs-Engines sind orthogonal
Das Tool-System und die Ausführungs-Engines sind unabhängige Belange. Beide Engines verbrauchen Tools aus derselbenToolRegistry. Die Wahl der Engine beeinflusst, wie Tools orchestriert werden, nicht welche Tools verfügbar sind.
ReAct ist eine iterative Tool-Schleife. Der Agent argumentiert, wählt ein Tool, beobachtet das Ergebnis und wiederholt dies, bis es fertig ist. Es zeichnet sich bei explorativen, konversationalen Aufgaben aus, bei denen der nächste Schritt vom vorherigen Ergebnis abhängt. Die Schleife läuft bis zu 50 Iterationen mit Kontextverwaltung pro Iteration über ContextGuard. Siehe ReAct Engine für Implementierungsdetails.
DAG zerlegt ein Ziel in 2-6 parallele Schritte. Jeder Schritt führt einen unabhängigen ReAct-Agent aus. Ein PlanAnalyzer bewertet, ob das Ziel erreicht wurde; wenn nicht, plant die Pipeline autonom neu (bis zu 3 Runden). DAG zeichnet sich bei Aufgaben mit klaren Teilaufgaben aus, die gleichzeitig ausgeführt werden können – „drei Quellen durchsuchen und Ergebnisse vergleichen” dauert so lange wie eine Suche, nicht drei. Siehe DAG Engine für die vollständige Pipeline.
Die beiden Engines teilen sich Infrastruktur: structured_llm_call für zuverlässige strukturierte Ausgaben, ContextGuard für Durchsetzung des Token-Budgets und die ToolRegistry für Tool-Auflösung. Das Hinzufügen eines neuen Tools erfordert keine Änderungen an einer der Engines. Das Hinzufügen einer neuen Engine (falls jemals erforderlich) erfordert keine Änderungen am Tool-System.
Lifecycle-Übersicht
Startup.start.sh führt Alembic-Migrationen aus, startet den FastAPI-Server, erkennt integrierte Tools und etabliert MCP-Serververbindungen für alle vorkonfigurierten globalen Server.
Pro Anfrage. JWT-Authentifizierung, Agenten-Konfigurationssuche, Tool-Zusammenstellung (die 6-Schritte-Pipeline oben), Engine-Auswahl (ReAct oder DAG basierend auf Agenten-Konfiguration), Ausführung mit SSE-Streaming und Ergebnispersistenz.
Übergreifende Belange. Context-Verwaltung (5-Schichten-Token-Budget) schützt jeden LLM-Aufruf vor Überlauf. Audit-Logging verfolgt jede Konnektor-Tool-Invokation. Sandbox-Isolation enthält Code-Ausführungs-Tools. Die Zwei-LLM-Architektur (smart + fast) optimiert Kosten über Planung, Ausführung und Synthese.
Die Architektur ist so gestaltet, dass jeder Belang – Tool-Registrierung, Ausführungs-Orchestrierung, Context-Verwaltung, Sicherheit – unabhängig weiterentwickelt werden kann. Ein neuer Konnektor-Typ, eine neue Ausführungs-Engine oder eine neue Context-Strategie können hinzugefügt werden, ohne kaskadierende Änderungen im gesamten System zu verursachen.