mirrors2/openteam
1
0 Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity
113 Commits 2 Branches 0 Tags
0e10f0bbde8870c37b98c3be368c1ec5b49f388f
Commit Graph
25 Commits
Author SHA1 Message Date
Sakurasan 0e10f0bbde feat: 余额预扣 reserve/capture、冷却兜底重试、Prometheus /metrics 
- 预扣：每请求按 body 估算成本上界计入冻结额（1e-8 USD 原子计数），402 判定
  改为「余额 - 在途冻结 ≤ 0」，并发的长流式请求不再互相透支；OT_PROXY_RESERVE_MAX_TOKENS
  控制估算基数（默认 4096，0=关闭），handler defer 释放，失败/中断/panic 均覆盖
- 调度：全部候选都在运行期冷却时，剩余冷却 ≤ OT_PROXY_COOLDOWN_GRACE 的最早恢复渠道
  兜底重试一次而不是 503（429 Retry-After 语义）；DB 层不可用的渠道不参与兜底
- 指标：openteam_proxy_requests_total / request_duration / channel_failures /
  usage_queue_depth / frozen_balance，/metrics 默认关闭（OT_METRICS_ENABLED 开启）
 2026-11-09 01:04:40 +08:00
Sakurasan b2e500ff51 feat: 金额 decimal 精确计费、failover 按失败类型封顶、渠道小时桶预聚合、分层守护测试 
- 计费：19 个金额字段 float64→decimal.Decimal，DB 列保持 numeric(20,8) 零迁移；
  API 金额仍为 JSON number（MarshalJSONWithoutQuotes），前端零改动
- failover：保留时间预算，新增 OT_PROXY_FAILOVER_CAPS_NET/SERVER/RATE/QUOTA
  按失败类型封顶换渠道次数（429/配额类瞬时失败时间预算形同虚设）
- 预聚合：新增 usage_channel_hourlies（schema v10），记账事务内同步 upsert，
  长窗口渠道统计走桶不再扫明细，spent_last_30d 改扫 usage_daily，v10 一次性回填幂等
- 守护：internal/arch_test.go 用 go/parser 强制分层依赖（fail-closed）
 2026-11-09 00:41:48 +08:00
Sakurasan f1181150aa perf: 亲和表分片、记账按驱动并发、访问日志与原始体控量 
继续上一轮性能改造的剩余项：

- 会话亲和表分 16 片（原来一个全局 mutex，每个请求都要走一遍），
  键改为内联 FNV-1a 的 64 位摘要（原先是拼接字符串 + hex，每请求两次分配），
  请求路径上零分配；新增键稳定性/无分配/分片并发测试。
- 记账落库按驱动自适应并发：Recorder 按用户分片到多个 worker（同一用户恒定
  同片，流水顺序不变）。SQLite 只有一个写者，实测 4 worker 会互相抢锁把
  p99 拖到 19–34ms，所以 SQLite 固定 1 个、PostgreSQL 用 4 个。
  新增多分片落库与顺序测试（用显式 worker 数在 SQLite 上验证语义）。
- 访问日志：每请求一次 log.Printf 直写 stderr，高 QPS 下是系统调用热点；
  改为 64 KiB 缓冲 + 每秒 flush（写/flush 互斥，-race 已验）。
- 原始体控量：LogRaw 落库的请求体截到 256 KiB、响应体截到 1 MiB 并标注原始
  体积，避免单条日志几十 MB 拖慢 usage_logs 查询与备份。
- 渠道加权随机选路从 crypto/rand + big.Int 换成 math/rand/v2 的 IntN，
  去掉每请求的系统调用与两次分配。

跳过的两项与原因：
- 「PG 下把 model 目录查询合并成一次 JOIN」：目录已缓存 10s，冷路径每模型
  10 秒才走一次，合并收益接近 0。
- 「每流一个 heartbeat goroutine」：Go 的 ticker 成本很低，千级并发流仍在
  可接受范围，改动收益不抵风险。

实测（16 并发、mock 上游、SQLite）：p50 679µs→558µs、p99 2.6ms→2.2ms、
RPS 18.7k→23.9k。验证：go vet、go test ./...、-race（proxy/channel/usage）全绿。
 2026-10-30 14:25:10 +08:00
Sakurasan 8c12207478 perf: 目录缓存与流式正文快路径，请求热路径开销减半 
按性能分析逐项落地，实测对比（16 并发、mock 上游零延迟、SQLite）：

