krisolo/boss

Fork 0

Files

kris 90cb6b7ff1 feat: ship native boss android console

2026-03-26 23:16:56 +08:00

15 KiB

Raw Blame History

量产版综合解决方案：媒体直连、任务网关、账本结算与代理兜底

1. 文档定位

这份文档是基于前面讨论进一步收敛出来的一版“量产优先”的综合方案。
目标不是追求理论上最轻，而是在下面几个维度同时拿到更好的平衡：

开发更便捷
安全性更高
更适合商业化和量产
不明显影响用户体感
服务器压力尽量小

这份方案相对于“设备直接调用方舟文本 API + 业务 token 切片”的版本，做了一个关键收敛：

不让设备长期持有可直接消费方舟文本推理能力的真实主能力。

也就是说：

媒体面尽量直连云侧
AI 任务面由你的服务端托管
配额、续权、计量、结算由你的服务端统一掌控
长任务保留代理通道做兜底

2. 最终推荐结论

如果你要做量产交付，我建议采用这一版架构：

媒体直连 + 任务网关 + 配额账本 + 长任务代理兜底

一句话解释：

设备可以直连低延迟媒体链路
设备不直接持有长期方舟文本 API 能力
所有高价值 AI 任务由你的服务端创建、放行、续权、停止和结算
用户侧卖套餐能力，不直接卖 token
用量以云侧回流为最终结算依据

这是我认为更适合商业化量产的原因：

对设备端更友好，开发边界更清晰
对服务端更可控，后续改套餐和风控不用动设备协议
对用户体感更稳，可以做自然边界续写和无感续权
对财务和运营更友好，能做账本、对账、客服排障和渠道分账

3. 为什么不直接沿用网页最后那套方案

网页最后那套方案的核心优点是：

链路短
服务器流量小
设备直连，用户体感好

但量产时它有四个硬伤：

3.1 设备端不可信

只要设备能直接消费方舟文本能力，理论上就总会面临：

固件被逆向
协议被重放
授权被抽取
请求被伪造
套餐控制被绕过

3.2 开发复杂度其实不低

看起来是“直连更轻”，但如果真的要补齐：

细粒度计量
低水位续权
中断恢复
长故事续写
用量回补
审计和客服排障

设备端和服务端两边都会变复杂。

3.3 商业化边界不够清晰

一旦你要支持：

不同套餐
多设备共享
家庭账户
渠道/OEM
试用版与正式版
企业版和标准版

“设备直连 + 业务 token 切片”会越来越难维护。

3.4 结算闭环不够硬

真正能拿来做最终扣费和纠纷处理的，不能是设备估算，必须是云侧真实用量。
如果设备可以绕开你的任务控制面，后续审计很容易出灰区。

4. 设计目标与非目标

4.1 设计目标

用户说话和收听时延保持低
套餐额度、续权和停用由你自己掌控
设备端协议尽量稳定，后续套餐和规则升级尽量不改设备逻辑
结算必须可追溯、可回放、可纠偏
支持 1000 台到 1 万台设备平滑扩展
支持后续做渠道版和企业版

4.2 非目标

不追求所有能力都完全绕开服务端
不追求把所有 token 精确暴露给最终用户
不追求第一版就做极致复杂的租户隔离

5. 方案全貌

设备
  │
  ├─ 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 设备侧模块

设备端建议只保留下面这些稳定模块：

设备身份模块
- 保存设备身份和短期租约
会话管理模块
- 开始、续权、结束、重连
媒体模块
- 处理音频输入输出
本地缓存与播放模块
- 缓冲流式文本、缓冲 TTS 播放
状态上报模块
- 心跳、弱网状态、任务阶段

设备端不要自己做：

复杂套餐计算
最终结算
风控决策
多租户逻辑

8.2 服务端模块

A. 设备身份中心

负责：

设备注册
激活
黑名单
固件版本治理

B. 用户与套餐中心

负责：

订阅档位
套餐预算
设备绑定
家庭共享
试用和正式套餐切换

C. 任务网关

负责：

