OpenClaw インスタンス間通信

このスキルを使用する場合

• 別の OpenClaw インスタンスにメッセージを送信する必要がある場合
• マシンを跨いでリモートでコマンドを実行する必要がある場合
• 複数の agent で協調してタスクを行う場合
• リポジトリ/ファイルをリモートインスタンスに同期する場合

通信方式の優先順位

信頼性とリアルタイム性の順に、以下の順で試行します。

1. sessions_send（最適、要設定）

直接 agent-to-agent メッセージ、リアルタイム双方向。

前提: 双方の設定で以下を有効にする必要があります。

// ~/.openclaw/openclaw.json
"tools": { "agentToAgent": { "enabled": true } }

用法:

sessions_send(sessionKey="agent:<target-agent>:main", message="...")

利点: リアルタイム、双方向、最も簡潔 欠点: デフォルトで無効、両端で有効にする必要あり

2. nodes.run（リモートコマンド実行）

ペアリング済みの node を介して、リモートマシン上でコマンドを実行します。

前提: ターゲットマシンが node としてペアリング済みで、かつオンラインであること（nodes status で確認）

用法:

nodes(action="run", node="<node-name>", command=["bash", "-c", "<command>"], commandTimeoutMs=30000)

注意事項:

• 環境変数がローカルと異なる可能性がある（例：プロキシ設定）
• env -u HTTP_PROXY -u HTTPS_PROXY で異なるプロキシを回避
• 複雑なコマンドはタイムアウトしやすいので、複数の小さなステップに分割
• gateway の応答が遅いとタイムアウトする（デフォルト 30s）。commandTimeoutMs を大きくすることで対応可能

典型的なシナリオ:

# ファイルが存在するか確認
nodes run: ["bash", "-c", "ls ~/target-dir 2>/dev/null && echo EXISTS || echo NOT_FOUND"]

# リポジトリを clone（プロキシの問題に注意）
nodes run: ["bash", "-c", "env -u HTTP_PROXY -u HTTPS_PROXY git clone https://github.com/user/repo.git ~/repo 2>&1"]

# ソフトリンクを作成
nodes run: ["bash", "-c", "ln -sfn /source/path /target/path && readlink /target/path"]

3. openclaw agent CLI（node を介してリモート gateway を呼び出す）

リモート node 上で CLI を使用して、ターゲットインスタンスにメッセージを注入します。

用法:

openclaw agent --session-id <session-id> -m '<message>' --json

注意: gateway が agent のターンを処理するのを待つ必要があり、タイムアウトしやすい（60-120s）。緊急性の低い通知に適しています。

4. ファイルレベル通信（最終手段）

ターゲットインスタンスの memory ファイルに直接書き込み、heartbeat が読み取るのを待ちます。

用法:

# nodes.run を使用してリモート memory ファイルに書き込む
cat >> <workspace>/memory/YYYY-MM-DD.md << 'EOF'
## 小aからの通知 (HH:MM)
<メッセージ内容>
EOF

利点: 必ず到達する、リアルタイム接続に依存しない 欠点: リアルタイムではない、heartbeat または新しい session を待つ必要がある

5. Telegram/メッセージチャネル（制限あり）

message ツールを使用して送信します。

制限: Telegram bot 間でメッセージを相互に送信することはできません（403 Forbidden）。bot → 人間のシナリオにのみ適用されます。

不可能な方式

実戦チェックリスト

1. nodes status — ターゲット node はオンラインですか？
2. ターゲットマシンにプロキシ/ネットワーク制限はありますか？
3. SSH key は設定されていますか？（git clone には HTTPS を使用する方が安定）
4. タイムアウト設定は十分ですか？
5. ソフトリンクのパスは正しいですか？

推奨アーキテクチャ

小a (Linux VPS)                    小m (Mac-Mini)
├── OpenClaw gateway               ├── OpenClaw gateway
├── ~/AGI-Super-Skills (git repo)  ├── ~/AGI-Super-Skills (git clone)
├── ~/clawd/skills/ (workspace)    ├── ~/.openclaw/workspace/skills → ~/AGI-Super-Skills/skills
│                                  │
├── nodes.run ──────────────────── ├── paired node (connected)
└── sessions_send ─────────────── └── agent-to-agent (要有効化)

ローカル Agent 連携（A2A）

⭐ 高管工作模式（コア原則）

あなたは高管であり、伝書鳩ではありません。

1. 派活即走 — sessions_send に timeoutSeconds を指定しない（または 1-5s に設定）、指示を送信したらすぐに次のことを行う
2. 不转发 — 従業員は自分でグループにメッセージを送信し、あなたは彼らの代わりに転送/返信しない
3. 不傻等 — 9 人の従業員が並行して作業する場合、結果を個別に待つ必要はない
4. 并行处理 — 派活後も Daniel の他の要求を処理し続ける
5. 只管结果 — 従業員がグループに報告するので、あなたは品質を審査するだけでよい

❌ 誤ったモード（秘書）:
   派活 → 返信を待つ → 返信を転送 → 次の派活

✅ 正しいモード（高管）:
   一括派活（待たない） → 他の作業をする → グループの報告を見る → 品質を審査

指令テンプレート

sessions_send(
  sessionKey="agent:<agentId>:telegram:group:YOUR_GROUP_CHAT_ID",
  message="【小a工作指令】<具体的なタスク>。結果は直接グループに送信してください。私に返信しないでください。",
  timeoutSeconds=5  // 最大5秒待つ。タイムアウトしても問題ない。バックグラウンドで継続される
)

sessions_send vs message の違い

sessionKey 形式（ローカル agent）

agent:<agentId>:telegram:group:<chatId>

⚠️ 注意：delivery エコーバックの問題

sessions_send のデフォルトの delivery: "announce" は、agent の返信を呼び出し元のセッションにエコーバックするため、メイン bot がグループ内で agent の返信を繰り返し送信することになります。agent 自身がすでに message tool を介してメッセージを送信しているため、エコーバックは不要です。

解決: agent 自身がグループにメッセージを送信するため、メイン bot は転送する必要はありません。agent の status=ok/timeout を確認するだけで十分です。

完整员工列表

注意：quant の accountId は xiaoq（xiaoquant ではない）です。

GLM-5 身份覆盖问题

GLM-5 には組み込みの "Kiro" 人格があり、SOUL.md の人格を上書きします。解決策：AGENTS.md の先頭に CRITICAL IDENTITY を追加して強制的に宣言します。

批量调度

for agent_id in ["ops", "code", "quant", "content", "data", "finance", "research", "market", "pm"]:
    sessions_send(
        sessionKey=f"agent:{agent_id}:telegram:group:YOUR_GROUP_CHAT_ID",
        message="あなたのタスク指示"
    )

触发词

• "小mにメッセージを送る"
• "別のインスタンスに通知する"
• "マシンを跨いで実行する"
• "リモートに同期する"
• "agent間通信"
• "インスタンス間通信"