105 lines
6.5 KiB
Markdown
105 lines
6.5 KiB
Markdown
# integration-platform 迁移实施计划
|
||
|
||
## Phase 0：脚手架与基础契约
|
||
|
||
- 在 Agent memory 的 PostgreSQL 18 `easyai-pgvector` 实例上建立独立数据库 `easyai_ai_gateway` 和 AI Gateway 表，不直接使用 `easyai_memory` 记忆库。正式 EasyAI compose 默认账号为 `easyai` / `easyai2025`。
|
||
- 完成 Go API、React 前端、Nx/go.work/pnpm monorepo、基础 migration。
|
||
- 完成本地账号注册登录、可选邀请码、JWT / API Key 授权验证骨架，并将默认身份模式设为 `hybrid`。
|
||
- 固化兼容路由、任务事件、队列、定价、限流、回调 outbox 的基础设计。
|
||
- React 前端先具备登录页、首页、模型、用户工作台、管理工作台、API 文档的页面骨架。
|
||
|
||
## Phase 1：模型库 + 首批生成能力
|
||
|
||
第一阶段只做可落地的核心闭环：**模型库、大模型对话、文本生图、图像编辑**。Client 只迁移 **OpenAI** 和 **Gemini** 两个，暂不迁移视频和其他 provider。
|
||
|
||
### 1.1 模型库
|
||
|
||
- 建立 `model_catalog_providers`、`base_model_catalog`、`model_pricing_rules` 的首批数据。
|
||
- 建立 `gateway_tenants`、`gateway_users`、`gateway_user_groups`、`gateway_tenant_invitations` 和用户组策略，支持独立租户/用户、可选邀请码注册、`server-main` 同步租户/用户、不同用户组的充值折扣、调用折扣和并发/限流策略。
|
||
- 建立独立模式本地闭环表：`gateway_api_keys`、`gateway_wallet_accounts`、`gateway_wallet_transactions`、`gateway_recharge_orders`。
|
||
- 导入 OpenAI、Gemini 的基准 provider、基准模型、能力 schema、默认限流模板。
|
||
- 支持全局模型配置：模型类型、上下文、多模态能力、图片输入/输出能力、stream 支持、价格规则。
|
||
- 支持平台模型 follow 基准模型、平台折扣、模型级自定义价格和能力覆盖。
|
||
- 管理工作台可查看和编辑基准模型、平台模型、定价规则、默认限流。
|
||
|
||
### 1.2 大模型对话
|
||
|
||
- 迁移兼容路由：
|
||
- `/chat/completions`
|
||
- `/v1/chat/completions`
|
||
- `/responses` / `/v1/responses` 可先保留契约，按 OpenAI/Gemini Chat 能力逐步补齐。
|
||
- 支持同步响应和 stream 响应。
|
||
- 支持文本、多模态图片输入的参数归一与能力校验。
|
||
- 支持 TPM/RPM/并发限流、失败切换、任务事件、usage / billings 回填。
|
||
- 先完成 OpenAI Chat Client 和 Gemini Chat Client 的 contract test。
|
||
|
||
### 1.3 生图与图像编辑
|
||
|
||
- 迁移兼容路由：
|
||
- `/images/generations`
|
||
- `/v1/images/generations`
|
||
- `/images/edits`
|
||
- `/v1/images/edits`
|
||
- 支持 prompt、参考图、mask / edit 输入、尺寸、质量、数量等参数归一。
|
||
- 文件输入与结果转存统一调用 `server-main` `/v1/files/upload`。
|
||
- 支持图像价格预估：分辨率、质量、数量、生成/编辑模式权重。
|
||
- 先完成 OpenAI Image Client 和 Gemini Image Client 的 contract test。
|
||
|
||
### 1.4 第一阶段验收
|
||
|
||
- 模型库中能维护 OpenAI、Gemini 的基准模型、能力和价格。
|
||
- 管理员能配置平台、平台模型、折扣、限流和重试策略。
|
||
- 管理员能配置租户、用户、用户组、成员关系、充值折扣、调用折扣、TPM/RPM/并发策略。
|
||
- 普通用户能在模型页看到可用 Chat / 生图 / 图像编辑模型。
|
||
- API 文档能在线测试 Chat、生图、图像编辑。
|
||
- OpenAI 与 Gemini 的 Chat、生图、图像编辑至少各跑通一个端到端用例。
|
||
- estimated billing 与真实 billings 使用同一个 effective pricing resolver。
|
||
- 测试模式可模拟 Chat、生图、图像编辑的成功、可重试失败、不可重试失败。
|
||
- 任务进度写入 `gateway_task_events` 和 callback outbox，失败可重试和 replay。
|
||
|
||
## Phase 2：路由、队列与稳定性补强
|
||
|
||
- 从旧代码抽取以下行为测试：
|
||
- 同名模型平台权限过滤。
|
||
- `assignClientsByModelName` 候选排序。
|
||
- estimated billing 使用真实候选集。
|
||
- 建立 TPM/RPM/并发限流 fixtures，覆盖预占、释放、失败切换重新计数。
|
||
- Go 侧实现 router，并用 fixtures 对齐旧行为。
|
||
- 补齐持久化队列、任务租约、heartbeat、重启恢复、attempt 审计。
|
||
- 补齐租户、用户和用户组策略解析：`source + externalTenantId` 租户同步、`source + externalUserId` 用户同步、多组命中、优先级、策略合并、任务策略快照。
|
||
- 补齐 callback outbox、settlement outbox 的重试、死信和手动 replay。
|
||
|
||
## Phase 3：server-main 薄门面与灰度
|
||
|
||
- `server-main` 的 Chat、生图、图像编辑入口内部切到 Gateway HTTP SDK。
|
||
- 开启 shadow / dry-run，比对旧实现和 Gateway 的候选模型、预估扣费、参数预处理结果。
|
||
- 前端逐步增加 `VITE_GATEWAY_API_BASE_URL`，灰度切流核心接口。
|
||
- 观察任务成功率、平均排队时间、限流命中、扣费一致性、回调 outbox 滞留。
|
||
|
||
## Phase 4：视频与更多 provider
|
||
|
||
- 在 Phase 1 稳定后再迁移生视频、音频、Embedding、音乐、数字人等能力。
|
||
- 迁移 RunningHub、Jimeng、Vidu、Kling、Hunyuan Video、Suno 等 provider。
|
||
- 对 app-style provider 补 `assignClientsByProviderMethod` 和 `provider + methodName` 队列 key。
|
||
- 每个 provider 增加 contract test、retry classification test、billing snapshot。
|
||
|
||
## Phase 5：清理旧实现
|
||
|
||
- 删除或冻结 `server-main` 中重复的 runtime client。
|
||
- 保留必要 BFF、用户历史、账单、文件上传能力。
|
||
- 将旧 `integration-platform` 配置迁移脚本和回滚脚本固化。
|
||
|
||
## 风险控制
|
||
|
||
- 第一阶段不做视频和大量 provider，避免迁移面过宽。
|
||
- 不做 first-match 回退，所有候选选择都要有行为测试。
|
||
- 接入 `server-main` 模式下 API Key 不在 Gateway 落库；独立模式的本地 API Key、余额、充值订单和钱包流水在 Gateway 闭环。
|
||
- OSS 密钥不进入 Gateway；文件统一调用 server-main 开放上传接口。
|
||
- 租户、用户和用户组可由 Gateway 管理或从 server-main 同步；接入模式下充值执行、余额流水仍以 server-main 为事实源。
|
||
- 平台凭证和 provider 凭证当前阶段只允许全局管理员配置，不开放租户管理员自助维护。
|
||
- 业务前端实时进度仍走现有 WebSocket 网关；Gateway 只负责事件与回调 outbox。
|
||
- 平台模型没有自定义价格时必须 follow 基准模型，不能隐式按 0 计费。
|
||
- estimated billing 与真实结算必须使用同一个 effective pricing resolver。
|
||
- 结算事件必须幂等和可重试。
|
||
- 任务推送与余额/历史推送拆分，避免重新耦合回 server-main。
|