Konfiguration

Die Anyy-Konfiguration gehört zu einem Profil. Jedes Profil hat eigene Modellrouten, Kanäle, Werkzeuge, Zeitpläne, Zugangsdaten, einen Workspace und Zustand.

Empfohlene Wege zum Ändern von Einstellungen

Änderung	Empfohlene Oberfläche
Ersteinrichtung	anyy setup
Modelle und Zugangsdaten	Dashboard → Modelle oder anyy setup model
Kanäle	Dashboard → Kanäle oder anyy setup channel
Bild-, Video- und Sprachrouten	Dashboard → Modelle oder die entsprechende Werkzeugseite
Websuche	Dashboard → Werkzeuge → Websuche
Rollen, Skills, MCP und Cron	Der jeweilige Dashboard-Bereich
Aufgelöste Konfiguration prüfen	anyy config

anyy config ist schreibgeschützt. Es meldet aufgelöstes Profil, Pfade, Anbieter-/Modellauswahl und den Zustand von Zugangsdatenreferenzen, ohne geheime Werte auszugeben.

Den unterstützten Editor verwenden

Dashboard und Einrichtungsbefehle validieren Änderungen, schützen Zugangsdaten und laden die laufende Laufzeit neu, soweit unterstützt. Direktes Bearbeiten von YAML ist für erweiterte Wiederherstellung nützlich, umgeht aber diese geführten Prüfungen.

Profilstruktur

Das aktive Profil-Home enthält die maßgeblichen Benutzerdaten dieses Profils. Wichtige Pfade sind:

Pfad	Zweck
config.yaml	Einstellungen und Zugangsdatenreferenzen; MCP-Wertfelder behalten eingegebene Zeichenfolgen
secrets/	Durch Anyy verwaltetes geheimes Material
state.db	Sitzungen, Nachrichten, Aufträge, Audit und weiterer dauerhafter Zustand
memory/USER.md	Dauerhafte Benutzerfakten und -vorlieben
memory/MEMORY.md	Dauerhafte Assistentenerinnerungen
objects/	Inhaltsadressierte dauerhafte Inhalte, die der kanonische Zustand referenziert
workspace/	Kontextdateien und vom Benutzer erstellte Arbeitsdateien
skills/	Im Profil lokal installierte Skills
roles/	Profillokale Rollendefinitionen

Betrachten Sie workspace/ nicht als Sicherheitsgrenze. Ein Werkzeug folgt weiterhin Betriebssystemrechten und Ausführungsgrenzen.

Welches Profil ist aktiv?

anyy status
anyy config

Um ein anderes benanntes Profil zu prüfen:

anyy --profile work config

Befehle mit --home PATH können ein explizites Profilverzeichnis ansprechen. Vermischen Sie --profile, --profile-root und spontane --home-Werte nur, wenn Sie die Pfadauflösung gezielt diagnostizieren.

Thinking-Konfiguration und Migration

Die globale Thinking-Vorliebe des Profils liegt in main_model.inference; optionale Überschreibungen für exakte Ziele liegen in der Map model_thinking_levels auf oberster Ebene:

main_model:
  provider_id: your-provider
  model: your-model
  inference:
    enabled: true
    # Leave level omitted to keep the global level unset.
model_thinking_levels:
  "your-provider/your-model": high

Verwenden Sie Ihre konfigurierten Anbieter-/Modell-IDs. Map-Schlüssel werden am ersten / geteilt; beide Seiten müssen nicht leer sein. Die Validierung normalisiert Schlüssel nicht, und die Suche erfolgt exakt. Ein nicht registrierter Modellschlüssel kann zur späteren Verwendung gespeichert werden. Werte sind benannte Pi-Stufen: off, minimal, low, medium, high, xhigh oder max; Laufzeitschnappschüsse entfernen Leerraum an den Werträndern. Ein leerer Map-Wert ist ungültig.

