# 量产版综合解决方案：媒体直连、任务网关、账本结算与代理兜底 ## 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. 风控规则清单 这六样补齐后，就可以直接拆给开发排期了。