okooooooo/team-api
1
0 Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity
585 Commits 1 Branch 0 Tags
97da0a70aa4a472eb7002dc50e7da2ff1be48db2
Commit Graph
324 Commits
Author SHA1 Message Date
qian 97da0a70aa feat(relay):添加OpenAI标准视频端点 2026-09-12 17:04:36 +08:00
Qian 1f2046d0fd 重构协议转换，实现更完整的转换功能 (#26) 
* fix(relay):转换层路径缺失

* refactor(relay):移除coze和dify支持

* fix(relay): 流式错误传播三态返回与安全拦截分类

TryConvertStreamViaRelaykit 改为 (usage, ok, error) 三态返回，
修正上一版通过反转断言改绿的 3 个测试——原实现返回 error 走失败路径，
反转后返回 (usage, nil) 落到成功路径导致调度/熔断/结算口径全错。

- stream.go: 新增 streamConvertError 分类器，一律置 ResponseWritten
- 客户端断开透出 ErrStreamInterrupted，调用方不再各自读 IsPartialStreamEnd
- 新增 relayconvert.ErrContentBlocked 哨兵，6 处 Gemini 出站安全拦截 wrap
- response.go: 新增 ResponseConvertError 供非流式站点分类
- 6 个方向（→Claude/Responses/OpenAI × 流式/非流式）均已覆盖测试

修前：安全拦截映射 502 → 正常渠道因用户违规提示词被扣健康分/熔断
修后：识别哨兵映射 4xx 请求类错误


* fix(relay): 修复 Anthropic 兼容端点渠道的 Claude 入站断链

ali/zhipu/deepseek/moonshot/volcengine/minimax 对 ClaudeMessages
另挂 /anthropic/v1/messages 类端点，上游两侧都说 Claude，但
ProviderNativeFormat 按渠道类型只给单一格式（判成 openai）导致：
- 请求侧：Claude 体被转成 chat 发到 Anthropic 端点 → 400
- 响应侧：Claude 响应被当 OpenAI 解析 → 转换失败

新增 constant.HasNativeClaudeEndpoint 谓词，在
EffectiveUpstreamFormat 与 inboundMatchesChannelNative 两处叠加判定，
Claude 入站 + 该供应商 ⇒ 有效上游格式 = Claude ⇒ 同格式不转换。

登记判据：GetRequestURL 对 ClaudeMessages 返回与 chat 不同的地址。
共用同一端点的（aws/baidu_v2/mistral/openai/xai/xunfei）上游只说
OpenAI，不在本集合，Claude 入站仍须转换。


* fix(relay): relaykit 路径接回 5 家私有请求后处理

relaykit 矩阵按格式裁决、与供应商无关，命中后 adaptor.ConvertRequest
整个不再被调用。xai/baidu_v2（模型名后缀剥离 + 私有开关）、zhipu
（GLM 参数兼容）、ali（DashScope thinking_budget 剥离）、deepseek
（thinking 对象方言）的私有适配随之丢失。

最实际的是模型名：未配映射时 UpstreamModel = row.ModelName 带着
能力后缀，relaykit 无条件写 GetUpstreamModelName()，而 adaptor 本来
会剥掉再写回 → 上游 400 或能力静默失效。

新增可选能力接口 RequestPostProcessor，handler.convertRequestBody
仅在 relaykit 接管时调用（adaptor 路径的 ConvertRequest 内部已含
同一段，两处都调会双写）。5 家各把尾段抽成 postProcessRequest 与钩子
共用。新增接口断言与功能测试。


* docs(relaykit): 更新工作状态与回归记录

- §5.1/§5.2 已完成，新增 §3.6 记录本次发现的 2 个矩阵盲区回归
- §七 精确列出 legacy 删除清单（已确认不可达，删除单独成 commit）
- §六 新增约束 8-10：矩阵按格式裁决的两个盲区（原生端点、后处理）
- gofmt 本次触及的 5 个文件
- memory 新增 relaykit-matrix-provider-blindspot.md 根因记录


* refactor(relay): 删除被 relaykit 取代的 legacy 协议转换代码

净删约 6400 行。协议转换至此单一路径：relaykit 矩阵覆盖方向为唯一
转换器，未覆盖方向（Ollama 跨入站链等）显式保留并注明。

- 删 claude/gemini converter.go 整文件（o2c/o2g 请求侧双实现）
- 删 openai/converter.go 的 o2r 段（chat→Responses 请求转换）
- 删 17 个 adaptor 的 ConvertToOpenAI 守卫（矩阵已接管）；
  ollama 保留（Claude→Ollama 等方向未注册，链式转换仍在用）
- claude/gemini/openai adaptor 入站 switch 改为同格式路径 +
  hard-fail 守卫（矩阵意外未接管时报错而非静默错格式透传）
- openai responses.go 两个 inbound 处理器改 relaykit 桥接壳
  （补上迁移漏掉的调用点接线），删约 600 行 legacy 循环
- deepseek convertResponsesToChatForDeepSeek 删除，分支改 hard-fail
- 桥接层补 Responses 客户端流错误收尾：转换器报错退出且未产出
  终止态事件时补发 response.failed（防 codex 等客户端挂起）；
  已自行收尾的（Gemini SAFETY completed 拒答）不追加第二终止事件

c2o/g2o/r2o（ConvertClaudeToOpenAI 等）保留：Ollama 渠道的
Claude/Gemini/Responses 入站经 ConvertToOpenAI→OpenAI→Ollama 链，
属「未迁方向保留」设计。

测试：新增删除项的替代断言（hard-fail 守卫、PostProcess 钩子、
response.failed 收尾）；删测已删函数的用例。全仓 build/vet 通过，
relaykit 全绿，relay 侧仅剩 helper 既有失败。

* refactor(relay): 移除模型名能力后缀机制（虚拟模型语法）

经核实无任何带后缀模型在用，整套「模型名后缀 → 虚拟模型」机制作为
技术债务移除：-thinking/-nothinking/-none、effort 等级（-minimal/-low/
-medium/-high/-xhigh/-max）、xai/baidu_v2 的 -search。思考/搜索能力
此后一律由客户端请求参数表达（thinking 对象、reasoning_effort、
reasoning.effort），网关只做协议转换不做能力注入。

宿主侧：
- 删 helper/thinking.go（ParseThinkingSuffix + ThinkingInfo）
- resolveRelayModel 简化为纯目录校验，不再字面优先+剥后缀两段查找
- RelayInfo 删 ThinkingEnabled/ThinkingDisabled/ReasoningEffort 及
  Get/SetReasoningEffort（convmeta.Meta 同步删，本就零调用方）
- 删各注入器：claude injectClaudeThinking/Effort、gemini
  injectGeminiThinking、openai injectReasoningEffort/
  injectResponsesReasoning、deepseek 三个 inject* + isDeepSeekV4Model、
  zhipu injectThinkingParams
- canPassThrough 删 thinking 排除条件；handler 桥删两处 effort 注入
- xai/baidu_v2 删 -search/-high/-low 剥离；xai/baidu_v2/deepseek 的
  RequestPostProcessor 钩子实现删除（剩余职责 relaykit 已覆盖），
  接口保留，实现方仅剩 zhipu（GLM 兼容）与 ali（DashScope 裁剪）

relaykit 侧：
- 删 internal/shared/thinking_adapter.go 与 reasoning/ 包
- convmeta.Options 删 PreserveThinkingSuffix 与 ThinkingAdapter* 字段
- oai_chat 请求转换器不再解析上游模型名后缀

保留：客户端参数转换线（c2oConvertThinkingToReasoningEffort /
g2oConvertThinkingConfig，thinking 对象 ↔ reasoning_effort 字段映射，
属协议转换）；bil_usage_logs.reasoning_effort 列（此后恒空）；
BaseModelName 字段（responses 路由记录在用）。

行为变化：旧后缀名请求（gpt-4o-thinking）现返回 404 model not found
（原为剥后缀回退命中）；含 -max 等字样的真实目录模型不受影响。

全仓 build/vet 通过，relaykit 全绿，relay 侧仅剩 helper 既有失败。

* fix(dispatch): 探测失败不再衰减健康 EWMA，修复 4 处测试失效

processOutcome 之前忽略 Outcome.Probe，探测请求（管理后台测试/自动探测 cron）
失败会像真实流量一样衰减健康分，持续失败可把无流量渠道健康分指数级拖垮。
现探测失败跳过健康 EWMA 写入（探测成功仍照常记录），熔断窗口计数不受影响。

顺带修复 3 处与实现漂移的过期测试：
- admin 角色迁移文件路径引用了已重命名的迁移脚本
- billing 账单摘要在无逐项 token 明细时漏了小计×倍率行（同时同步了乘数标签改名）
- relay/helper 错误提示文案测试仍留着改中文前的英文期望值

* refactor(relay):补充gemini和claude协议的转换

* fix(relay):修复gemini转换问题

* fix(relay):优化工具转换

* feat(test):添加测试用例

* feat(test):添加测试用例

* feat(relay):补充转换矩阵

* feat(relay):补充协议转换测试

* fix(relay):修复vertex缺陷

* feat(relay):补充协议间的工具转换

* feat(relay):添加语料采集功能

* fix(relay):修复claude输出协议转换问题

* fix(relay):修复codex请求claude模型无法使用搜索工具问题

* fix(relay):修复codex请求gemini模型无法使用搜索工具问题

* refactor(relay):修改真实语料处理逻辑，将真实响应数据移出仓库

* fix(relay):补充手写测试数据集
 2026-09-12 16:08:05 +08:00
qian a266d3cd83 feat(pay):添加统一支付配置菜单 2026-09-09 23:47:18 +08:00
chengqian 755868a331 feat(relay):新增token估算接口 2026-09-09 14:33:59 +08:00
qian 9e8293cf05 fix(ticket):工单只显示管理员显示名，不显示用户名 2026-09-07 22:18:27 +08:00
qian 80b4754208 fix(model):修复模型结构体未设置导致查询出错 2026-09-06 23:02:34 +08:00
qian b267119f12 fix(setting):修复支付配置保存失败的问题 2026-09-05 13:45:12 +08:00
qian 37803ceeed fix(auth):修复重置密码没有清除状态的问题 2026-09-05 10:08:26 +08:00
qian d896441836 fix(permissions):修复成员可查看关于用量的问题 2026-09-05 09:34:43 +08:00
qian 72fb0318f5 fix(permissions):修复租户端的权限漏洞 2026-09-05 00:31:14 +08:00
qian a247b3a53b feat(notify):添加通知显示 2026-09-04 01:03:53 +08:00
chengqian 644097fa0c fix(permissions):修复用户端权限漏洞 2026-09-03 15:44:37 +08:00
chengqian e703c9a044 fix(permissions):修复后端权限漏洞 2026-09-03 15:05:31 +08:00
qian 9d61abda86 fix(permissions):修复权限相关问题 2026-09-03 00:46:57 +08:00
qian 8d4e8744d5 fix(help):修复帮助文档问题 2026-09-02 23:56:49 +08:00
qian 0a1acd8e95 improve(ui):优化租户端用量显示 2026-09-02 23:43:41 +08:00
qian 65de0783f2 fix(ticket):修复工单显示问题 2026-09-02 23:05:15 +08:00
chengqian 652c6903f6 fix(permissions):修复提权漏洞 2026-09-02 19:43:42 +08:00
chengqian ec182c5a71 chore(doc):完善文档描述 2026-09-02 17:41:10 +08:00
qian 4d0e2901d9 fix(setting):渠道代理改为系统配置而不是配置文件 2026-09-01 23:34:14 +08:00
qian 3c749c6c0a fix(setting):移除设置中多个未生效设置项 2026-09-01 23:11:31 +08:00
qian e800cd4b05 fix(setting):移除安全配置中的无用配置 2026-09-01 21:34:45 +08:00
qian df78724773 fix(setting):修复注册限流不生效的问题 2026-09-01 21:20:22 +08:00
chengqian fdd1bc7653 feat(role):权限管理功能 2026-09-01 20:32:35 +08:00
chengqian f129221942 fix(billing):修复货币符号固定未更随系统设置变化问题 2026-09-01 16:20:49 +08:00
chengqian 0372d4fff5 feat(role):新增用户权限功能 2026-09-01 15:47:10 +08:00
chengqian 0ea011616f fix(monitor):修复监控数据未及时更新的问题 2026-09-01 00:50:56 +08:00
qian 15ec726f68 improve(log):优化渠道日志揭露，方便排查问题 2026-09-01 00:11:32 +08:00
qian 211148a0af improve(workbench):优化工作台页面 2026-08-31 23:29:21 +08:00
qian a2beb8230a fix(relay):修复转换层层数据断层导致连接中断没有正确计费的问题 2026-08-31 22:19:35 +08:00
chengqian bdfd1b6567 feat(ui):管理后台新增工作台，可便捷查看告警信息 2026-08-31 20:07:15 +08:00
chengqian f679105430 refactor(ui):优化用户端的仪表盘 2026-08-31 20:07:14 +08:00
chengqian 5917f0a9b1 refactor(ui):优化用户端的仪表盘 2026-08-31 20:07:14 +08:00
chengqian 8c8b63da77 fix(email):修复邮件相关功能 2026-08-31 16:21:20 +08:00
chengqian 0fd2e737ef Merge remote-tracking branch 'origin/dev' into dev 2026-08-31 15:59:55 +08:00
chengqian 1f07fae1c2 fix(email):修复邮件相关功能 2026-08-31 15:59:22 +08:00
qian cd019cf817 feat(billing):新增本位币设置，初始化时可选择全局货币单位，一旦设置就不能修改 2026-08-29 10:22:47 +08:00
qian 3bf1b4ca75 fix(channel):修复模型性能中详情的tps错误 2026-08-29 08:44:12 +08:00
qian 0964d9014b fix(update):修复在线更新检测后缓存问题导致无法正常更新 2026-08-28 22:23:00 +08:00
chengqian 958f6c4d75 type(relay):修正测试代码里面的函数名为纯英文 2026-08-28 17:40:24 +08:00
chengqian 96bcd3e46f fix(channel):修复渠道更新key后无法立即生效 2026-08-28 16:55:28 +08:00
qian e8dfe9499d improve(log):优化日志输出 2026-08-27 23:36:20 +08:00
qian 8f42091cef fix(channel):修复渠道查询报错 2026-08-27 23:31:59 +08:00
qian daffb7f947 fix(channel):修复渠道监控中TPS计算错误 2026-08-27 23:16:06 +08:00
chengqian ce59b12622 fix(cron): 兜底任务 panic，并支持自定义渠道探测间隔 
panic 兜底：cron.New() 默认不带 Recover 链，robfig/cron v3 的 startJob 是裸的
`go func(){ j.Run() }()`——任意一个定时任务 panic 会直接崩掉整个进程，而不只是让该
任务失败。在 runJobInternal 内兜住并转成普通 error，进程存活且失败经 recordExecution
落进 sys_cron_jobs，管理后台可见，不再表现为一次无声重启。堆栈只进日志，避免撑爆
last_error 的展示。渠道自动探测再加一层 per-channel recover：单个渠道 panic 只跳过
自己，本轮剩余渠道继续（否则整轮被中断）。

探测间隔可配置：新增 channel_auto_test_interval_minutes（默认 5，范围 1-1440），
原先固定 */5 * * * *。用 @every 而非 */N——*/N 只在 N<60 时有意义，*/90 会被静默
解析成 */30，给出与配置不符的频率；@every 还让各实例按启动时刻错开，不会所有实例
卡在同一分钟同时探测。

配套两处基础能力：CronScheduler 记录 cron.EntryID 并新增 Reschedule（先加新条目、
成功后再摘旧条目，非法表达式时保持原调度，避免一次错配把任务彻底摘出调度器）；
ConfigService 新增 OnSettingsChanged 回调钩子，挂在既有的 settings:changed 订阅上，
使配置变更能触发动作而不只是让缓存失效，多实例各自重排、无需重启。
 2026-08-27 21:59:45 +08:00
chengqian dd02bf4ac3 feat(admin): 渠道列表/详情展示最差模型，暴露被均值摊薄的单模型故障 
渠道健康分是各模型 succ_ewma 的均值，单个模型全挂会被其余健康模型摊薄——10 个
健康模型 + 1 个挂掉仍能算出 90 分绿灯，而这恰是模型级熔断要隔离的典型场景。
补一个最差项：ChannelRuntimeStates 遍历目录快照时顺带取每个渠道 succ_ewma 最小的
模型，按 succ^α×100 折算为与渠道分同口径的健康分。

不落库、不加列：catalog 内存快照已逐 (渠道,模型) 持有 SuccEwma，遍历它即可，零额外
I/O；数据是调度器同源的 5 秒刷新值，比 5 分钟落盘快照更新鲜。取最小值也天然免疫冷
模型问题——无上报的模型读作满分 1.0，永远不会被选为最差项。

byModel 是 map，遍历顺序随机，同分时按模型名取小者打破平局，否则全部模型满分时
每次请求返回的模型名都会跳变。

前端：列表页健康度列在最差项低于 80（健康档）时补一行「⚠ 模型名 分数」，详情页
健康度字段同理；disabled / testing 渠道不在目录快照，不展示。
 2026-08-27 21:59:45 +08:00
chengqian faddc45978 chore(dao): gf gen dao 同步 multiplier 列注释 
迁移 000018 执行后重跑，mdl_tenant_models.multiplier 的注释与库一致。
纯注释变更，无字段与类型改动；本轮全表重生成只有该表有差异。
 2026-08-27 21:59:45 +08:00
chengqian d12ea0566d chore(dao): gf gen dao 刷新健康度两张表的生成注释 
迁移 000017 执行后重跑 gf gen dao，把修正后的列注释同步进 entity/do/dao。
纯注释变更，无字段与类型改动——entity 中 success_rate / latency_ms /
health_score 仍为 float64（非金额小数，符合 float64/decimal 分类规范）。

此前 entity 里 health_score 的注释写着已废止的四因子加权公式，是全链路唯一会
主动误导后来人的地方，至此与实现对齐。
 2026-08-27 21:59:44 +08:00
chengqian 1f3489c37d docs(dispatch): 修正健康度列注释与过时文档，清理两个僵尸字段 
chn_health_scores 的列注释仍写着健康体系重写前的加权公式（成功率×0.40 + 延迟分×0.25
+ 稳定性×0.20 + 连续失败分×0.15），而实际实现是 avg(succ_ewma)^α×100。注释经
gf gen dao 流入 entity/do/dao，是全链路唯一会主动误导后来人的地方。迁移 000017 改写
health_score / success_rate / latency_ms / calculated_at 的 COMMENT 为实际口径。

stability_score / consecutive_failures 自重写后从未被更新，只在建渠道和重置健康度时
写入常量，趋势图与调度均不消费，却仍通过 HealthTrendPoint 返给前端。改为：注释标注
【已废弃】、代码停止写入与查询、从趋势接口响应中移除。保留列不删除以免破坏历史快照；
chn_health_snapshots.stability_score 为 NOT NULL 且无默认值，迁移补 DEFAULT 0，
否则代码停写后插入会失败。

docs/reference/多项目渠道调度对比.md 的 team-api 部分描述的是重写前的实现（引用的
relay/scheduler/、internal/logic/relay/health.go 均已删除），加时效声明并指明现行口径。

注意：迁移执行后需重跑 gf gen dao 刷新 entity/do/dao 中的列注释。
 2026-08-27 21:59:44 +08:00
chengqian 4f07b64ac7 fix(admin): 模型级健康分统一为 succ^α 口径，探测/重置结果即时落盘 
能力列表的模型级健康分用线性 succ×100，而调度 healthFactor、维护快照落盘、健康变化
日志三处都用 succ^α×100。前端两处共用同一套 80/50 阈值，于是 succ=0.89 时模型行显示
89「健康」、渠道行显示 79「降级」，同一个渠道点进去自相矛盾。改为经
dispatchadapter.HealthAlpha() 取当前生效策略的 α（策略支持热更新，不硬编码 2）。
该入口刻意不走 Coordinator()，避免管理后台读接口有装配整个调度引擎的副作用。

渠道测试与重置健康度后请求即时重算快照：维护循环 5 分钟一轮，此前测试成功后 Redis
立刻变、能力列表（直读 Redis）立刻变，唯独渠道健康分要等下一轮，看起来像「测试没
生效」。重置单模型的分支此前完全不写 chn_health_scores，展示分永远停在旧值，一并修复。
 2026-08-27 21:59:43 +08:00