Globales enabled ist standardmäßig true. Bei true oder fehlendem Wert bedeutet eine fehlende Stufe „nicht gesetzt“; enabled: false fordert ausdrücklich „aus“ an, auch ohne Stufe. Auch der benannte Wert off ist gültig. Das ausgewählte Modell begrenzt die Anfrage; inference.effective_level ist schreibgeschützt und keine YAML-Einstellung. Siehe Auswahlpriorität.

Beim Aktualisieren einer alten Konfiguration auf v0.1.107:

• Entfernen Sie den abgeschafften Schlüssel prompt_program.inference_level, auch wenn er leer ist. Null und andere typisierte Werte werden ebenfalls abgelehnt. Verschieben Sie die beabsichtigte globale Vorliebe nach main_model.inference oder eine exakte Modellvorliebe nach model_thinking_levels.
• Entfernen Sie prompt_program.render_profile, wann immer es vorhanden ist, selbst bei null oder leerem Wert. Es gibt weder einen Ersatzselektor noch eine Verpflichtung zu „high“.
• Ersetzen Sie Produktwerte provider_default durch eine benannte Pi-Stufe. Bei einer globalen Stufe bewahrt das Entfernen von level den ungesetzten Zustand; wählen Sie für einen Map-Eintrag einen benannten Wert oder entfernen Sie den Eintrag.

JSON/YAML und Produktmodell-APIs lehnen abgeschaffte Eingaben ausdrücklich ab; es gibt keinen Alias oder stillschweigende Umwandlung in medium. Anyy schreibt diese abgeschafften Werte nicht stillschweigend um; migrieren Sie sie ausdrücklich. Öffentliche prompt_program-Einstellungen behalten nur resource_class. Auf nativer niedriger Ebene bleibt eine ausgelassene Inference-Einstellung gültig.

Wiederholungen und Modellschnittstellen

Sitzungswiederholungen, Anbieter-SDK-Wiederholungen, Ausweichrouting und virtuelle Modell-Callbacks haben getrennte Einstellungen; retry.enabled schaltet nicht jedes Wiederholungsverhalten. Unter Anbieterprotokolle und Modellschnittstellen finden Sie typisierte providers[].models[]-Datensätze, Sampling-Felder sowie genaue retry-/httpIdleTimeoutMs-Einstellungen.

MCP-Konfiguration

Profilweite MCP-Definitionen bleiben unter mcp.client.servers in config.yaml. Der kanonische Workspace des Profils kann außerdem .anyy/mcp.json enthalten (derzeit <ProfileHome>/workspace/.anyy/mcp.json). Vollständige Projektdefinitionen ersetzen gleichnamige Profildefinitionen; teilweise Einträge überschreiben nur Aktivierungszustand, Bereitstellung und die vollständigen geordneten Werkzeugbereitstellungsregeln. Dateiformat und Wertausdrücke finden Sie unter Profil- und Projektkonfiguration.

Aktivierungs-/Bereitstellungseinstellungen werden in der ausgewählten Definition oder vorhandenen Projektüberschreibung gespeichert und betreffen nur diesen Server. Änderungen von Beschreibung, Werkzeugüberschreibungen, Transport und Zugangsdaten über Profilbefehle bleiben rohe Profiländerungen. CLI-Einstellungen und Profiloptionen müssen getrennt übermittelt werden. enable/disable --project erstellt für einen noch nicht überschriebenen Profilserver eine reine Aktivierungsüberschreibung. add/remove --local bearbeitet nur native Projektdefinitionen und bewahrt Profildefinition und unabhängige Zugangsdaten; diese Dateiänderungen werden nach dem nächsten Start oder Neuladen einer untätigen Sitzung wirksam.

anyy mcp reload verbindet einen Server mit geladenen Werten neu; es liest keine Dateien erneut. Beim Start und über den vorhandenen RPC session.reload einer untätigen Sitzung werden Profil-/Projektkonfiguration erneut eingelesen. Wertausdrücke, Bereitstellungsregeln und OAuth-Authentifizierung sind in der MCP-Anleitung beschrieben.

