[Bug]: view_image 工具结果的图片被序列化进 tool 消息，OpenAI 兼容端点（z-ai/GLM）400 且会话持续失败

[Arborsm]

Bug 描述

通过 OpenAI 兼容端点（如 z-ai / GLM-5.3-flash）使用带视觉能力的模型时，agent 一旦调用 view_image，该轮以及之后所有轮次的请求都会被服务商拒绝：

AI provider error: OpenAI Streaming API client error 400 Bad Request:
{"error":{"message":"Invalid input","type":"invalid_request_error","param":"messages.102.content"}}

会话从此"中毒"——图片 tool result 留在历史里，每次请求重发都会 400，用户发"继续"也失败。

根因

BitFun 内部消息模型（Anthropic 语义）允许 tool result 携带图片附件（imageAttachments），但 OpenAI 适配器在序列化时把 image_url part 原样塞进了 role: "tool" 消息的 content 数组。严格的 OpenAI 兼容端点（z-ai/GLM 实测）只允许图片出现在 user 消息中，tool 消息的 content 必须是字符串，因此以 invalid_request_error 拒绝，param 精确指向该 tool 消息的 content。

最小复现（直连 z-ai 端点，1x1 PNG data URL）

请求形态	结果
图片放 user 消息 content 数组（标准 vision 格式）	✅ 200，模型正确描述图片内容
图片 part 放 tool 消息 content 数组（BitFun 当前做法）	❌ 400 {"message":"Invalid input","param":"messages.2.content"}
同样的 tool 消息，content 为纯字符串	✅ 200

模型配置里 capabilities 包含 image_understanding，所以 BitFun 认为可以发图——问题不在 capability 判断，而在 tool 消息的序列化位置。

期望行为

OpenAI 适配器遇到带图片附件的 tool result 时应做降级转换，例如：

1. 把图片移到紧随其后的合成 user 消息（带 "[tool view_image returned an image]" 之类的说明文本）；或
2. 对不支持 tool 图片的端点，将图片替换为文本占位（如 [image: path, 1680x1000 png]）。

方案 1 保留视觉信息，对 agent 自查截图的工作流（view_image 的核心用途）更友好。

环境

• BitFun desktop 0.2.19, Windows 11
• Provider: OpenAI 兼容端点转发 z-ai/glm-5.3-flash（模型本身视觉能力正常，见复现表第一行）