Skip to main content
Führen Sie mehrere isolierte Agenten in einem Gateway-Prozess aus, jeweils mit eigenem Workspace, Zustandsverzeichnis (agentDir) und SQLite-gestütztem Sitzungsverlauf sowie mehreren Kanalkonten (z. B. zwei WhatsApp-Nummern). Eingehende Nachrichten werden über Bindungen an den richtigen Agenten weitergeleitet. Ein Agent umfasst den vollständigen Bereich einer Persona: Workspace-Dateien, Authentifizierungsprofile, Modellregistrierung und Sitzungsspeicher. Eine Bindung ordnet ein Kanalkonto (einen Slack-Workspace, eine WhatsApp-Nummer usw.) einem dieser Agenten zu.

Was ist ein Agent?

Jeder Agent verfügt über einen eigenen:
  • Workspace: Dateien, AGENTS.md/SOUL.md/USER.md, lokale Notizen, Persona-Regeln.
  • Zustandsverzeichnis (agentDir): Authentifizierungsprofile, Modellregistrierung, agentenspezifische Konfiguration.
  • Sitzungsspeicher: Chatverlauf und Routing-Zustand in ~/.openclaw/agents/<agentId>/agent/openclaw-agent.sqlite.
Authentifizierungsprofile gelten jeweils pro Agent und werden aus folgendem Pfad gelesen:
sessions_history ist der sicherere Weg zum sitzungsübergreifenden Abruf: Es gibt eine begrenzte, geschwärzte Ansicht zurück, keinen Rohdump des Transkripts. Signaturen von Denkblöcken, Details der Nutzdaten von Werkzeugergebnissen, <relevant-memories>-Gerüstcode, XML-Tags für Werkzeugaufrufe (<tool_call>, <function_call> sowie deren Plural- und herabgestufte Formen) und MiniMax-XML für Werkzeugaufrufe werden entfernt; anschließend wird die Ausgabe gekürzt und anhand der Byte-Größe begrenzt.
Verwenden Sie agentDir niemals agentenübergreifend erneut — dies verursacht Kollisionen beim Authentifizierungs- und Sitzungszustand. Wenn die lokale OAuth-Anmeldeinformation eines sekundären Agenten abgelaufen ist oder ihre Aktualisierung fehlschlägt, greift OpenClaw auf die Anmeldeinformation des standardmäßigen bzw. Hauptagenten mit derselben Profil-ID zurück und übernimmt das jeweils aktuellste Token, ohne das Aktualisierungstoken in den Speicher des sekundären Agenten zu kopieren. Wenn Sie ein vollständig unabhängiges OAuth-Konto benötigen, melden Sie sich über diesen Agenten an. Wenn Sie Anmeldeinformationen manuell kopieren, kopieren Sie nur übertragbare statische api_key- oder token-Profile — OAuth-Aktualisierungsmaterial ist standardmäßig nicht übertragbar (copyToAgents kann dies für ein Profil ausdrücklich aktivieren).
Skills werden aus dem Workspace jedes Agenten sowie aus gemeinsam genutzten Stammverzeichnissen wie ~/.openclaw/skills geladen und anschließend anhand der effektiven Skill-Zulassungsliste des Agenten gefiltert. Verwenden Sie agents.defaults.skills für eine gemeinsame Basis und agents.entries.*.skills für einen agentenspezifischen Ersatz (explizite Einträge ersetzen den Standard, sie werden nicht zusammengeführt). Siehe Skills: agentenspezifisch und gemeinsam genutzt und Skills: Agentenzulassungslisten. Der Plugin-eigene Speicher richtet sich nach der Konfiguration dieses Plugins; durch das Hinzufügen eines zweiten Agenten wird nicht automatisch jeder globale Plugin-Speicher aufgeteilt. Konfigurieren Sie beispielsweise agentenspezifische Memory-Wiki-Vaults, wenn Personas kein kompiliertes Wiki-Wissen gemeinsam nutzen dürfen.
Hinweis zum Workspace: Der Workspace jedes Agenten ist das standardmäßige cwd, keine feste Sandbox. Relative Pfade werden innerhalb des Workspace aufgelöst, absolute Pfade können jedoch auf andere Speicherorte des Hosts zugreifen, sofern Sandboxing nicht aktiviert ist. Siehe Sandboxing.