- 每请求 SQL 10 → 2：模型/渠道目录（模型行、绑定、渠道行）进程内缓存 10s，
  运行期状态（冷却、健康）仍每次实时判定；管理端写操作经中间件、
  健康状态变化经回调立即失效。新增 TestProxyRequestSQLBudget 钉住预算。
- 端到端 p50 1.3–1.6ms → 0.66–0.70ms，RPS 3.5–8.9k → 16–18k。
- 流式正文累积：字符串 += 改 strings.Builder（原为 O(n²)），
  逐行 JSON 提取改字节快路径，并加廉价的子串预过滤、拿到输出 usage 后停累积。
  500 块：949µs/7.9MB 分配 → 83µs/136KB。
- 请求体定点改写：模型映射从整包 unmarshal/marshal 改为顶层字段替换
  （100KB：585µs → 29µs），stream_options 注入同理；requestText 改为
  只在「上游没报用量」时按需提取，亲和键改用原始体前缀。
- 渠道满载背压：新增 Acquire 有界排队（OT_PROXY_CHANNEL_ACQUIRE_WAIT，
  默认 150ms）；排队仍满时返回 503 + Retry-After 而不是 502。
  实测渠道上限 4、16 并发：无排队 81 次 503；排队 150ms 后 400/400 成功。
- 记账按批聚合：同批同用户一次扣款、流水批量插入、日表按 (user,model,日期)
  聚合，替代每行 5 条语句；幂等仍靠 ref_id 唯一索引兜底。
- gorm 开启 PrepareStmt（SQL 解析此前占 CPU 15%）；tiktoken 编码器按模型复用。
- 管理端用量列表不再返回原始请求/响应体（可能几十 MB），
  改为 has_raw 标记 + GET /admin/usage/:id 按需拉取，前端弹窗打开时取。

验证：go vet、go test ./...、go test -race（proxy/channel/usage/tokenizer）、
vue-tsc、eslint、vite build 全绿；本地起 mock 上游实测列表/详情接口与
管理页弹窗按需加载。
 2026-10-30 14:14:21 +08:00
Sakurasan 04dfb4285d feat: 会话亲和粘住缓存渠道；透传 opaque 字段；用量记思考/1h 缓存写/实际模型 
会话亲和（proxy/affinity.go）：同一会话粘住上次应答的渠道，命中上游提示词
缓存而非被加权随机打散后全价重算。会话身份 = 密钥 + 模型 + 请求文本稳定前缀
摘要，不依赖各客户端会话头；TTL 默认 5m（OT_PROXY_AFFINITY_TTL，0=关闭），
成功应答刷新。亲和渠道必须在候选集内（健康/未冷却/绑定），否则回退加权随机。
proxyOne 增加 served 返回值区分「应答成功」与「已终结但失败」。

opaque 透传（convert）：chat↔responses 互转原样携带 metadata、service_tier、
parallel_tool_calls。此前逐字段重建请求体会丢它们，而中转上游会校验/使用。

用量细化（proxy+store）：usage_logs 新增 reasoning_tokens（展示口径，不重复
计费）、cache_write_1h_tokens（Anthropic 1h 缓存写按 2× 输入价，此前统一
1.25× 少算 60%）、served_model（上游实际应答模型，映射/聚合商场景对账）。
schema v6→v7。

验证：go vet ./... 干净；go test ./... 与 go test -race ./... 全绿；
新增测试覆盖亲和粘性与冷却回退、opaque 双向透传、reasoning 不重复计费、
1h/5m 缓存写分开计价、served_model 提取（非流式与流式）。
 2026-10-30 11:41:51 +08:00
Sakurasan 979973ddde feat: 流式首包缓冲容错（hold）与失败分类冷却 
流式请求在首个内容事件到达前由网关缓冲（借鉴 magpie 的 holdWriter）：上游的错误
事件、空流、断连、协议形态不符（要流给了整包）都在放行前换渠道消化，客户端无感知。
扣住期间照常发 SSE 注释心跳；缓冲超过 1MB 直接放行退化为普通转发，判定失效不吞正文。

- 新增 proxy/hold.go：streamHold（缓冲/放行/心跳/首 token 计时与放行互斥）、
  sseEventHasContent（chat/messages/responses 三种协议的内容判定）、
  sseUpstreamError（200+流式形式的错误事件识别）、classifyUpstreamError +
  quotaSignals（余额/配额特征识别）
- 非流式改为先读完整响应再写头：读失败（网络错误/超时）发生在写出之前，可换渠道
  重试；此前先写 200 头再读，超时只能给客户端留一个 200 空响应
