openteam/PLANNING.md

大模型中转站（OpenRouter-like）规划文档

版本：v0.3 · 2026-08-15 · 状态：规划（未开始编码）

本文档是项目蓝图，覆盖技术选型、系统架构、核心功能、数据模型、API 设计、前端设计方向与开发里程碑。编码开始前，本文档应与团队确认一遍。

---

1. 项目概述

1.1 定位

一个自托管的 LLM API 中转网关，功能对标 OpenRouter / one-api：

• 对下游用户暴露统一的、OpenAI 兼容的 API 入口，背后接入多个上游渠道（OpenAI、Anthropic、兼容第三方等）。
• 对外提供三套协议入口：OpenAI Responses API、OpenAI Chat Completions、Anthropic Messages，覆盖两大生态的 SDK 与客户端。
• 内置用户体系、API Key 管理、用量统计与计费（充值暂缓，见 §4.5）。

1.2 核心价值

对用户	对管理员
一个 Key 访问多家模型，OpenAI/Anthropic 生态格式互通	统一管理多个上游渠道，做模型定价
查询用量、成本明细	管理用户、审核充值、看全局营收
配额/余额控制	渠道健康检查、负载均衡、故障转移

1.3 对外协议（明确范围）

端点	协议	说明
POST /v1/responses	OpenAI Responses API	OpenAI 新生态（SDK/Agents）首选，含流式、工具调用、结构化输出
POST /v1/chat/completions	OpenAI Chat Completions	兼容面最广的格式，含流式（SSE）与工具调用
POST /v1/messages	Anthropic Messages	Claude 生态原生格式，含流式与工具调用
GET /v1/models	OpenAI 风格模型列表	对外列出可用模型；也用于渠道侧自动导入模型列表

三套协议之间可互相转换：例如客户端按 Responses 调用 claude-sonnet-5，网关会转换成 Anthropic 协议打给 Anthropic 渠道，再以 Responses 流式返回；同理可反向。协议与渠道匹配时走直通（见 4.1.3）。

---

1.4 首版范围（MVP）

纳入	暂缓
大模型代理（三套协议 + 渠道 + 转换）	充值（暂停，见 §4.5）
用户管理（注册/登录/角色/API Key）	邀请码（配置开关预留）
用量计费（token 统计、计价、余额、流水）	在线支付、审计报表、多实例
渠道管理（API 类型、模型导入、健康检查）	组织/团队（多租户）
管理后台（用户/渠道/模型/全局用量）

2. 技术选型

2.1 后端（Go）

项	选型	理由
语言/运行时	Go 1.23+	高并发流式转发、低内存、部署为单二进制
Web 框架	Gin	生态成熟，中间件丰富；代理层可用标准库 net/http 做流式读写
ORM	GORM	简单、迁移工具内建；后期可换 sqlc
数据库	PostgreSQL 15+（开发可 SQLite 起步）	JSON/数组字段、数值精度对计费友好；单一存储，无额外部署
缓存/限流	Redis 7	token bucket 限流、热点数据、分布式计数器
认证	JWT（访问令牌）+ 刷新令牌 HttpOnly Cookie	见 4.3
密码	argon2id	现代 KDF
配置	viper + .env	密钥进环境变量，不进代码库
日志	zap	结构化日志，含请求 trace
上游密钥加密	AES-GCM（主密钥来自环境变量）	渠道 key 落库前加密

2.2 前端（Vue 3）

项	选型	理由
框架	Vue 3 + TypeScript + Vite	团队栈、构建快
状态	Pinia	官方推荐
路由	Vue Router	标准
样式	Tailwind CSS + taste-skill 产出的设计 tokens	自建设计系统，避免套模板
组件基座	Ark UI（headless）+ 自建基础组件	无头组件可控性强，符合 taste-skill 的 anti-slop 取向
图表	ECharts（vue-echarts）	用量/营收图表
HTTP	axios + TanStack Query	缓存、重试、请求状态管理

说明：不选用 Element Plus 这类"完整模板感"较重的库，管理后台的表格/表单由自建组件提供，视觉由 taste-skill 统一定调。

2.3 部署

• Docker Compose 起步：nginx（静态资源 + 反代） + api（Go） + postgres + redis。
• 单实例起步（记账时序简单），需要时再做多实例（见 §9 风险）。

---

3. 系统架构

3.1 模块划分

