FIM One ist ein AI-Connector-Hub, der drei progressive Modi bedient:
Standalone → Dein eigener KI-Assistent (Portal)Copilot → KI eingebettet in ein Host-System (iframe / Widget / Embed)Hub → Zentrale systemübergreifende Orchestrierung (Portal / API)
Hub-Modus ist der Kernunterscheidungsfaktor. Unternehmenskunden haben Legacy-Systeme — ERP, CRM, OA, Finanzen, HR — die über KI miteinander kommunizieren müssen:GTM-Pfad: Land and Expand
Schritt
Modus
Was passiert
Land
Copilot
In ein System einbetten, Wert in ihrer UI nachweisen
Nachverfolgter Fehler, die in der Produktion reproduzierbar sind, aber noch nicht behoben wurden. Jeder Eintrag benennt das Symptom, den vermuteten Bereich und die Problemumgehung (falls vorhanden). Einträge werden in einen Versionsabschnitt verschoben, sobald eine Behebung definiert und geplant ist.
Agent-Editor zeigt Warnung zu ungespeicherten Änderungen ohne tatsächliche Bearbeitung. Das Öffnen eines vorhandenen Agenten über /agents/[id] und sofortiges Zurückklicken löst den Dialog „Ungespeicherte Änderungen” aus, auch wenn kein Feld berührt wurde. Die Dirty-Check vergleicht 20+ Felder mit der geladenen Agent-Payload, daher reicht eine asymmetrische Standardeinstellung zwischen State-Initialisierung und Dirty-Vergleich aus, um einen Phantom-Mismatch zu verursachen – aktuelle Vermutung ist eines der verschachtelten model_config_json / Benachrichtigungs- / Genehmigungsrouting-Felder, möglicherweise von undefined vs null vs "" Normalisierung. Reproduzierbar besonders bei organisationsgebundenen Agenten. Problemumgehung: Dialog verwerfen (Discard and leave) – kein Datenverlust, da sich nichts tatsächlich geändert hat. Versuchte Behebung (cb40c86a) entfernte ein verwandtes Orphan-Badge-Flimmern auf den Ressourcen-Pickern, löste aber dieses Problem nicht.
Das Speichern einer Agent-Bearbeitung kann mit Input should be 'initiator', 'agent_owner' or 'org_members' fehlschlagen. Pydantic lehnt das Feld confirmation_approver_scope an der /api/agents/{id} PUT-Grenze ab, obwohl jeder gespeicherte Wert in der Datenbank einer der drei gültigen Literale ist. Vermutung: Das Frontend as "initiator" | "agent_owner" | "org_members" Cast ist nur ein Compile-Time-Versprechen, daher kann ein Legacy- oder unerwarteter Runtime-String (möglicherweise aus einer Vorlage, einem Import oder einer älteren Migration) durch setConfirmationApproverScope durchschlüpfen und wörtlich zurückgesendet werden. Problemumgehung: Wählen Sie explizit einen Wert in der Dropdown-Liste Genehmigung → Genehmiger-Bereich aus, bevor Sie speichern.
Playground-Stopp-und-Wiederholung zeigt vorübergehende visuelle Artefakte, die ein Seiten-Refresh immer behebt. Drei gleichzeitige Render-Quellen – activeConversation.messages (DB-Snapshot), der SSE messages Stream und der optimistische pendingQuery Platzhalter – werden nicht in einen einzelnen abgeleiteten State zusammengefasst, daher kann die UI zwischen dem Klick auf „Retry” und dem Eintreffen der gepaarten Assistenten-Antwort (a) kurzzeitig die gleiche Abfrage zweimal im Pre-Stream-Fenster rendern, (b) vorherige verwaiste User-Blasen aus dem Wiederholungsverlauf löschen, während hasLiveMessages wahr ist und bevor der Snapshot neu geladen wird, und (c) im engen Fenster zwischen dem SSE „done” Event und dem nächsten selectConversation Refresh flimmern. Daten gehen nie verloren – jede Benutzer-Nachricht (einschließlich abgebrochener Wiederholungen) wird in conversation.messages beibehalten, in den nächsten LLM-Aufruf über normalize_alternating_messages übernommen und nach Refresh über HistoryTurn.orphanUserContents (eingeführt in der 48ba08c6 Render-Behebung) korrekt gerendert. Zum Kontext: Claude’s eigene Web-UI zeigt eine analoge Fehlerklasse – das Stoppen einer Antwort und sofortiges Senden einer Folgefrage verzweigt die Folgefrage manchmal als Sibling-Edit-Zweig der ersten Abfrage, anstatt sie als neue Runde anzuhängen – daher ist dies ein bekanntes schwieriges Problem in Optimistic-UI + SSE + Persisted-History Designs, kein FIM-One-spezifischer Defekt. Eine ordnungsgemäße Behebung erfordert das Zusammenfassen der drei Render-Quellen in einen einzelnen abgeleiteten State; aufgeschoben bis zu einer breiteren Playground State-Machine Umgestaltung.
Dokumentationsseite zur Modellkonfiguration mit Extended-Thinking-Setup pro Anbieter
SSE Protocol v2: Echtzeit-Antwort-Streaming mit delta_reasoning, usage-Feldern und geteilten done/suggestions/title/end-Events; SQLite-Pool-Größe 5 -> 20
AI Builder-Erweiterung: 7 neue Builder-Tools (GetSettings, TestConnection, ImportOpenAPI für Konnektoren; ListConnectors, AddConnector, RemoveConnector, SetModel für Agenten), is_builder-Flag auf Agenten, automatische Builder-Prompt-Aktualisierung, SSRF-Schutz
SSE v2 Frontend: Streaming-Punkt-Puls-Cursor, DAG-Neuplan-Runden-Snapshots als einklappbare Karten, DAG-Layout entkoppelt von Schrittzuständen
Konzeptdokumentationsseite für AI Builder mit Konnektoren- und Agenten-Builder-Leitfäden
Organisationssystem: vollständige CRUD-Operationen mit rollenbasierter Mitgliedschaft (Eigentümer/Admin/Mitglied), Admin-Verwaltungs-UI
Dreiebenen-Ressourcensichtbarkeit (persönlich/Org/global) für Agenten, Konnektoren, Wissensdatenbanken, MCP-Server
Veröffentlichungs-/Unveröffentlichungs-API für alle Ressourcentypen; Eigentümerdelegation für veröffentlichte Agenten
Drei Modellrollen (Allgemein/Schnell/Reasoning) mit isolierter Umgebungskonfiguration pro Tier; Schnellmodell erbt keine Hauptmodell-Einstellungen mehr
StepOutput-Dataclass ersetzt einfache String-Schrittergebnisse für strukturierte Daten und Artefakt-Übergabe
Tool-Cache für DAG-Ausführung — identische Tool-Aufrufe pro Lauf gecacht mit asynchronem Lock-Stampede-Schutz (DAG_TOOL_CACHE)
Pro-Schritt-LLM-Verifizierung mit 1 Wiederholung bei Fehler (DAG_STEP_VERIFICATION)
Auto-Routing: schnelles LLM klassifiziert Abfragen als ReAct oder DAG; /api/auto-Endpoint; Frontend 3-Wege-Modusumschalter (AUTO_ROUTING)
Shadow Market Organization + Resource Subscriptions: Integrierte Market-Org (Shadow, kein automatischer Beitritt) ersetzt Platform-Org; Ressourcen werden durch Marketplace-Browsing entdeckt und explizit abonniert (Pull-Modell); Market-API zum Abonnieren gemeinsamer Ressourcen; Veröffentlichung auf Market erfordert immer Überprüfung; Ressourcen-Abonnements-Tabelle; Org-basierte Ressourcenfreigabe ersetzt globale Sichtbarkeit
Agent Auto-discovery and Sub-agent Binding: discoverable-Flag auf Agenten; sub_agent_ids-Whitelist; CallAgentTool zum Delegieren von Aufgaben an spezialisierte Agenten
MCP Server Credentials + Per-User Override: mcp_server_credentials-Tabelle; PUT /api/mcp-servers/{id}/my-credentials-Endpoint; allow_fallback-Flag für Fallback-Verhalten bei Anmeldedaten
Connector/KB Toggle: POST /api/connectors/{id}/toggle und POST /api/knowledge-bases/{id}/toggle zum Aussetzen/Fortsetzen von Ressourcen
Standalone KB Conversations: kb_ids-Feld auf Konversationen für direkten KB-Chat ohne Agent-Bindung
RBAC: Konnektor-Zugriffskontrolle pro Benutzer/Rolle (in v0.7.x ausgeliefert — Org-System + dreistufige Sichtbarkeit)
Konnektor-Anmeldedaten-Verschlüsselung + Benutzer-Override: connector_credentials-Tabelle, Fernet-Verschlüsselung über CREDENTIAL_ENCRYPTION_KEY, allow_fallback-Flag, GET/PUT/DELETE /my-credentials-Endpunkte, Auflösung von Benutzer-Anmeldedaten beim Laden von Chat-Tools
Veröffentlichungs-Review-UI: Org-übergreifendes Veröffentlichungs-Review-System — Review-Toggle pro Org, ReviewsSheet mit Genehmigung/Ablehnung-Workflow, Status-Badges auf Ressourcen-Karten, Review-Hinweis im Veröffentlichungs-Dialog, erneute Einreichung für abgelehnte Ressourcen
Konnektor Progressive Offenlegung (Phase 1-2): einzelnes ConnectorMetaTool ersetzt Pro-Action-Tools; System-Prompt erhält nur leichte Stubs (Name + 1-Zeilen-Beschreibung, ~30 Token/Konnektor vs ~250 Token/Action); Agent ruft discover(connector) auf, um vollständiges Action-Schema bei Bedarf zu laden — Schema wird nur geladen, wenn das Modell einen Konnektor auswählt, wodurch das Prompt-Präfix für Caching stabil bleibt. Folgt dem verzögerten Tool-Loading-Muster, das in modernen Agent-Frameworks üblich ist. execute-Unterbefehl; Feature-Flag für Rückwärtskompatibilität.
Agent-Skill-System + Kompakte Anweisungen: On-Demand-Skill-Loading für Agent-Anweisungen — Skill-Modell (Name, Inhalt/SOP, optionale Skripte) an Agenten angehängt; im System-Prompt nur nach Name referenziert (~10 Token/Skill); Agent ruft read_skill(name) auf, um vollständigen Inhalt bei Bedarf zu laden. Reduziert Pro-Konversations-Anweisungs-Token-Kosten um ~80%, während umfangreichere SOP-Bibliotheken ermöglicht werden. Gegenstück zur Progressive Offenlegung von ConnectorMetaTool auf Anweisungsebene angewendet. Ermöglicht die Differenzierungsgeschichte “指令 + 工具 + 技能”. Fügt auch compact_instructions-Feld zum Agent-Modell hinzu — Pro-Agent-Komprimierungs-Prioritätsliste in ContextGuard bei Komprimierung eingefügt (z. B. “Bestellungs-IDs und Beträge bewahren, rohe API-Antworten verwerfen”), ersetzt die aktuelle statische generische Eingabeaufforderung. Folgt der Compact Instructions-Konvention, die in modernen Agent-Frameworks weit verbreitet ist.
Workflow Phase 2 Knoten: Iterator, Loop, VariableAggregator, ParameterExtractor, ListOperation, Transform, DocumentExtractor, QuestionUnderstanding, HumanIntervention — 9 erweiterte Knotentypen mit vollständigem Frontend + Backend + 150 neue Tests (275 insgesamt). Knoten-Wiederholung mit exponentiellem Backoff, sichere Ausdrucksevaluierung. Stats-Panel mit Erfolgsquoten-Balken. 12 integrierte Vorlagen. Bereichs-Kontextmenü (Einfügen, Alles auswählen, Ansicht anpassen, Auto-Layout).
Workflow Phase 3 Knoten: SubWorkflow + ENV — 2 neue Knotentypen (25 Knoten insgesamt), 14 neue Tests (306 insgesamt), 14 integrierte Vorlagen. SubWorkflow: vollständig DB-gestützter verschachtelter Workflow-Executor mit Ziel-Workflow-Auswahl, Variablenmapping und konfigurierbarem Tiefenlimit zur Vermeidung unendlicher Rekursion. ENV: liest verschlüsselte Umgebungsvariablen mit Schlüssel-Picker und Fallback-Standardwerte. Vollständiges Frontend (Knotenkomponenten, Konfigurationspanels, Palette-Einträge, Minimap-Farben). Pro-Knoten-Ausführungsstatistik-Panel (Erfolgsquoten, Dauern, Fehleranzahl sortiert nach Schlimmsten zuerst). getNodeStats-API-Client + NodeStatEntry-Typ. Tastaturkürzel-Dialog (?-Taste).
Workflow Geplante Trigger: Pro-Workflow-Cron-Konfiguration mit Zeitzone, Standard-Eingaben und Berechnung des nächsten Laufs. Voreingestellte Cron-Schaltflächen, 30 Trigger-Tests.
Workflow API Trigger: Öffentliche Pro-Workflow-API-Schlüssel (wf_-Präfix) für externe Ausführung ohne Benutzer-Authentifizierung, mit Rate Limiting. API-Schlüssel-Verwaltungs-Dialog mit Generieren/Neugenerieren/Widerrufen, Trigger-URL und cURL/JS-Beispiele.
Workflow Batch-Ausführung: POST /batch-run mit bis zu 100 Eingabesätzen, konfigurierbare Parallelität (1-10), zusammenklappbare Pro-Element-Ergebnisse, JSON-Export. 14 Batch-Ausführungs-Tests.
Workflow Ausführungsprotokoll-Viewer: Echtzeit-chronologischer SSE-Ereignisstrom im Run-Panel mit Zeitstempeln, farbcodierten Badges und Ereignistyp-Filter-Umschaltern.
Workflow Run Stats: Backend batch-abruft Run-Anzahl und Erfolgsquoten über GROUP BY-Unterabfrage; Frontend zeigt Stats auf Workflow-Karten mit farbcodierten Erfolgsquoten-Indikatoren an.
Workflow Scheduler Daemon: Hintergrund-Async-Service, der alle 60 Sekunden auf fällige Cron-basierte Workflows abfragt. Croniter-Zeitzone-Unterstützung, Semaphore-Parallelität, last_scheduled_at-Verfolgung, Webhook-Zustellung. 14 Tests.
Workflow Import Konflikt-Resolver: Erkennt ungelöste Agent/Konnektor/KB/MCP-Referenzen während des Imports. Batch-DB-Abfragen mit Sichtbarkeitsfilterung, Frontend-Toast-Warnungen. 17 Tests.
Workflow Test-Knoten-Ausführung: Isolierte Einzelknoten-Tests mit Mock-Variablen, in Editor integriert (Konfigurationspanel Test-Schaltfläche + Kontextmenü). 23 Tests.
Workflow Version Diff: Nebeneinander-Blueprint-Vergleich mit Knoten/Kanten-Änderungserkennung, farbcodierte Indikatoren (hinzugefügt/entfernt/geändert).
Workflow Run Management: Löschen einzelner Runs (DELETE /runs/{run_id}) und Löschen aller abgeschlossenen Runs (DELETE /runs), mit Frontend-Bestätigungsdialogen.
Workflow Run Replay Overlay: “Auf Canvas anzeigen”-Schaltfläche in Run-Verlauf zur Überlagerung vergangener Ausführungsergebnisse auf dem Canvas, Anzeige von Pro-Knoten-Status und Ausgabe ohne Neuausführung.
Workflow Favoriten/Anheften: Workflows mit Stern markieren/an die Spitze der Liste anheften mit localStorage-Persistierung.
Workflow Run History Export: Export-Run-Verlauf als JSON-Datei-Download mit vollständigen Run-Metadaten und Pro-Knoten-Ergebnissen.
Admin Workflows Management: Admin-Panel-Tab zur Verwaltung aller Workflows über Benutzer hinweg — Auflisten, Aktivieren/Deaktivieren umschalten, Löschen mit Bestätigung. Batch-Endpunkte zum Löschen, Umschalten und Veröffentlichen mit Audit-Protokollierung.
Workflow Templates System: WorkflowTemplate-ORM-Modell mit Admin-CRUD, öffentliche Auflistungs-/Clone-API und 5 Seed-Vorlagen, die beim ersten Start automatisch eingefügt werden.
Workflow Inline Validation Badges: Echtzeit-Pro-Knoten ValidationBadge auf Canvas mit Fehler-/Warnungs-Tooltips für sofortiges visuelles Feedback während der Bearbeitung.
Workflow Execution Trace Viewer: Timeline-basierter Trace-Viewer Sheet mit Engine trace_level-Parameter und Pro-Knoten-Variablen-Snapshots für Step-Through-Debugging.
Workflow Rate Limiting und Timeout: Pro-Benutzer WorkflowRateLimiter (Sliding Window 10 Runs/Min, 3 gleichzeitig) und Standard 10-Minuten-Global-Run-Timeout.
Workflow Blueprint System: Visueller Workflow-Editor zum Entwerfen und Ausführen mehrstufiger Automatisierungs-Blueprints — Workflow / WorkflowRun-ORM-Modelle, vollständig CRUD + SSE-Ausführungs-API, Import/Export, Duplikat, Blueprint-Validierungs-Endpunkt, WorkflowEngine mit topologischer Sortierung + Semaphore-basierter Parallelität + Bedingungsverzweigung und 12 Knotentypen (Start, End, LLM, ConditionBranch, QuestionClassifier, Agent, KnowledgeRetrieval, Connector, HTTPRequest, VariableAssign, TemplateTransform, CodeExecution), VariableStore mit {{node_id.output}}-Interpolation und env.*-Namespace, Fehlerstrategien pro Knoten (STOP_WORKFLOW / CONTINUE / FAIL_BRANCH) mit Pro-Knoten-Timeout und erweiterter Konfigurations-UI, React Flow v12 visueller Editor mit Drag-and-Drop-Palette + Knoten-Konfigurationspanel + Variablen-Picker-Combobox + Add-Node-on-Edge + Auto-Layout (ELK.js) + Run-Verlauf Sheet, Dify-ähnliches kompaktes Knoten-Design mit Ring-basiertem Run-Status-Styling und animierten Kanten-Übergängen, 4 integrierte Starter-Vorlagen (Simple LLM Chain, Conditional Router, Knowledge-Augmented QA, HTTP API Pipeline) mit Template-Picker-Dialog und GET /templates + POST /from-template-API, Stats-Endpunkt, ?run=true-URL-Parameter Auto-Open, Subprocess-basierte Code-Ausführungs-Sicherheit, 105-Test-Suite (Vorlagen, Eval-Namespace-Flattening, Blueprint-Validierungs-Warnungen, Knoten/Kanten-Löschung, Import/Export/Duplikat, Deadlock-Erkennung, Multi-Bedingungsverzweigung)
Operation Audit: detaillierte Protokollierung wer was getan hat — Admin-Review-Log-Audit-Tab hinzugefügt (Veröffentlichungs-Review-Trail pro Org/Ressource)
Semantic Schema Annotations: Konnektor-Schema-Felder mit semantic_tag, description und pii-Flags erweitern; Annotationen in LLM-Tool-Beschreibungen angezeigt, damit der Agent die Feldabsicht versteht, ohne von Spaltennamen zu raten
Agent Core Phase 0 — Compact prompt upgraded to 9-section structured format; empty tool result protection (descriptive message instead of (no output)); anti-loop prompt + cycle detection threshold lowered to 2; domain classifier + pre-flight DB config resolution parallelized (400–1100 ms saved per request); SSE end event sent immediately after answer, with title/suggestions moved to background tasks
Agent Core Phase 1 (Context Anti-Bloat) — MicroCompact rule-based old tool result cleanup (keep last 6); REACT_TOOL_RESULT_BUDGET=40000 aggregate cap; reactive compact on context overflow (auto-compact to 50% budget and retry instead of crashing)
Agent Core Phase 2 (Speed) — Keyword-based tool pre-selection (skips LLM call on obvious matches, 200–500 ms saved); SharedHttpClient LLM connection pooling; completion check skipped for answers >200 tokens; FallbackLLM wraps primary+fast with automatic failover on 429/503/529/connection errors
Intelligent Document Processing (Vision-Aware) — Adaptive document handling: PDF pages rendered as images via PyMuPDF for vision-capable models (GPT-4o, Claude 3/4, Gemini), text-only fallback via pdfplumber. Per-model supports_vision flag. Modes via DOCUMENT_PROCESSING_MODE, DOCUMENT_VISION_DPI, DOCUMENT_VISION_MAX_PAGES. DOCX/PPTX embedded image extraction. Multi-turn vision persistence across conversation turns. Smart PDF processing (text-rich pages extract text + images; scanned pages render as full-page PNG). Pre-built sandbox image (Dockerfile.sandbox) with common data-science packages for --network=none code execution
File integrity guardrail — System prompt rule prevents the agent from substituting unrelated file contents when a target file is unreadable; uploaded files now include file_id in message context for direct read_uploaded_file access
System prompt section registry with cache breakpoints — Memoized PromptRegistry splits system prompts into stable prefix + dynamic suffix; cache-capable providers (Claude, Bedrock Anthropic, Vertex Claude) receive cache_control: {"type": "ephemeral"} on the prefix for ~60-80% per-turn input token savings. Non-cache providers get a single concatenated message (zero behavior change)
Prompt cache observability — cache_read_input_tokens and cache_creation_input_tokens tracked through UsageSummary → TurnProfiler → done_payload.cache field. Structured turn_cache log line per turn. Doubles as relay cache-honesty probe
Conversation recovery MVP — Synthetic tool_result rows persist after interrupted turns; POST /chat/resume replays cached SSE events from a monotonic cursor; frontend useSseResume hook auto-reconnects with exponential backoff (300ms → 1s → 3s, max 3 attempts) and “Reconnecting…” indicator
Thinking-block persistence with signature — reasoning_content + Anthropic signature persisted in metadata_["thinking"] and replayed on subsequent turns; fixes HTTP 400 signature mismatch on Claude 4 multi-turn conversations
Provider-aware reasoning replay policy — Centralized reasoning_replay_policy() in core/prompt/reasoning.py gates serialization per provider family: Claude replays thinking blocks with signature; DeepSeek-R1/Qwen-QwQ/Gemini-thinking/o-series drop reasoning_content on outbound (previously leaked, breaking provider KV caches and violating API docs)
Feishu Channel (Phase 1 subset) — Org-scoped Channel resource with Fernet-encrypted credentials; FeishuChannel supports interactive card send + callback (signature verification + URL challenge); Settings → Channels management UI (list, create/edit with dirty-state protection, details with copyable callback URL, test-send); CRUD API (/api/channels) and event callback endpoint (/api/channels/{id}/callback). Shipped early for 2026-04-24 roadshow
Agent Hook System (live in ReAct + DAG runtime) — PreToolUseHook / PostToolUseHook abstraction in src/fim_one/core/hooks/; agents declaring hooks.class_hooks in model_config_json have hooks instantiated and registered per chat session. First consumer FeishuGateHook posts an Approve/Reject card to the linked Feishu group when an agent calls a requires_confirmation=True tool, blocks execution, and resumes or aborts based on verdict
Configurable confirmation gate (inline OR channel) — Every agent gets an Approval section with three routing modes (Auto / Inline only / Channel only), approver-scope selector (initiator / owner / anyone in org), per-tool override, and explicit approval-channel picker. Auto mode gracefully falls back to an inline approval card when no channel is linked. POST /api/confirmations/{id}/respond shares a single decision-recording path with the Feishu webhook
Per-agent task completion notifications — Long-running ReAct or DAG agents can push a summary card to the org’s channel when a task finishes. First consumer of the generic outbound notification pattern
Hook Approval Playground — Channels details sheet has a “Test Approval Flow” action that exercises the full production path (genuine ConfirmationRequest row, real Feishu callback, status transitions) — same code path a production hook uses
Contributor-friendly i18n CI fallback — .github/workflows/i18n-sync.yml translates EN → ZH/JA/KO/DE/FR on master after PR merge and auto-commits with [skip ci]; contributors no longer need LLM_API_KEY locally. Pre-commit locale-edit guard refuses manual edits to generated locale files (ALLOW_LOCALE_EDIT=1 override for legitimate translation fixes). End-to-end verified via smoke-test push
Exa integration docs — Dedicated Integrations section with a first-class Exa page covering the full Exa search surface (neural / fast / deep-reasoning / instant), filtering, content retrieval, and three tuned presets
Xinchuang (信创) database support — Database Connector now lists KingbaseES (人大金仓), HighGo (瀚高), and DM8 (达梦) alongside PostgreSQL/MySQL. PG-compatible drivers reuse asyncpg; DM8 uses dmPython. scripts/test_xinchuang_dbs.py verifies live connectivity from the CLI
Channels + Hook System architecture docs — docs/architecture/hook-system.mdx explains the three hook points and walks through FeishuGateHook end-to-end; existing architecture pages cross-link; README lists Messaging Channels as a first-class capability
Hardening — Duplicate Feishu callback clicks produce a replacement card instead of double-deciding; concurrent callback clicks resolved via conditional UPDATE ... WHERE status='pending' rowcount check; pending approvals auto-expire after CHANNEL_CONFIRMATION_TTL_MINUTES (default 24h) via background sweeper; Settings → Channels respects org role (members see read-only UI); parallel tool-call aggregator handles providers that reuse index=0 for every delta; session-expiry redirect preserves query string
Goal: Close loose ends from the v0.8.5 Channel + Hook rollout before the v0.9 production-hardening wave lands. Scope is intentionally narrow — polish, not new capability.
Per-hook config pass-through — class_hooks entries today are bare strings; to override FeishuGateHook.timeout_seconds, poll_interval_seconds, or callback_base_url per-agent, the schema needs to accept {"name": "feishu_gate", "config": {...}} objects that get forwarded as kwargs to the hook factory. Low-risk follow-up; current defaults (120s timeout / 1.5s poll / env-var callback URL) are acceptable in the meantime.
DAG tools_used accuracy — the completion notification card currently derives tools_used from plan.steps[*].tool_hint (the planner’s suggestion), not the real tool names the per-step ReAct loops chose. Plumb the actual chosen tool names out of the DAG executor’s step-completion callback so notification cards reflect what was actually run.
Hook inheritance policy for delegated sub-agents and Workflow AGENT nodes — today CallAgentTool children and Workflow AGENT nodes create fresh ReActAgents that do not inherit the parent’s hook registry, so a sensitive tool call reached via delegation silently bypasses feishu_gate. Decide and document: do child agents inherit (default-secure, prevents gate bypass) or isolate (lets teams delegate non-approval-gated work to a child agent)? Eval Center runs stay opt-out by design (automation cannot block on human approval).
Playground follow-up suggestions restored, opt-in per agent — the v0.8.5 post-processing refactor moved suggestion generation into a fire-and-forget background task and dropped the post_processing / suggestions SSE events, so the chip row beneath an answer never appeared. Suggestions now stream inline between done and end and are gated by a new per-agent suggest_followups toggle (default off) — task-style agents stay quiet, conversational agents that explicitly opt in pay the one fast-model round-trip and get the chips back.
Everything here is additive and behind existing abstractions — no schema changes, no breaking API changes, safe to land piecewise between v0.8.5 and v0.9.
Ziel: Produktionsreife Operationen, Debugging und Monitoring. Führt das Hook System ein — eine deterministische Durchsetzungsschicht, die unterhalb von Agent-Anweisungen sitzt und vom LLM nicht überschrieben werden kann.
Connector Progressive Disclosure (Phase 3-4): einheitliche ConnectorExecutor-Schnittstelle (API/DB/MCP hinter einer Abstraktion); Validierung von Aktionsparametern mit jsonschema; protokollagnostisches Discover/Execute
IM Channel Integration (bidirektional): Phase 1 — Outbound Push: Lark, WeCom, Slack, Email, Teams Benachrichtigungsaktionen aus Agent/Workflow-Ergebnissen. Phase 2 — Inbound Trigger: Benutzer @erwähnen Agent in IM-Gruppenchats, um Aufgaben auszulösen, ohne das Portal zu öffnen; Webhook-Empfänger pro Kanal; jeder IM-Kanal modelliert als Connector mit bidirektionalen Aktionen (senden + empfangen). Hub-Modus Killer-Feature
Feishu Channel (Phase 1 Teilmenge) — Org-scoped Channel-Ressource mit Fernet-verschlüsselten Anmeldedaten; FeishuChannel-Implementierung mit Unterstützung für interaktive Kartensendung + Callback (Signaturverifizierung + URL-Challenge); integriert mit Bestätigungsgate, sodass Schreibvorgangs-Genehmigungen als Approve/Reject-Karten im konfigurierten Feishu-Gruppenchat landen; Settings → Channels Management UI. Früh ausgeliefert für 2026-04-24 Roadshow. Verbleibend: WeCom, Slack, Email, Teams Outbound + Phase 2 Inbound Trigger.
Outbound Notification Patterns (generisch, wiederverwendbar über Kanaltypen): Die gleiche BaseChannel-Abstraktion unterstützt einen Katalog von Outbound-Anwendungsfällen über Genehmigungsgating hinaus. Jedes Pattern wird einmal gegen BaseChannel implementiert und funktioniert automatisch für jeden konkreten Kanal (Feishu heute; Slack/WeCom/Teams/Email wenn sie landen).
Task Completion Notification: Wenn ein langfristiger DAG / Workflow / geplanter Agent beendet wird, poste eine Zusammenfassungskarte zum Org-Kanal (oder einen vom Benutzer gewählten Kanal) mit Ergebnis-Snippet + Artifact-Links. Das minimal viable “Channel Outbound”-Produkt — erster Consumer nach FeishuGateHook
Exception / Failure Alerts: Agent-Inferenz schlägt fehl, ein LLM-Provider-Fehler, ein Connector wirft einen 5xx, ein DAG-Plan erschöpft das Re-Plan-Budget → push eine Diagnose-Karte zum Ops-Kanal mit Trace ID und Retry-Möglichkeit
Cost / Budget Warnings: Pro-Benutzer oder Pro-Agent Token/Request-Budget erreicht 80% / 100% Schwellenwerte → push zum Admin-Kanal (oder @-mention den Agent-Besitzer) mit aktuellem Verbrauch vs. Obergrenze
Scheduled Digests: Agents oder Workflows senden periodische (täglich / wöchentlich) Zusammenfassungskarten — KPI-Rollup, Open-Ticket-Triage, Vertragsverlängerungsliste — direkt in den Kanal, ohne dass Benutzer das Portal öffnen müssen
Escalation on Stuck Agent: Agent hat N aufeinanderfolgende Iterationen keine beobachtbaren Fortschritte gemacht (Zyklus erkannt, oder max_iterations überschritten) → poste eine Karte, die einen menschlichen Operator auffordert, die Kontrolle zu übernehmen, mit aktuellem Kontext und “mit deiner Notiz fortsetzen”-Aktion
Audit Receipts for Sensitive Tool Calls: unabhängig vom Genehmigungsgate — jeder Aufruf eines Tools mit Tag audit=true sendet eine schreibgeschützte Quittungskarte zum Compliance-Kanal (wer / was / wann / args), was einen dauerhaften Audit-Trail außerhalb der Datenbank bietet
Approval Escalation: Wenn eine feishu_gate Genehmigungskarte innerhalb von N Minuten keine Antwort erhält, @-mention automatisch den Gruppeneigentümer oder leite die Karte an einen höherwertigen Kanal weiter; konfigurierbar pro Tool/Connector
Bestehende RBAC-Kontrollen steuern die Ressourcensichtbarkeit (wer einen Connector sehen kann), nicht die Autorisierung zur Ausführungszeit (was der Aufrufer damit tun kann). Wenn ein Administrator eine DB/API mit hochprivilegierten Anmeldedaten verbindet, erben alle Organisationsmitglieder, die diesen Connector nutzen, den Blast-Radius des Administrators. Dieser Abschnitt schließt die Lücke über drei unterschiedliche upstream-Funktionsebenen:
Ebene 1 — DB-Modus (vollständiger Admin + Basic/Legacy): Der Administrator stellt eine einzelne DB-Anmeldedaten bereit (Root oder ein Least-Privilege-Service-Konto), da die meisten Legacy-Systeme keine benutzergesteuerten DB-Konten ausstellen können. Die Durchsetzung erfolgt oberhalb der Verbindung über ConnectorScopeGuard — einen PreToolUse-Hook, der query- / execute-Aufrufe pro Aufruferidentität filtert. Funktionen: Blockierung destruktiver Verben (DROP, TRUNCATE, unscoped DELETE/UPDATE); Allow/Deny-Listen auf Tabellenebene; Spaltenredaktion basierend auf pii=true-Semantikannotationen; automatische Injektion von Scope-Prädikaten (z. B. AND dept_id = :caller_dept an jeden SELECT anhängen). Die Konfiguration ist ein scope_rules-JSON-Feld auf dem Connector mit rollenbasiertem Matching; Standard ist Deny-if-ambiguous.
Ebene 2 — Open-API-Modus (API-Schlüssel pro Benutzer): Der bevorzugte Weg. Benutzer bringen ihren eigenen API-Schlüssel mit (in v0.8 ausgeliefert — connector_credentials + allow_fallback=false); die native Autorisierung des upstream-Systems erzwingt den Scope auf natürliche Weise. Verbleibende Arbeit: Pro-Connector-Admin-UI zur Anforderung von benutzergesteuerten Anmeldedaten (Admin-Fallback global deaktivieren) und ein Health-Dashboard, das zeigt, welche Organisationsmitglieder ihren eigenen Schlüssel noch nicht gebunden haben.
Ebene 3 — Mittlere Ebene (Login-Ticket-Austausch): Für Frontend/Backend-Split-Systeme ohne benutzergesteuerten API-Schlüssel. Rufen Sie den Login-Endpoint des Systems mit vom Benutzer bereitgestellten Anmeldedaten auf, cachen Sie das zurückgegebene kurzlebige Ticket, aktualisieren Sie es automatisch bei Ablauf. Neuer LoginTicketCredential-Typ neben API-Schlüssel / OAuth; Connector-Spezifikation deklariert auth_type: login_ticket mit login_endpoint, ticket_field und refresh_strategy. Die Adapter-Schicht konvertiert das Ticket pro Anfrage in den ausgehenden Auth-Header.
Ebenenübergreifende Nachverfolgbarkeit: Jeder Tool-Aufruf wird mit caller_user_id, effective_credential_source (Benutzer / Admin-Fallback / Ticket) und scope_rules_applied in ConnectorCallLog gekennzeichnet, damit Ops nach einem Incident die Frage „wer hat tatsächlich was als wen ausgeführt” beantworten können.
Heute ist Feishu als Channel + Connector-Paar verdrahtet — Lieferpipe und API-Oberfläche. Enterprise-Rollouts benötigen eine dritte Rolle: Integration (die gleiche Third-Party-Bindung bietet auch SSO und Org-Graph-Synchronisierung). Landung in v0.9, da die bestehende Feishu-Bindung bereits 3 der 4 erforderlichen Facetten abdeckt, und die Identity-Story entsperrt die Tier-2-Autorisierung oben (Benutzer können ihr eigenes Upstream-Token bei der Anmeldung abrufen, anstatt API-Schlüssel manuell bereitzustellen).
Channel → Integration-Modell: Förderung von Channel von “nur ausgehende Lieferung” zu einem ThirdPartyIntegration-Parent mit drei optionalen Sub-Funktionen — (a) Delivery (vorhandenes Channel-Verhalten: Karten senden, Bestätigungen gating); (b) Login (OIDC / Custom SSO; “Mit Feishu anmelden” ergibt sowohl eine FIM-Sitzung als auch das Upstream-Plattform-Token); (c) Org-Graph-Synchronisierung (Upstream-Abteilungen/Mitglieder in FIM-Org-Struktur spiegeln; geplant oder Webhook-gesteuert). Administratoren schalten jede Funktion pro Bindung um.
Feishu SSO als Integration-Funktion: Wiederverwendung der bestehenden Feishu-App-Bindung (app_id/secret bereits auf dem Channel), um “Mit Feishu anmelden” jedem Benutzer bereitzustellen, dessen Feishu-Mandant an eine Org gebunden ist. Das bei der Anmeldung erhaltene Token wird zur Standard-Anmeldeinformation des Benutzers für den Feishu Connector — Entfernung der “Hol dir deinen eigenen API-Schlüssel”-Reibung für Tier-2-Durchsetzung.
Org-Graph-Synchronisierung (Feishu → FIM org): Feishu-Abteilungen + Mitglieder in FIM abrufen; Feishu-Mandantenadministrator / Abteilungsleiter / Mitgliederrollen auf FIM-Besitzer/Administrator/Mitglied abbilden. Grundlage für WeCom und DingTalk als nächstes, und für Kingdee / Yonyou / SAP ERP-OA-Adapter in v1.0.
Phase 1 (ausgeliefert): API-Schlüssel-Authentifizierungsmiddleware, Scope-Unterstützung, kuratierte OpenAPI-Spezifikation, Mintlify API Reference mit interaktivem Playground.
Pro-Schlüssel-Ratenbegrenzung — Konfigurierbare Anfragen/Minute und Anfragen/Tag-Limits pro API-Schlüssel; 429 Too Many Requests Antworten mit X-RateLimit-* Headern
Pro-Schlüssel-Nutzungskontingent — Monatliche Token/Request-Budgets mit Admin-Dashboard und Schwellenwert-Benachrichtigungen
Scope-Durchsetzung pro Endpunkt — require_scope("chat") Abhängigkeit auf allen geschützten Endpunkten; Schlüssel mit scopes=chat können nur auf Chat-bezogene APIs zugreifen
API-Versionierung (/v1/...) — Stabiler versionierter API-Vertrag; Deprecation-Header für Sunset-Endpunkte
Webhook-Callbacks — Webhook-URLs pro API-Schlüssel registrieren; POST-Benachrichtigungen für Gesprächsvervollständigung, Agent-Fehler und asynchrone Task-Ergebnisse erhalten
SDK-Generierung — Automatisch generierte Python und TypeScript Client-SDKs aus OpenAPI-Spezifikation; veröffentlicht auf PyPI und npm
Developer Portal — Interaktive “Try it” Panels in Mintlify Docs; Nutzungsanalysen für Schlüsseleigentümer sichtbar
API-Schlüssel-Rotation — One-Click-Schlüssel-Rotation mit Übergangsfrist (alter Schlüssel 24h nach Rotation gültig)
Batch-/Async-API — POST /api/batch akzeptiert bis zu 100 Abfragen; gibt eine batch_id zum Abrufen von Ergebnissen zurück; nützlich für Bulk-KB-Abfragen oder Multi-Agent-Orchestrierung
Circuit Breaker pro externe Abhängigkeit — Verhinderung von kaskadierenden Ausfällen, wenn nachgelagerte LLM-Anbieter oder Konnektoren nicht verfügbar sind; automatisches Fallback und Recovery
Agent Trace Layer (Observability++): Anwendungsebenen-Run/Trace/Thread-Hierarchie zum Debuggen von Agenten — jede Konversation → Trace, jeder LLM-Aufruf / Tool-Aufruf / DAG-Schritt → Span mit Input/Output/Tokens/Timing. Frontend-Trace-Viewer mit Timeline und erweiterbaren LLM-Aufruf-Payloads. Dies geht über OTel (Infrastrukturebene) hinaus, um umsetzbares Agent-Loop-Debugging für Entwickler und Enterprise-Kunden bereitzustellen. OpenTelemetry-Export als Daten-Sink-Option. Modelliert nach LangSmith’s Run/Trace/Thread-Konzepten — das branchenbewährte Muster für Agent-Observability.
Metrics-Dashboard: Latenz, Erfolgsquote, Token-Nutzung, Connector-Call-Analytik — pro Agent, pro Benutzer, pro Org-Aufschlüsselungen
Circuit Breaker: Drei-Zustands-Maschine (closed/open/half-open) mit Pro-Connector-Fehler-Tracking, 5xx-Erkennung und Monitoring-Endpoints(früh ausgeliefert — implementiert in v0.8)
Workflow-Run-Aufbewahrung Cleanup: Background-Cleanup-Task mit konfigurierbarem Max-Alter und Max-Anzahl pro Workflow; Pro-Workflow-Overrides; Admin-Endpoint für manuelles Auslösen(ausgeliefert in v0.8.1)
Workflow-Versionsänderungs-Zusammenfassungen: compute_blueprint_diff() generiert automatisch menschenlesbare Zusammenfassungen aus Blueprint-Diffs beim Speichern der Version(ausgeliefert in v0.8.1)
DAG-Qualitäts-Überholung: Standard-Modell-Upgrade für Nicht-Fast-Schritte; Skill-Auto-Discovery in der Planung; Citation-Verifier für Legal/Medical/Financial-Domänen; Strukturierte Content-Context-Beibehaltung; Domain-Klassifizierung im Router mit Domain-bewusster Modellauswahl(ausgeliefert in v0.8.1)
Domain-Modell-Eskalation in ReAct: Spezialist-Domänen eskalieren automatisch zu Reasoning-Modell mit obligatorischer Web-Suche und Citation-Verifikation(ausgeliefert in v0.8.1)
Pro-Modell Native Function Calling Toggle: tool_choice_enabled Einstellung lässt Modelle erzwungene Tool-Auswahl überspringen und direkt zu JSON Mode gehen(ausgeliefert in v0.8.1)
DatabaseMetaTool (Progressive Disclosure für DB-Connectoren): Single database Meta-Tool mit list_tables/discover/query Subcommands ersetzt 3N einzelne Tools pro Database-Connector; konfigurierbar über DATABASE_TOOL_MODE Env-Var (progressive Standard, legacy Fallback)(ausgeliefert in v0.8.1)
On-Demand-Tool-Laden über request_tools Meta-Tool: Wenn >12 Tools nach intelligenter Auswahl verfügbar sind, kann LLM dynamisch zusätzliche Tools mid-Konversation laden; funktioniert in JSON und nativen Function-Calling-Modi(ausgeliefert in v0.8.1)
MCPServerMetaTool (Progressive Disclosure für MCP): Single mcp Meta-Tool mit discover/call Subcommands ersetzt N*M einzelne MCP-Tools; konfigurierbar über MCP_TOOL_MODE Env-Var (progressive Standard, legacy Fallback)(ausgeliefert in v0.8.1)
Workflow Connection Dep Auto-Subscribe: Erweitern Sie Market-Abonnement-Kaskade, um automatisch Workflow’s Connection-Abhängigkeiten (API Connectors, MCP Servers) zu abonnieren. Workflow-Knoten können Connectors, MCP Servers, Agents (die rekursiv mehr Deps referenzieren) und Sub-Workflows referenzieren — alle Connection-Deps im vollständigen Baum müssen beim Abonnieren automatisch abonniert und beim Abmelden kaskadenbereinigt werden. Komplexer als Skill/Agent aufgrund rekursiver Sub-Workflow-Auflösung mit Zyklenerkennung. Gegenstück zu Solution (Skill/Agent) Connection-Dep Auto-Subscribe(ausgeliefert in v0.8.1)
Workflow Real Executors: Ersetzt MCP und BuiltinTool Node Executor Stubs durch vollständige Implementierungen (MCP Server Discovery + Tool Calling; ToolRegistry Integration)(ausgeliefert in v0.8.1)
Agent Hook System: Eine deterministische Durchsetzungsebene, die außerhalb der LLM-Schleife läuft — Hooks führen automatisch bei Tool-Events aus und können nicht durch Agent-Anweisungen umgangen werden. Drei Hook-Punkte: PreToolUse (validieren / blockieren vor Ausführung), PostToolUse (Nebenwirkungen nach Ausführung), SessionStart (dynamischen Context injizieren). Eingebaute Hooks: Auto-Write ConnectorCallLog bei jedem Connector-Aufruf (derzeit manuell); Schreib-Operationen blockieren, wenn Org im Read-Only-Modus ist; Oversized DB-Query-Ergebnisse automatisch abschneiden, bevor sie den Agent erreichen; Rate-Limit Pro-Connector-Call-Häufigkeit. Benutzerdefinierte Hooks: Pro-Agent YAML-Konfiguration (hooks: Feld) mit Shell-Befehlen oder Python-Callables, die bei passenden Tool-Events ausgelöst werden — ein Hook-basiertes Durchsetzungsmuster, das über moderne Agent-Frameworks geteilt wird. Schlüssel-Design-Prinzip: Hooks sind für “muss immer passieren”-Logik, die niemals davon abhängen sollte, dass sich der LLM daran erinnert. Anweisungen sagen “alle Aufrufe aufzeichnen”; Hooks zeichnen sie tatsächlich auf. Anweisungen sagen “nicht im Read-Only-Modus schreiben”; Hooks blockieren es tatsächlich.
Hook System Skeleton + FeishuGateHook — Klassen-basierte PreToolUseHook / PostToolUseHook Abstraktionen verdrahtet unterhalb der ReAct-Schleife; erster konkreter Hook ist FeishuGateHook, der Tools mit requires_confirmation=True abfängt und Genehmigung durch den Feishu Channel der Org leitet. Vollständiger Hook-Lebenszyklus (benutzerdefinierte YAML-Hooks, eingebaute Audit/Block/Truncate-Hooks, SessionStart) bleibt v0.9-Umfang. Früh ausgeliefert für 2026-04-24 Roadshow.
Hook Approval Playground — UI-gesteuerte Round-Trip-Tester: Channels Details Sheet startet jetzt einen Dialog, der eine echte ConfirmationRequest Reihe erstellt, die Production Card zu Feishu sendet und die Entscheidung live abfragt. Nutzt den exakten Code-Pfad, den ein Production Hook hätte, was Pre-Rollout-Proben und Demos zuverlässig macht.
Hook System Live in ReAct + DAG Runtime — build_hook_registry_for_agent löst agent.model_config_json.hooks.class_hooks bei jeder Chat-Session auf; ReAct und DAG Entry Points instanziieren beide Hooks vor Tool-Dispatch. Tool Adapter stellt requires_confirmation als öffentliche Eigenschaft bereit, damit Hook-Prädikate Duck-Type ohne Adapter-Kopplung können. Gepaart mit einem End-to-End-Smoke-Script (scripts/smoke_feishu_gate.py), das Approve / Reject Pfade durch die echte Agent-Schleife abdeckt.
Per-Hook Config Pass-Through — class_hooks Einträge sind heute bloße Strings; um FeishuGateHook.timeout_seconds, poll_interval_seconds oder callback_base_url pro-Agent zu überschreiben, muss das Schema {"name": "feishu_gate", "config": {...}} Objekte akzeptieren, die als kwargs an die Hook-Factory weitergeleitet werden. Niedriges Risiko v0.8.5 Follow-Up; aktuelle Defaults (120s Timeout / 1.5s Poll / Env-Var Callback URL) sind für v0.8 akzeptabel.
Agent Workspace (Persistent Agent Desktop): Drei Ebenen: (1) Tool Output Offloading — Oversized Tool Responses (>8K Zeichen) automatisch zu workspace:// Dateien speichern, abgeschnittene Vorschau + URI zurückgeben; Builtin Tools read_workspace_file, list_workspace_files, write_workspace_file für selektiven Zugriff und Agent-generierte Artefakte. (2) Handoff Notes — write_handoff(summary) für Context-Übergänge über Kompression/Session-Wechsel. (3) Workspace UI — Frontend-Datei-Browser-Panel pro Konversation (Vorschau Text/JSON/CSV, Download, Löschen/Umbenennen); Cross-Session-Datei-Aufbewahrung; Pro-Benutzer-Speicher-Quota-Integration. Erweitert truncate_tool_output() in Adaptern + GET /api/conversations/{id}/workspace Endpoint
Smart File Content Injection + read_uploaded_file Tool: Kleine hochgeladene Dateien (<32K Zeichen) werden automatisch in LLM-Context eingefügt; große Dateien erhalten Metadaten + Tool-Hinweis. Dual-Mode read_uploaded_file Tool (Paginiertes Lesen + Regex-Suche). GET /api/files/{file_id}/content Endpoint, .content Sidecar-Speicher, content_length in Datei-API-Responses
Intelligent Document Processing (Vision-Aware): Adaptive Document Handling — PDF-Seiten werden als Bilder über PyMuPDF für Vision-fähige Modelle (GPT-4o, Claude 3/4, Gemini) gerendert; Text-Only-Fallback über pdfplumber. Pro-Modell supports_vision Flag in Admin. Zwei Modi (Vision/Text) konfigurierbar über DOCUMENT_PROCESSING_MODE Env-Var. Smart PDF Processing: Text-reiche Seiten extrahieren Text + eingebettete Bilder (Token-effizient), gescannte Seiten rendern als Full-Page PNG. DOCX/PPTX eingebettete Bild-Extraktion. Multi-Turn Vision Persistenz. Pre-Built Sandbox Image (Dockerfile.sandbox). Gecachte Seiten-Rendering mit .pages/ Sidecar.(ausgeliefert in v0.8.2)
Universal Document Conversion (convert_to_markdown + OCR) — Eingebautes Agent Tool, das Microsoft MarkItDown umhüllt, verfügbar für jeden Agent standardmäßig. Konvertiert PDF, Word, Excel, PowerPoint, HTML, JSON, CSV, XML, ZIP, EPUB, Outlook .msg, Bilder, Audio, YouTube URLs und Data URIs in sauberes Markdown in-Konversation. Eingebettete Bilder in Office-Dateien und gescannten PDF-Seiten werden automatisch über das offizielle markitdown-ocr Plugin mit dem Vision-fähigen LLM des Workspace (DB-First, ENV Fallback) OCR’d. Der gleiche Konvertierungs-Kernel wird von der RAG-Ingestion-Pipeline geteilt, daher produzieren Chat-Zeit-Konvertierung und Knowledge-Base-Ingestion byte-identisches Markdown. Nicht-OpenAI-Provider (Claude, Gemini, Bedrock, Azure) werden transparent über einen LiteLLMOpenAIShim unterstützt, der jeden FIM One LLM als openai-SDK-förmigen Client präsentiert und dann durch LiteLLM leitet. Null-Regressions-Fallback: Wenn kein Vision-Modell verfügbar ist, setzt Text-Only-Extraktion genau wie zuvor fort.(ausgeliefert in v0.8.3)
Session-Level File Associations: Verfolgen Sie, welche Dateien in welchen Konversationen verwendet wurden
Cross-Session Conversation Recall: Agent Tools zum Auflisten, Suchen und Lesen von Konversationsverlauf — list_conversations, search_conversations (Keyword/Regex über Verlauf), read_conversation (vollständigen Thread abrufen). Ermöglicht “was haben wir letztes Mal besprochen” und “finde die API-Änderung, die ich letzte Woche gefragt habe” Workflows. Gepaart mit Cross-Session File Management zur Bildung einer vollständigen Long-Term Agent Memory Layer
Sandbox Hardening: v2 Verbesserungen zur Code-Execution-Isolation
Performance Testing: Concurrent Load Benchmarks
MCP Connection Pooling: Pro-Request STDIO Subprocess Spawning skaliert nicht — 100 gleichzeitige Benutzer = 100 Subprozesse pro MCP Server. Pool STDIO Connections mit Pro-Benutzer Env Isolation (gekennzeichnet durch (server_id, env_hash)); SSE/HTTP Transporte teilen httpx.AsyncClient Sessions. Ziel: ≤100 ms Warm-Start für gepoolte STDIO, O(1) HTTP Connections pro MCP Server unabhängig von Benutzeranzahl
Internal Harness Benchmark — Eingebaute Test Suite zur Quantifizierung von Harness-Parameter-Änderungen (System Prompt, Self-Reflection Häufigkeit, Tool Selection Threshold) mit EVAL CENTER Infrastruktur
Workflow Trigger Identity Observability: Fügen Sie ExecutionContext.trigger_source ("webhook" | "cron" | "manual" | "batch" | "sub") hinzu, das bei jedem der fünf WorkflowEngine Instanziierungsorte (trigger_workflow, run_workflow, batch_run_workflow, scheduler, sub_workflow) gefüllt wird. Heute mischen diese Pfade implizit Owner-Identität (wf.user_id — webhook/cron) mit Caller-Identität (`
Prompt Cache + Reasoning Follow-ups (aus Batch A MVPs)
Diese Elemente vervollständigen teilweise in Batch A ausgelieferte Arbeiten (Conversation Recovery, System Prompt Registry, Thinking Blocks) und erweitern die Cache-Abdeckung auf die verbleibenden Provider-Familien.
Gemini Context Cache Adapter: Google Gemini verwendet eine separate REST API (POST /v1beta/cachedContents → gibt cacheName zurück → referenziert via cachedContent: "<cacheName>" in nachfolgenden generateContent Aufrufen) anstelle des Inline-cache_control Markers, den Anthropic verwendet. Erfordert einen GeminiCacheAdapter mit Lifecycle-Management (Präfix vorregistrieren → cacheName referenzieren → TTL-bewusste Invalidierung), integriert in den Gemini-Pfad von OpenAICompatibleLLM oder LiteLLMs Gemini-Provider. Read-Rabatt ~0,25×, minimales Präfix 32.768 Token (Gemini Pro) / 4.096 (Flash) — primäre Nutznießer sind Long-Context KB/RAG-Agenten und dokumentenintensive Workflows.
Prompt Registry-Erweiterung auf Planner / Verifier / Domain Classifier: erweitern Sie das PromptRegistry + DYNAMIC_BOUNDARY Muster von ReAct auf die verbleibenden LLM-Aufruforte: DAGPlanner, PlanAnalyzer, StepVerifier, CitationVerifier, DomainClassifier, ExecutionModeRouter, CompactUtils. Derzeit werden diese Prompts bei jedem Aufruf von Grund auf neu erstellt. Niedrigere Häufigkeit als ReAct, daher niedrigerer ROI, aber vervollständigt die Cache-Story.
Pro-Agent cache_ttl Konfiguration: Ermöglichen Sie Agent-Besitzern, zwischen ephemeral (5 Min., Standard, günstiger Schreibzugriff) und extended (1 Stunde, 2× Schreibkosten, aber besser für Batch- / geplante Workflows) zu wählen. Oberflächlich als Feld auf dem Agent-Modell und übergeben via cache_control: {"type": "...", "ttl": "..."} wo unterstützt.
DAG-Schritt-Level Checkpoint-Tabelle: Das aktuelle A1 Conversation Recovery MVP persistiert synthetische tool_results und gecachte SSE-Events, aber der DAG-Zwischenschritt-Status lebt nur im Speicher. Neue dag_execution_step Tabelle erstellt Snapshots von jedem Schritt’s tool_calls, Ergebnissen und Artifact-Referenzen, damit eine Mid-DAG-Unterbrechung ohne Neuausführung abgeschlossener Schritte fortgesetzt werden kann. Gekoppelt mit dem Frontend useSseResume Hook für End-to-End-Kontinuität.
Dedizierte tool_call_id Spalte auf Message: Heute lebt tool_call_id in metadata_ JSON, was json_extract(...) / ::json->> Lookups für Orphan-Tool-Use-Abfragen erfordert. Für High-Traffic-Deployments würde eine First-Class-indizierte Spalte der Recovery-Pass O(log n) statt O(n) Scans ermöglichen. Niedrige Priorität bis die Skalierung es verlangt.
Mid-Stream Thinking Token Rekonstruktion: Die aktuelle Resume-Granularität ist „nächstes vollständiges SSE-Event” — wenn der Drop innerhalb eines Thinking-Delta auftritt, startet der Client vom folgenden Event neu. Token-Level-Resume würde eine Neuemission der gepufferten Token des laufenden Thinking-Blocks erfordern. Nischeverbesserung; nur verfolgungswert, wenn Benutzer Thinking-UX-Jitter bei instabilen Verbindungen melden.
API Relay Cache-Honesty Probe: Background-Tool (Admin-ausgelöst oder geplant), das zwei identische Claude-Anfragen durch jeden konfigurierten Relay sendet, vergleicht tatsächlich abgerechnete Input vs cache_read_input_tokens, und kennzeichnet Relays, die den cache_control Marker entfernen oder den 0,10× Rabatt nicht weitergeben. Oberflächlich als Workspace-Level „Relay Health” Signal — nützliches Operationstool für Unternehmen, die durch chinesische API-Proxies routen.
Der Großteil der Agent Core-Integrations-Roadmap (Phase 0–3, I.1–I.16) wurde in v0.8.2 und v0.8.3 ausgeliefert. Die folgenden Elemente stammen aus der parallelen Priority Matrix, die noch Aufmerksamkeit benötigen.
Content replacement state persistence (streaming invariant #2): “once seen, fate frozen” — Nachrichteninhalte, die bereits an den Client gesendet wurden, dürfen nicht rückwirkend über resume / reload mutiert werden. Erfordert ein Replacement Ledger, das mit dem SSE cursor von A1 abgestimmt ist. Blockiert durch das Verständnis tatsächlicher benutzer-sichtbarer Glitches; keine aktiven Beschwerden.
Attachment context router: intelligentere Attachment-Injection mit alreadySurfaced + readFileState Deduplizierung, aggregiertes Attachment-Budget und Liveness-Checks. Verhindert das erneute Versenden desselben 50KB PDF-Extrakts bei jedem Turn. Koppelt mit Workspace-Datei-Offloading (bereits im v0.9-Plan).
Side query workers (prompt worker pool): dedizierte leichtgewichtige Pools für Recall / Classification / Summary / Session-Memory-Abfragen, damit sie nicht mit dem Haupt-Agent LLM-Aufruf um das Rate-Limit-Budget konkurrieren. Voraussetzung: Prompt Registry-Erweiterung (oben).
Geplante Jobs + Event-getriggerte Agenten (Loop): cron-ähnliche Hintergrund-Task-Trigger; scheduled_jobs + job_runs DB-Tabellen; APScheduler-Integration; Job-CRUD-API + Job-Verlauf-UI; Ergebnis-Benachrichtigung über Message-Push-Konnektoren. Der Umfang umfasst sowohl zeitgesteuerte (cron) als auch ereignisgesteuerte (Webhook-Eingang) Muster — ein Agent, der asynchron im Hintergrund läuft, IST der asynchrone Sub-Agent-Anwendungsfall für Hub-Modus.
Vorgefertigte Lösungsvorlagen (Market Seed Content): 8 einsatzbereite vertikale Lösungen, die bei der Erstbenutzerregistrierung auf dem Markt veröffentlicht werden — Financial Audit, Contract Review, Data Reporting, IT Helpdesk, HR Onboarding, Sales Assistant, Content Writer, Meeting Summary. Jede bündelt einen Agenten + Skill mit chinesischen SOPs; idempotent über ensure_solution_templates() bootstrapped, auf Market-Org für sofortige Marketplace-Verfügbarkeit veröffentlicht(in v0.8.1 ausgeliefert)
DB-Schema Advanced Builder: KI-gesteuerte Schema-Management-Agent für großskalige Datenbanken — strategische Tabellenannotation (musterbasiert, SQL-Ausführungs-informiert), Bulk-Sichtbarkeitsverwaltung nach Domain-Präfix, iterative mehrrundige Annotation für 1K–7K+ Tabellenbereitstellungen; ergänzt bestehenden Batch-Annotationsjob mit Selektivität und geschäftskontextgesteuertem Reasoning
Resource Fork (Package Phase 1 — Voraussetzung für v1.0 Package System): Alle Pro-Ressource-Fork-Endpunkte implementiert — MCP Server, Skill, Agent, Konnector, Workflow. KB-Fork entfernt (inhärent benutzerlokal). Jeder POST /api/{type}/{id}/fork erstellt eine benutzergesteuerte tiefe Kopie mit forked_from Lineage-Tracking.(in v0.8.1 abgeschlossen)
Pro-Workflow credential_policy Override (owner | caller | auto): Die fünf Workflow-Trigger-Pfade codieren derzeit hartcodiert, wessen Identität Konnector-Aktionen ausführt — Webhook/Cron übergeben wf.user_id (Besitzer), manuell/Batch übergeben current_user.id (Aufrufer). Dies entspricht der häufigen Erwartung „Automationen laufen als Besitzer, manuelle Läufe als Aufrufer”, aber Enterprise-Bereitstellungen müssen gelegentlich pro Workflow überschreiben (z. B. ein Cron, der unter dem aktuellen On-Call-Ingenieur laufen muss, oder eine gemeinsame Vorlage, die die Anmeldedaten des Besitzers auch bei manuellem Lauf ausleihen muss). Fügen Sie ein credential_policy-Feld auf dem Workflow-Modell hinzu, das in der UI neben Schedule / API-Key-Konfiguration angezeigt wird und das Standard-trigger_source → identity-Mapping überschreibt. Voraussetzung: trigger_source Observability oben.
Auswirkung: Führen Sie FIM One mit Zuversicht in großem Maßstab aus. Vier Säulen: Trace Layer (sehen Sie, was passiert ist), Hook System (erzwingen Sie, was passieren muss), Agent Workspace (persistente Dateiverwaltung + Handoff), IM Channel (Agenten leben dort, wo Benutzer arbeiten). Vorgefertigte Lösungsvorlagen eliminieren Kaltstart; Dashboard Enhancement zeigt operative Gesundheit. Die Lücke zwischen „Anweisungen, denen der Agent möglicherweise folgt” und „Garantien, die das System erzwingt” wird geschlossen — der Unterschied zwischen einer Demo und einem produktiven Enterprise-Tool.
Cross-Connector Entity Alignment (Ontology Registry): Definieren Sie gemeinsame Entity-Typen (Customer, Order, Asset) mit Feldmappings über Connectors hinweg; DAGPlanner löst Cross-System JOIN-Schlüssel automatisch auf; ermöglicht Cross-Connector-Abfragen (z. B. „Kunden in Salesforce, die in Shopify bestellt haben”) ohne hartcodierte Feldnamen
Hot-plug Connectors: OpenAPI-Spezifikation hochladen, KI generiert Konfiguration, live in 5 Minuten (kein Neustart)
Market Package System: Verteilbare Ressourcen-Bundles für den Marketplace — ersetzt pro-Typ „Marketplace” durch eine einheitliche Packaging-Schicht. fim-package.yaml Manifest deklariert: Metadaten (Name, Version, Beschreibung, Autor, Lizenz, Tags, min_fim_version), Entry Point (primäre Skill oder Agent), Ressourcenliste (Agents, Skills, Connectors, KBs, MCP Server, Workflows) mit Konfigurationsreferenzen, Inter-Package-Abhängigkeiten (Semver-Bereiche), erforderliche Anmeldedaten (auf Connector-Refs abgebildet für Installation-Zeit-Erfassung) und benutzerkonfigurierbare Variablen mit Standardwerten. Zwei Konsummodi: (1) install — Batch-Erstellung aller Ressourcen + automatisches Verdrahten interner Referenzen über ID-Substitution; Installation mit Quelle verknüpft für Versionsaktualisierungsbenachrichtigungen; POST /api/market/packages/{id}/install; (2) fork — Klonen als benutzergesteuerte bearbeitbare Kopien ohne Update-Link (dies IST der Template-Modus); POST /api/market/packages/{id}/fork. Zusätzliche Endpunkte: Veröffentlichung (POST /api/market/packages mit Review-Workflow), Deinstallation (DELETE /packages/{id}/uninstall mit Abhängigkeitsprüfung + Bestätigung geänderter Ressourcen), Versionsverlauf (GET /packages/{id}/versions), Upgrade (POST /packages/{id}/upgrade mit Diff-Vorschau pro Ressource). Abhängigkeitsresolver für verschachtelte Paketanforderungen mit Konflikt-Erkennung. PackageInstallation Tabelle verfolgt installierte Pakete pro Benutzer mit Ressourcen-ID-Mapping für Deinstallation/Upgrade. Koexistiert mit individueller Ressourcenveröffentlichung — Package ist eine Kompositionsschicht, kein Ersatz; ein einzelner Connector ist weiterhin eigenständig veröffentlichbar. Beispiel-Abhängigkeitsbaum: Package: contract-review → Skill: contract-review (Entry Point) → Agent: contract-analyst + Agent: risk-scorer → KB: legal-clauses + Connector: docusign-api + MCP: pdf-extractor + Workflow: contract-approval-flow
Creator Program: Marketplace-Monetarisierungsschicht — Creator-Profile mit Portfolio-Seiten, Pro-Package-Analysen (Installationen, Forks, aktive Benutzer, Bewertungen/Rezensionen), Affiliate-Provisionserfassung, wenn Pakete neue Abonnements fördern. Bezahlte Package-Stufe mit Preisgestaltung, Kaufablauf und Genehmigungsworkflow. Creator-Dashboard mit Installationstrends, Umsatzberichterstattung und Benutzer-Feedback. Öffentliche Creator-API für programmgesteuerte Package-Veröffentlichung (CI/CD für Package-Autoren). Community-Funktionen: Package-Kommentare, Q&A, Changelogs pro Version
Embeddable Widget: <script src="fim-one.js"> in Host-Seite injiziert
Batch-Ausführung: Verarbeitung von 1000+ Elementen über DAG
Enterprise Security: IP-Whitelisting, Verschlüsselung im Ruhezustand, SSO
KB Advanced Editor: Builder-Modus-Agent für Power-User, die große Wissensdatenbanken verwalten — Massen-URL-Aufnahme, Duplikat-Erkennung, Gap-Analyse, Dokument-Lifecycle-Management; erweitert vorhandenen KB-KI-Chat mit ReAct-Tool-Loop
Auswirkungen: Unternehmen stellen FIM One von Null bis Multi-System-Orchestrierung in Tagen bereit. Das Package-System schafft ein Creator-Ökosystem — Lösungsautoren veröffentlichen zusammengesetzte Bundles (Skill + Agents + Connectors + KBs + Workflows), Unternehmen installieren mit einem Klick, Creator verdienen durch Adoption. Install/Fork-Dualität deckt sowohl „As-is verwenden” als auch „Von Template anpassen” Anwendungsfälle in einem einzigen Mechanismus ab.
Gemäß der Orthogonality Strategy würden diese hohen Aufwand erfordern und Absorptionsrisiken bergen:
Feature
Grund für Aufschub
Multi-Agent Orchestration (tiefe Hierarchien)
Provider bauen nativ (OpenAI Swarm, Google A2A und ähnliche Multi-Agent-Angebote). FIM One’s CallAgentTool deckt den One-Level-Delegationsfall ab; ereignisgesteuerte Hintergrund-Agenten werden durch Scheduled Jobs in v0.9 abgedeckt
Agent Self-modifying Skills (Procedural Memory)
Agenten aktualisieren ihre eigene skill.md während der Ausführung — hohe Komplexität, Sicherheits-/Audit-Oberfläche. Hängt davon ab, dass Agent Skill System (v0.8) zuerst ausgeliefert wird. Neu bewerten, wenn Enterprise-Kunden selbstverbessernde Agenten explizit anfordern
Agent Workspace (Tool Output File Offloading)
Zu v0.9 befördert. Der Wert liegt in selektivem Lesen, nicht in Kontextkapazität — Framework-übergreifende Validierung bestätigt. Ursprüngliche Aufschublogik („200K+ Fenster reduzieren Dringlichkeit”) war falsch.
Cross-Session Long-Term Memory
Context Windows wachsen schnell (200K–2M); Provider fügen eingebautes Memory hinzu (OpenAI memory, Gemini context caching); hohe Implementierungskosten vs. sinkender Differenzierungswert. Neu bewerten, wenn Enterprise-Kunden es explizit anfordern
Memory Lifecycle (TTL, Quotas)
Hängt von Cross-Session Memory ab; zusammen aufgeschoben
Active Context Compression Tool (Agent-ausgelöst)
Explizit eingefroren mit ContextGuard (v0.5). Context Windows bei 200K+ reduzieren den Wert. Wird nicht überprüft, es sei denn, Kontextkosten werden zu einer großen Enterprise-Beschwerde
Browser Automation / Computer Use
Hohe Wartungskosten (DOM-Änderungen, Anti-Bot, Sandboxing). Industrie konvergiert auf Computer Use Mode (Anthropic, OpenAI Operator, Google Mariner) und MCP Browser Tools (Puppeteer/Playwright MCP). Über MCP Integration konsumieren, nicht selbst bauen. Neu bewerten, wenn stabiler Computer Use MCP Standard entsteht
Web Push Notifications
Browser-natives Push über Service Worker + VAPID. Überlappt mit IM Channel Integration (v0.8), die Enterprise-bevorzugte Kanäle abdeckt (Lark/Slack/WeCom/Email). IM Push hat höheren Enterprise-Wert; Web Push ist ein Nice-to-Have für Portal-only-Benutzer. Neu bewerten nach IM Channel Auslieferung — wenn Benutzer Browser-Benachrichtigungen über IM-Abdeckung hinaus anfordern
Multi-user Workflow Collaborative Editing
Echtzeit-Co-Editing desselben Workflow-Blueprints (Figma/Notion-Stil) mit Cursor-Awareness, Konfliktauflösung und Pro-Node-Lock. Hohe Implementierungskosten (CRDT / OT, Presence-Infrastruktur), unklar Enterprise-Nachfrage gegenüber heutigem „ein Editor gleichzeitig + Version Diff” Modell. Neu bewerten, wenn mehrere Enterprises explizit gemeinsames Live-Editing anfordern
Per-Node Workflow Execution Permissions (RBAC on Run)
Feinkörnige Autorisierung innerhalb eines einzelnen Workflow-Laufs — z.B. „Node X erfordert Rolle finance_approver zur Ausführung”. Heute findet Autorisierung auf Workflow-Ebene statt (wer kann auslösen) und auf Connector-Ebene (wessen Credential läuft); Per-Node RBAC fügt eine dritte Achse mit erheblicher Komplexität und keiner aktiven Kundenanfrage hinzu
Cross-org Workflow Sharing mit Live Updates
Workflow aus einer anderen Org abonnieren und Upstream-Updates ohne Neu-Forking erhalten. Heute Abonnement = Fork (Snapshot), daher brechen Upstream-Änderungen nie aus. Live Updates würden Upstream-kompatible Schema-Evolution + Konfliktauflösung erfordern; hohe Wartungskosten. Neu bewerten, wenn Enterprises „gemeinsame Workflows über Tochtergesellschaften” anfordern
Marketplace-Moderation: Wie können Community-Pakete und einzelne Ressourcen validiert werden? Automatisierte Scans auf Credential-Leaks in Paket-Konfigurationen? (v1.0)
Token-Ökonomie: Wie können Multi-User-, Multi-Agent-Szenarien bepreist werden? (v1.0)
Paket-Versionierung: Breaking Changes in installierten Paketen — automatisches Upgrade mit Migrationsskripten oder manuelle Genehmigung pro Update? Auflösung des Dependency-Diamond-Problems? (v1.0)
Paket-Preisgestaltung: Kostenlose vs. kostenpflichtige Stufen, Provisionsätze für Creator Program, Integration von Zahlungsanbietern? (v1.0)
Paket-Credential-UX: Credential-Erfassung bei Installation — Wizard-ähnlich Schritt für Schritt oder aufgeschobenes Setup? Credential-Sharing über Pakete hinweg, die denselben Connector-Typ verwenden? (v1.0)
Telemetry-Opt-out: Wie können Datenschutzpräferenzen respektiert werden? (v0.8)
Connector-Versionierung: Wie können Breaking Changes in Connector-APIs verwaltet werden? (v0.8)
Connector-Autorisierungsstufen-Auswahl: Wie kann ein Admin herausfinden, welche Stufe für ein bestimmtes Upstream-System gilt? Auto-Probe (versuche Pro-User-API-Key → Fallback auf Login-Ticket → Fallback auf Shared-DB) vs. explizite Deklaration in der Connector-Spezifikation? Wie drücken wir “dieser Connector unterstützt Stufe 2, aber der Admin hat sich für Stufe 1 entschieden” in der UI aus, ohne nicht-technische Admins zu verwirren? (v0.9)
Integration vs. Connector-Dualität: Wenn eine Feishu-Bindung gleichzeitig ein SSO-Provider UND eine API-Call-Oberfläche ist, wie präsentieren wir sie in den Einstellungen? Ein Objekt mit drei Umschaltern oder drei separate Bindungen, die eine Credential teilen? Auswirkungen auf die Deinstallations-Semantik (tötet das Widerrufen von SSO den Connector?) (v0.9)
