agentDir)、SQLite ベースのセッション履歴を持ち、さらに複数のチャンネルアカウント(例: 2 つの WhatsApp 番号)を利用できます。受信メッセージは バインディングを通じて適切なエージェントへルーティングされます。
エージェントとは、ワークスペースファイル、認証プロファイル、モデルレジストリ、セッションストアを含む、ペルソナごとの完全なスコープです。バインディングは、チャンネルアカウント(Slack ワークスペース、WhatsApp 番号など)をいずれかのエージェントに対応付けます。
1 つのエージェントとは
各エージェントは以下を個別に持ちます。- ワークスペース: ファイル、
AGENTS.md/SOUL.md/USER.md、ローカルノート、ペルソナルール。 - 状態ディレクトリ(
agentDir): 認証プロファイル、モデルレジストリ、エージェントごとの設定。 - セッションストア:
~/.openclaw/agents/<agentId>/agent/openclaw-agent.sqlite内のチャット履歴とルーティング状態。
sessions_history は、セッションをまたいで記憶を呼び出すための、より安全な経路です。生のトランスクリプトをそのまま返すのではなく、範囲が制限され、秘匿化されたビューを返します。思考ブロックの署名、ツール結果ペイロードの詳細、<relevant-memories> の足場、ツール呼び出しの XML タグ(<tool_call>、<function_call>、およびそれらの複数形やダウングレード形式)、MiniMax のツール呼び出し XML を除去したうえで、出力を切り詰め、バイトサイズで上限を設定します。~/.openclaw/skills などの共有ルートから読み込まれ、その後、有効なエージェントの Skills 許可リストによって絞り込まれます。共有ベースラインには agents.defaults.skills を使用し、エージェントごとの置き換えには agents.entries.*.skills を使用します(明示的なエントリはデフォルトを置き換え、マージはしません)。Skills: エージェントごとと共有の違いおよびSkills: エージェントの許可リストを参照してください。
Plugin が所有するストレージは、その Plugin の設定に従います。2 番目のエージェントを追加しても、
すべてのグローバル Plugin ストアが自動的に分割されるわけではありません。たとえば、ペルソナ間で
コンパイル済みの Wiki ナレッジを共有してはならない場合は、
エージェントごとの Memory Wiki ボールト
を設定してください。
ワークスペースに関する注意: 各エージェントのワークスペースはデフォルトの cwd であり、厳格なサンドボックスではありません。相対パスはワークスペース内で解決されますが、サンドボックス化が有効でない限り、絶対パスからホスト上の他の場所にアクセスできます。サンドボックス化を参照してください。
パス
単一エージェントモード(デフォルト)
何も設定しない場合、OpenClaw は 1 つのエージェントを実行します。agentIdのデフォルトはmainです。- セッションのキーは
agent:main:<mainKey>です(デフォルトのmainKeyはmain)。 - ワークスペースのデフォルトは
~/.openclaw/workspaceです(OPENCLAW_PROFILEがdefault以外に設定されている場合はworkspace-<profile>)。 - 状態のデフォルトは
~/.openclaw/agents/main/agentです。
エージェントヘルパー
新しい分離エージェントを追加します。--workspace <dir>、--model <id>、--agent-dir <dir>、--bind <channel[:accountId]>(繰り返し指定可能)、--non-interactive(--workspace が必要)。
受信メッセージをルーティングするには bindings を追加し(ウィザードでも設定できます)、その後、以下で確認します。
クイックスタート
1
各エージェントのワークスペースを作成する
SOUL.md、AGENTS.md、任意の USER.md を含む独自のワークスペースに加え、専用の agentDir と ~/.openclaw/agents/<agentId> 配下のセッションストアが作成されます。2
3
エージェント、アカウント、バインディングを追加する
agents.entries にエージェント、channels.<channel>.accounts にチャンネルアカウントを追加し、bindings で接続します(以下に例があります)。4
再起動して確認する
複数のエージェント、複数のペルソナ
設定された各agentId は、エージェントのコア状態について個別のペルソナ境界となります。
- チャンネルごとに異なるアカウント(
accountIdごと)。 - 異なるパーソナリティ(エージェントごとの
AGENTS.md/SOUL.md)。 - 認証とセッションを分離し、エージェント間アクセスは明示的な機能または Plugin 設定によってのみ有効化。
エージェントごとの Memory Wiki ボールト
Memory Wiki はデフォルトで 1 つのグローバルボールトを使用します。サポートエージェントの コンパイル済みナレッジをマーケティングエージェントのものと分離するには、plugins.entries.memory-wiki.config.vault.scope を agent に設定します。
~/.openclaw/wiki/support や
~/.openclaw/wiki/marketing のようなパスを生成します。複数のエージェントが設定されている場合、
エージェントスコープの CLI および Gateway 操作には
エージェントの明示的な指定が必要です。ブリッジの
フィルタリング、移行、信頼境界の詳細については、エージェントごとの Memory Wiki ボールトを参照してください。
エージェント間の QMD メモリ検索
あるエージェントから別のエージェントの QMD セッショントランスクリプトを検索できるようにするには、agents.entries.*.memory.search.qmd.extraCollections 配下に追加のコレクションを設定します。すべてのエージェントで同じコレクションを共有する場合は、memory.search.qmd.extraCollections を使用します。
name は明示的なままです。ワークスペース内のパスはエージェントスコープのままなので、各エージェントは独自のトランスクリプト検索セットを維持できます。
1 つの WhatsApp 番号を複数人で使用する(DM の分割)
peer.kind: "direct" で送信者の E.164(+15551234567)を照合することにより、1 つの WhatsApp アカウント上で異なる WhatsApp DM を別々のエージェントへルーティングします。返信は引き続き同じ WhatsApp 番号から送信され、エージェントごとの送信者 ID はありません。
ダイレクトチャットはデフォルトでエージェントのメインセッションキーに集約されるため、完全な分離にはユーザーごとに 1 つのエージェントが必要です。
ルーティングルール
バインディングは決定的であり、最も具体的なものが優先されます。階層の完全な順序(完全一致するピア、親ピア、ピアのワイルドカード、ギルド+ロール、ギルド、チーム、アカウント、チャンネル、デフォルトエージェント)については、チャンネルルーティングを参照してください。ここでは、特に重要ないくつかのルールを示します。- 同じ階層内で複数のバインディングが一致する場合、設定内で最初に記述されたものが優先されます。
- バインディングに複数の照合フィールド(例:
peer+guildId)が設定されている場合、指定されたすべてのフィールドが一致する必要があります(ANDのセマンティクス)。 accountIdを省略したバインディングは、すべてのアカウントではなく、デフォルトアカウントのみに一致します。チャンネル全体のフォールバックにはaccountId: "*"を使用し、特定の 1 アカウントにはaccountId: "<name>"を使用します。同じバインディングを明示的なアカウント ID とともに再度追加すると、重複を作成せず、既存のチャンネルのみのバインディングが更新されます。
複数のアカウント/電話番号
複数のアカウントをサポートするチャンネル(例: WhatsApp)は、各ログインの識別にaccountId を使用します。各 accountId はそれぞれ独自のエージェントへルーティングされるため、1 台のサーバーでセッションを混在させることなく、複数の電話番号をホストできます。
accountId が省略された場合に使用するアカウントを選択するには、channels.<channel>.defaultAccount を設定します。未設定の場合、OpenClaw は default があればそれを使用し、なければ設定済みアカウント ID の先頭(並べ替え後)を使用します。
複数のアカウントをサポートするチャンネル: discord、feishu、googlechat、imessage、irc、line、mattermost、matrix、nextcloud-talk、nostr、signal、slack、telegram、whatsapp、zalo、zalouser。
概念
agentId: 1 つの「頭脳」(ワークスペース、エージェントごとの認証、エージェントごとのセッションストア)。accountId: 1 つのチャンネルアカウントインスタンス(例: WhatsApp アカウントpersonalとbiz)。binding:(channel, accountId, peer)、および必要に応じてギルド ID/チーム ID に基づいて、受信メッセージをagentIdにルーティングします。- ダイレクトチャットは
agent:<agentId>:<mainKey>に集約されます(エージェントごとの「メイン」。session.mainKeyを参照)。
プラットフォーム別の例
エージェントごとの Discord ボット
エージェントごとの Discord ボット
各 Discord ボットアカウントは、一意の
accountId に対応します。各アカウントをエージェントにバインドし、ボットごとに許可リストを維持します。- 各ボットをギルドに招待し、Message Content Intent を有効にします。
- トークンは
channels.discord.accounts.<id>.tokenに保存します(デフォルトアカウントではDISCORD_BOT_TOKENを使用できます)。
エージェントごとの Telegram ボット
エージェントごとの Telegram ボット
- BotFather でエージェントごとに 1 つのボットを作成し、それぞれのトークンをコピーします。
- トークンは
channels.telegram.accounts.<id>.botTokenに保存します(デフォルトアカウントではTELEGRAM_BOT_TOKENを使用できます)。 - 同じ Telegram グループで複数のボットを使用する場合は、各ボットを招待し、応答させるボットをメンションします。
- 各グループボットについて BotFather の Privacy Mode を無効にし(
/setprivacy-> Disable)、Telegram に設定を適用させるため、ボットを削除してから再度追加します。 channels.telegram.groupsでグループを許可するか、信頼できるグループへのデプロイに限ってgroupPolicy: "open"を使用します。- 送信者のユーザー ID は
groupAllowFromに指定します。グループ ID とスーパーグループ ID はgroupAllowFromではなくchannels.telegram.groupsに指定します。 - 各ボットがそれぞれ専用のエージェントにルーティングされるよう、
accountIdでバインドします。
エージェントごとの WhatsApp 番号
エージェントごとの WhatsApp 番号
Gateway を起動する前に、各アカウントをリンクします。
~/.openclaw/openclaw.json(JSON5):一般的なパターン
- 日常用途の WhatsApp + 集中作業用の Telegram
- 同じチャンネルで 1 つのピアだけを Opus にルーティング
- WhatsApp グループにバインドされた家族用エージェント
チャンネルごとに分割します。WhatsApp は高速な日常用途のエージェントに、Telegram は Opus エージェントにルーティングします。これらの例では
accountId: "*" を使用しているため、後からアカウントを追加してもバインディングは引き続き機能します。その他は chat に維持したまま、単一の DM/グループを Opus にルーティングするには、そのピア用の match.peer バインディングを追加します。ピアの一致は常にチャンネル全体のルールより優先されます。エージェントごとのサンドボックスとツール設定
各エージェントには、個別のサンドボックスとツール制限を設定できます。setupCommand は sandbox.docker 配下にあり、コンテナの作成時に 1 回だけ実行されます。解決されたスコープが "shared" の場合、エージェントごとの sandbox.docker.* オーバーライドは無視されます。- セキュリティの分離: 信頼できないエージェントのツールを制限します。
- リソース制御: 一部のエージェントをサンドボックス化し、その他はホスト上で実行します。
- 柔軟なポリシー: エージェントごとに異なる権限を設定します。
tools.elevated には、グローバルゲート(tools.elevated.enabled/allowFrom)とエージェントごとのゲート(agents.entries.*.tools.elevated.enabled/allowFrom)の両方があります。エージェントごとのゲートでは、グローバルゲートよりもさらに制限することしかできません。昇格コマンドを実行するには、両方で送信者が許可されている必要があります。グループを対象にする場合は、@メンションが対象のエージェントに明確に対応するよう、agents.entries.*.groupChat.mentionPatterns を使用します。関連項目
- ACP エージェント — 外部コーディングハーネスの実行
- チャネルルーティング — メッセージがエージェントにルーティングされる仕組み
- プレゼンス — エージェントのプレゼンスと可用性
- セッション — セッションの分離とルーティング
- サブエージェント — バックグラウンドでのエージェント実行の生成