Systemübersicht

Documentation Index

Fetch the complete documentation index at: https://docs.fim.ai/llms.txt

Use this file to discover all available pages before exploring further.

​

Die einheitliche Werkzeug-Abstraktion

Die zentrale Designidee in FIM One ist, dass alles, was der Agent tun kann, ein Werkzeug ist. Ein Rechner, eine Wissensdatenbankabfrage, ein ERP-API-Aufruf und ein MCP-Server eines Drittanbieters implementieren alle das gleiche Tool-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 weitergeleitet wird oder einen Community-MCP-Server aufruft. Er sieht eine flache Liste von aufrufbaren Werkzeugen 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 Werkzeuge; der Agent nutzt sie. Fünf Funktionsquellen konvergieren in einer Registrierung. Der Agent schöpft aus allen gleichermaßen.

​

Fünf Fähigkeitsquellen

​

Integrierte Werkzeuge

Werden beim Start automatisch über discover_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 Agent kb_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 das Tool-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.

​

Fähigkeiten

Fähigkeiten sind wiederverwendbare Standard Operating Procedures (SOPs) – Unternehmensrichtlinien, Handlungsverfahren, schrittweise Workflows – die global gelten, unabhängig davon, welcher Agent ausgewählt ist. Im Gegensatz zu Konnektoren und Knowledge Bases (die auf bestimmte Agenten beschränkt werden können), werden Fähigkeiten immer für jeden Benutzer basierend auf der Sichtbarkeit (persönlich, organisationsweit freigegeben oder Market-abonniert) geladen. Fähigkeiten unterstützen zwei Injektionsmodi – progressiv (Standard) und inline – gesteuert durch SKILL_TOOL_MODE. Im progressiven Modus erscheinen kompakte Stubs im System-Prompt und das LLM ruft read_skill(name) bei Bedarf auf. Dies ist Teil der umfassenderen Progressive Disclosure-Architektur, die das gleiche Stub-First-, Detail-on-Request-Muster auf Fähigkeiten, Konnektoren, Datenbanken und MCP Server anwendet. Für einen tieferen Einblick, warum Fähigkeiten global sind (nicht an Agenten gebunden) und wie sie mit der dualen Ressourcenermittlung interagieren, siehe Agent & Ressourcenermittlung.

​

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 acht Schritte:

1. Basis-Erkennung. discover_builtin_tools() lädt alle integrierten Werkzeuge, begrenzt auf die Sandbox des Gesprächs.
2. Agent-Kategorie-Filter. filter_by_category(*agent.tool_categories) beschränkt auf nur die Kategorien, die der Agent verwenden darf.
3. KB-Injektion. Wenn der Agent kb_ids hat, wird das generische Abruf-Werkzeug durch KBRetrieveTool oder GroundedRetrieveTool basierend auf dem Abrufmodus ersetzt.
4. Konnektor-Laden. Im Agent-beschränkten Modus werden nur die an den Agent gebundenen Konnektoren geladen. Im Auto-Discovery-Modus (kein Agent ausgewählt) werden alle für den Benutzer sichtbaren Konnektoren geladen. Sowohl API-Konnektoren (ConnectorMetaTool) als auch Datenbank-Konnektoren (DatabaseMetaTool) verwenden standardmäßig Progressive Disclosure — leichte Stubs im System-Prompt, vollständige Schemas bei Bedarf geladen.
5. MCP-Laden. Die persönlichen MCP-Server des Benutzers sowie von Administratoren bereitgestellte globale MCP-Server werden geladen und verbunden. Im Progressive-Modus (Standard) konsolidiert ein einzelner MCPServerMetaTool alle Server; das LLM ruft discover- und call-Unterbefehle bei Bedarf auf. Siehe Progressive Disclosure.
6. Skills-Injektion. Alle aktiven Skills, die für den Benutzer sichtbar sind, werden geladen — unabhängig von der Agent-Auswahl. Im Progressive-Modus wird ReadSkillTool mit kompakten Stubs im System-Prompt registriert. Im Inline-Modus wird der vollständige Skill-Inhalt direkt eingebettet.
7. CallAgent-Registrierung (nur Auto-Modus). Wenn kein spezifischer Agent ausgewählt ist, werden alle aktiven, sichtbaren Agenten in einen Katalog zusammengefasst und über CallAgentTool verfügbar gemacht, wodurch das LLM Aufgaben an spezialisierte Agenten delegieren kann. Delegierte Agenten erhalten eine vollständige ToolRegistry, die aus ihrer eigenen Konfiguration erstellt wird, schließt aber call_agent aus, um unendliche Rekursion zu verhindern. Wenn ein spezifischer Agent ausgewählt ist, wird CallAgentTool nicht registriert — Agenten sind spezialisiert und delegieren nicht an andere Agenten. Dies verhindert, dass Marketplace-Agenten auf die privaten Prompts anderer Agenten zugreifen.
8. 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. Ein request_tools Meta-Werkzeug wird automatisch registriert, das es dem LLM ermöglicht, während des Gesprächs dynamisch zusätzliche Werkzeuge zu laden, falls die anfängliche Auswahl ein benötigtes Werkzeug übersehen hat. Auswahlfehlschlag ist nicht fatal — der Agent fällt auf den vollständigen Satz zurück. Siehe Progressive Disclosure.
9. Hook-Registrierung. Die deklarierten Hooks des Agenten (aus model_config_json.hooks) werden instanziiert und an eine HookRegistry angehängt. Jeder gewählte Werkzeugaufruf wird umhüllt: PreToolUse Hooks können Argumente vor der Ausführung blockieren oder umschreiben; PostToolUse Hooks können die Beobachtung umschreiben, bevor sie an das LLM zurückkommt. Hooks laufen außerhalb der LLM-Schleife und können nicht durch Agent-Anweisungen umgangen werden — siehe Hook-System.

