Zum Inhalt springen

Sprache wählen

Aktuelle Sprache: Deutsch

Compression Engines

Komprimierungskombinationen sind benannte Komprimierungsprofile, die Routing-Kombinationen zugewiesen werden können:

  • compression_combos: speichert Modus, Pipeline, RTK-Konfiguration, Sprachkonfiguration und Standardmarkierung
  • compression_combo_assignments: ordnet eine Komprimierungskombination einer Routing-Kombination zu
  • die Laufzeitintegration löst eine zugewiesene Komprimierungskombination vor generischen Überschreibungen der Kombination auf
  • Analysen enthalten compression_combo_id und engine

Dashboard-Bereich: Dashboard -> Context & Cache -> Compression Combos.

Route Zweck
/api/settings/compression Globale Komprimierungseinstellungen (einschließlich mcpAccessibility-Konfiguration)
/api/compression/preview Vorschau eines beliebigen Komprimierungsmodus
/api/compression/language-packs Verfügbare Caveman-Sprachpakete auflisten
/api/context/caveman/config Alias für Caveman-Einstellungen
/api/context/rtk/config RTK-Standardwerte und -Einstellungen
/api/context/rtk/filters RTK-Filterkatalog
/api/context/rtk/test RTK-Vorschau-/Test-Endpunkt
/api/context/rtk/raw-output/[id] Authentifizierte Wiederherstellung redigierter Rohausgaben
/api/context/combos CRUD für Komprimierungskombinationen
/api/context/combos/[id]/assignments CRUD für Zuweisungen zu Routing-Kombinationen
/api/context/analytics Alias für Komprimierungsanalysen

Verwaltungsrouten erfordern eine Verwaltungsauthentifizierung oder API-Schlüssel-Richtlinienprüfungen.

Die Komprimierung stellt fünf MCP-Tools bereit:

Tool Umfang Zweck
omniroute_compression_status read:compression Einstellungen, Analysen, Cache-Statistiken
omniroute_compression_configure write:compression Globale Einstellungen aktualisieren
omniroute_set_compression_engine write:compression Modus und optionale Pipeline festlegen
omniroute_list_compression_combos read:compression Komprimierungskombinationen auflisten
omniroute_compression_combo_stats read:compression Kombinations-/Engine-Analysen abrufen

Embeddings werden niemals komprimiert. open-sse/handlers/embeddings.ts ruft niemals eine Komprimierungs-Engine auf — die Anfrage-/Antwortinhalte werden unverändert direkt an den Executor weitergegeben. Dies ist derzeit strukturell bedingt (Embeddings und Chat Completions werden von getrennten Handlern verarbeitet) und keine Laufzeitprüfung. Das bedeutet jedoch, dass das Problem der Vektorverzerrung aus #8034 im Embeddings-Pfad keine Angriffsfläche hat.