┌─────────────────────────────────────────────────────────────┐
│                         前端 web (Vue3)                        │
│  Landing / 登录注册 / 控制台(密钥·用量·充值) / 管理后台           │
└──────────────────────────┬──────────────────────────────────┘
                           │ HTTP/JSON（管理 API）
┌──────────────────────────▼──────────────────────────────────┐
│                       Go API 服务                             │
│  ┌──────────┐ ┌──────────┐ ┌──────────┐ ┌────────────────┐  │
│  │  认证/用户 │ │  API Key │ │ 用量/计费 │ │  充值(暂停)     │  │
│  └──────────┘ └──────────┘ └──────────┘ └────────────────┘  │
│  ┌────────────────────────────────────────────────────────┐ │
│  │              API 网关（代理核心）                          │ │
│  │  Auth/Ratelimit → 余额检查 → 模型解析 → 渠道选择           │ │
│  │  → 格式转换 → 上游调用 → 流式转发 → 记账                   │ │
│  └────────────────────────────────────────────────────────┘ │
│  ┌──────────┐ ┌──────────┐ ┌──────────┐ ┌───────────────┐   │
│  │ 渠道管理  │ │ 负载均衡  │ │ 健康检查  │ │ 重试/故障转移   │   │
│  └──────────┘ └──────────┘ └──────────┘ └───────────────┘   │
└──────────┬──────────────────────────────┬───────────────────┘
           │                              │
   ┌───────▼────────┐             ┌────────▼────────┐
   │ PostgreSQL      │             │ Redis            │
   │ 用户/密钥/渠道/  │             │ 限流/配额/热点    │
   │ 模型/用量/订单   │             │                  │
   └────────────────┘             └─────────────────┘

3.2 一次代理请求的完整链路

Client                     Go 网关                          上游渠道(如 Anthropic)
  │  POST /v1/chat/completions (sk-xxx)                        │
  ├──────────────────────────────▶│                             │
  │                               │ 1. 取 Bearer，哈希查 API Key  │
  │                               │ 2. 限流检查（Redis）          │
  │                               │ 3. 余额检查                  │
  │                               │ 4. 解析请求 → 标准中间模型     │
  │                               │ 5. 按模型选渠道（LB/健康）      │
  │                               │ 6. 转换请求为 Claude 格式     │
  │                               ├───────────────────────────▶ │
  │                               │ ◀────────────────────────── │
  │                               │ 7. 流式/非流式转发+格式转回    │
  │ ◀──────────────────────────────│                             │
  │                               │ 8. 异步记账（token→价格→扣费）│

关键点：

• 记账是异步的：请求完成后写入 usage_logs，批量落库，不阻塞响应。
• 流式响应不整体缓冲：用 io.Pipe 边读上游边写客户端；Token 计数取流结束时的 usage 字段（OpenAI 末块 / Claude message_delta）。
• 只转发请求体与必要头：Authorization 一律替换为渠道 key，不向客户端暴露上游信息。

---

4. 核心功能设计

4.1 API 网关 / 格式转换

4.1.1 内部统一格式（标准模型）

网关内部使用 OpenAI Chat Completions 形状 作为"标准中间模型"，三套协议都先转成它、再转成目标协议：

OpenAI /v1/responses       ──┐
OpenAI /v1/chat/completions ─┼──▶ 标准模型（OpenAI chat 形状） ──▶ 各渠道原生格式
Anthropic /v1/messages    ──┘

这样新增一种上游渠道（如 Gemini）只需写一对转换器（标准模型 ↔ 渠道格式），不用为每个协议组合写转换器；Responses 与 Chat、Messages 与 Chat 之间各维护一个转换适配器。

4.1.2 转换映射要点

Chat ↔ Claude Messages

维度	OpenAI chat ↔ Claude messages
system	OpenAI messages[role=system] ↔ Claude system 参数（支持数组/文本）
消息	assistant.tool_calls ↔ content 中的 tool_use 块；role=tool ↔ tool_result 块
工具	tools[{type:function,name,description,parameters}] ↔ tools[{name,description,input_schema}]
采样	temperature（OpenAI 0–2，Claude 0–1，越界按目标协议 clamp）、top_p
长度	max_tokens ↔ max_tokens（Claude 必填，缺失时给默认值）
停止	stop ↔ stop_sequences（数组对齐）
流式	OpenAI SSE data: {chunk} + [DONE] ↔ Claude 事件流 message_start / content_block_delta / message_delta / message_stop，逐事件互转
用量	usage.prompt_tokens/completion_tokens ↔ usage.input_tokens/output_tokens，并映射 Claude 的缓存 token

