Für wen: Betriebsteams, die OpenClaw auf einem Remote-Mac (Apple Silicon) mit einer reproduzierbaren /v1/embeddings-Route, stabiler RAG-Konfiguration (agents.defaults.memorySearch laut docs.openclaw.ai) und nachvollziehbaren CI-Alarmen betreiben. Referenz: Gateway-Konfiguration. Vertiefung auf Deutsch: Gateway-Härtung, Harbor-Webhook & Prefetch sowie GHCR-/Registry-Pull-Matrix — für konsistente Ausgangs-Whitelist und Cache-Disziplin.

Welche Störungen dieser Ablauf vermeidet

  1. Kalte Embeddings: Der erste Aufruf lädt Gewichte oder trifft eine API, die Sie nie aus Sicht des Daemon-Benutzers getestet haben — CI ist grün, das Gateway liefert 500.
  2. Geteiltes Gehirn bei Auth: openclaw onboard schreibt Token in eine Shell-Datei, launchd liest eine andere — interaktives curl funktioniert, Automation scheitert mit 401.
  3. Stille CI: Pipelines melden Erfolg, obwohl Vektorindizes fehlen, weil niemand strukturierte JSON-Fehler an Ihr Monitoring mit begrenzten Wiederholungen sendet.

Entscheidung: wo Embeddings laufen

Modus Sinnvoll wenn … Abwägung
Gehostete API (OpenAI-kompatibel) Stabiler Egress, wenig RAM auf dem Mac Kontingente, Schlüsselrotation, Allowlist-Pflege
Lokale Laufzeit / GGUF Airgap oder vorhersehbare Kosten Großer APFS-Fußabdruck; warme Caches Pflicht
Ollama oder Sidecar auf Loopback Schnelle Iteration in kleinen Teams Zusätzlicher Dienst: Upgrades + Healthchecks

Installation, onboard und --install-daemon

Node 22 LTS mit Ihrem Standardwerkzeug pinnen (nvm, fnm oder Apple-/offizielle Pakete). Die globale CLI-Installation gehört demselben Unix-Benutzer wie das Gateway — kein gemischtes sudo npm -g:

node -v   # Erwartung: v22.x
npm install -g openclaw
which openclaw

Onboarding nach Richtlinie oft nicht-interaktiv; immer --install-daemon nutzen, wenn Ihre Distribution es dokumentiert — dann registriert macOS einen LaunchAgent, der SSH-Abbrüche und Logouts überlebt. Beispielmuster (Anbieter-Flags anpassen):

openclaw onboard --non-interactive --accept-risk --install-daemon \
  --auth-choice anthropic-api-key --anthropic-api-key "$ANTHROPIC_API_KEY"

Geheimnisse in ~/.openclaw/.env.gateway mit chmod 600; in der plist unter EnvironmentVariables referenzieren — niemals Token in CI-Logs echoen. Nach der Installation die Session des Dienstbenutzers einmal frisch anmelden, damit PATH und globale npm-Binaries mit dem übereinstimmen, was launchd sieht.

MemorySearch aktivieren und /v1/embeddings prüfen

In ~/.openclaw/openclaw.json (JSON5 erlaubt oft Kommentare) agents.defaults.memorySearch auf Anbieter, Modell und Dimensionen setzen — siehe Memory-Search-Doku. Gateway möglichst nur auf 127.0.0.1 binden; TLS davor terminieren. Port dynamisch lesen und lokal testen:

OC_PORT=$(jq -r '.gateway.port // 18789' "$HOME/.openclaw/openclaw.json" 2>/dev/null || echo 18789)
export OPENCLAW_GATEWAY_TOKEN="$(tr -d '\n' < "$HOME/.openclaw/.env.gateway" 2>/dev/null || true)"
curl -sS "http://127.0.0.1:${OC_PORT}/v1/embeddings" \
  -H "Authorization: Bearer ${OPENCLAW_GATEWAY_TOKEN}" \
  -H "Content-Type: application/json" \
  -d '{"model":"text-embedding-3-small","input":"healthcheck ping"}' | head -c 500

Erwartung: HTTP 200 und JSON mit data[0].embedding. Bei 401 zuerst Shell-Token und plist-Token vergleichen, Zeilenumbrüche entfernen, Daemon neu laden — erst danach Modellparameter ändern.

openclaw doctor, Gateway-Status und Logs