Pfade

Einzelagentenmodus (Standard)

Wenn Sie nichts konfigurieren, führt OpenClaw einen Agenten aus:
  • agentId verwendet standardmäßig main.
  • Sitzungsschlüssel haben das Format agent:main:<mainKey> (der Standardwert mainKey ist main).
  • Der Workspace verwendet standardmäßig ~/.openclaw/workspace (oder workspace-<profile>, wenn OPENCLAW_PROFILE auf einen anderen Wert als default gesetzt ist).
  • Der Zustand verwendet standardmäßig ~/.openclaw/agents/main/agent.

Agenten-Hilfsfunktion

Fügen Sie einen neuen isolierten Agenten hinzu:
Flags: --workspace <dir>, --model <id>, --agent-dir <dir>, --bind <channel[:accountId]> (wiederholbar), --non-interactive (erfordert --workspace). Fügen Sie bindings hinzu, um eingehende Nachrichten weiterzuleiten (der Assistent bietet an, dies für Sie zu erledigen), und überprüfen Sie anschließend die Konfiguration:

Schnellstart

1

Workspace für jeden Agenten erstellen

Jeder Agent erhält einen eigenen Workspace mit SOUL.md, AGENTS.md und optional USER.md sowie ein dediziertes agentDir und einen Sitzungsspeicher unter ~/.openclaw/agents/<agentId>.
2

Kanalkonten erstellen

Erstellen Sie auf Ihren bevorzugten Kanälen jeweils ein Konto pro Agent:
  • Discord: ein Bot pro Agent; aktivieren Sie Message Content Intent und kopieren Sie jedes Token.
  • Telegram: ein Bot pro Agent über BotFather; kopieren Sie jedes Token.
  • WhatsApp: Verknüpfen Sie für jedes Konto die jeweilige Telefonnummer.
Siehe Kanalanleitungen: Discord, Telegram, WhatsApp.
3

Agenten, Konten und Bindungen hinzufügen

Fügen Sie Agenten unter agents.entries und Kanalkonten unter channels.<channel>.accounts hinzu und verbinden Sie sie mit bindings (Beispiele weiter unten).
4

Neu starten und überprüfen

Mehrere Agenten, mehrere Personas

Jeder konfigurierte agentId bildet eine eigenständige Persona-Grenze für den zentralen Agentenzustand:
  • Unterschiedliche Konten pro Kanal (je accountId).
  • Unterschiedliche Persönlichkeiten (agentenspezifische AGENTS.md/SOUL.md).
  • Getrennte Authentifizierung und Sitzungen; agentenübergreifender Zugriff wird nur durch explizite Funktionen oder die Plugin-Konfiguration aktiviert.
Dadurch können sich mehrere Personen ein Gateway teilen, während der zentrale Agentenzustand getrennt bleibt.

Agentenspezifische Memory-Wiki-Vaults

Memory Wiki verwendet standardmäßig ein globales Vault. Um das kompilierte Wissen eines Support-Agenten vom Wissen eines Marketing-Agenten zu trennen, setzen Sie plugins.entries.memory-wiki.config.vault.scope auf agent:
Der konfigurierte Pfad ist das übergeordnete Verzeichnis. OpenClaw hängt die normalisierte Agenten-ID an und erzeugt Pfade wie ~/.openclaw/wiki/support und ~/.openclaw/wiki/marketing. Agentenspezifische CLI- und Gateway-Vorgänge erfordern einen expliziten Agenten, wenn mehrere Agenten konfiguriert sind. Weitere Informationen zur Bridge-Filterung, Migration und zu Vertrauensgrenzen finden Sie unter Agentenspezifische Memory-Wiki-Vaults.

Agentenübergreifende QMD-Speichersuche