Responses ↔ Chat（Responses 结构化能力更多，映射如下）

Responses 字段	Chat 对应
instructions	messages[0].system
input[]（input_text / input_image / input_file）	messages[]（user 多模态 content 数组）
input[] 中 function_call / function_call_output 条目	assistant.tool_calls / role=tool 消息
output[] 中 message / function_call / reasoning 条目	choices[].message / tool_calls（reasoning 跨协议丢弃）
tools[{type:function,name,description,parameters}]	tools[{type:function,...}]（结构相同）
output_format / text.format	response_format
max_output_tokens	max_tokens
previous_response_id	仅直通 OpenAI 渠道可用；跨协议时降级（见 4.1.3）
reasoning.effort	仅直通或特定渠道，跨协议丢弃
流式事件 response.created / output_text.delta / function_call_arguments.delta / response.completed	chat SSE data: {delta} + [DONE]，逐事件互转

4.1.3 直通（passthrough）与转换策略

• 直通优先：客户端协议与渠道原生协议一致时直接透传报文（仅做鉴权/限额/记账），不转格式——保证 Responses 的 previous_response_id、reasoning、结构化输出等新能力在 OpenAI 渠道上零损失。
• 转换路径：协议不匹配时才经标准模型转换（如 Responses → Anthropic 渠道、Messages → OpenAI 渠道）。
• 有损边界（文档明示）：
  • previous_response_id、reasoning.effort 跨协议时降级或丢弃，错误响应中提示。
  • Anthropic 渠道不接收 response_format 类结构化约束，降级为 prompt 提示或丢弃。
  • Claude 的 thinking 块在 OpenAI 协议侧丢弃（无法表达）。
• 转换标记：转换过的请求/响应加 x-converted: true 头，便于排查。

4.1.4 错误响应统一

无论上游是什么错误，都按客户端请求的协议返回错误体：

• OpenAI 格式：{"error":{"message","type","param","code"}} + 映射过的 HTTP 状态码。
• Claude 格式：{"type":"error","error":{"type","message"}}。
• 状态码映射：上游 429 → 429（附 retry-after）、上游 5xx → 触发重试后返回 502/504、400（含 context length 超限）→ 原样返回、余额不足 → 402。

4.2 渠道系统

能力	设计
渠道 CRUD	管理员增删改：名称、API 类型（openai / anthropic / compatible）、base_url、上游 key（AES-GCM 加密存储）、超时、并发上限
API 类型选择	新增渠道时选择类型，决定支持的原生协议（决定直通还是转换）与模型列表导入方式
模型列表导入	渠道支持 GET /v1/models 时提供"拉取模型列表"按钮，自动导入可用模型到全局模型库并生成绑定；不支持该端点的渠道（部分第三方）可手动录入
模型绑定	模型(全局) ↔ 渠道(多个) 多对多，每个绑定记录 upstream_model 名、权重/优先级
负载均衡	按权重 + 优先级 + 健康状态选择渠道；健康渠道优先
健康检查	定时用最廉价模型发一次测试请求（非流式），连续失败 N 次进入 cooldown，恢复后再放回
重试/故障转移	仅对"可安全重试"的失败（网络错误、429、5xx、超时、上游连接断开且尚未写出响应头）；对 400/context 类错误不重试。流式一旦已向客户端写出首字节，放弃重试
并发控制	每渠道信号量限制最大并发，超限排队或溢出到其他渠道

4.3 认证与用户

4.3.1 角色

角色	权限
admin	全部；渠道管理、模型定价、用户管理、余额调整、充值审核、全局用量
user	创建/管理自己的 API Key、查询用量、充值、查看余额

预留 viewer（只读运营）角色，首版不做。

4.3.2 会话

• 登录：用户名/邮箱 + 密码（argon2id 校验）。
• 颁发：短时访问令牌（JWT，如 2h，存内存）+ 刷新令牌（存 HttpOnly Cookie，7d）。
• 注册：开放注册，可切换——默认 open，配置项 registration.mode 切到 invite 即启用邀请码（管理员后台生成）。

4.3.3 API Key

• 生成格式：sk- + 48 位随机字符（base62），创建时仅展示一次。
• 存储：库中只存 SHA-256 哈希 + 展示用前缀（如 sk-aB3c…）；请求时对 Bearer 哈希后查表。
• 附加能力：密钥级配额（每日 token 上限 / 每日请求数上限）、模型白名单、过期时间、启停。
• 限额检查用 Redis 计数，与用户级限流叠加。