- 协议形态校验：要流却给了整包（didNotStream）按失败换渠道，反复如此的渠道会被
  健康计数剔除
- 记账：每次尝试独立 trySink，只有成功走到 EOF 才并入请求级 sink——失败渠道的
  message_start 用量不计入账单
- 冷却按原因分类（channel.FailKind）：余额/配额类第一次失败即冷却 30 分钟（429 不
  一定是限流，智谱 429「余额不足」也在此列）；其余按连续进冷却次数指数退避
  30s→60s→120s，封顶 10 分钟；短于退避值的 Retry-After 不再缩短冷却
- 新增 OT_PROXY_FIRST_TOKEN_WAIT（默认 0=不限）：放行前等内容的最长时间，超时即
  取消本次尝试换下一个渠道
- 渠道列表接口返回 cooldown_reason，后台可区分「限流」与「余额耗尽」
- 测试：hold 缓冲/放行/心跳、内容与错误事件判定、失败分类与指数退避、容量热生效
- docs/magpie-plugin-mechanism.md：参考实现的插件机制调研
 2026-10-30 02:43:23 +08:00
Sakurasan d6db0f8162 feat: 补齐三个方向的流式工具调用；Anthropic 上游走 x-api-key；禁用模型真正下架 
- 流式转换补齐 chat→responses / responses→chat / messages→responses 的工具调用（此前只转文本，SDK 客户端拿不到 tool_calls）；completed 事件携带完整 output 数组
- Anthropic 协议上游同时发 x-api-key（官方 API 不接受 API key 走 Bearer）并透传 anthropic-beta
- 请求侧校验模型存在且启用：禁用模型 404 model_not_found，不再只是从 /v1/models 消失、实际照发照扣费；空模型名 400
- 模型在请求中途被删时按 0 记账留痕，不再按硬编码示例价扣用户的钱
- finishUsage 新增一行式请求日志（trace/user/model/channel/tokens/cost/status/latency），记账是异步的，日志是唯一即时排障依据
 2026-10-29 02:56:37 +08:00
Sakurasan c39c3e7da4 feat: 补齐上游细节、渠道观测与模型定价元数据 
- 上游 429 的 Retry-After 转成渠道冷却时长（夹在 10 分钟内；比默认值短则不缩短，
  否则 1s 就把坏渠道放回轮转）。失败计数改由 proxyOne 就地报——只有它读得到响应头。
- 故障转移时间预算 OT_PROXY_FAILOVER_BUDGET（默认 30s）：只约束第二个及以后的渠道，
  首个不受限（长回答本就要跑几分钟），但坏渠道不再把客户端拖到 N×timeout。
- 流式空闲心跳 OT_PROXY_STREAM_HEARTBEAT（默认 15s）：补一行 SSE 注释 `: ping`，
  防止 nginx/Cloudflare 的空闲超时掐掉长思考。心跳与正文共用一把写的锁，
  gin 的 ResponseWriter 不是并发安全的；注释行不进转换也不计费。
- 渠道观测：GET /api/v1/admin/channels/stats?window=5m|1h|6h|24h|7d 聚合请求量、
  成功率、P50/P95/max 延迟、成本与 top_errors；分位只取成功样本，canceled（客户端
  主动断开）不计入渠道错误率。渠道页桌面表格加「近N小时」列、移动端加同内容条，
  顶部可切窗口。
- 修一个让统计瞎掉的归因问题：全部渠道失败时 recordError 传的是 nil，
  usage_logs 里 channel_id=0，这类失败在渠道维度完全看不见。改为归到最后一个
  真正试过的渠道。
- 模型定价与元数据：Model 新增 cache_write_price（0 则回退输入价×1.25，可显式配
  Anthropic 1h 的 ×2）、context_length 与 supports_tools/vision/reasoning；
  finishUsage 走 CacheWritePriceOr()。/v1/models 叠加用户与密钥白名单过滤
  （原来会把限制外的模型名直接泄漏在列表里）并返回元数据，价格不外泄。
- /v1/models 的 Anthropic 分支原是死代码：协议只按路径判，而两种客户端共用这个路径。
  改为按 x-api-key / anthropic-version 头判，OpenAI SDK 从不发这两个头，互不影响。
- NewGateway 的十个位置参数换成 Options 结构体（三个 Duration 两个 int，传错编译期发现不了）。