Damit ein Agent die QMD-Sitzungstranskripte eines anderen Agenten durchsuchen kann, fügen Sie unter agents.entries.*.memory.search.qmd.extraCollections zusätzliche Sammlungen hinzu. Verwenden Sie memory.search.qmd.extraCollections, wenn alle Agenten dieselben Sammlungen gemeinsam nutzen sollen.
Der Pfad einer zusätzlichen Sammlung kann von mehreren Agenten gemeinsam genutzt werden, sein name bleibt jedoch explizit, wenn der Pfad außerhalb des Agenten-Workspace liegt. Pfade innerhalb des Workspace bleiben agentenspezifisch, sodass jeder Agent seinen eigenen Satz durchsuchbarer Transkripte behält.

Eine WhatsApp-Nummer, mehrere Personen (DM-Aufteilung)

Leiten Sie verschiedene WhatsApp-DMs in einem WhatsApp-Konto an unterschiedliche Agenten weiter, indem Sie die E.164-Nummer des Absenders (+15551234567) mit peer.kind: "direct" abgleichen. Antworten werden weiterhin von derselben WhatsApp-Nummer gesendet — es gibt keine agentenspezifische Absenderidentität.
Direktchats werden standardmäßig im Hauptsitzungsschlüssel des Agenten zusammengeführt; eine echte Isolation erfordert daher einen Agenten pro Person.
Die DM-Zugriffssteuerung (Kopplung/Zulassungsliste) gilt global pro WhatsApp-Konto, nicht pro Agent. Binden Sie gemeinsam genutzte Gruppen an einen Agenten oder verwenden Sie Broadcast-Gruppen.

Routing-Regeln

Bindungen sind deterministisch; die spezifischste Übereinstimmung gewinnt. Die vollständige Rangfolge (exakter Kommunikationspartner, übergeordneter Kommunikationspartner, Platzhalter für Kommunikationspartner, Guild und Rollen, Guild, Team, Konto, Kanal, Standardagent) finden Sie unter Kanal-Routing. Einige Regeln sind hier besonders hervorzuheben:
  • Wenn mehrere Bindungen innerhalb derselben Rangstufe übereinstimmen, gewinnt die erste in der Konfigurationsreihenfolge.
  • Wenn eine Bindung mehrere Abgleichsfelder festlegt (beispielsweise peer + guildId), müssen alle angegebenen Felder übereinstimmen (AND-Semantik).
  • Eine Bindung ohne accountId stimmt nur mit dem Standardkonto überein, nicht mit jedem Konto. Verwenden Sie accountId: "*" für einen kanalweiten Fallback oder accountId: "<name>" für ein einzelnes Konto. Wenn dieselbe Bindung erneut mit einer expliziten Konto-ID hinzugefügt wird, wird die bestehende reine Kanalbindung aktualisiert, statt sie zu duplizieren.

Mehrere Konten/Telefonnummern

Kanäle, die mehrere Konten unterstützen (z. B. WhatsApp), verwenden accountId, um jede Anmeldung zu identifizieren. Jedes accountId wird an einen eigenen Agenten weitergeleitet, sodass ein Server mehrere Telefonnummern hosten kann, ohne Sitzungen zu vermischen. Setzen Sie channels.<channel>.defaultAccount, um das Konto auszuwählen, das verwendet wird, wenn accountId weggelassen wird. Ist dies nicht festgelegt, greift OpenClaw auf default zurück, sofern vorhanden, andernfalls auf die erste konfigurierte Konto-ID (sortiert). Kanäle mit Unterstützung für mehrere Konten: discord, feishu, googlechat, imessage, irc, line, mattermost, matrix, nextcloud-talk, nostr, signal, slack, telegram, whatsapp, zalo, zalouser.

Konzepte

  • agentId: ein „Gehirn“ (Arbeitsbereich, agentenspezifische Authentifizierung, agentenspezifischer Sitzungsspeicher).
  • accountId: eine Instanz eines Kanalkontos (z. B. WhatsApp-Konto personal gegenüber biz).
  • binding: leitet eingehende Nachrichten anhand von (channel, accountId, peer) und optional anhand von Guild-/Team-IDs an einen agentId weiter.
  • Direktchats werden in agent:<agentId>:<mainKey> zusammengeführt (agentenspezifisch „main“; siehe session.mainKey).

Plattformbeispiele