4.4 用量与计费

4.4.1 Token 统计

• 优先取上游响应中的 usage（OpenAI usage 字段、Claude message_delta.usage）。
• 上游缺失时 fallback：本地近似计数（按字符/字节估算，或引入 tiktoken-go 按模型分词）。
• Claude 渠道额外记录 cache_read_input_tokens / cache_creation_input_tokens，用于缓存计费。

4.4.2 计价

• 模型注册表（models）中每个模型配置：input_price、output_price、cache_read_price（按 每百万 token）。
• 单次成本 = in×in_price + out×out_price + cache_read×cache_read_price（统一以 USD 记账，前端按配置汇率显示）。
• 管理员可随时调价，历史用量按当时价格入账（用量表冗余快照价格字段）。

4.4.3 余额与扣费

• 预充值余额制：每次请求结束后异步扣费并写余额流水（balance_logs）。
• 扣费前先检查：余额 ≤ 0 时新请求返回 402。可选开关：按模型估算成本超余额即拦截（防止大单超额）。
• 余额为负不拒绝已进行的流式请求（流中途无法中断），但后续请求被拒。

4.4.4 用量查询

• usage_logs：请求级明细（用户、密钥、模型、渠道、token、成本、耗时、状态）。
• 聚合：日粒度预聚合表（usage_daily）支撑 Dashboard 图表，避免每次实时扫明细表。

4.5 充值（暂停开发）

已决定：充值暂缓，首版不做，先交付"代理 + 用户 + 计费"。方案（人工审核 / 在线支付）确定后再落地。 预留：recharge_orders / balance_logs 数据模型与订单状态机先行建好，后续接入不影响现有结构。

订单状态机（预留）：

pending(待审核) ──approve──▶ credited(已入账)
      │                         │
      └──reject──▶ rejected     └─（错误入账→adjust 冲正）

4.6 管理后台

• 渠道管理：增删改、模型绑定、手动测试连接、健康状态查看。
• 模型管理：全局模型清单、多渠道绑定、价格设置、启停。
• 用户管理：列表/搜索、改角色/状态、调整余额、重置密码。
• 充值审核：待审订单列表、通过/驳回、流水留痕。
• 全局用量：跨用户查询、按模型/渠道/天聚合、营收统计。
• 系统配置：开放注册、邀请码、汇率、限流阈值、维护开关。

---

5. 数据模型

统一 id 为 bigint 自增（或 snowflake），时间用 UTC，金额/价格用 numeric(20,8)，token 用 bigint。

5.1 users

字段	类型	说明
id	bigint PK
username / email	text UNIQUE
password_hash	text	argon2id
role	enum(user,admin)
balance	numeric(20,8)	余额
status	enum(active,disabled)
invite_code	text nullable	注册来源邀请码
last_login_at / created_at / updated_at	timestamptz

5.2 api_keys

字段	类型	说明
id	bigint PK
user_id	bigint FK
name	text	展示名
key_hash	text UNIQUE	SHA-256
key_prefix	text	sk-aB3c…
quota_tokens_per_day	bigint nullable	密钥级限额
quota_requests_per_day	int nullable
allowed_models	jsonb nullable	模型白名单
expires_at	timestamptz nullable
status	enum(active,revoked)
last_used_at	timestamptz nullable
created_at	timestamptz

5.3 channels

字段	类型	说明
id	bigint PK
name	text
provider	enum(openai,anthropic,compatible)	API 类型：决定原生协议与模型导入方式
base_url	text	上游地址
api_key_enc	text	AES-GCM 密文
weight / priority	int	负载均衡权重 / 优先级
timeout_ms	int
max_concurrency	int
health_status	enum(healthy,degraded,cooldown)
enabled	bool
created_at / updated_at	timestamptz

5.4 models + channel_model_bindings

models（全局模型 + 价格）：

字段	类型
id, name(全局名如 claude-sonnet-5), display_name
input_price / output_price / cache_read_price	numeric(20,8)（每百万 token）
enabled, sort

channel_model_bindings（多对多）：

字段	类型
id, channel_id FK, model_id FK
upstream_model	text（如 us.anthropic.com:claude-sonnet-5）
weight	int

5.5 usage_logs（请求级明细）