新增 6 个用例：Retry-After 两种写法与夹顶、重试预算截止、空闲心跳出帧、
/v1/models 过滤与双形状、缓存写价两条路径、失败归因。
 2026-10-17 04:09:39 +08:00
Sakurasan e865f69a41 fix: 修掉模型调用链路上的四处失效逻辑 
- 超时：NewGateway 里 gw_timeout*time.Second 把已是 Duration 的值二次换算，
  int64 溢出后无论 OT_PROXY_TIMEOUT 填多少都等于没有超时，渠道 timeout_ms
  也从没被读过。现在非流式用 context deadline 约束整段时长，流式只约束首包
  （Transport.ResponseHeaderTimeout），正文不限时长，长回答不会被砍。
- 断连：上游请求改用 NewRequestWithContext 绑定客户端 context，客户端断开即
  取消上游并记 canceled，不再空转生成继续付费；PATCH 已写 200 头后不再往
  响应里追加错误体。
- 白名单：APIKey.AllowedModels 以前只存不用，现在 Auth 注入 context 并参与
  判定（用户黑名单 > 密钥白名单 > 用户白名单 > 全局）。
- 选路：模型已有渠道绑定时只用绑定渠道，都不可用直接 503 no_channel，不再
  把请求发给不认识它的渠道；新增运行期健康（连续 3 次网络错误/超时/429/5xx
  进 30s 冷却，成功清零），与 60s 一次的 /models 探测互补。
- 密钥 API：PATCH 回显更新后的完整对象；限额填 0 统一视为不限制（原来
  token 配额存 0 会让密钥第一次请求就被 429 打死，而请求配额存 0 又等于
  不限制，两个字段语义相反）；前端编辑框总是提交白名单，清空能真的取消。

测试：新增 proxy 链路集成测试（超时生效、流式不被截断、断连取消并记账、
密钥白名单 403、连续 429 后候选剔除）与 channel 用例（绑定模型不退全局、
冷却阈值与到期恢复、成功清零）。
 2026-10-16 19:15:51 +08:00
Sakurasan 2e3bb22f81 fix: use weighted random pick for load balancing instead of sequential iteration 2026-09-02 17:32:12 +08:00
Sakurasan 923ac79039 删除请求超时 2026-09-02 13:08:32 +08:00
Sakurasan d8257df100 fix: messages 流式缓存场景 token 记账错乱 
qwen/dashscope 等上游 messages 流式的 usage 语义：
- message_start.usage.input_tokens = 总输入
- message_delta.usage.input_tokens = 非缓存输入（缓存部分单列
  cache_read/cache_creation 字段），是最终计费口径

原 usageSink 字段级合并中 delta 的 input 覆盖 start 的 input，
总输入丢失（31790 → 8）；缓存写也未参与计费。

- push：带 cache_* 字段的 usage 视为最终口径，整体替换 sink
- finishUsage：缓存写按 1.25× 输入价计费（Anthropic 5m 口径）；
  落库 input_tokens 存总量（含缓存读/写）便于对账
- 估算兜底条件排除已有缓存计数的请求
- 回归测试：缓存写/缓存命中/chat 末块合并不回归
 2026-08-28 18:11:24 +08:00
Sakurasan 79545aa48e fix: 兼容上游 SSE data: 后无空格格式，流式记账不再 0 消耗 
火山方舟等上游流式返回 data:{...}（data: 后无空格），原解析只认
'data: '（带空格），导致 content 文本与 usage 全部漏解析：
- sseContentText 抽成 sseDataPayload，统一处理 data: 前缀
  （支持带/不带空格 + event:+data: 多行块）
