769 lines
15 KiB
Markdown
769 lines
15 KiB
Markdown
# 量产版综合解决方案：媒体直连、任务网关、账本结算与代理兜底
|
||
|
||
## 1. 文档定位
|
||
|
||
这份文档是基于前面讨论进一步收敛出来的一版“量产优先”的综合方案。
|
||
目标不是追求理论上最轻，而是在下面几个维度同时拿到更好的平衡：
|
||
|
||
- 开发更便捷
|
||
- 安全性更高
|
||
- 更适合商业化和量产
|
||
- 不明显影响用户体感
|
||
- 服务器压力尽量小
|
||
|
||
这份方案相对于“设备直接调用方舟文本 API + 业务 token 切片”的版本，做了一个关键收敛：
|
||
|
||
`不让设备长期持有可直接消费方舟文本推理能力的真实主能力。`
|
||
|
||
也就是说：
|
||
|
||
- 媒体面尽量直连云侧
|
||
- AI 任务面由你的服务端托管
|
||
- 配额、续权、计量、结算由你的服务端统一掌控
|
||
- 长任务保留代理通道做兜底
|
||
|
||
---
|
||
|
||
## 2. 最终推荐结论
|
||
|
||
如果你要做量产交付，我建议采用这一版架构：
|
||
|
||
`媒体直连 + 任务网关 + 配额账本 + 长任务代理兜底`
|
||
|
||
一句话解释：
|
||
|
||
1. 设备可以直连低延迟媒体链路
|
||
2. 设备不直接持有长期方舟文本 API 能力
|
||
3. 所有高价值 AI 任务由你的服务端创建、放行、续权、停止和结算
|
||
4. 用户侧卖套餐能力，不直接卖 token
|
||
5. 用量以云侧回流为最终结算依据
|
||
|
||
这是我认为更适合商业化量产的原因：
|
||
|
||
- 对设备端更友好，开发边界更清晰
|
||
- 对服务端更可控，后续改套餐和风控不用动设备协议
|
||
- 对用户体感更稳，可以做自然边界续写和无感续权
|
||
- 对财务和运营更友好，能做账本、对账、客服排障和渠道分账
|
||
|
||
---
|
||
|
||
## 3. 为什么不直接沿用网页最后那套方案
|
||
|
||
网页最后那套方案的核心优点是：
|
||
|
||
- 链路短
|
||
- 服务器流量小
|
||
- 设备直连，用户体感好
|
||
|
||
但量产时它有四个硬伤：
|
||
|
||
### 3.1 设备端不可信
|
||
|
||
只要设备能直接消费方舟文本能力，理论上就总会面临：
|
||
|
||
- 固件被逆向
|
||
- 协议被重放
|
||
- 授权被抽取
|
||
- 请求被伪造
|
||
- 套餐控制被绕过
|
||
|
||
### 3.2 开发复杂度其实不低
|
||
|
||
看起来是“直连更轻”，但如果真的要补齐：
|
||
|
||
- 细粒度计量
|
||
- 低水位续权
|
||
- 中断恢复
|
||
- 长故事续写
|
||
- 用量回补
|
||
- 审计和客服排障
|
||
|
||
设备端和服务端两边都会变复杂。
|
||
|
||
### 3.3 商业化边界不够清晰
|
||
|
||
一旦你要支持：
|
||
|
||
- 不同套餐
|
||
- 多设备共享
|
||
- 家庭账户
|
||
- 渠道/OEM
|
||
- 试用版与正式版
|
||
- 企业版和标准版
|
||
|
||
“设备直连 + 业务 token 切片”会越来越难维护。
|
||
|
||
### 3.4 结算闭环不够硬
|
||
|
||
真正能拿来做最终扣费和纠纷处理的，不能是设备估算，必须是云侧真实用量。
|
||
如果设备可以绕开你的任务控制面，后续审计很容易出灰区。
|
||
|
||
---
|
||
|
||
## 4. 设计目标与非目标
|
||
|
||
### 4.1 设计目标
|
||
|
||
1. 用户说话和收听时延保持低
|
||
2. 套餐额度、续权和停用由你自己掌控
|
||
3. 设备端协议尽量稳定，后续套餐和规则升级尽量不改设备逻辑
|
||
4. 结算必须可追溯、可回放、可纠偏
|
||
5. 支持 1000 台到 1 万台设备平滑扩展
|
||
6. 支持后续做渠道版和企业版
|
||
|
||
### 4.2 非目标
|
||
|
||
1. 不追求所有能力都完全绕开服务端
|
||
2. 不追求把所有 token 精确暴露给最终用户
|
||
3. 不追求第一版就做极致复杂的租户隔离
|
||
|
||
---
|
||
|
||
## 5. 方案全貌
|
||
|
||
```text
|
||
设备
|
||
│
|
||
├─ 1. 设备认证 / 会话启动 / 续权 / 心跳
|
||
│ 走你的任务网关
|
||
│
|
||
├─ 2. RTC / 音频 / 媒体
|
||
│ 尽量直连云侧
|
||
│
|
||
└─ 3. 文本生成 / 故事生成 / 高价值任务
|
||
走你的任务网关或代理通道
|
||
|
||
你的服务端
|
||
│
|
||
├─ 设备身份中心
|
||
├─ 用户与套餐中心
|
||
├─ 任务网关
|
||
├─ 续权中心
|
||
├─ 配额账本
|
||
├─ 风控中心
|
||
├─ 用量归因与结算中心
|
||
└─ 运营与报表后台
|
||
|
||
云侧
|
||
│
|
||
├─ RTC / 媒体服务
|
||
├─ 方舟模型服务
|
||
└─ usage / task / bill 回流能力
|
||
```
|
||
|
||
---
|
||
|
||
## 6. 核心设计原则
|
||
|
||
### 6.1 媒体和任务分离
|
||
|
||
不要把“低延迟媒体链路”和“高价值 AI 计费链路”混成一个面。
|
||
|
||
建议划分：
|
||
|
||
- 媒体链路：尽量直连，追求低延迟
|
||
- 任务链路：服务端托管，追求控制权
|
||
|
||
### 6.2 设备侧只保存短期能力
|
||
|
||
设备最多保存：
|
||
|
||
- 设备身份凭证
|
||
- 当前会话的短期租约
|
||
- 当前任务的临时句柄
|
||
|
||
设备侧不应该保存：
|
||
|
||
- 长期主 API Key
|
||
- 可跨任务复用的高价值主能力
|
||
|
||
### 6.3 套餐卖能力，不卖底层计费单位
|
||
|
||
对用户展示：
|
||
|
||
- 月度陪伴时长
|
||
- 月度故事次数
|
||
- 高级模型次数
|
||
- 家庭共享设备数
|
||
|
||
内部映射：
|
||
|
||
- 预算单位
|
||
- 账本流水
|
||
- 云侧真实成本
|
||
|
||
### 6.4 真正的结算只认云侧回流
|
||
|
||
设备侧心跳和事件上报只能辅助判断：
|
||
|
||
- 在线状态
|
||
- 故障定位
|
||
- 体验追踪
|
||
|
||
不能拿来做最终结算真相。
|
||
|
||
---
|
||
|
||
## 7. 核心对象模型
|
||
|
||
### 7.1 设备身份
|
||
|
||
用于唯一识别一台量产设备。
|
||
|
||
建议字段：
|
||
|
||
- `device_id`
|
||
- `product_id`
|
||
- `firmware_version`
|
||
- `device_public_key`
|
||
- `activation_status`
|
||
- `risk_level`
|
||
|
||
### 7.2 用户订阅
|
||
|
||
用于控制套餐和可用能力。
|
||
|
||
建议字段：
|
||
|
||
- `user_id`
|
||
- `plan_id`
|
||
- `plan_start_at`
|
||
- `plan_end_at`
|
||
- `monthly_budget_units`
|
||
- `daily_budget_units`
|
||
- `max_active_devices`
|
||
- `max_active_sessions`
|
||
|
||
### 7.3 会话
|
||
|
||
一段连续的用户使用周期。
|
||
|
||
建议字段：
|
||
|
||
- `session_id`
|
||
- `device_id`
|
||
- `user_id`
|
||
- `session_type`
|
||
- `status`
|
||
- `started_at`
|
||
- `last_seen_at`
|
||
- `closed_at`
|
||
- `close_reason`
|
||
|
||
### 7.4 任务租约
|
||
|
||
这是这套方案的核心对象。
|
||
它不是云厂商 token，而是你自己的业务租约。
|
||
|
||
建议字段：
|
||
|
||
- `lease_id`
|
||
- `session_id`
|
||
- `user_id`
|
||
- `device_id`
|
||
- `task_type`
|
||
- `granted_units`
|
||
- `consumed_units_estimate`
|
||
- `soft_threshold`
|
||
- `hard_threshold`
|
||
- `grace_units`
|
||
- `expires_at`
|
||
- `state`
|
||
|
||
### 7.5 账本流水
|
||
|
||
所有额度变化必须流水化，而不是只存一份余额。
|
||
|
||
流水类型建议：
|
||
|
||
- `reserve`
|
||
- `consume`
|
||
- `release`
|
||
- `grace_consume`
|
||
- `refund`
|
||
- `manual_adjust`
|
||
- `settlement_delta`
|
||
|
||
---
|
||
|
||
## 8. 架构分层
|
||
|
||
## 8.1 设备侧模块
|
||
|
||
设备端建议只保留下面这些稳定模块：
|
||
|
||
1. 设备身份模块
|
||
- 保存设备身份和短期租约
|
||
2. 会话管理模块
|
||
- 开始、续权、结束、重连
|
||
3. 媒体模块
|
||
- 处理音频输入输出
|
||
4. 本地缓存与播放模块
|
||
- 缓冲流式文本、缓冲 TTS 播放
|
||
5. 状态上报模块
|
||
- 心跳、弱网状态、任务阶段
|
||
|
||
设备端不要自己做：
|
||
|
||
- 复杂套餐计算
|
||
- 最终结算
|
||
- 风控决策
|
||
- 多租户逻辑
|
||
|
||
## 8.2 服务端模块
|
||
|
||
### A. 设备身份中心
|
||
|
||
负责：
|
||
|
||
- 设备注册
|
||
- 激活
|
||
- 黑名单
|
||
- 固件版本治理
|
||
|
||
### B. 用户与套餐中心
|
||
|
||
负责：
|
||
|
||
- 订阅档位
|
||
- 套餐预算
|
||
- 设备绑定
|
||
- 家庭共享
|
||
- 试用和正式套餐切换
|
||
|
||
### C. 任务网关
|
||
|
||
负责：
|
||
|
||
- 会话启动
|
||
- AI 任务创建
|
||
- 模型路由
|
||
- 文本流式输出代理
|
||
- 任务停止与取消
|
||
|
||
### D. 续权中心
|
||
|
||
负责：
|
||
|
||
- 低水位续租
|
||
- 授权回收
|
||
- 租约失效
|
||
- 自然边界停机
|
||
|
||
### E. 配额账本
|
||
|
||
负责：
|
||
|
||
- 预算预占
|
||
- 实时估算扣减
|
||
- 最终结算
|
||
- 退款和纠偏
|
||
|
||
### F. 风控中心
|
||
|
||
负责：
|
||
|
||
- 单设备单活会话
|
||
- 请求速率限制
|
||
- 异常续权检测
|
||
- 风险分级处理
|
||
|
||
### G. 用量归因中心
|
||
|
||
负责：
|
||
|
||
- 接收云侧 usage 回流
|
||
- 归因到用户、设备、会话、任务
|
||
- 和账本做差异修正
|
||
|
||
---
|
||
|
||
## 9. 核心流程设计
|
||
|
||
## 9.1 设备激活
|
||
|
||
1. 设备首次启动，调用 `/device/activate`
|
||
2. 服务端下发设备身份和初始化配置
|
||
3. 设备绑定用户
|
||
4. 建立设备和用户关系
|
||
|
||
结果：
|
||
|
||
- 后续所有会话都可以挂到 `device_id + user_id` 上
|
||
|
||
## 9.2 开始一次会话
|
||
|
||
1. 设备调用 `/sessions/open`
|
||
2. 服务端校验：
|
||
- 设备有效
|
||
- 用户有效
|
||
- 套餐有效
|
||
- 当前并发不超限
|
||
- 风控未触发
|
||
3. 服务端创建 `session`
|
||
4. 服务端预占一笔预算
|
||
5. 服务端签发第一段 `lease`
|
||
6. 设备拿到可用会话句柄开始交互
|
||
|
||
## 9.3 正常生成
|
||
|
||
短任务流程：
|
||
|
||
1. 设备把请求发到你的任务网关
|
||
2. 任务网关决定模型、上下文、预算和任务类型
|
||
3. 任务网关调用云侧模型
|
||
4. 服务端把流式文本回给设备
|
||
5. 设备边播边显示
|
||
|
||
为什么这里不直接让设备调用云侧文本 API：
|
||
|
||
- 服务端才能稳定插入套餐控制
|
||
- 服务端才能统一做日志和风控
|
||
- 文本流量很小，代理成本远低于媒体流代理
|
||
|
||
## 9.4 低水位续租
|
||
|
||
设备本地不做最终计费，但可以做“估算预警”。
|
||
|
||
建议策略：
|
||
|
||
1. 当前租约只发一小段预算
|
||
2. 设备端收到服务端回传的预算阈值
|
||
3. 消费逼近低水位时，后台调用 `/leases/renew`
|
||
4. 服务端再次检查套餐余额和风险状态
|
||
5. 若可续，则下发下一段租约
|
||
6. 当前任务不阻塞
|
||
|
||
## 9.5 长故事续写
|
||
|
||
长故事和长文本不要按“耗尽就停”处理，而要按自然边界处理。
|
||
|
||
建议流程：
|
||
|
||
1. 服务端把故事拆成片段目标
|
||
2. 每一片都有独立租约预算
|
||
3. 到片尾或句尾时判断是否续租
|
||
4. 续租成功则继续下一片
|
||
5. 续租失败则在当前片自然结束时收口
|
||
|
||
这样用户的感知会明显更好。
|
||
|
||
## 9.6 grace quota 机制
|
||
|
||
为了避免“生成到一半突然断”，建议每个高价值任务都预留一小段 `grace_units`。
|
||
|
||
含义：
|
||
|
||
- 正常额度用完后，不立刻砍掉
|
||
- 允许把当前句、当前段或当前故事片收完
|
||
- 收完后再提示继续购买或等待下周期恢复
|
||
|
||
这部分一定要小，避免被长期滥用。
|
||
|
||
## 9.7 异常中断与重连
|
||
|
||
设备断网时：
|
||
|
||
1. 设备缓存最近的 `session_id` 和 `lease_id`
|
||
2. 恢复后调用 `/sessions/resume`
|
||
3. 服务端判断：
|
||
- 会话是否仍有效
|
||
- 租约是否仍有效
|
||
- 是否需要补发一段租约
|
||
|
||
## 9.8 结束与结算
|
||
|
||
1. 任务完成或用户主动结束
|
||
2. 设备调用 `/sessions/close`
|
||
3. 服务端标记会话结束
|
||
4. 云侧 usage 回流到服务端
|
||
5. 用量归因中心做最终结算
|
||
6. 账本释放未用完预占
|
||
7. 记录最终账单明细
|
||
|
||
---
|
||
|
||
## 10. 用户体验设计原则
|
||
|
||
## 10.1 不把续权做成显式动作
|
||
|
||
不要让用户看到：
|
||
|
||
- “正在续费中”
|
||
- “额度同步中”
|
||
- “请等待 token 刷新”
|
||
|
||
用户侧应该只感知：
|
||
|
||
- 正常继续
|
||
- 自然结束
|
||
- 结束后再提示套餐不足
|
||
|
||
## 10.2 所有中断都尽量在自然边界发生
|
||
|
||
自然边界包括：
|
||
|
||
- 一句话结束
|
||
- 一段故事结束
|
||
- 一轮语音回复结束
|
||
- 一个章节结束
|
||
|
||
## 10.3 设备侧必须有最小缓冲
|
||
|
||
为了避免轻微抖动造成体感卡顿，设备侧要有：
|
||
|
||
- 流式文本缓冲
|
||
- TTS 音频缓冲
|
||
- 最近一次租约状态缓存
|
||
|
||
## 10.4 续权失败的用户提示
|
||
|
||
不要提示“token 不足”。
|
||
建议提示业务语言：
|
||
|
||
- “本月故事额度已用完”
|
||
- “当前套餐已达上限”
|
||
- “请升级套餐继续使用”
|
||
|
||
---
|
||
|
||
## 11. 安全设计
|
||
|
||
## 11.1 基线原则
|
||
|
||
1. 设备不保存长期方舟主密钥
|
||
2. 所有租约都短期有效
|
||
3. 每次请求都有唯一 `request_id`
|
||
4. 设备请求必须带签名和时间戳
|
||
5. 所有可重放请求都要有去重机制
|
||
|
||
## 11.2 强制做的风控规则
|
||
|
||
- 单设备单活会话
|
||
- 单用户并发设备数限制
|
||
- 单 IP / 单设备 / 单账号速率限制
|
||
- 短时间异常高频续租熔断
|
||
- 固件版本黑名单
|
||
- 风险设备强制切代理通道
|
||
|
||
## 11.3 审计能力
|
||
|
||
至少保留以下审计链：
|
||
|
||
- 设备请求日志
|
||
- 会话启动日志
|
||
- 租约签发日志
|
||
- 云侧任务日志
|
||
- usage 回流日志
|
||
- 最终结算流水
|
||
|
||
这样客服和财务才能查账。
|
||
|
||
---
|
||
|
||
## 12. 商业化设计
|
||
|
||
## 12.1 用户侧套餐表达
|
||
|
||
建议对用户卖下面这些能力包：
|
||
|
||
- 基础版：短问答 + 基础陪伴
|
||
- 标准版：更多陪伴时长 + 更多故事次数
|
||
- 高级版：长故事、优先模型、更高并发家庭设备数
|
||
- 企业版：独立策略、独立配额池、独立报表
|
||
|
||
## 12.2 内部结算单位
|
||
|
||
内部不要只用一个 token 概念，建议统一成 `budget_units`。
|
||
|
||
映射规则举例：
|
||
|
||
- 1 次短问答 = X units
|
||
- 1 分钟语音陪伴 = Y units
|
||
- 1 次长故事片段 = Z units
|
||
|
||
真实云侧成本回来后，再做误差校准。
|
||
|
||
## 12.3 渠道/OEM 预留
|
||
|
||
从第一版就建议预留：
|
||
|
||
- `tenant_id`
|
||
- `channel_id`
|
||
- `plan_catalog`
|
||
- `billing_group`
|
||
|
||
这样以后做渠道版不用重构核心账本。
|
||
|
||
---
|
||
|
||
## 13. 数据模型建议
|
||
|
||
建议至少落下面这些表：
|
||
|
||
1. `device_registry`
|
||
2. `device_binding`
|
||
3. `user_subscription`
|
||
4. `plan_catalog`
|
||
5. `session`
|
||
6. `lease`
|
||
7. `quota_ledger`
|
||
8. `vendor_task`
|
||
9. `vendor_usage_raw`
|
||
10. `usage_settlement`
|
||
11. `risk_event`
|
||
12. `ops_adjustment`
|
||
|
||
### 核心关系
|
||
|
||
- 一个用户可以绑定多台设备
|
||
- 一台设备同一时刻只允许一个活跃主会话
|
||
- 一个会话可以有多段租约
|
||
- 多段租约统一归并到一次最终结算
|
||
|
||
---
|
||
|
||
## 14. 接口建议
|
||
|
||
第一版建议只做下面这组接口。
|
||
|
||
### 设备侧接口
|
||
|
||
- `POST /device/activate`
|
||
- `POST /device/login`
|
||
- `POST /sessions/open`
|
||
- `POST /sessions/heartbeat`
|
||
- `POST /leases/renew`
|
||
- `POST /sessions/close`
|
||
- `POST /sessions/resume`
|
||
|
||
### 云侧回调接口
|
||
|
||
- `POST /vendor/callback/task`
|
||
- `POST /vendor/callback/usage`
|
||
- `POST /vendor/callback/bill`
|
||
|
||
### 运营后台接口
|
||
|
||
- `POST /ops/device/blacklist`
|
||
- `POST /ops/session/terminate`
|
||
- `POST /ops/quota/adjust`
|
||
- `GET /ops/user/usage`
|
||
- `GET /ops/device/history`
|
||
|
||
---
|
||
|
||
## 15. 服务器压力控制思路
|
||
|
||
这套方案比全量代理轻，原因在于：
|
||
|
||
1. 媒体流不走你的服务端
|
||
2. 文本流量远小于音频/视频流量
|
||
3. 账本、续权、风控都是轻量 JSON 请求
|
||
4. usage 回流是异步的，不阻塞主链路
|
||
|
||
推荐压测关注点：
|
||
|
||
- `sessions/open`
|
||
- `leases/renew`
|
||
- 流式文本转发连接数
|
||
- usage 回调写库速度
|
||
- Redis 热键和并发锁
|
||
|
||
推荐基础组件：
|
||
|
||
- API 网关
|
||
- 应用服务
|
||
- Redis
|
||
- MySQL 或 PostgreSQL
|
||
- MQ
|
||
- 对象存储
|
||
- 可观测系统
|
||
|
||
---
|
||
|
||
## 16. 分阶段落地建议
|
||
|
||
## 第一阶段：可上线 MVP
|
||
|
||
先做：
|
||
|
||
- 设备激活
|
||
- 用户绑定
|
||
- 套餐档位
|
||
- 会话启动
|
||
- 低水位续租
|
||
- 单设备单活会话
|
||
- usage 回流
|
||
- 账本结算
|
||
|
||
## 第二阶段：量产增强
|
||
|
||
再补：
|
||
|
||
- 渠道/OEM
|
||
- 家庭账户
|
||
- 黑名单和熔断
|
||
- 运营后台
|
||
- 套餐促销和试用
|
||
|
||
## 第三阶段：企业化
|
||
|
||
最后补：
|
||
|
||
- 租户隔离
|
||
- SLA 分层
|
||
- 独立报表
|
||
- 分账能力
|
||
|
||
---
|
||
|
||
## 17. 这套方案最适合什么业务阶段
|
||
|
||
最适合：
|
||
|
||
- 正准备量产
|
||
- 需要卖套餐
|
||
- 设备长期在线
|
||
- 既有实时语音，也有高价值文本任务
|
||
- 后面可能要做渠道和企业客户
|
||
|
||
不那么适合：
|
||
|
||
- 纯内部测试 Demo
|
||
- 完全不考虑商业化
|
||
- 完全不在意设备破解风险
|
||
|
||
---
|
||
|
||
## 18. 最终建议
|
||
|
||
如果你要我给一个量产优先的单一结论，我的建议就是：
|
||
|
||
`不要做设备长期直连方舟文本 API。`
|
||
|
||
而要做：
|
||
|
||
`媒体直连 + 任务网关 + 配额账本 + 长任务代理兜底`
|
||
|
||
这是当前最平衡的一版：
|
||
|
||
- 比全量代理轻
|
||
- 比纯直连稳
|
||
- 比“设备直连 + 业务 token 切片”更适合量产和商业化
|
||
|
||
---
|
||
|
||
## 19. 后续建议继续补的文档
|
||
|
||
如果继续往下推进，下一批建议补：
|
||
|
||
1. 接口字段定义文档
|
||
2. 会话与租约状态机
|
||
3. 数据库表结构草案
|
||
4. 用户套餐与账本扣费规则
|
||
5. 异常流程和兜底时序图
|
||
6. 风控规则清单
|
||
|
||
这六样补齐后，就可以直接拆给开发排期了。
|