字段	类型
id, request_id(上游 id), user_id FK, key_id FK, channel_id FK, model_id FK
input_tokens / output_tokens / cache_read_tokens / cache_creation_tokens	bigint
input_price / output_price / cache_read_price	numeric(20,8) 快照
cost	numeric(20,8)
latency_ms	int
status	enum(success,error,canceled)
error_code	text nullable
created_at	timestamptz，带索引 (user_id, created_at)

5.6 usage_daily（日聚合）

id, user_id, model_id, date, requests, input_tokens, output_tokens, cache_read_tokens, cost

5.7 recharge_orders

id, user_id FK, amount numeric(20,8), status enum(pending/credited/rejected), method enum(manual/online), transaction_id, reviewed_by FK, reviewed_at, remark, created_at

5.8 balance_logs（余额流水，幂等保证）

id, user_id FK, change numeric(20,8), balance_after numeric(20,8), type enum(recharge/usage/refund/admin_adjust), ref_id, created_at

5.9 system_configs

key text PK, value jsonb

---

6. API 设计

6.1 代理端点（对外，Bearer API Key 认证）

方法	路径	说明
POST	/v1/responses	OpenAI Responses API
POST	/v1/chat/completions	OpenAI Chat 格式
POST	/v1/messages	Anthropic Messages
GET	/v1/models	可用模型列表（OpenAI 风格）

6.2 管理 API（/api/v1，会话认证）

认证/用户

• POST auth/register · POST auth/login · POST auth/logout · GET auth/me
• GET user/profile · GET user/balance

API Key

• GET/POST /keys · PATCH/DELETE /keys/:id

用量

• GET /usage/summary（今日/本月汇总）
• GET /usage/stats?from&to&group=day|model
• GET /usage/logs?from&to&page&model&keyId

充值

• POST /recharges · GET /recharges（暂停，接口预留）

管理后台（/api/v1/admin，仅 admin）

• GET/POST/PUT/DELETE /channels · POST /channels/:id/test
• GET/POST/PUT /models · PUT /models/:id/price
• GET /users · PATCH /users/:id · POST /users/:id/balance
• GET /recharges · POST /recharges/:id/approve|reject（暂停，接口预留）
• GET /usage · GET /stats/overview
• GET/PUT /config

---

7. 前端设计（taste-skill）

7.1 设计流程

1. 前端阶段启动时调用 taste-skill：传入产品 brief 与页面清单，由它推断设计方向，产出：
   • 设计 tokens：色板（含暗色/亮色）、字体系统、间距、圆角、阴影、栅格。
   • 核心页面高保真方向（先做 3–5 个代表页，不一次铺开）。
2. 以 tokens 建立 Tailwind 主题（tailwind.config + CSS variables）与基础组件（Button / Table / Form / Modal / Nav）。
3. 按页面清单逐组实现，每个阶段结束用 web-design-guidelines 复查（对比度、可访问性、交互细节）。
4. 设计评审迭代，不套模板。

7.2 预期设计方向（taste-skill 最终决定，此处为倾向）

开发者工具 / API 网关类产品，倾向：

• 深色优先、仪表盘质感；等宽字体点缀 token、端点、代码片段。
• 数据密度高的表格（用量、密钥、订单），克制的中性色 + 单一强调色。
• Landing 简洁可信：产品价值、端点示例、模型列表预览。

7.3 页面清单

区域	页面
公开	Landing · 登录 · 注册
用户	Dashboard（余额/今日用量/最近请求/图表）· API Keys · 用量查询 · 充值（后置） · 个人设置
管理	运营总览 · 渠道管理（API 类型 + 模型导入） · 模型与定价 · 用户管理 · 充值审核（后置） · 全局用量 · 系统配置

7.4 前端工程注意点

• 流式调试体验：控制台页提供"用 curl / 请求编辑器"快速验证 key 与模型（可选，v2）。
• 图表统一用 ECharts，暗色主题与设计 tokens 对齐。
• 表格/表单为自建组件，行为一致性优先，后续可沉淀为内部组件库。

---

8. 非功能需求

类别	要求
安全	API Key 仅存哈希；渠道密钥加密存储；密码 argon2id；JWT 刷新令牌 HttpOnly；日志/错误信息脱敏（不泄露渠道 key、完整 key）；CORS 白名单；管理接口二次鉴权
限流	Redis token bucket：用户级 + 密钥级 + 全局并发保护
稳定性	渠道 cooldown + 重试；流式请求 client 断连即取消上游调用（ctx cancel）；上游超时兜底
可观测	zap 结构化日志 + request_id；Prometheus 指标（请求数/延迟/错误率/成本）；管理后台健康概览
性能	流式零缓冲转发；记账异步批量落库；聚合查询走预聚合表
合规	用户协议与数据留存说明；退款/冲正流程可追溯

