场景描述：

在 CodeArts IDE「设置 → 模型 → 添加模型」中，分别以 OpenAI Chat Completions 格式 与 Anthropic Messages 格式 接入智谱 GLM-5.3（经公司内部 AI 网关 aigateway.venusgroup.com.cn 转发），两种协议均无法正常使用，链路在网关层即被阻断。同套 Key 与端点在 Claude Code、Zcode 中可正常调用，仅 CodeArts 不可用。

根因分析：

OpenAI 协议：结构性不兼容（无法通过配置规避） 网关规则将前缀 /ai/zhipu/openai 重写为 /v4/chat/completions，其余路径原样拼接；而 CodeArts 客户端固定在 Base URL 之后追加 /chat/completions

Anthropic 协议：链路畅通，受阻于 thinking 参数 端点 …/anthropic/v1/messages 调用通畅（已返回模型层错误码 1210，证明请求抵达模型服务）。 GLM-5.3 为"始终思考"型，Anthropic 协议下 thinking 字段仅接受 low / high / max，不接受 disabled。 CodeArts 在 Anthropic 协议下默认发送 thinking: disabled，且「添加模型」界面 无 thinking / reasoning 开关。 Claude Code / Zcode 在相同端点可用，说明二者对 thinking 参数做了默认值或显式配置，CodeArts 缺失该能力。

建议方案：

P0 — Anthropic 协议：开放 thinking 参数配置 在「添加模型 / 编辑模型」对话框新增可选字段 思考强度 (thinking)，枚举值：low / high / max / 不发送，默认"不发送"（兼容现有行为）。 或在「高级参数 / 自定义请求体参数」中开放键值对覆写，允许用户手动注入 "thinking": "low"。

P1 — Anthropic 协议：默认值容错 将默认发送的 thinking: disabled 改为 不下发 thinking 字段，交由模型侧按自身默认值处理；可避免对所有"始终思考型"模型的连带阻断。

P2 — OpenAI 协议：Base URL 拼接策略可配置 在「添加模型」中增加开关 「不再自动追加 /chat/completions」，由用户自行在 Base URL 中写完整路径，适配前缀重写型网关。 或在文档中明确 OpenAI Base URL 的拼接规则与示例，降低用户试错成本。

P3 — 错误反馈机制 404 等网关错误当前被 CodeArts 吞掉，仅显示"正在分析问题"，请将后端响应体直接透传到 UI，便于用户与网关方定位。 增加"请求超时"显式提示（当前会无限等待，用户体验差）。