TokenSeq 背后的网关——部署在你的域内。

接入（SDK、智能体与 CLI 工具、下游中转、自研应用）→ 边缘（TLS、声明式路由、会话亲和、健康探测）→ 数据面（文本、图像、视频服务，含计费与审计）→ 适配（每种上游协议一个纯函数适配器）→ 供给（一个渠道 = 一个上游账号）。控制面——管理端、控制台、单一配置存储——与之并列。

上游会缓存对话前缀。路由一旦漂移，缓存就白白浪费。网关把一段对话在其整个生命周期内固定在同一条链路上——缓存命中与负载均衡因此兼得，首字延迟与成本都得到改善。

由一条简短的关卡链决定每个请求：渠道与模型两级的启用开关、规格精确匹配，以及避开近期故障的渠道。每一跳都记录状态、原因与时间。故障渠道只降级，不停用：慢一点可以接受；无路可走不行。

每一层各自消化自己的那一份：边缘保持热连接并快速失败；进程层随实际获得的资源伸缩；租户层在读取任何请求体之前就执行并发与速率限制。流式响应不经缓冲直接透传。

• 图像按顺序报价 → 扣费 → 调用上游；一个订单，一条账目。上游故障会被统一翻译成稳定的错误码，由它决定退款、重试以及客户看到什么。生成的图像由我们自有存储以稳定地址提供。
• 视频我们承诺什么、如何判定、渠道当前接受什么，分别保存为三份独立规格——因此对外公布的规格绝不会悄悄宽于现实。任务在调用任何上游之前即已创建并计费；每一个后台失败都会以稳定的原因码退款。

按模态分别管理（渠道、定价、统计、档位、测试），结构对称；渠道生命周期涵盖接入、盲评、上架、定时巡检与自动暂停 / 恢复；每个管理操作同时也是一个 MCP 工具，智能体与运维人员走同一条路径。