---

9. 仓库结构（规划）

openteam/
├── server/                  # Go 后端
│   ├── cmd/server/main.go
│   ├── internal/
│   │   ├── config/          # viper + env
│   │   ├── user/            # 认证/角色/用户
│   │   ├── apikey/
│   │   ├── proxy/           # 网关核心
│   │   │   ├── responses/   # OpenAI Responses 格式编解码
│   │   │   ├── openai/      # OpenAI Chat 格式编解码
│   │   │   ├── claude/      # Anthropic Messages 格式编解码
│   │   │   ├── convert/     # 标准模型 ↔ 各协议转换
│   │   │   └── stream/      # SSE 双向流式转发
│   │   ├── channel/         # 渠道、负载均衡、健康检查、重试
│   │   ├── billing/         # 计价、余额、流水
│   │   ├── usage/           # 记账、聚合
│   │   ├── recharge/        # 订单（待定方案）
│   │   ├── admin/           # 管理 API
│   │   ├── store/           # GORM models + repositories
│   │   └── pkg/             # jwt, crypto, ratelimit, tiktoken
├── web/                     # Vue3 前端
│   ├── src/styles/          # taste-skill 设计 tokens
│   ├── src/components/      # 基础组件
│   ├── src/views/           # 页面
│   ├── src/stores/ · src/api/ · src/router/
├── deploy/                  # docker-compose, nginx, Dockerfile
└── docs/

---

10. 开发里程碑

里程碑	内容	验收标准
M0 基建	仓库结构、配置、DB 迁移、JWT/密码工具、CI；taste-skill 启动产出设计 tokens	空服务可启动，tokens 落地
M1 用户+密钥+核心代理	注册/登录/角色、API Key CRUD；/v1/responses 与 /v1/chat/completions 直连 OpenAI 渠道（非流式+流式，直通）；OpenAI 错误格式	用 curl 完成一次带流式的对话与一次 Responses 调用；密钥可建可吊销
M2 用量+计费	记账、token 统计、价格表、余额扣减、用量 API；前端 Dashboard/用量页	请求后余额正确变化，用量图表正确
M3 跨协议转换	/v1/messages 代理；Responses ↔ Chat ↔ Messages 转换（含流式、工具调用）；Anthropic 渠道	OpenAI 客户端调 Claude 模型、Anthropic 客户端调 OpenAI 模型均通
M4 渠道系统	渠道 CRUD（API 类型）、/models 模型导入、模型绑定、负载均衡、健康检查、重试/故障转移；管理后台渠道页	一个渠道挂掉自动切换；后台可加渠道、拉取模型并测试
M5 充值（暂停）	方案待定，首版不做；仅预留订单表与状态机	—
M6 打磨上线	限流、监控指标、审计日志、taste-skill 全站设计复查、docker-compose 部署、文档与测试补全	可对外交付部署

---

11. 风险与待定决策

#	事项	状态	说明
1	充值	⏸ 暂停	首版不做，订单表与状态机预留，方案确定后再落地
2	注册策略	✅ 已确认	开放注册，配置可切换邀请码
3	协议范围	✅ 已确认	Responses + Chat Completions + Anthropic Messages；去掉 legacy /v1/completions
4	流式重试边界：首字节发出后不可重试	✅ 已决策	仅连接建立前重试；文档明示
5	Responses 跨协议有损边界	🟡 实现中确认	previous_response_id、reasoning 跨协议降级/丢弃，加 x-converted 头
6	模型列表导入差异	🟡 实现中确认	部分渠道无 /v1/models，需手动录入 fallback
7	计费精度：Claude 缓存 token、上游缺 usage	✅ 已决策	冗余快照价格；近似计数 fallback
8	多实例扩展：记账时序	🟡 后置	单实例起步，必要时引入消息队列
9	合规：数据留存、日志脱敏	🟡 上线前	隐私说明、审计日志

---

12. 下一步

范围已收敛：代理（三协议）+ 用户管理 + 用量计费 + 渠道管理，充值暂停。

1. 无阻塞性待定项，可按 M0 → M1 开始实施；taste-skill 先行产出设计方向，后端同时搭骨架。
2. 实施中确认两处细节：Responses 跨协议降级边界（§11 #5）、模型导入的渠道差异（#6）。