Technical reference
リッチ出力プロトコル
Assistant の出力は、いくつかの専用チャンネルを通じて配信/レンダリング指示を運びます。
- 添付ファイル配信用の構造化された
mediaUrl/mediaUrlsフィールド。 - 音声表示ヒント用の
[[audio_as_voice]]。 - 返信メタデータ用の
[[reply_to_current]]/[[reply_to:<id>]]。 - Control UI のリッチレンダリング用の
[embed ...]。
構造化メディアフィールドと [[...]] タグは配信メタデータです。[embed ...] は別個の Web 専用リッチレンダリング経路であり、メディアの別名ではありません。
メディア添付
リモート添付ファイルは公開 https: URL である必要があります。http:、ループバック、リンクローカル、プライベート、内部ホスト名は添付ファイル指示として拒否されます。サーバー側のメディア取得処理は、それに加えて独自のネットワークガードを適用します。
ローカル添付ファイルは、絶対パス、ワークスペース相対パス、またはホーム相対の ~/ パスを受け付けます。配信前には引き続き、エージェントのファイル読み取りポリシーとメディアタイプチェックを通過します。
プレーンな Markdown 画像構文 () はデフォルトではテキストのままです。Markdown 画像をメディア返信として扱いたいチャンネルは、送信アダプターでオプトインします。Telegram はこれを行うため、 はメディア添付になります。
ブロックストリーミングが有効な場合、メディアは構造化ペイロードフィールドに載せる必要があります。同じメディア URL がストリーミングブロック内に現れ、最終 assistant ペイロードにも再び現れた場合、OpenClaw はそれを 1 回だけ配信し、最終ペイロードから重複を取り除きます。
[embed ...]
[embed ...] は Control UI 向けの、エージェントが使う唯一のリッチレンダリング構文です。自己終了の例:
[embed ref="cv_123" title="Status" /]ルール:
[view ...]は新しい出力では無効です。- Embed ショートコードは assistant メッセージサーフェスでのみレンダリングされます。
- URL に裏付けられた embed のみレンダリングされます。
ref="..."またはurl="..."を使用してください。 - ブロック形式のインライン HTML embed ショートコードはレンダリングされません。
- Web UI は表示テキストからショートコードを取り除き、embed をインラインでレンダリングします。
保存されるレンダリング形状
正規化/保存された assistant コンテンツブロックは、構造化された canvas アイテムです。
{ "type": "canvas", "preview": { "kind": "canvas", "surface": "assistant_message", "render": "url", "viewId": "cv_123", "url": "/__openclaw__/canvas/documents/cv_123/index.html", "title": "Status", "preferredHeight": 320 }}present_view は認識されません。保存/レンダリングされるリッチブロックは常にこの canvas 形状を使用します。