技术澄清文档

Vibe API 客户反馈澄清说明

客户在使用过程中对平台模型质量提出疑问。经当日数小时排查、源码分析、修复和验证，所有问题均已定位根因并解决。

日期 2026-05-16 性质 技术澄清 + 问题修复 状态 已完成

问题概览

4
反馈问题类别
3h
排查修复耗时
+32
修复代码行数
100%
问题解决率
!
问题根因与状态
问题根因状态
图片识别失败底层代理 bug（tool_result 图片未提取）✓ 已修复
上下文频繁压缩未开启 [1m] + 第三方工具兼容性文档完善中
Ultra 渠道不稳定外部供应商封杀✓ 已降级保障
速度/质量差距非同等条件对比已澄清
缓存失效担忧平台天然无缓存机制已澄清

图片识别问题 — 排查与修复

问题现象

客户在第三方编程工具中通过 @ 文件引用方式发送截图，AI 反复读取 3 次均无法识别图片内容。

图片传输链路

① 客户端将图片编码为 base64，放入请求体
直接粘贴/拖入
message content → image block
✓ 一直正常
@ 文件引用
tool_result → image block
✓ 新版已修复
② API 请求传输（JSON + base64）
③ 底层代理提取 image block，转换为上游格式
④ 上游模型接收图片并理解

根因定位

⚠
extract_tool_result_content 函数缺陷

源码审查发现：该函数处理 tool_result 的 content 数组时，只提取了 type: "text" 的内容块，静默丢弃了 type: "image" 的内容块。

// 旧代码 — 只处理 text，丢弃 image fn extract_tool_result_content(content) { for item in arr { if let Some(text) = item.get("text") { // ← 只取 text parts.push(text); } // image 类型在此被静默忽略 } }
✓
修复方案 — 新增 extract_tool_result_images
// 新增函数 — 从 tool_result 中提取图片 fn extract_tool_result_images(content, images) { for item in arr { if item.type == "image" { let format = get_image_format(item.source.media_type); images.push(KiroImage::from_base64(format, item.source.data)); } } }

验证修复后的图片能力

✓
修复验证通过

修复后使用相同的 tool_result 图片请求测试，模型正确识别并详细描述了图片全部内容。同时验证了 Anthropic 原生格式下多图支持正常（实测 18 张 / 28MB 均可正确识别）。

建议用户使用 Alt+V 粘贴或 Anthropic 原生格式发送图片。

另：另有客户反馈通过 OpenAI 兼容格式发送多图时报错，该问题与本次反馈无关，已另行记录排查。

上下文窗口说明

i
关于 [1m] 上下文

[1m] 后缀是 Claude Code / Claude Desktop SDK 层面的兼容处理，告知客户端该模型支持 1M 上下文。直接调用 API 时该参数不生效，实际上下文窗口由上游分配决定。若未在官方客户端配置中指定，默认为 200K tokens。

日志实证 — 上下文满额提供

主站 2026-05-16 使用日志显示，单次请求输入 token 数稳定在 180K-360K 区间：

时间输入 tokens输出 tokens
01:08:35359,941125
01:08:29181,04488
01:08:22359,668111
01:07:38359,38058
01:07:25359,082155

远超客户怀疑的 16K/32K，证明上下文窗口未做任何人为限制。

压缩实测 — 从未自动触发

✓
长时间使用无压缩

我方使用同一套 API 进行日常开发，上下文累积到 400,000 - 500,000 tokens 的情况下，从未见自动压缩触发。如遇到频繁压缩，建议检查客户端配置文件，并将对应工具更新至最新版本。

?
关于"之前没内容"的上下文丢失

Claude API 是无状态的 — 每次请求都由客户端携带完整历史发送，服务端不维护对话状态。出现上下文丢失只能是客户端工具自身触发了压缩或丢弃了历史消息，与服务端无关。

渠道架构与定价

关于 Kiro 渠道

i
Kiro 并非先天不足

Kiro 是作为 Anthropic 股东的亚马逊（AWS）提供的货真价实的模型服务。虽然对比官方直连存在一定差距，但模型本身质量有保障。我方只是照原样转发请求，不做任何降级处理。

渠道分组

分组说明倍率
GPTGPT 最新文本模型 + gpt-image-2 生图0.6x
KiroAWS Kiro 渠道，支持 Opus 4.7 原生（算力紧张时响应可能较慢）0.5x
Ultra高价优质线路（近期不稳定），自动转发 Kiro0.5x
default默认分组，含 Claude、GPT、Gemini、国产模型、生图。Opus 4.7 默认转发到 4.6 以保障响应速度0.6x

由于上游当前 Opus 4.7 算力紧张，default 分组中的 4.7 请求默认转发到 4.6 以保障响应速度。如需原生 4.7，可选用 Kiro 分组。

定价逻辑

1:3
常规汇率（1元=3美元额度）
1:6
活动期间（1元=6美元额度）

推广期优惠策略，非以牺牲质量换取低价。平台自身也在使用同一套 API 进行日常开发。

技术架构澄清

请求链路

客户端
Claude Code
Claude Desktop
第三方工具
→
API 网关
粘性路由
令牌管理
格式兼容
→
底层代理
协议转换
负载均衡
故障转移

关键技术事实

维度客户担忧实际情况
切账号/缓存切账号导致缓存失效协议层不含 cache 字段，天然无缓存；网关层有粘性路由
上下文窗口可能被限制到 16K/32K日志证明 180K-360K 输入，满额提供
多模态处理图片数据丢失已定位为代理层 bug，已修复验证
响应速度比官方慢很多TTFT 与上下文大小正相关，180K+ 请求 6-15s 属正常

修复过程时间线

18:18
收到客户第一段录音反馈
18:38
收到第二段录音，问题升级
19:00
开始排查，对比官方账号与 Vibe API 图片识别差异
19:15
确认 @ 引用图片在 Vibe API 下失败，直接粘贴正常
19:30
开始审查底层代理源码（Rust，约 1200 行协议转换模块）
19:45
定位根因 — extract_tool_result_content 丢弃 image block
20:00
编写修复代码，新增 extract_tool_result_images 函数
20:10
提交修复，合并到主分支
20:15
触发 CI 构建（多架构 Docker 镜像：amd64 + arm64）
20:20
构建成功，拉取新镜像到测试服务器并重启
20:25
验证修复 — tool_result 图片识别恢复正常 ✓
20:30
执行多图压力测试（6-18 张，最大 28MB），全部通过
21:00
主站验证多图支持，确认无问题

结论

平台模型质量没有问题

图片识别 bug 属于代理层功能覆盖遗漏，已在当日完成从发现 → 定位 → 修复 → 构建 → 部署 → 验证的完整闭环。

上下文窗口满额提供（日志可证），渠道已做降级保障，定价为推广期优惠。感谢客户提出质疑，这直接帮助我们发现并修复了一个影响用户体验的技术问题。

建议

  1. 使用官方 Claude Code 或 Claude Desktop，而非开源或自研编程工具
  2. 某些第三方工具实则是本地 Claude Code 的进一步封装，推荐将本地 Claude Code 更新至最新版本 v2.1.143（截止 2026-05-16 22:08）
  3. 对比体验质量请在相同的官方客户端中进行，排除工具差异
  4. 1M 上下文需在官方客户端配置中指定 [1m] 后缀手动开启
  5. 多图场景建议使用 Anthropic 原生格式（/v1/messages）
  6. 图片发送建议使用 Alt+V 粘贴或直接拖入方式