|
|
e4111337cd
|
feat(gateway): /v1/messages 端到端 —— 内核不含任何 Anthropic 出站字段名
Phase 2 收尾。证明「对外协议由适配器决定、内核只调度」不是纸面主张：
Anthropic 客户端打 /v1/messages，拿到的是 Anthropic 形状。
- internal/gateway/messages.go：入向把 Anthropic 请求解析进统一格式
（content blocks 原样保留——只有适配器知道自己的上游接受哪种块类型；
system 支持字符串与 [{type:text,text}] 两种写法）。
调度/配额/AUTO 链/冷却/审计/插件 hook 全部复用 /v1/chat/completions
的同一条路径（serveUnified），差别只有两端线格式。
- internal/lua/adapters/anthropic.lua：新增 serialize_response /
serialize_open_preamble / serialize_chunk / serialize_close，
把统一格式译回 Anthropic Messages 形状（含 content 分块、
stop_reason 反向映射、input/output_tokens 改名）。
- 流式是 message_start → content_block_delta → message_delta →
message_stop；DoneMarker 为空所以内核**不会**擅自加 [DONE]。
内核出向零 Anthropic 字段名：解析是表驱动的，序列化属于适配器。
测试：
- messages_test.go 5 个端到端用例（真实 core+gateway + 只懂 Anthropic 的
假上游）：形状/stop_reason/块顺序/usage 命名、流式事件序列、入向校验、
鉴权、以及「未声明钩子时回落 OpenAI 兜底」。
- 修正两个 serializer 测试的前提断言（anthropic 现在确实声明了钩子，
这正是 Phase 2 的意图），并发测试改为按适配器各自校验形状。
golden 字节级未漂移；go test -tags luajit ./... 全绿。
|
2026-10-11 09:51:27 +08:00 |
|
|
|
438629256d
|
feat(ui): 生图二级页面 + 图像模型不再混进对话页
## ① 图像模型曾与对话模型不可区分
根因是结构性的，不是漏了个过滤：
Provider.Models() → []string ← 只有 ID，Kind 被丢掉
SourceStatus.Models → []string ← 扁平列表
于是 /api/status 给前端的 34 个模型（29 对话 + 5 图像）长得一模一样。选了
gpt-image-2 就 POST 到 /api/chat —— 那个端点服务不了图像模型，必然失败，
而且报错完全不提「这是图像模型」。
修法：新增 ModelKinds []ModelKindInfo（[{id,kind}]），纯增量、omitempty，
老 UI 不受影响；前端按 optgroup 分组，且这些 option 是 **disabled** 的。
分组还不够 —— 分组只是视觉分隔，operator 照样能选，选了照样失败。
disabled 的 option 会自解释（「请到生图页」），可选的只会失败。
★ 写这段时踩了一次 String.replace 的坑：`imgOpts.join("").replace(...)`
只替换**第一个**匹配，于是 6 个图像模型里只有第 1 个被禁用。浏览器实测
逐条读 e.disabled 才抓到（siliconflow 禁用了、vela 的 5 个没有）。
判据只看 value 里有没有 "image" 的话，第一次跑就会永远报警——那是判据
自己错了，比没判据更糟。
## ② 生图二级页面
侧栏新增 tab，与「对话」并列。网格展示 + 提示词输入 + 数量/尺寸，
调用 /v1/images/generations（不是 /api/chat）。
按钮显示已用秒数：实测该上游 15.7s~112.5s，波动 7.6 倍，不显示进度
看起来就像卡死了。
浏览器实测（几何测量，非仅 DOM 断言）：
tab-image 容器 986×523 visible
img-grid 840×374 visible
提示词输入框 634×64 visible
生图页 6 个模型，全部 kind=image，全部可选
对话页 6 个图像模型，全部 disabled；97 个对话模型全部可选
## ③ base_url 引导不足
文案直接给出截断位置和具体后果，而不是泛泛地说「填 URL」：
填主机地址，通常不带 /v1 —— 网关会自动拼接路径。但各家约定不同：
若填 https://x.com/v1，对话路径会正确，而图像生成会变成 /v1/v1/… 而 404。
不确定就用上方「自动探测模型」。
/v1/v1 不是假设：ImageURL 是 BaseURL + ImageEndpoint()，而图像默认路径
是**绝对**的 /v1/images/generations，chat 的默认是相对的 /chat/completions。
两者对「版本段归谁管」的假设相反。今天在 vela 上为此排查了两次。
## 判据
新增 6 个契约测试：
- 对话页必须读 model_kinds（不读就会退回扁平列表）
- 禁用图像模型不能用 joined-HTML 的 String.replace（只改第一个）
- 生图页存在且注册进 TABS（漏了则 pane 永不可见，症状是「页面空白」）
- sendImage 必须打 /v1/images/generations
- urlHint 必须同时提到 /v1 和 404
- TestImageEndpointComposesUnderRealConditions 用真实形态验证：
相对路径拼出 /v1/images/generations 得 200，默认路径拼出 /v1/v1/… 得 404
|
2026-10-06 15:02:42 +08:00 |
|
