agentDir)、セッションストアを持ち、さらに複数のチャンネルアカウント(例: 2つの WhatsApp 番号)も扱えます。受信メッセージは bindings を通じて適切なエージェントへルーティングされます。
エージェントとは、ペルソナごとの完全なスコープです。ワークスペースファイル、認証プロファイル、モデルレジストリ、セッションストアを含みます。binding はチャンネルアカウント(Slack ワークスペース、WhatsApp 番号など)をそれらのエージェントの1つに対応付けます。
1つのエージェントとは
各エージェントは専用の次のものを持ちます。- ワークスペース: ファイル、
AGENTS.md/SOUL.md/USER.md、ローカルノート、ペルソナルール。 - 状態ディレクトリ(
agentDir): 認証プロファイル、モデルレジストリ、エージェントごとの設定。 - セッションストア:
~/.openclaw/agents/<agentId>/sessions配下のチャット履歴とルーティング状態。
sessions_history はより安全なクロスセッション想起パスです。生のトランスクリプトダンプではなく、範囲が制限され、リダクトされたビューを返します。thinking-block シグネチャ、ツール結果ペイロードの詳細、<relevant-memories> の足場、ツール呼び出し XML タグ(<tool_call>、<function_call>、およびそれらの複数形/ダウングレード形式)、MiniMax ツール呼び出し XML を取り除き、その後バイトサイズで出力を切り詰め、上限を適用します。~/.openclaw/skills などの共有ルートから読み込まれ、その後、有効なエージェント Skills 許可リストでフィルタリングされます。共有ベースラインには agents.defaults.skills を、エージェントごとの置き換えには agents.list[].skills を使用してください(明示的なエントリはデフォルトを置き換え、マージしません)。Skills: エージェントごと vs 共有 と Skills: エージェント許可リスト を参照してください。
ワークスペース注記: 各エージェントのワークスペースは デフォルト cwd であり、強制的なサンドボックスではありません。相対パスはワークスペース内で解決されますが、サンドボックス化が有効でない限り、絶対パスはホスト上の他の場所に到達できます。サンドボックス化 を参照してください。
パス
| 対象 | デフォルト | 上書き |
|---|---|---|
| 設定 | ~/.openclaw/openclaw.json | OPENCLAW_CONFIG_PATH |
| 状態ディレクトリ | ~/.openclaw | OPENCLAW_STATE_DIR |
| デフォルトエージェントのワークスペース | ~/.openclaw/workspace(または OPENCLAW_PROFILE が設定されている場合は workspace-<profile>) | agents.list[].workspace、次に agents.defaults.workspace、または OPENCLAW_WORKSPACE_DIR |
| その他のエージェントのワークスペース | <stateDir>/workspace-<agentId>(または設定時は <agents.defaults.workspace>/<agentId>) | agents.list[].workspace |
| エージェントディレクトリ | ~/.openclaw/agents/<agentId>/agent | agents.list[].agentDir |
| セッション | ~/.openclaw/agents/<agentId>/sessions | — |
単一エージェントモード(デフォルト)
何も設定しない場合、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 を追加し(ウィザードがこれを行うか提案します)、その後検証します。
クイックスタート
各エージェントワークスペースを作成
SOUL.md、AGENTS.md、任意の USER.md を含む専用ワークスペースに加え、専用の agentDir と ~/.openclaw/agents/<agentId> 配下のセッションストアが割り当てられます。エージェント、アカウント、bindings を追加
agents.list 配下にエージェントを、channels.<channel>.accounts 配下にチャンネルアカウントを追加し、bindings で接続します(例は下記)。複数のエージェント、複数のペルソナ
設定された各agentId は、完全に分離されたペルソナです。
- チャンネルごとの異なるアカウント(
accountIdごと)。 - 異なる人格(エージェントごとの
AGENTS.md/SOUL.md)。 - 明示的に有効化しない限りクロストークのない、分離された認証とセッション。
クロスエージェント QMD メモリ検索
1つのエージェントが別のエージェントの QMD セッショントランスクリプトを検索できるようにするには、agents.list[].memorySearch.qmd.extraCollections 配下に追加コレクションを追加します。すべてのエージェントが同じコレクションを共有する必要がある場合は、agents.defaults.memorySearch.qmd.extraCollections を使用します。
name は明示的なままです。ワークスペース内のパスはエージェントスコープのままなので、各エージェントは専用のトランスクリプト検索セットを保持します。
1つの WhatsApp 番号、複数の人(DM 分割)
送信者 E.164(+15551234567)を peer.kind: "direct" で照合することで、1つの WhatsApp アカウント上の異なる WhatsApp DM を別々のエージェントにルーティングします。返信は引き続き同じ WhatsApp 番号から送信されます。エージェントごとの送信者 ID はありません。
ダイレクトチャットはデフォルトでエージェントのメインセッションキーに折りたたまれるため、真の分離には人ごとに1つのエージェントが必要です。
ルーティングルール
Bindings は決定的で、最も具体的なものが優先されます。完全なティア順序(正確なピア、親ピア、ピアワイルドカード、guild+roles、guild、team、account、channel、デフォルトエージェント)については、チャンネルルーティング を参照してください。ここで取り上げる価値のあるルールがいくつかあります。- 同じティア内で複数の bindings が一致する場合、設定順で最初のものが優先されます。
- binding が複数の match フィールド(例:
peer+guildId)を設定している場合、指定されたすべてのフィールドが一致する必要があります(ANDセマンティクス)。 accountIdを省略した binding は、すべてのアカウントではなくデフォルトアカウントのみに一致します。チャンネル全体のフォールバックにはaccountId: "*"を、1つのアカウントにはaccountId: "<name>"を使用してください。同じ binding を明示的なアカウント ID 付きでもう一度追加すると、既存のチャンネルのみの binding を複製するのではなくアップグレードします。
複数アカウント / 電話番号
複数アカウントをサポートするチャンネル(例: 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)と、任意で guild/team ID によって、受信メッセージをagentIdにルーティングします。- ダイレクトチャットは
agent:<agentId>:<mainKey>に折りたたまれます(エージェントごとの「main」。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: "*" を使用しているため、後でアカウントを追加してもバインディングは動作し続けます。残りをチャットに保持したまま単一の DM/グループを Opus にルーティングするには、そのピアの match.peer バインディングを追加します。ピア一致は常にチャンネル全体のルールより優先されます。エージェントごとのサンドボックスとツール設定
各エージェントは独自のサンドボックスとツール制限を持つことができます。setupCommand は sandbox.docker の下にあり、コンテナ作成時に 1 回実行されます。解決後のスコープが "shared" の場合、エージェントごとの sandbox.docker.* オーバーライドは無視されます。- セキュリティ分離: 信頼できないエージェントのツールを制限します。
- リソース制御: 特定のエージェントをサンドボックス化し、他のエージェントはホスト上に保持します。
- 柔軟なポリシー: エージェントごとに異なる権限を設定します。
tools.elevated にはグローバルゲート(tools.elevated.enabled/allowFrom)とエージェントごとのゲート(agents.list[].tools.elevated.enabled/allowFrom)の両方があります。エージェントごとのゲートはグローバルゲートをさらに制限することしかできません。昇格コマンドを実行するには、両方が送信者を許可している必要があります。グループを対象にする場合は、@mentions が意図したエージェントに明確に対応するよう、agents.list[].groupChat.mentionPatterns を使用してください。関連
- ACP エージェント — 外部コーディングハーネスの実行
- チャンネルルーティング — メッセージがエージェントにルーティングされる仕組み
- プレゼンス — エージェントのプレゼンスと可用性
- セッション — セッション分離とルーティング
- サブエージェント — バックグラウンドエージェント実行の生成