OpenClawエージェントリレープラグインでマルチエージェントTelegram送信を修正

開発者がopenclaw-agent-relayをリリースしました。このプラグインは、マルチエージェント設定におけるsessions_sendがTelegramユーザーに応答を配信できない問題を解決します。

sessions_sendの問題点

エージェント間でメッセージを渡すためにsessions_sendを使用すると、ターゲットエージェントの応答はユーザーに届かず、channel=webchat（内部チャネル）に送信されてしまいます。これは、sessions_sendがセッションと会話履歴を保持するものの、配信を適切に処理しないために発生します。この問題は、NOT_PLANNEDとしてマークされたクローズドチケット#13374で文書化されています。さらに、セッションの配信コンテキストを破損させ、telegramからwebchatに恒久的に切り替えてしまう可能性もあります（#44153および#31671を参照）。

既存の回避策とその限界

開発者は主に2つのアプローチを試みてきました：

明示的なメッセージツールの使用：ターゲットエージェントがchannel: "telegram"と明示的なto/threadIdでmessageを呼び出し、ANNOUNCE_SKIPを返します。これは#47971および#28603で文書化されています。問題点としては、すべてのsessions_sendペイロードに配信指示を埋め込む必要があること、特に長いセッションではエージェントが回避策を使用するのを忘れがちなことが挙げられます。
アナウンスステップへの依存：timeout=0を使用してアナウンスステップを取得し、エージェントがユーザー向けの応答を記述できるようにします。しかし、モデルはコンテンツを記述する代わりにANNOUNCE_SKIPを返す傾向があります（#43295）。アナウンス配信にも問題があります：TelegramトピックのthreadIdが失われる（#47971、#45878）、マルチチャネル設定ではサイレントに失敗する（#47524）、ANNOUNCE_SKIPテキストがユーザーに漏洩する可能性がある（#45084）などです。

解決策：openclaw-agent-relay

このプラグインは、sessions_sendとアナウンスの両方を完全に回避します。サブエージェントが内部で使用するのと同じゲートウェイWebSocket RPC（callGateway({ method: "agent" })）を使用して、既存のセッションでdeliver: trueでエージェントターンをトリガーします。エージェントは特別な指示、ANNOUNCE_SKIP、またはメッセージツールの回避策なしで通常通り応答し、応答は直接Telegramに送信されます。

使用方法

2つの方法が利用可能です：

ツールwake_agent：任意のエージェントが呼び出して、同じセッション内の別のエージェントを起動できます：
wake_agent({ sessionKey: "agent:my-agent:telegram:direct:123456", message: "Hey, remind the client about the contract" })

HTTP POST /notify：cronジョブ、スクリプト、または外部トリガー用：

curl -X POST http://127.0.0.1:18790/notify \
-H "Authorization: Bearer your-secret-token" \
-H "Content-Type: application/json" \
-d '{"sessionKey":"agent:my-agent:telegram:direct:123456", "message":"Reminder: client asked for the contract"}'