Ausschlussfilter pro Modell/Endpunkt (#8034). Für Chat Completions kann ein Betreiber Modell-IDs bzw. provider/model-Ziele angeben, die niemals komprimiert werden dürfen — eine nützliche Schutzmaßnahme, falls die Komprimierung später näher an einen Embeddings-nahen Pfad angebunden wird, und allgemein nützlich für jedes Modell, bei dem der Prompt bytegenau erhalten bleiben muss (deterministische Auswertungen, cache-sensitive Präfixe usw.).

  • Einstellungsfeld: exclusions?: string[] in der globalen Komprimierungskonfiguration (GET/PUT /api/settings/compression), persistiert über den vorhandenen key_value-Namensraum für die Komprimierung (src/lib/db/compression.ts) — keine neue Tabelle.
  • Dashboard-Registerkarte: Dashboard → Compression → Exclusions (/dashboard/compression/exclusions).
  • Mustersyntax: * ist der einzige Platzhalter. Jedes andere reguläre Ausdrucksmetazeichen in einem Muster wird vor dem Abgleich maskiert, sodass gpt-5.6 nur mit der exakten Zeichenfolge übereinstimmt, niemals mit gpt-5x6 (ReDoS-sicher, begrenzt, keine verschachtelten Quantifizierer). Muster werden ohne Berücksichtigung der Groß-/Kleinschreibung sowohl mit der reinen Modell-ID als auch mit der zusammengesetzten Angabe provider/model abgeglichen — gpt-5-6, openai/gpt-5-6 und openai/* funktionieren alle, und * allein schließt jedes Modell aus.
  • Abgleich: isCompressionExcluded() / normalizeCompressionExclusions() in open-sse/services/compression/exclusions.ts. chatCore.ts prüft das ausgeschlossene Ziel unmittelbar nach dem Auflösen der Komprimierungseinstellungen, bevor eine Engine ausgeführt wird, und behandelt eine Übereinstimmung genau so, als wäre die Komprimierung global deaktiviert — der Anfrageinhalt bleibt nachweislich byteidentisch. Das Überspringen wird über writeCompressionSkip(..., "excluded") für die Sichtbarkeit in Analysen erfasst.
  • Standardwert (leere/nicht vorhandene Liste): identisch mit dem Verhalten vor #8034 — nichts wird ausgeschlossen.
  • LLMLingua-2 (SLM) erfordert gemeinsam platzierte optionale Abhängigkeiten. Der Worker wird in einem Produktions-Build nur ausgeführt, wenn @atjsh/llmlingua-2 und seine Peer-Abhängigkeiten gemeinsam unter dist/node_modules platziert sind (siehe scripts/build/colocateOptionals.mjs, #4286). Ohne sie arbeitet die Engine nach dem Fail-open-Prinzip (sie gibt den ursprünglichen Text zurück). Die Auflösung des Workers hängt nicht mehr von import.meta.url ab (dies schlägt im eigenständigen Bundle fehl), sondern orientiert sich zur Laufzeit am cwd / an argv[1].
  • Die Caveman-Sprachpakete de / fr / ja sind unvollständig. Sie enthalten Regeln für context + filler + structural, aber keine Pakete für dedup / ultra, sodass die Intensität ultra für diese Sprachen nicht stärker ist als full (sie verwenden ausschließlich ihre eigenen Regeln — es gibt keinen stillen Rückgriff auf die englischen dedup-/ultra-Regeln, der fremdsprachigen Text verstümmeln würde). en / es / id / pt-BR sind vollständig. Beiträge in Form von dedup.json + ultra.json für die unvollständigen Pakete sind willkommen.
  • Die Telemetrie gestapelter Pipelines listet nur Engines auf, die eine Komprimierung erzielt haben. Ein Schritt einer gestapelten Pipeline, dessen Engine ausgeführt wurde, aber 0 % Einsparung erzielte, gibt stats:null zurück und erscheint daher nicht in engineBreakdown — er ist somit nicht von einem übersprungenen Schritt zu unterscheiden. Die Unterscheidung zwischen „ausgeführt, 0 %“ und „übersprungen“ würde eine Änderung des Aufschlüsselungsmodells erfordern und wird zurückgestellt.

Die gezielten Prüfungen für diesen Bereich sind:

Terminal-Fenster
node --import tsx/esm --test tests/unit/compression/rtk-*.test.ts tests/unit/compression/pipeline-integration.test.ts tests/unit/compression/context-compression-api.test.ts
node --import tsx/esm --test tests/unit/compression/*.test.ts tests/golden-set/*.test.ts tests/integration/compression-pipeline.test.ts tests/unit/api/compression/compression-api.test.ts
node --import tsx/esm --test tests/unit/compression/mcpAccessibility*.test.ts
npm run typecheck:core

undefined (a58000c7685f)

HagiCode

HagiCode ist ein agentischer Coding-Arbeitsplatz. Vielseitige, komfortable Interaktionen in der Benutzeroberfläche machen Planung, Agent-Ausführung und Projektarbeit zugänglich und leicht nachvollziehbar – für ein ansprechendes Entwicklungserlebnis.

Entdecken Sie ein ansprechendes Entwicklungserlebnis mit vielseitigen, komfortablen Interaktionen in der Benutzeroberfläche.

HagiCode besuchenDokumentation lesen
  • IntelligentOpenSpec-Workflows machen aus einer Absicht einen umsetzbaren Weg vom Vorschlag über Design und Aufgaben bis zur Auslieferung.
  • EffizientMulti-Agent-Ausführung führt Recherche, Umsetzung und Prüfung parallel aus, über mehrere Repositories und die Agent CLIs, die Sie bereits nutzen.
  • InteressantVielseitige, komfortable Interaktionen in der Benutzeroberfläche machen Planung, Agent-Ausführung und Projektarbeit zugänglich und leicht nachvollziehbar.

Für Windows herunterladen

Im Microsoft Store erhaltenAlle Downloads

Aus Ideen wird ausgelieferte Software.

HagiCode ist ein agentischer Coding-Arbeitsplatz: OpenSpec-Workflows planen die Änderung, Multi-Agent-Ausführung setzt sie um, und Hero Scenario macht den langen Weg sichtbar, bis aus der Idee ausgelieferte Software wird.

Intelligent
OpenSpec-Workflows machen aus einer Absicht einen Weg vom Vorschlag bis zur Auslieferung.
Effizient
Multi-Agent-Ausführung treibt Recherche, Umsetzung und Prüfung parallel voran.
Unterhaltsam
UI-Interaktionen erleichtern Planung, Agent-Ausführung und Projektarbeit.