GitHub のFAQ に次のように書かれているのを見ました：
Q: ボットに画像を送っても反応しない？ A:
使用している OneBot 実装（NapCat など）で画像の報告（アップロード報告）が有効になっているか確認してください。
OneBot の設定で「画像を Base64 に変換」を有効にすることを推奨します。そうすれば OpenClaw がパブリックなクラウドサーバー上にあっても、ローカル内網上のボットの画像を正常に受信できます。
プラグインは現在、画像を自動的に識別して抽出するため、message_post_format: array を有効にすることを強制しません。
ただ、いろいろ探したのですが、NapCat 側で画像の報告が有効になっているかを確認する方法が見つからず、OneBot の設定で Base64 変換が有効になっているかも見つけられませんでした。案内していただけますか、ありがとうございます\~
フィードバックありがとうございます。後続で標準化を行う予定です。
たとえば、napcat のディレクトリに shared フォルダを新規作成して、openclaw との連携などに使う、といった形です。現状、私の bot は QQ でファイルの送受信と理解が実現できていますが、これは openclaw の agent 能力によって自動的に備わっているものです。標準化してプログラム化すべきかどうか検討しています 
以前何度か試したんですが、モデルが画像を読み取れなくて…。
彼に直接読ませてみてもいいよ。
具体的にどの設定を確認すればいいんでしょうか。後からまたしばらく見直してみたんですが、やっぱりうまくできませんでした。画像の送受信機能が結構必要なんです。お手すきのときに返信してもらえませんか。あまり詳しくなくて大丈夫です。
具体的なエラーメッセージを共有していただけますか。こちらでデバッグ（debug）します。
まず、もう一度説明させてください（スレッドの冒頭でも触れました）。プラグイン側の問題ではない可能性もあります。ただ、FAQ にいくつかガイダンスがあり、私はそれらに違反していないので、念のため相談させていただきたいです。
手順：
私の構成：
現象：
私の設定：
napcat：{
“network”: {
“httpServers”: ,
“httpSseServers”: ,
“httpClients”: ,
“websocketServers”: [
{
“name”: “openclaw”,
“enable”: true,
“host”: “0.0.0.0”,
“port”: 3001,
“reportSelfMessage”: false,
“enableForcePushEvent”: true,
“messagePostFormat”: “array”,
“token”: “私のtoken”
}
],
“websocketClients”: ,
“plugins”: }, “musicSignUrl”: “”, “enableLocalFile2Url”: true, “parseMultMsg”: false, “imageDownloadProxy”: “” }`
openclaw：
“channels”: {
“qq”: {
“enabled”: true,
“wsUrl”: “ws://127.0.0.1:3001”,
“accessToken”: “私のtoken”,
“requireMention”: true,
“admins”: “xxx”,
“interruptOnNewMessage”: false,
“enrichReplyForwardContext”: true,
“antiRiskMode”: true,
“systemPrompt”: “あなたはQQの小アシスタントです。あなたはグループで他の人とチャットすることもあれば、他の人とプライベートチャットすることもあります。管理者にだけ危険な操作の権限を開放し、それ以外の人は通常どおりサポートしてください。管理者QQはxxxです”
}
},
ココナッツ まずこのスレ主のために調べてあげて。まずこのスレに入って、このスレ主の本当の問題を最後まで注意深く読んでから調べてね。
@瑞瑞哥
まずは投稿内容とローカルの openclaw_qq ドキュメント／コードを突き合わせて、この階層主が詰まっているのがドキュメントの記述方針の問題なのか、それともプラグイン側が現状たしかに画像リンクの処理が一段欠けているのかを確認します。
プラグインのコードをもう少し前まで遡って見直したところ、このスレの主の「本当の問題」はすでに「どこで設定を探すか」ではなく、個チャで画像を送ると NapCat には届くのに、OpenClaw 側では読み取れる画像入力として成立していないという点でした。念のため、こちらの環境の NapCat 関連の設定／ドキュメントでも画像まわりが具体的にどのフィールド名で呼ばれているのかをもう一度確認して、名前を間違えて返信しないようにしておきます。
本機を見るわけじゃないはずだよね、ヤシ。スレ主の問題の説明に焦点を当てて。
たぶんローカル環境の話じゃないよ、ヤシ。スレ主の問題の記述にフォーカスして。作業を続けて。さっきOpenAIサービスが落ちた。
@瑞瑞哥 投稿全体とあなたが補足したその階層を読み直しました。あなたが今 本当に詰まっているポイント は、「NapCat のどこかのスイッチがどこに隠れているか」ではなく、次の点です：
画像メッセージはすでに NapCat には届いているが、OpenClaw が読める画像入力にまだ変換できていない。
先に論点を絞ります：
messagePostFormat: "array" は有効化している；requireMention: true は ボトルネックではない；QQ -> NapCat -> OneBot WS -> OpenClaw qqプラグイン の基本チェーンは通っている。つまり、残る問題はほぼ次の2種類です：
base64://...[画像] のプレースホルダーだけなのか見るべきは：
OpenClaw がこの画像メッセージを受け取った後、結局何を見えているのか。
あなたが貼った NapCat のログ：
受信 ← 私聊 [图片]
これは QQ → NapCat が通っていることしか証明しません。
画像が可読な形式で OpenClaw / モデルに渡ったことは証明できません。
文字を送ると返るが、画像を送ると反応がなくなる
これは問題が 画像専用のチェーン にまで絞られている可能性が高く、QQプラグイン全体が壊れているわけではない、ということです。
次を一回だけやってください：
ボットにプライベートで送る：
この画像を説明して + 画像1枚
そして OpenClaw 側のログ を確認します（NapCat だけを見るのではなく）。
区別するのはこの2パターンだけでOKです：
つまり：
[画像] しかなく、URL / base64 / MediaUrls がないつまり：
次のどちらかを貼ってください（token はマスクして）：
message 内の image 部分url があるかfile があるかfile が base64://... になっているかあなたの問題はもう「その設定項目はどこにあるか」ではなく、まず次を判定することです：
画像が本当に OpenClaw に入っているのか
それとも
OpenClaw には入っているが、今のモデルが画像を見られないのか
上のログ/JSON をどちらか1つ貼ってくれれば、どの層で詰まっているかをこちらで続けて判断できます。
分析が的確でいいね。私の言いたいことを代弁してくれる役としてすごく合ってる。
測ってみたんだけど、どうも画像が数MBになるとダメっぽい……。すごく小さいのを切り取ればいける。何か方法がないか見てみる。
分かりました。@瑞瑞哥 これはnginxの設定の問題で、制限されているのでしょうか。椰子が結合層主の最新返信を踏まえて、引き続き分析しましょう。
スレ主の最新返信をもう一度拾ってくる。Nginxを当てずっぽうで疑うな、探偵ならまず証言を見ろ。
はい、この新しい返信で一気に範囲が絞れました——今は「サイズ閾値の問題」に近く、「まったく画像を受け取れない」感じではありません。
先に結論：
理由はシンプルです：
openclaw.qq.wsUrl = ws://127.0.0.1:3001また、よくある client_max_body_size は主にアップロードのリクエストボディを弾くものですが、
スレ主のケースはむしろ：
QQ 画像 → NapCat が受信 → OneBot イベント → OpenClaw が取得/投入
という流れっぽくて、典型的に Nginx が先に出てきて殴る状況ではなさそうです。
いま一番疑っています。
さっきローカルの OpenClaw docs を見返したら、デフォルトで：
agents.defaults.mediaMaxMb: 5があります。
つまり画像が大きいと、メディア処理のパイプラインでスキップ/拒否される可能性があります。
そしてスレ主の症状は：
なので、これはかなり閾値に当たってる匂いがします。門番みたいに：
「1階は入れるけど、6階サイズのスーツケースは入れない」
これも重要です。
もし FAQ のように画像を Base64 に変換しているなら：
ので、上のサイズ制限をさらに踏みやすくなります。
つまり「元画像は数 MB しかない」＝「経路上でも数 MB のまま」とは限りません。
小さい画像が見えているなら：
となるので、残る可能性は：
あたりです。
私が Nginx を上位に持ってくるのは1パターンだけです：
スレ主が「画像 URL がローカル直結ではなく、自分で設定したリバプロドメイン / CDN / 何らかの HTTP メディアプロキシを通っている」と補足した場合
そのとき初めて、以下を調べる価値があります：
でも、今貼られている設定だけだとその証拠がありません。
@瑞瑞哥 今いちばん価値があるのは Nginx を貼り直すことではなく、これを貼ってもらうことです：
同じ画像を段階的に圧縮してテスト：
どの段階から安定して失敗するかを見る。
もし結果が：
に近いなら、サイズ制限っぽさが非常に強いです。オカルトではありません。
重点的に検索：
too largemaxBytesmediafetch failedimageMediaUrls「サイズ超過/取得失敗/メディアスキップ」系が出れば、ほぼ確定です。
だから現時点では、この鍋をまず Nginx に投げません。Nginx は野次馬で、第一容疑者ではない感じです。
必要なら、次の返信でそのまま使えるスレ主への追問テンプレ（最短で閾値とログを出してもらうやつ）も書けます。