Zugangsdaten

Durch Anyy verwaltete Zugangsdaten verwenden Referenzen statt geheimer Werte in der Konfiguration. Explizite unterstützte Zugangsdatenaktionen in Dashboard und Einrichtung schreiben Schlüssel mit eingeschränkten Rechten unter secrets/ des Profils. Gewöhnliche MCP-Wertschreibvorgänge bewahren eingegebene Zeichenfolgen und Ausdrücke; sie erstellen nicht automatisch verwaltete Geheimnisse. Siehe MCP-Werte.

Ersetzen, löschen, verbinden oder trennen Sie Zugangsdaten über dieselbe Funktionsoberfläche, die sie erstellt hat. Fügen Sie Geheimnisse niemals in Chatprompts, Screenshots, Shell-Verlauf oder Supportpakete ein.

Änderungen anwenden

Viele Dashboard- und Einrichtungsaktionen laden nach erfolgreichem Schreiben die betroffene Laufzeit neu. Kanaländerungen können auch ausdrücklich angewendet werden:

anyy channel reload

Ist eine Änderung gespeichert, aber das Verhalten unverändert, prüfen Sie:

anyy status
anyy doctor
anyy gateway status

Starten Sie Gateway nur neu, wenn die Abhilfe der Funktion dies verlangt oder ein Neuladen im Betrieb nicht abgeschlossen werden kann.

v0.1.107 lehnt diese alten MCP-Einstellungen ab. Entfernen oder migrieren Sie sie in manuell gepflegter Konfiguration:

• mcp.client.enabled: Verwenden Sie enabled des jeweiligen Servers.
• mcp.client.session_idle_ttl_ms: abgeschafft; Werkzeugkataloge werden bei Benachrichtigungen und expliziten Aktionen aktualisiert.
• Server-connect_timeout_ms: Verwenden Sie das vorhandene call_timeout_ms für jede Initialisierung, Erkennung oder Werkzeuganfrage.
• tools.include, tools.exclude und tools.trusted: Verwenden Sie exposure und toolExposure; auch tools.resources und tools.prompts sind abgeschafft.

Es gibt keinen neuen Konfigurationsschlüssel request_timeout_ms. Vollständige Formate und Migration finden Sie unter MCP-Server.

Vor manueller Bearbeitung sichern

anyy backup create

Standardmäßig werden das verwaltete Verzeichnis secrets/ und der unterstützte Speicher mcp/oauth/ ausgelassen; --include-secrets schließt diese Speicher zusätzlich ein. Kanonische Konfiguration und Workspace-Dateien werden weiterhin erfasst, sodass darin bereits direkt enthaltene Zugangsdaten auch in ein Standardarchiv gelangen können. Vollständige Redigierung ist nicht garantiert. Schützen Sie jedes Archiv als private Daten und schließen Sie die verwalteten Geheimnisspeicher nur ein, wenn das Archiv wie ein Zugangsdaten-Speicher geschützt wird. Siehe Sicherung und Wiederherstellung.

Fehlerbehebung

Symptom	Prüfung
Eine Einstellung scheint unverändert	Bestätigen Sie das aktive Profil und prüfen Sie anyy config
Gateway verwendet noch alte Werte	Führen Sie die passende Neuladeaktion aus und prüfen Sie dann anyy status
Die Konfigurationsprüfung schlägt fehl	Verwenden Sie Dashboard-Formular oder Einrichtungsassistenten, um das ungültige Feld zu finden
Zugangsdaten sind konfiguriert, aber nicht auflösbar	Ersetzen Sie sie auf der zuständigen Seite Modelle, Werkzeuge oder Kanäle
Manuell bearbeitetes YAML verhindert den Start	Stellen Sie die letzte gültige Datei wieder her oder eine Sicherung in einem neuen Profil