Konfiguration

Tools so konfigurieren, dass Tempo und Kontrolle zusammenpassen

In QuantenRam sind Tools nicht bloss Zusatzfunktionen, sondern der eigentliche Ausfuehrungsrahmen fuer agentische Arbeit. Gute Tool-Konfiguration beginnt deshalb nicht mit maximaler Freiheit, sondern mit der Frage, welche Faehigkeiten fuer einen konkreten Arbeitsmodus wirklich gebraucht werden und welche Rechte bewusst geschlossen bleiben sollen.

Der praktischste Einstieg ist immer ein kleines, klar lesbares Profil. Fuer Dokumentation, API-Checks und normale Implementierung reichen in vielen Faellen Datei-, Such- und Diagnosewerkzeuge als Standard aus, waehrend 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 aehnliche Strukturtools sollten dein Standardprofil bilden, weil sie schnell sind und Seiteneffekte gering halten. In QuantenRam-Workflows tragen sie den groessten Teil von Analyse, Refactoring-Vorbereitung und Dokumentationsarbeit, ohne dass du dafuer gleich freie Shell-Rechte oder Netzwerkzugriffe freischalten musst.

Shell nur fuer echte Laufzeitfragen

Bash ist wertvoll, wenn du Tests, Django-Checks, Git-Status oder reale API-Smoke-Tests brauchst. Als Default fuer 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 fuehrt, 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 zusaetzlich freigeben, waehrend ein Review-Profil fuer 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 fuer Tools. So erkennst du spaeter schneller, ob ein Problem vom Modell, von der Freigabe oder vom eigentlichen Auftrag kommt.

Rechte, Sicherheit und Nachvollziehbarkeit

Fuer produktive Setups sollte die Rechteebene mindestens drei Zonen unterscheiden: lokale Strukturarbeit, echte Ausfuehrung und externe Kommunikation. Lokale Strukturarbeit darf meist automatisch laufen. Shell-Kommandos mit Schreibwirkung, Git-Aktionen oder Netzwerkanfragen gehoeren in der Regel auf ask. Destruktive oder schwer rueckgaengig zu machende Muster bleiben auf deny. Damit wird Sicherheit nicht als abstrakte Policy behandelt, sondern als taeglich sichtbare Ausfuehrungsgrenze.

In QuantenRam ist diese Disziplin auch wirtschaftlich sinnvoll. Wenn ein Toolprofil zu breit ist, fuehrt das oft nicht nur zu Sicherheitsrisiko, sondern auch zu unnoetigen 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 durchfuehrt und dafuer 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 fuer Billing-Ausreisser oder eine kleine Release-Pruefung fuer den eigenen API-Key und den gewuenschten 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 koennen.

{
  "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 oeffnet nicht moeglichst 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.