← Zur Doku-Startseite
Konfiguration

Tools so konfigurieren, dass Tempo und Kontrolle zusammenpassen

In QuantenRam sind Tools nicht bloss Zusatzfunktionen, sondern der eigentliche Ausführungsrahmen für agentische Arbeit. Gute Tool-Konfiguration beginnt deshalb nicht mit maximaler Freiheit, sondern mit der Frage, welche Fähigkeiten für einen konkreten Arbeitsmodus wirklich gebraucht werden und welche Rechte bewusst geschlossen bleiben sollen.

Der praktischste Einstieg ist immer ein kleines, klar lesbares Profil. Für Dokumentation, API-Checks und normale Implementierung reichen in vielen Fällen Datei-, Such- und Diagnosewerkzeuge als Standard aus, während Shell, Netzwerk und externe Integrationen nur dann geoeffnet werden, wenn der Arbeitsauftrag sie wirklich verlangt. Genau diese Staffelung passt gut zu QuantenRam, weil Modellwahl, Toolnutzung und Verifikationsschritte dann denselben roten Faden haben: erst lokal und strukturiert arbeiten, dann gezielt eskalieren.

Built-in als sichere Baseline

Read-, Grep-, LSP- und ähnliche Strukturtools sollten dein Standardprofil bilden, weil sie schnell sind und Seiteneffekte gering halten. In QuantenRam-Workflows tragen sie den grössten Teil von Analyse, Refactoring-Vorbereitung und Dokumentationsarbeit, ohne dass du dafür gleich freie Shell-Rechte oder Netzwerkzugriffe freischalten musst.

Shell nur für echte Laufzeitfragen

Bash ist wertvoll, wenn du Tests, Django-Checks, Git-Status oder reale API-Smoke-Tests brauchst. Als Default für jede kleine Dateioperation ist die Shell aber meist zu breit, weil sie gleichzeitig mehr Risiko, mehr Varianz und mehr Review-Aufwand mitbringt.

Netzwerk und Custom Tools bewusst kapseln

Alles, was QuantenRam von lokalen Dateien in externe Systeme führt, sollte als eigener Freigabetyp erkennbar sein. So bleibt sauber nachvollziehbar, ob ein Agent nur im Repo gearbeitet hat oder ob reale Requests, Webabfragen oder teaminterne Spezialtools beteiligt waren.

Tool-Auswahl und Enablement praktisch aufbauen

Konfiguriere Tools am besten rollen- oder workflowbezogen statt global. Ein kostensensitives Start-Profil braucht meist nur Lesen, Suchen, LSP und gelegentliche Shell-Verifikation. Ein Coding-Profil kann Shell und Refactoring-Helfer zusätzlich freigeben, während ein Review-Profil für Zenmaster-Arbeit eher auf Diff-Analyse, Testauswertung und sichere Read-only-Integrationen setzt. Wichtig ist dabei nicht der Dateiname der Konfiguration, sondern dass jede Capability einen klaren Zweck hat und nicht nur aus Bequemlichkeit offen steht.

{
  "provider": {
    "type": "openai-compatible",
    "base_url": "https://quantenram.net/v1",
    "api_key_env": "QUANTENRAM_API_KEY"
  },
  "models": {
    "default": "quantenram-start/glm-5",
    "coding": "quantenram-coding/qwen3codernext",
    "review": "quantenram-zenmaster/gpt-5.4"
  },
  "tools": {
    "read": "allow",
    "grep": "allow",
    "lsp": "allow",
    "bash": "ask",
    "webfetch": "ask",
    "custom.release-check": "deny"
  }
}

Dieses Muster zeigt die typische Reihenfolge: Zuerst wird QuantenRam als einheitlicher Provider gesetzt, danach werden Aliasmodelle pro Arbeitsklasse definiert, und erst dann folgt die Rechteebene für Tools. So erkennst du später schneller, ob ein Problem vom Modell, von der Freigabe oder vom eigentlichen Auftrag kommt.

Rechte, Sicherheit und Nachvollziehbarkeit

Für produktive Setups sollte die Rechteebene mindestens drei Zonen unterscheiden: lokale Strukturarbeit, echte Ausführung und externe Kommunikation. Lokale Strukturarbeit darf meist automatisch laufen. Shell-Kommandos mit Schreibwirkung, Git-Aktionen oder Netzwerkanfragen gehören in der Regel auf ask. Destruktive oder schwer rückgängig zu machende Muster bleiben auf deny. Damit wird Sicherheit nicht als abstrakte Policy behandelt, sondern als täglich sichtbare Ausführungsgrenze.

In QuantenRam ist diese Disziplin auch wirtschaftlich sinnvoll. Wenn ein Toolprofil zu breit ist, führt das oft nicht nur zu Sicherheitsrisiko, sondern auch zu unnötigen Modellaufrufen, mehr Eskalation auf Premiumpfade und schwerer lesbaren Activity- oder Billing-Spuren. Ein enges Profil macht also nicht langsamer, sondern meistens schneller debugbar.

Custom Tools sauber integrieren

Eigene Tools lohnen sich dann, wenn dein Team denselben Schritt immer wieder durchführt und dafür bisher mehrere manuelle Befehle, Prompts oder Dashboards kombinieren muss. In QuantenRam sind gute Kandidaten zum Beispiel ein fester Rollout-Check gegen /v1/models, ein Team-Report für Billing-Ausreisser oder eine kleine Release-Prüfung für den eigenen API-Key und den gewünschten Alias. Halte solche Tools klein, deterministisch und mit einer klaren Ein-/Ausgabe versehen, damit sie wie normale Infrastruktur und nicht wie versteckte Magie behandelt werden können.

{
  "custom_tools": {
    "verify-quantenram-rollout": {
      "description": "Prueft Aliasfreigabe und einen echten Smoke-Request",
      "inputs": ["api_key_env", "model", "prompt"],
      "permissions": ["network"],
      "verify": ["GET /v1/models", "POST /v1/chat/completions"]
    }
  }
}

Die beste Tool-Konfiguration öffnet nicht möglichst viel, sondern genau genug: strukturierte Built-ins als Default, Shell und Netzwerk nur mit Anlass, und Custom Tools nur dort, wo ein wiederholbarer QuantenRam-Workflow dadurch wirklich einfacher und sicherer wird.