Das Ergebnis: Der Agent sieht genau die Werkzeuge, die er braucht, nicht mehr. Ein einfacher Agent ohne Konnektoren und ohne KB könnte 5 Werkzeuge sehen. Ein Hub-Agent, der mit 3 Unternehmenssystemen verbunden ist, mit einer fundierten Wissensdatenbank und 2 MCP-Servern könnte 30 sehen — aber nach der Auswahl schaffen es nur die 6 relevantesten in den Kontext.

​

Wann man was verwendet

Die Kategorien schließen sich nicht gegenseitig aus. Ein einzelner Agent kann alle fünf Funktionsquellen in einem Gespräch nutzen – ein Skill für das SOP zur Beschwerdeverarbeitung laden, eine Knowledge Base nach Richtliniendokumenten abfragen, einen Connector aufrufen, um das ERP zu überprüfen, die Analyse an einen spezialisierten Agent delegieren (im Auto-Modus) und ein Built-in Tool verwenden, um die Ergebnisse zu formatieren.

​

Ausführungs-Engines sind orthogonal

Das Tool-System und die Ausführungs-Engines sind unabhängige Belange. Die LLM-gesteuerten Engines (ReAct und DAG) verbrauchen Tools aus derselben ToolRegistry. 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 er 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” wird in der Zeit einer Suche abgeschlossen, 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 nötig) erfordert keine Änderungen am Tool-System. Beide Engines unterstützen auch Agent-Delegation über CallAgentTool im Auto-Modus (kein Agent ausgewählt). Im nativen Function-Calling-Modus kann das LLM mehrere call_agent-Aufrufe in einer einzigen Runde aufrufen, die gleichzeitig über asyncio.gather ausgeführt werden. Jeder delegierte Agent erhält seine eigene ToolRegistry und läuft als vollständige Ausführungseinheit. Für das detaillierte Design der Agent-Erkennung, Skills als globale SOPs und Agent-Delegation siehe Agent & Resource Discovery.

​

Workflow Engine — das dritte Paradigma

Neben den LLM-gesteuerten ReAct- und DAG-Engines enthält FIM One einen Workflow Engine — einen visuellen DAG-Editor mit 26 Knotentypen für die Automatisierung fester Prozesse (Genehmigungsketten, geplante ETL, mehrstufige Pipelines). Workflows können Agenten, Konnektoren, Knowledge Bases, MCP Server, LLM-Aufrufe, HTTP-Anfragen, Python-Code und manuelle Genehmigungsgates aufrufen. Die Beziehung ist asymmetrisch: Workflows können Agenten orchestrieren (über den AGENT-Knoten), aber Agenten können Workflows nicht direkt aufrufen. Verwenden Sie Agenten für flexible, explorative Aufgaben; verwenden Sie Workflows für deterministische, wiederholbare Prozesse. Weitere Informationen finden Sie unter Execution Modes.

​

Lifecycle-Übersicht

Startup. start.sh führt Alembic-Migrationen aus, startet den FastAPI-Server, erkennt integrierte Tools und stellt MCP-Serververbindungen für alle vorkonfigurierten globalen Server her. Pro Anfrage. JWT-Authentifizierung, Agent-Konfigurationssuche, Tool-Zusammenstellung (die 8-Schritte-Pipeline oben), Engine-Auswahl (ReAct oder DAG basierend auf Agent-Konfiguration), Ausführung mit SSE-Streaming und Ergebnispersistenz. Übergreifende Belange. Kontextverwaltung (5-Schichten-Token-Budget) schützt jeden LLM-Aufruf vor Überlauf. Das Hook-System umhüllt jeden Tool-Aufruf mit plattformgesteuerte PreToolUse / PostToolUse Logik — der Mechanismus hinter der Genehmigung durch Menschen in der Schleife (FeishuGateHook), Audit-Protokollierung und Durchsetzung des Nur-Lesen-Modus. Die Audit-Protokollierung verfolgt jeden Connector-Tool-Aufruf. Sandbox-Isolierung enthält Code-Ausführungs-Tools. Die Zwei-LLM-Architektur (smart + fast) optimiert die Kosten über Planung, Ausführung und Synthese. Die Architektur ist so konzipiert, dass jeder Belang – Tool-Registrierung, Ausführungsorchestration, Kontextverwaltung, Sicherheit – sich unabhängig entwickeln kann. Ein neuer Connector-Typ, eine neue Ausführungs-Engine oder eine neue Kontextstrategie können hinzugefügt werden, ohne kaskadierende Änderungen im gesamten System zu verursachen.