Jedes Discord-Bot-Konto wird einer eindeutigen accountId zugeordnet. Binden Sie jedes Konto an einen Agenten und verwalten Sie die Positivlisten pro Bot.
  • Laden Sie jeden Bot in die Guild ein und aktivieren Sie Message Content Intent.
  • Die Tokens befinden sich in channels.discord.accounts.<id>.token (das Standardkonto kann DISCORD_BOT_TOKEN verwenden).
  • Erstellen Sie mit BotFather einen Bot pro Agent und kopieren Sie jedes Token.
  • Die Tokens befinden sich in channels.telegram.accounts.<id>.botToken (das Standardkonto kann TELEGRAM_BOT_TOKEN verwenden).
  • Laden Sie bei mehreren Bots in derselben Telegram-Gruppe jeden Bot ein und erwähnen Sie denjenigen, der antworten soll.
  • Deaktivieren Sie für jeden Gruppen-Bot den BotFather Privacy Mode (/setprivacy -> Disable). Entfernen Sie den Bot anschließend und fügen Sie ihn erneut hinzu, damit Telegram die Einstellung übernimmt.
  • Erlauben Sie Gruppen mit channels.telegram.groups, oder verwenden Sie groupPolicy: "open" nur für vertrauenswürdige Gruppenbereitstellungen.
  • Tragen Sie Benutzer-IDs von Absendern in groupAllowFrom ein. Gruppen- und Supergruppen-IDs gehören in channels.telegram.groups, nicht in groupAllowFrom.
  • Binden Sie anhand von accountId, damit jeder Bot Nachrichten an seinen eigenen Agenten weiterleitet.
Verknüpfen Sie jedes Konto, bevor Sie den Gateway starten:
~/.openclaw/openclaw.json (JSON5):

Gängige Muster

Nach Kanal aufteilen: Leiten Sie WhatsApp an einen schnellen Agenten für den Alltag und Telegram an einen Opus-Agenten weiter.
Diese Beispiele verwenden accountId: "*", damit die Bindungen weiterhin funktionieren, wenn Sie später Konten hinzufügen. Um einen einzelnen Direktchat oder eine einzelne Gruppe an Opus weiterzuleiten und den Rest beim Chat-Agenten zu belassen, fügen Sie für diesen Peer eine match.peer-Bindung hinzu — Peer-Übereinstimmungen haben stets Vorrang vor kanalweiten Regeln.

Agentenspezifische Sandbox- und Tool-Konfiguration

Jeder Agent kann eigene Sandbox- und Tool-Einschränkungen haben:
setupCommand befindet sich unter sandbox.docker und wird bei der Container-Erstellung einmal ausgeführt. Agentenspezifische sandbox.docker.*-Overrides werden ignoriert, wenn der aufgelöste Geltungsbereich "shared" ist.
Dies bietet Ihnen:
  • Sicherheitsisolierung: Tools für nicht vertrauenswürdige Agenten einschränken.
  • Ressourcenkontrolle: Bestimmte Agenten in einer Sandbox ausführen, während andere auf dem Host verbleiben.
  • Flexible Richtlinien: unterschiedliche Berechtigungen pro Agent.
tools.elevated verfügt sowohl über eine globale Zugriffsprüfung (tools.elevated.enabled/allowFrom) als auch über eine agentenspezifische Zugriffsprüfung (agents.entries.*.tools.elevated.enabled/allowFrom). Die agentenspezifische Zugriffsprüfung kann die globale lediglich weiter einschränken — beide müssen einen Absender zulassen, damit Befehle mit erhöhten Berechtigungen ausgeführt werden. Verwenden Sie für die Gruppenzuordnung agents.entries.*.groupChat.mentionPatterns, damit @Erwähnungen eindeutig dem vorgesehenen Agenten zugeordnet werden.
Ausführliche Beispiele finden Sie unter Sandbox und Tools für mehrere Agenten.

Verwandte Themen

  • ACP-Agenten — Ausführen externer Coding-Harnesses
  • Kanal-Routing — wie Nachrichten an Agenten weitergeleitet werden
  • Präsenz — Präsenz und Verfügbarkeit von Agenten
  • Sitzung — Sitzungsisolierung und Routing
  • Unteragenten — Starten von Agentenläufen im Hintergrund