- scanUsage 复用 sseDataPayload
- convert/stream.go parseLine 也支持 data:{ 无空格
- 新增回归测试覆盖无空格/带空格/多行块三种形态
 2026-08-27 01:24:30 +08:00
Sakurasan 10f51cbdae 请求明细支持查看原始请求/响应：OT_PROXY_LOG_RAW 开关控制，仅管理员记录与可见，流式全量捕获 
- 配置: ProxyConfig.LogRaw (OT_PROXY_LOG_RAW, 默认 false)
- 存储: usage_logs 新增 raw_request/raw_response 文本列 (AutoMigrate)
- 网关: NewGateway 接收 logRaw 参数
- handlers: 三个协议入口按 开关+管理员 条件记录原始请求体
- passthrough: 非流式 copyAndCapture 捕获响应, 流式 streamCopy 累积全部原始 SSE 行, finishUsage 统一写入
- admin API: AdminUsage 返回 raw_request/raw_response (仅管理员)
- 前端: 用量页新增查看入口, 弹窗 tab 切换请求/响应
- gitignore: 修正 server/web/ 忽略规则（尾随空格导致未生效）
 2026-08-20 00:37:48 +08:00
Sakurasan 0939f98fb5 修复流式请求记账为 0 消耗：支持 SSE 多行块 usage 提取 + 无上游 usage 时 tiktoken 估算 
- sseContentText/scanUsage 兼容 event:+data: 多行块（转换器 eventLine 产出）
- usageFromMap 新增 delta.usage 支持（Anthropic message_delta 标准格式）
- finishUsage: 流式成功但上游不返回 usage（如火山方舟）时按内容 tiktoken 估算，in/out 独立估算
- .gitignore 忽略 server/web 本地静态托管软链
 2026-08-19 20:59:04 +08:00
SakurasanandClaude 0ee92d78e7 代理: 流式中断按已生成部分计费 
- 新增 tokenizer 包(tiktoken-go)按模型估算 token, 未知模型回退 cl100k_base
- passthrough 提取请求输入文本 + SSE 已生成内容, 客户端断开时记 canceled
- usage 计费范围扩展: canceled(流式中断)按已生成部分收费

Co-Authored-By: Claude <noreply@anthropic.com>
 2026-08-16 09:04:18 +08:00
SakurasanandClaude db83972b6f 渠道: 分协议 Base URL + 模型抽屉/远程拉取/操作图标 
- 渠道支持分协议 base_url(chat/responses/messages 各一), 网关按协议选 base 直通
  (如智谱三种格式不同 base, 一个渠道即可), UpstreamURL 按 proto 拼接
- 渠道模型改为下方抽屉: 当前绑定列表(内联改上游/解除)、从接口拉取(remote 预览+勾选添加)、手动添加
- 新增 /channels/:id/models/remote 预览接口; 操作按钮加 Phosphor 图标
- 修复 formats jsonb 更新未序列化问题; 手机端渠道卡片化

Co-Authored-By: Claude <noreply@anthropic.com>
 2026-08-16 04:31:28 +08:00
SakurasanandClaude 4d4d09ba58 渠道: 模型名称映射(网关生效 + 渠道侧管理) 
- 候选渠道携带 upstream_model, prepareUpstream 改写请求体 model 字段为上游名
- 新增渠道视角绑定 CRUD: GET/POST/PATCH/DELETE /admin/channels/:id/models
- 前端渠道页新增"模型映射": 列出绑定、内联改上游名、解除、添加
- rewriteModel 三种协议通用(model 均在顶层)

Co-Authored-By: Claude <noreply@anthropic.com>
 2026-08-16 00:09:01 +08:00
SakurasanandClaude 8d9940ad5a 渠道: Base URL 智能识别前缀/完整端点 + API 格式垂直堆叠 
- upstreamURL 按内容智能拼接: 完整端点直接用 / 含 /v1 只拼资源路径 / 纯域名拼全路径
- resolveBaseURL 不再去 /v1, 交网关识别
- 渠道表 API 格式改垂直堆叠, 显示短标识 chat/completions / responses / messages
- 前端 Base URL 提示支持前缀或完整端点

Co-Authored-By: Claude <noreply@anthropic.com>
 2026-08-16 00:08:52 +08:00
SakurasanandClaude d0bc28a4fe 渠道: 移除主页/favicon 特性, Base URL 可选+完整地址 
- 回退渠道 homepage/favicon 字段与代理接口(未采用)
- Base URL 改为可选: 留空按供应商默认(openai/anthropic),
  兼容兼容型渠道必须填; 填完整地址(含 /v1)时归一化去尾
- 网关 upstreamURL 兜底去 /v1, 避免路径重复

Co-Authored-By: Claude <noreply@anthropic.com>
 2026-08-15 20:55:17 +08:00
SakurasanandClaude 5eff32afd8 渠道支持多 API 格式 + 协议全名展示 
- Channel 新增 formats(jsonb: chat|responses|messages), 一个渠道可同时声明
  支持 OpenAI Chat Completions / OpenAI Responses API / Anthropic Messages
- 路由改为按渠道声明的 formats 决定直通/转换: 客户端协议在 formats 内直通,
  否则转换为其首选支持格式(chat > messages > responses)
- 兼容旧数据: formats 为空时按 provider 推断(openai→chat+responses, anthropic→messages, compatible→chat)
- 前端: 渠道表/表单展示 API 格式(支持多选), usage 明细显示协议全名
  (OpenAI Chat Completions / OpenAI Responses API / Anthropic Messages)

Co-Authored-By: Claude <noreply@anthropic.com>
 2026-08-15 16:47:03 +08:00
SakurasanandClaude 4846db9293 M3 收尾: 限流/配额 + 前端骨架屏 + 单端口托管前端 
- ratelimit(内存计数): 密钥级每日请求数/Token 配额、用户级每秒速率
  (OT_RATELIMIT_USER_RPS), 超限返回 429
- 网关 Auth 前置配额/限流检查, finishUsage 累计密钥 token 用量
- 前端 Skeleton 组件 + Dashboard/管理总览加载态
- Go 服务托管 web/dist 静态资源(SPA 回退), 单端口即可访问前后端

Co-Authored-By: Claude <noreply@anthropic.com>
 2026-08-15 16:13:09 +08:00
SakurasanandClaude 0637ce0a51 M5: 渠道体系(负载均衡+并发控制+健康检查+故障转移) 
- channel.Candidates 按模型绑定取候选 + Pick 加权随机负载均衡
- TryAcquire 每渠道并发信号量, 满载溢出到其他候选
- HealthMonitor 后台定时探测, 连续失败进 cooldown, 恢复放回(可配 interval/threshold)
- doProxy 遍历候选故障转移: 网络错误/429/5xx/超时且未写出响应头时安全重试;
  400 等业务错误透传, 流式写出首字节后放弃重试
- 单测覆盖候选过滤/加权/并发/健康状态机
- E2E: 杀上游自动切换、cooldown、恢复、并发溢出 10/10

Co-Authored-By: Claude <noreply@anthropic.com>
 2026-08-15 15:57:48 +08:00
SakurasanandClaude ec4de8d913 M0-M4: 推倒重来基线(基建+用户/密钥/核心代理+前端+管理后台+三协议互转) 
- 后端 Go+Gin+GORM: 配置(OT_ env)/SQLite/Postgres 双驱动、用户体系(argon2id+JWT access/refresh)、
  API Key(sk- 48位, 仅存 SHA-256 哈希)
- 代理网关: /v1/chat/completions、/v1/responses、/v1/messages、/v1/models;错误按客户端协议返回
- 三协议互转(convert 包): Chat↔Messages↔Responses 请求/响应 + 流式 SSE 逐事件转换(直通优先)
- 用量计费: 异步批量记账、余额扣减、balance_logs、usage_daily 日聚合
- 管理 API: 用户/渠道 CRUD+测试+模型导入/模型定价+绑定/统计/系统配置
- 前端 Vue3+TS+Tailwind(taste-skill 设计 tokens): Landing/登录注册/控制台/管理后台,
  自建组件+Phosphor 图标+自建 SVG 趋势图, 已过 web-design-guidelines 复查
- mock 上游: OpenAI+Anthropic 双协议模拟(含流式)

Co-Authored-By: Claude <noreply@anthropic.com>
 2026-08-15 15:34:06 +08:00
Sakurasan 360c6b33a6 M0+M1: 基建 + 用户/密钥/核心代理 
后端 (Go/Gin/GORM):
- 配置(viper+env)、SQLite/Postgres 迁移、argon2id、AES-GCM 渠道密钥、JWT+refresh cookie
- 用户注册/登录/刷新/登出、API Key CRUD(仅存哈希、明文一次展示)
- 代理网关: /v1/chat/completions、/v1/responses、/v1/models 直通 OpenAI 渠道
  非流式+流式(SSE 零缓冲转发), 用量捕获(chat 末块/responses completed 嵌套),
  OpenAI 错误格式(401/402/404/502), 余额检查
- 异步批量记账 + 余额流水 + 日聚合, admin 用户/余额/配置 API
- 单测: crypto/jwt/apikey/流式 usage 提取

前端 (Vue3+TS+Vite+Tailwind v4):
- taste-skill 设计 tokens: 深色仪表盘, 石墨+信号铜色, Outfit+JetBrains Mono
- Landing/登录/注册, 控制台(仪表盘图表/密钥管理/用量明细)
- 基础组件 Button/Input/Badge/Modal, ECharts 用量图

部署: docker-compose(nginx+api+postgres), 双 Dockerfile, nginx SSE 反代
联调: scripts/mockupstream 本地 mock 上游, 端到端验证通过
 2026-08-15 13:10:47 +08:00