工作台
工作台是跑测用的：验证一个模型在你的渠道上到底能不能用、返回什么。
只有两个 tab：
| tab | 作用 |
|---|---|
| 图像 | 图像生成与编辑 |
| 文字 | 流式对话 |
模型能力注册表曾经是这里的第三个 tab，已经移到模型页的「模型工具」里。 它描述的是模型清单里的协议数据，不是跑测；工作台只保留「图像 / 文字」。
一、图像 tab
自动模式：按参考图数量决定生成还是编辑
不需要手动选「生成」还是「编辑」——工作台按参考图数量解析：
| 参考图数量 | 实际请求 |
|---|---|
| 0 张 | 生成 |
| ≥ 1 张 | 编辑 |
协议按模型与渠道决定
| 情况 | 协议 |
|---|---|
| GPT-Image 生成 | JSON |
| GPT-Image 编辑（有参考图） | multipart |
| grok2api 编辑 | JSON |
这就是为什么「同一份输入换个模型就报 415」——上游对编辑端点的协议要求不同。
若上游的
/v1/images/edits只收 JSON，用 multipart 会直接415。这类「网关的 bug」多数其实是上游协议不匹配。
请求转编辑的 shim
路由上开启 image_edit_shim 后，带参考图的聊天请求会被转成图像编辑请求。继续复用正常转发的分组、计费与取消处理，响应头 X-Meta-Image-Shim 会标出实际使用的路径。
点名一个上游
工作台可以点名具体上游（member_id 或 channel_id），而不是走正常选型。
member_id 是精确的那个：一个统一别名会为每个上游原名挂一个成员，它们可能都在同一个渠道上，所以只给 channel_id 无法定位操作员选中的那一行。
点名失败不会被静默重定向：不可用的成员就是一个可见的失败，而不是把你的检查偷偷变成对另一个东西的测试。
二、文字 tab
流式对话跑测。它走的是与 /v1 相同的选型与转发路径，所以验证的是整条链路：选型、适配、转发。
鉴权用的是管理面 Bearer，不需要下游令牌。响应头里带诊断信息（如 X-Meta-Upstream-URL），用来回答「这次到底打到哪个端点」。
三、跑测与健康度、计费的关系
工作台的试调与健康探测都是合成调用，但它们对日志和计费的处理不同：
试调（Diagnostic） | 探测（Probe） | |
|---|---|---|
记 proxy_logs 行 | 是 | 否（结果记在 probe_results） |
| 成员冷却 / 渠道连续失败计数 | 豁免 | 豁免 |
| 计入用量与账单 | 否（没有下游令牌 id） | 否 |
| 消耗上游 token | 是 | 是 |
两个豁免的理由相同：探测失败是信息，不是故障。一个由操作员手动触发、或由调度器定时触发的检查失败，不应该把一个正常渠道推进冷却。
而试调刻意保留日志行——「我刚才那次试调到底做了什么」是日志页必须能回答的问题。如果试调不留痕迹，排障时就只能重复试一次。
两者都不计费（没有
DownstreamKeyID），所以成本为 0，但会消耗上游 token。