会话启动
AI 任务创建
模型路由
文本流式输出代理
任务停止与取消

D. 续权中心

负责：

低水位续租
授权回收
租约失效
自然边界停机

E. 配额账本

负责：

预算预占
实时估算扣减
最终结算
退款和纠偏

F. 风控中心

负责：

单设备单活会话
请求速率限制
异常续权检测
风险分级处理

G. 用量归因中心

负责：

接收云侧 usage 回流
归因到用户、设备、会话、任务
和账本做差异修正

9. 核心流程设计

9.1 设备激活

设备首次启动，调用 /device/activate
服务端下发设备身份和初始化配置
设备绑定用户
建立设备和用户关系

结果：

后续所有会话都可以挂到 device_id + user_id 上

9.2 开始一次会话

设备调用 /sessions/open
服务端校验：
- 设备有效
- 用户有效
- 套餐有效
- 当前并发不超限
- 风控未触发
服务端创建 session
服务端预占一笔预算
服务端签发第一段 lease
设备拿到可用会话句柄开始交互

9.3 正常生成

短任务流程：

设备把请求发到你的任务网关
任务网关决定模型、上下文、预算和任务类型
任务网关调用云侧模型
服务端把流式文本回给设备
设备边播边显示

为什么这里不直接让设备调用云侧文本 API：

服务端才能稳定插入套餐控制
服务端才能统一做日志和风控
文本流量很小，代理成本远低于媒体流代理

9.4 低水位续租

设备本地不做最终计费，但可以做“估算预警”。

建议策略：

当前租约只发一小段预算
设备端收到服务端回传的预算阈值
消费逼近低水位时，后台调用 /leases/renew
服务端再次检查套餐余额和风险状态
若可续，则下发下一段租约
当前任务不阻塞

9.5 长故事续写

长故事和长文本不要按“耗尽就停”处理，而要按自然边界处理。

建议流程：

服务端把故事拆成片段目标
每一片都有独立租约预算
到片尾或句尾时判断是否续租
续租成功则继续下一片
续租失败则在当前片自然结束时收口

这样用户的感知会明显更好。

9.6 grace quota 机制

为了避免“生成到一半突然断”，建议每个高价值任务都预留一小段 grace_units。

含义：

正常额度用完后，不立刻砍掉
允许把当前句、当前段或当前故事片收完
收完后再提示继续购买或等待下周期恢复

这部分一定要小，避免被长期滥用。

9.7 异常中断与重连

设备断网时：

设备缓存最近的 session_id 和 lease_id
恢复后调用 /sessions/resume
服务端判断：
- 会话是否仍有效
- 租约是否仍有效
- 是否需要补发一段租约

9.8 结束与结算

任务完成或用户主动结束
设备调用 /sessions/close
服务端标记会话结束
云侧 usage 回流到服务端
用量归因中心做最终结算
账本释放未用完预占
记录最终账单明细

10. 用户体验设计原则

10.1 不把续权做成显式动作

不要让用户看到：

“正在续费中”
“额度同步中”
“请等待 token 刷新”

用户侧应该只感知：

正常继续
自然结束
结束后再提示套餐不足

10.2 所有中断都尽量在自然边界发生

自然边界包括：

一句话结束
一段故事结束
一轮语音回复结束
一个章节结束

10.3 设备侧必须有最小缓冲

为了避免轻微抖动造成体感卡顿，设备侧要有：

流式文本缓冲
TTS 音频缓冲
最近一次租约状态缓存

10.4 续权失败的用户提示

不要提示“token 不足”。
建议提示业务语言：

“本月故事额度已用完”
“当前套餐已达上限”
“请升级套餐继续使用”

11. 安全设计

11.1 基线原则

设备不保存长期方舟主密钥
所有租约都短期有效
每次请求都有唯一 request_id
设备请求必须带签名和时间戳
所有可重放请求都要有去重机制

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. 数据模型建议

建议至少落下面这些表：

device_registry
device_binding
user_subscription
plan_catalog
session
lease
quota_ledger
vendor_task
vendor_usage_raw
usage_settlement
risk_event
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. 服务器压力控制思路

