> ## 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.

# Ausführungsmodi

> Standalone, Copilot und Hub — drei Möglichkeiten zur Bereitstellung von FIM One.

## Drei Modi

FIM One arbeitet in drei Modi, die davon bestimmt werden, wie der Agent bereitgestellt und verwendet wird:

| Modus          | Was es ist                                  | Bereitstellung          | Beispiel                                                             |
| -------------- | ------------------------------------------- | ----------------------- | -------------------------------------------------------------------- |
| **Standalone** | Universeller KI-Assistent                   | Portal                  | Chat, Suche, Code-Ausführung, Wissensdatenbank-Q\&A                  |
| **Copilot**    | KI eingebettet in ein Host-System           | iframe / Widget / Embed | „Finance Copilot" eingebettet in ERP-Web-UI                          |
| **Hub**        | Zentrale systemübergreifende Orchestrierung | Portal / API            | Agent fragt ERP ab, prüft OA-Genehmigungen, benachrichtigt über Lark |

Die Entwicklung ist natürlich: Beginnen Sie mit Standalone, betten Sie es als Copilot in ein Host-System ein, und richten Sie dann einen Hub für systemübergreifende Orchestrierung ein. Der Copilot läuft weiterhin eingebettet; der Hub fügt eine zentrale Orchestrierungsebene hinzu.

## Modusdetails

### Standalone (0 Konnektoren)

Der Standardmodus. FIM One funktioniert als vollwertiger KI-Assistent:

* Integrierte Tools: Websuche, Python-Ausführung, Rechner, Dateivorgänge, Shell-Befehle
* Wissensdatenbank mit RAG (PDF, DOCX, Markdown, HTML, CSV)
* Dynamische DAG-Planung für komplexe mehrstufige Aufgaben
* Echtzeit-Streaming mit DAG-Visualisierung

Kein externer Systemzugriff erforderlich. Nützlich für allgemeine Analysen, Recherchen und Code-Aufgaben.

### Copilot (eingebettet)

Betten Sie FIM One in die Web-UI eines Host-Systems ein. Der Agent arbeitet neben Benutzern in ihrer vertrauten Oberfläche – kein Kontextwechsel erforderlich. Der Copilot-Modus kann mehrere Konnektoren verwenden (z. B. die Datenbank des Host-Systems + einen Benachrichtigungsdienst).

```mermaid theme={null}
flowchart LR
  subgraph Host["Host System (ERP / CRM / OA)"]
    Copilot["FIM One Copilot<br/>(iframe / widget)"]
  end
  Copilot -- Connectors --> DB["DB"]
  Copilot -- Connectors --> API["API"]
  Copilot -- Connectors --> Lark["Lark"]
```

Beispiele:

* **Finance Copilot**: Verbunden mit Kingdee (金蝶) über DB-Konnektor → Finanzberichte abfragen, Analysberichte generieren
* **Contract Copilot**: Verbunden mit Vertragsmanagementsystem über API-Konnektor → Verträge suchen, Klauseln extrahieren, Risiken bewerten
* **HR Copilot**: Verbunden mit HR-System über API-Konnektor → Mitarbeiterinformationen abfragen, Statistiken generieren

Der Agent nutzt die gleiche ReAct/DAG-Engine wie der Standalone-Modus, hat aber jetzt Zugriff auf echte Geschäftsdaten über den Konnektor.

### Hub (zentrale Orchestrierung)

Der Hub ist ein eigenständiges Portal (oder eine API), das als zentrale Intelligenzschicht dient. Er ist nicht in ein einzelnes System eingebettet – stattdessen verbindet er sich mit allen Systemen. Benutzer greifen über die Portal-UI oder API darauf zu.

```mermaid theme={null}
flowchart LR
  ERP --> Hub["FIM One Hub<br/>(AI orchestration)"]
  Database --> Hub
  Lark --> Hub
  CRM --> Hub
  OA --> Hub
  CustomAPI["Custom API"] --> Hub
```

Beispiele:

* "Überprüfe überfällige Verträge in CRM, kreuze mit ERP-Zahlungen ab, benachrichtige Finanzteam auf Lark"
* "Wenn OA-Genehmigung abgeschlossen ist, aktualisiere Vertragsstatus in CRM und protokolliere in Audit-Datenbank"
* "Abfrage von Verkaufsdaten aus Salesforce, Prognose mit Business-DB generieren, Zusammenfassung per E-Mail an Management senden"