Nach jedem Upgrade openclaw doctor ausführen und Warnungen abarbeiten. Wo verfügbar: openclaw gateway status bzw. openclaw gateway status --deep von derselben Umgebung wie der LaunchAgent. StandardOutPath/StandardErrorPath in der plist auf datierte Logs legen und nach 401, EADDRINUSE oder Provider-Fehlern filtern.

Remote-Mac-CI: Vektormodelle vorwärmen, Alarme zurückspielen

Auf demselben Remote-Mac-Pool dieselben Cache-Variablen setzen wie im Gateway (HF_HOME, Hersteller-Caches, Symlinks auf schnelles NVMe). Ein Preflight-Job lädt Embedding-Gewichte und — falls vorhanden — Vektorindizes außerhalb kritischer Release-Builds; so greifen Agenten und Tests nur noch auf lokale Dateien zu.

Scheitert ein Schritt, strukturiertes application/json an Ihr Observability-Webhook senden: Wiederholungen 2 s / 4 s / 8 s mit Jitter, maximal drei Versuche; bei wiederholten 401 sofort eskalieren statt endlos zu retryen — dieselbe Disziplin wie bei Registry-Pulls in Ihren bestehenden Runbooks.

Häufige Fehler — was zuerst prüfen

Symptom Erste Maßnahmen
EADDRINUSE auf Gateway-Port lsof -nP -iTCP:"$OC_PORT" -sTCP:LISTEN; alten Prozess beenden; openclaw.json und Reverse-Proxy-Upstream angleichen.
HTTP 401 auf /v1/embeddings Token diff (Shell vs. launchd); chmod 600 für Env-Datei; Daemon reload; Uhrzeit sync.
HTTP 429 vom Anbieter Parallele CI-Prefetches senken; Retry-After beachten; Prefetch von interaktiven Tests trennen.
ENOSPC beim Modellzug df -h und df -i auf Symlink-Ziel; Warm-Tier verschieben oder Temp-Shards leeren.

Leitplanken zum Abnahme-PR anhängen

  • Gateway-Bearer-Datei 600; Token-Rotation gekoppelt an CI-Geheimnis-Rotation.
  • Webhook-Backoff 2 / 4 / 8 s; nach drei Fehlversuchen Stopp und Mensch informieren.
  • Platten-Warnschwelle z. B. 80 % auf dem schnellen Tier vor warteschlangen Embeddings-Jobs.

FAQ

Brauche ich einen separaten Key nur für Embeddings?

Wenn der Anbieter feingranulare Schlüssel erlaubt: ja — nur Embedding-Scopes, in derselben geschützten Datei wie das Gateway, niemals Admin-Konsolen-Keys in Skripten.

Warum CI-Prefetch, wenn das Gateway sowieso zieht?

CI bestätigt identische Pfade und Rechte wie der Daemon, verschiebt große Downloads aus dem kritischen Build-Pfad und deckt Cross-User-Bugs früh auf.

Warum liefert /v1/embeddings nach dem Onboarding 401?

Meist unterschiedliche OPENCLAW_GATEWAY_TOKEN-Werte in interaktiver Shell und LaunchAgent-Plist. Token vergleichen, Zeilenumbrüche mit tr -d '\n' entfernen, Env-Datei chmod 600, Daemon neu laden, erneut curl.

Wie retries ohne das Gateway zu fluten?

Backoff 2/4/8 s mit kleinem Jitter; HTTP 429 (Rate-Limit) von Auth-Fehlern trennen; nach drei Fehlversuchen stoppen und Menschen informieren — nicht endlos automatisch wiederholen.

Fazit, Kauf und Hilfe

Kurz: Reproduzierbare Embeddings auf einem Remote-Mac entstehen aus npm install -g openclaw, onboard --install-daemon, explizitem memorySearch, einer grünen /v1/embeddings-Probe, doctor plus tiefem Gateway-Status und CI-Jobs, die Modelle und Indizes in gemeinsame Caches vorwärmen. Alarm-Webhooks mit begrenzten Wiederholungen sorgen dafür, dass Fehler dort landen, wo Ihr Team ohnehin hinschaut.

Kapazität anfragen: Jetzt kaufen, Preise, Hilfe sowie der Technik-Blog — viele Seiten ohne Login lesbar.

Dedizierte Apple-Silicon-Knoten halten Embedding-Caches warm, ohne „laute Nachbarn“ in geteilten Umgebungen.

Stabilen Remote-Mac für OpenClaw?

Mac Mini M4 mit schnellem NVMe für Gateway-Daemons und Embedding-Caches — Preise, Kauf und Hilfe ohne Zwang zur Anmeldung.

Preise Kaufen Hilfe Blog