这套方案比全量代理轻，原因在于：

媒体流不走你的服务端
文本流量远小于音频/视频流量
账本、续权、风控都是轻量 JSON 请求
usage 回流是异步的，不阻塞主链路

推荐压测关注点：

sessions/open
leases/renew
流式文本转发连接数
usage 回调写库速度
Redis 热键和并发锁

推荐基础组件：

API 网关
应用服务
Redis
MySQL 或 PostgreSQL
MQ
对象存储
可观测系统

16. 分阶段落地建议

第一阶段：可上线 MVP

先做：

设备激活
用户绑定
套餐档位
会话启动
低水位续租
单设备单活会话
usage 回流
账本结算

第二阶段：量产增强

再补：

渠道/OEM
家庭账户
黑名单和熔断
运营后台
套餐促销和试用

第三阶段：企业化

最后补：

租户隔离
SLA 分层
独立报表
分账能力

17. 这套方案最适合什么业务阶段

最适合：

正准备量产
需要卖套餐
设备长期在线
既有实时语音，也有高价值文本任务
后面可能要做渠道和企业客户

不那么适合：

纯内部测试 Demo
完全不考虑商业化
完全不在意设备破解风险

18. 最终建议

如果你要我给一个量产优先的单一结论，我的建议就是：

不要做设备长期直连方舟文本 API。

而要做：

媒体直连 + 任务网关 + 配额账本 + 长任务代理兜底

这是当前最平衡的一版：

比全量代理轻
比纯直连稳
比“设备直连 + 业务 token 切片”更适合量产和商业化

19. 后续建议继续补的文档

如果继续往下推进，下一批建议补：

接口字段定义文档
会话与租约状态机
数据库表结构草案
用户套餐与账本扣费规则
异常流程和兜底时序图
风控规则清单

这六样补齐后，就可以直接拆给开发排期了。

15 KiB Raw Blame History Unescape Escape

量产版综合解决方案：媒体直连、任务网关、账本结算与代理兜底

1. 文档定位

2. 最终推荐结论

3. 为什么不直接沿用网页最后那套方案

3.1 设备端不可信

3.2 开发复杂度其实不低

3.3 商业化边界不够清晰

3.4 结算闭环不够硬

4. 设计目标与非目标

4.1 设计目标

4.2 非目标

5. 方案全貌

6. 核心设计原则

6.1 媒体和任务分离

6.2 设备侧只保存短期能力

6.3 套餐卖能力，不卖底层计费单位

6.4 真正的结算只认云侧回流

7. 核心对象模型

7.1 设备身份

7.2 用户订阅

7.3 会话

7.4 任务租约

7.5 账本流水

8. 架构分层

8.1 设备侧模块

8.2 服务端模块

A. 设备身份中心

B. 用户与套餐中心

C. 任务网关

D. 续权中心

E. 配额账本

F. 风控中心

G. 用量归因中心

9. 核心流程设计

9.1 设备激活

9.2 开始一次会话

9.3 正常生成

9.4 低水位续租

9.5 长故事续写

9.6 grace quota 机制

9.7 异常中断与重连

9.8 结束与结算

10. 用户体验设计原则

10.1 不把续权做成显式动作

10.2 所有中断都尽量在自然边界发生

10.3 设备侧必须有最小缓冲

10.4 续权失败的用户提示

11. 安全设计

11.1 基线原则

11.2 强制做的风控规则

11.3 审计能力

12. 商业化设计

12.1 用户侧套餐表达

12.2 内部结算单位

12.3 渠道/OEM 预留

13. 数据模型建议

核心关系

14. 接口建议

设备侧接口

云侧回调接口

运营后台接口

15. 服务器压力控制思路

16. 分阶段落地建议

第一阶段：可上线 MVP

第二阶段：量产增强

第三阶段：企业化

17. 这套方案最适合什么业务阶段

18. 最终建议

19. 后续建议继续补的文档

15 KiB

Raw Blame History