Jeder Konnektor ist eine unabhängige Brücke. Das Hinzufügen oder Entfernen eines Konnektors beeinträchtigt die anderen nicht.

## Liefermethoden

| Liefermethode       | Beschreibung                                       | Typischer Modus                   |
| ------------------- | -------------------------------------------------- | --------------------------------- |
| **Portal (Web UI)** | Integrierte Next.js-Schnittstelle                  | Standalone, Hub                   |
| **API (headless)**  | HTTP/SSE-Endpunkte (`/api/execute`, `/api/stream`) | Hub (programmgesteuerte Zugriffe) |
| **iframe / Embed**  | In Host-System-Seiten injiziert                    | Copilot                           |

Liefermethode und Modus sind verwandt, aber nicht gekoppelt: Sie können auf einen Hub über die API zugreifen oder einen eigenständigen Agent über das Portal verwenden. Das typische Muster ist jedoch Portal für Hub und Embed für Copilot.

## Ausführungs-Engines (interne Implementierung)

Unter der Haube bietet FIM One zwei Ausführungs-Engines:

| Engine           | Am besten für                 | Funktionsweise                                                             |
| ---------------- | ----------------------------- | -------------------------------------------------------------------------- |
| **ReAct**        | Einzelne komplexe Abfragen    | Reason → Act → Observe Loop mit Tools                                      |
| **DAG Planning** | Multi-Step parallele Aufgaben | LLM generiert Abhängigkeitsgraph, unabhängige Schritte laufen gleichzeitig |

```mermaid theme={null}
flowchart TD
  DAG["DAG Planning<br/>(orchestration layer)"]
  DAG --> step_1
  DAG --> step_2
  step_1 --> ReAct1["ReAct Agent"] --> Tools1["Tools"]
  step_2 --> ReAct2["ReAct Agent"] --> Tools2["Tools"]
  step_1 & step_2 --> step_3
  step_3 --> ReAct3["ReAct Agent"] --> Tools3["Tools"]
```

ReAct ist die atomare Einheit; DAG ist die Orchestrierungsschicht. Beide Engines funktionieren in allen drei Modi (Standalone, Copilot, Hub). Im Hub-Modus kann ein einzelner DAG-Schritt Konnektoren zu verschiedenen Systemen aufrufen.

## Zwei Ausführungsparadigmen

FIM One bietet zwei komplementäre Paradigmen für die Erledigung von Aufgaben:

| Paradigma        | Orchestrierung                                                                     | Am besten geeignet für                                          |
| ---------------- | ---------------------------------------------------------------------------------- | --------------------------------------------------------------- |
| **Agent (Chat)** | LLM entscheidet nächsten Schritt dynamisch (ReAct oder DAG)                        | Explorative Aufgaben, Gespräche, flexible Argumentation         |
| **Workflow**     | Festes DAG, das zur Entwurfszeit definiert wird (visueller Editor, 26 Knotentypen) | Genehmigungsketten, geplante ETL, mehrstufige Automatisierungen |

**Agenten** glänzen, wenn die Aufgabe offen ist — „analysiere die Daten dieses Quartals und empfehle Maßnahmen." Der LLM plant und passt sich spontan an.

**Workflows** glänzen, wenn der Prozess bekannt und wiederholbar ist — „jeden Montag Rechnungen aus dem ERP abrufen, Compliance-Prüfungen durchführen, Ausnahmen an einen Prüfer weiterleiten." Der visuelle Editor ermöglicht es dir, Knoten (Agent, Connector, KB, LLM, HTTP, Code, Human Approval, Sub-Workflow) in ein festes DAG zu verbinden.

Die beiden Paradigmen lassen sich natürlich kombinieren: Ein Workflow kann einen Agenten bei jedem Schritt aufrufen, der flexible Argumentation innerhalb einer ansonsten festen Pipeline benötigt. Agenten können Workflows nicht direkt aufrufen — die Beziehung ist unidirektional.

<Tip>
  **Wann man welches wählt:** Wenn du sehr spezifische, Schritt-für-Schritt-Anweisungen für einen Agenten schreibst, gehört dieser Prozess wahrscheinlich in einen Workflow. Wenn die Aufgabe Urteilsvermögen, Erkundung oder Anpassung an unerwartete Daten erfordert, behalte sie als Agenten.
</Tip>