OceanWay 平台架构

当前执行原则与重点

2026-09-12 用户明确：大部分代码参考并优先复用 new-api，大部分现有接口直接沿用，当前技术栈与 new-api 完全一致；工作重点转为 Core 和 API Edge。多仓架构保持不变。

采用已核验的固定 new-api 版本作为代码与接口基线，优先保留原有路由、HTTP 方法、请求/响应字段、鉴权语义、分页与错误结构。主要工作是按职责提取、接入与补差，不重新设计全部 API。复用比例是实施原则，不是已完成的覆盖率；实际支持状态以迁移和兼容验证为准。

Core 承接客户管理与商业实现，Edge 承接模型 API 入口和流式处理。跨服务授权/预留/结算/查询及 OceanWay 商业差异才新增或调整接口。Contracts 接收现成规范并记录差异，不成为全量协议重写前置。

2026-09-12 最终决定：恢复第一版多仓库设计，直接修订第一版架构与各仓实施文档。Core、API Edge、Contracts 分仓，产品与网关各自维护；new-api 是重点实现参考，不再以一套深度二开的 oceanway-platform 单体作为整个共享后台。

本页是当前架构入口。单体二开和之前的候选方案已移入历史档案。第一版原文的字节快照仍保留，旧实现的验收不能自动算作本次新实现已完成。

Core 统一客户身份、Key 生命周期、模型销售目录、客户定价、积分与结算、持久调用和任务关联。
API Edge 负责公共模型 API 接入、请求校验、授权执行、流式转发和用量交接；客户账务只由 Core 写入。
Contracts 维护版本化接口、事件与生成客户端，不是业务服务或共享数据库。
独立 new-api 网关负责供应商、渠道、协议适配与执行，保持近上游；自研媒体网关保留独立维护边界。
Developer 是独立公开门户，Console 承担客户管理；Admin 为三人内部团队服务。企业首期专属账户与协议价，暂不做成员协作。
零售目标迁入 OceanWay 并保留旧价待遇，FDE 推荐使用统一平台；两类共享模型目录、客户价格不同，人民币充值、系统内积分。模型对接客户单列，允许不迁入，当前推荐暂留 uumi；sub2api 迁移后退役。见三类客户定价。
技术选型对齐 new-api，具体代码按职责参考和有界提取；不机械复制整个后台，不恢复旧 TypeScript 实现或过期协议限制。

Core 不逐片处理流式内容；模型执行期间不保持账务事务。产品业务数据不统一塞入 Core，也不能绕过客户授权使用供应凭据。

恢复的是第一版职责分仓。第一版曾规定文本和媒体网关不级联，后续用户明确模型请求统一通过 new-api 网关，当前采用后续边界；媒体协议需验证适配，不据此宣称所有模型已经接通。

产品页面、接口明细、原型和运维说明分别进入产品需求、接口规范、设计与原型、运行与运维。排期和执行任务见实施计划，完成证据见项目进度。

架构、需求、原型、代码、运行验证、上线分别记录。当前没有新 Go Core/Edge 的完整运行或容量验证证据。