实时语音入口
边录边传、实时转写、VAD 状态、最终文本提交，面向客服、调度、销售、现场作业等自然交互场景。
企业 AI 多模态接入与运营中台
让企业系统拥有像人一样接收信息的入口。
全模通小欧统一接入语音、图片、文件、文本和业务上下文，把多模态输入转成可治理、可编排、可收费、可回调的企业任务流。
小欧
实时语音
“帮我查一下这张单据现在到哪了”
自动编排
边说边传 → 实时转写 → 多模态入口 → 业务任务 → 系统回调
稳定发布治理
稳定版放量 · 候选版观察 · 异常立即回退
9.5 发布锚点
release anchor 已形成 · 门禁 100 分 · 线上当前版验收通过
Capabilities
不是单点模型调用，而是一层企业可控、可运营、可结算的多模态基础设施。
图片与文件解析
统一承接单据、图片、PDF、附件等输入，沉淀标准化结果和原始服务商输出，便于排障与审计。
服务商治理
多服务商配置、路由、健康检查、失败分类、回退策略和死信恢复，避免业务被某一个模型或厂商锁死。
商业闭环
按租户套餐、用量汇总、超额计费、账单草稿与发票流程收口，让 AI 能作为正式对外服务售卖。
Use Cases
适合先从高频、重复、信息入口复杂的业务切入。
物流订单、签收回单、异常工单、合同附件、客户语音需求、现场图片上报。
销售、客服、供应链、财务、人事、政企服务等需要把非结构化输入转成业务动作的团队。
已有业务系统，但缺少统一 AI 接入层、审计层、服务商治理层和计费层的企业。
Featured Chains
现在最适合先卖、先落地、先拿结果的 3 条主推链路。
先把高频链路打成可复用样板，比继续横向铺功能更值钱。
客服与企业助手实时语音
面向“怎么查订单、帮我新建客户、帮我查资料”这类高频短句场景，先用 realtime 打通输入，再叠加词库、final 修正和反馈回灌，把体验从能用拉到顺滑。
- 适合客服、销售、运营、内部助手
- 价值信号：响应更快、录入更轻、人工重复操作更少
- 交付姿势：先走 `pcm16 / 16000 / mono` 主链路，再补行业词包
物流单据与回单图片链路
把回单、面单、签收单、异常单照片统一进多模态入口，配合上传、异步任务、结果回调和后台排障，先把物流现场数据回传做成标准化流程。
- 适合物流、仓配、现场作业、配送履约
- 价值信号：资料回传更快、错漏更少、任务状态更可追
- 交付姿势：先走稳定上传 + task/result，再按单据类型扩 provider
票据与文档解析链路
把发票、表单、合同、附件等文档入口统一接到任务流，保留原始输出、标准化结果和审计链路，适合做财务、行政和业务资料收口。
- 适合财务票据、业务单证、合同附件流转
- 价值信号：录入成本下降、审计链更完整、可回调进系统
- 交付姿势：先做真实 provider 可用性，再补行业模板与字段映射
Case Playbooks
如果今天就要推进客户，这 3 套打法可以直接拿去讲。
每条都先做一条硬链路，不先承诺大而全。
01
实时语音助手 PoC
先让客户感受到“边说边有结果”，最快看到价值。
适合谁
客服、销售、运营、调度、企业内部助手，希望减少键盘输入和重复查询。
怎么接
先在开发者页跑 `Realtime Playground`，再按 `pcm16 / 16000 / mono + audioBase64 + audio.commit` 接进前端或中间层。
价值信号
更快录入、更自然交互、内部知识和业务动作能通过语音触发。
当前边界
先强调主链路稳定和行业词优化，不提前承诺所有噪声环境或所有口音都达到最终极致表现。
推荐套餐：试点版 / 成长版
02
物流单据回传闭环
先把照片、回单和异常单从现场拉回系统，再谈更深自动化。
适合谁
物流、仓配、配送履约、现场巡检、移动作业团队，需要现场图片与单据快速回传。
怎么接
优先用上传 + `multimodal-entries` + task/result/callback 做标准闭环，先让相机侧、异步任务和回调稳定落库。
价值信号
资料回传更快、异常更容易追、回单与任务状态能统一进入原有业务系统。
当前边界
先绑定少量高频单据类型和真实 provider，可用性跑稳后再扩 documentType 和字段映射。
推荐套餐：成长版
03
票据文档统一解析
先把分散文档入口收成一条标准任务流，再叠加字段治理和审计。
适合谁
财务、行政、法务、合同管理、表单资料流转类团队，需要稳定接入图片、PDF、附件等文档输入。
怎么接
先锁定 1-2 类高频文档，走 ingestion/task/result 主链，再把标准化结果和原始 provider 输出一起回传。
价值信号
减少人工录入、提高可追溯性、让外部文档进入系统时就带审计和状态管理。
当前边界
不要先承诺“所有票据模板通吃”，应先按行业模板、字段集和路由策略逐步扩展。
推荐套餐：成长版 / 企业版
Delivery Language
销售、实施、客户三方，最好统一用这一套成交口径。
少讲平台想象力，多讲主链路、验收口径和当前边界。
销售怎么讲
- 先讲场景，不先讲平台有多少模块
- 先讲接入后能省什么、快什么、稳什么
- 先卖 1 条主链路，不先卖大而全
- 边界要讲清楚，不提前承诺全场景成熟
实施怎么做
- 先锁 1 个输入场景和 1 条主链路
- 先锁验收口径，再开始接业务系统
- 先把回调、排障、重试、死信路径跑通
- 主链路稳定后再补词库、纠错和行业模板
客户该知道什么
- 现在最稳的是既定主链路，不是所有链路一起放量
- 先试点、先跑真实样本，再决定扩大范围
- 最终效果取决于输入质量、业务词库和真实样本治理
- 当前适合说“可接、可测、可试商用”，不是“全场景最终成熟”
统一推荐话术全模通是企业多模态输入底座。当前先把实时语音、物流单据、票据文档三条主链路打成可交付样板，再按场景继续扩深。
统一边界话术9.5 release anchor 已形成，主场景证据、商用门禁和发布锚点已齐；但不应宣传所有公网节点都已切到最新 tag，线上切换仍以正式部署记录为准。
Acceptance Metrics
什么叫“这条链路已经过线”，最好先看这些量化基准。
这是当前官网、试点和实施阶段都适合引用的最小验收口径。
实时语音主链
- success rate 建议 `>= 85%`
- weak audio rate 建议 `<= 20%`
- noisy risk rate 建议 `<= 25%`
- 联调单次健康分建议 `>= 90`，回归平均建议 `>= 85`
异步任务闭环
- dead letters 建议为 `0`
- failed callbacks 建议为 `0`
- 高频任务类型应已有真实结果样本
- 失败任务应能回放、追踪和排障
商用放量前
- `quality:commercial` 已通过
- 主场景 reported = `3/3`
- 最弱场景覆盖率建议 `>= 0.8`
- 当前 provider 不应存在建议回滚项
Commercial
先跑业务，再跑规模，再跑营收。
适合单团队验证。含多模态入口、基础实时语音和后台运营能力。
适合正式生产。含更高实时语音分钟数、任务量和商用对接支持。
适合集团级、多租户和专属 SLA 场景，支持定制实施、私有化和专属运维。
收费逻辑基础套餐费 + 超额用量费
结算方式月结 / 季结 / 年结 / 项目制
交付方式开放 API / 官网入口 / 后台管理台
收款方式人工开票先落地，后续可接在线支付
发布策略稳定版承接生产流量，候选版先观察，异常版本有明确回退目标。
交付信号不只看“能不能跑”，还看健康分、回调失败、死信与发布结论是否达标。
Integration
官网地址和 API Key 给到你的业务系统，就能接入。
官网
https://omnimodal.shenliu.cc
API Base URL
https://omnimodal.shenliu.cc/api
鉴权 Header
x-omnimodal-api-key: 你的租户密钥
适合方式
建议由你的后端调用，避免把密钥暴露在公开前端。
开发者入口
/developers/ 提供快速开始、curl 示例和接口清单。
Controlled Evidence
对外不是只发一句“能接”，而是发一份受控证据，把当前能力和边界一起讲清楚。
这套材料适合给客户、销售、实施和合作方统一对齐口径。
证据页
把主推样板、Readiness、商用门禁、部署证据、量化口径和当前边界一次性摊开，不再靠口头描述当前进度。
- 适合客户初看、销售推进、实施对齐
- 支持受控分享、访问记录、撤销和过期治理
- 只代表当前快照窗口，不替代后台和全局结论
开发者页
先跑最小可用链路，再看 Realtime Playground、curl 示例、OpenAPI 和联调验收，不要一上来就自己猜协议。
- 先开通租户，再带 `x-omnimodal-api-key` 调用
- 先用联调台确认 partial、final、ACK 和健康分
- 主实时链路优先 `pcm16 / 16000 / mono`
交付简报
把接入顺序、正式主链路、回调规则、错误码和当前边界收成一页，适合直接发给客户技术负责人、实施和外部研发。
- 适合销售、实施、客户技术负责人统一口径
- 支持直接复制、下载 Markdown、作为对外交付材料
- 解决“网址和 key 给了，但别人还是不知道怎么接”的问题
现在该怎么讲
可以讲“公网可接、主场景证据已齐、商用门禁已通过、进入稳定放量准备阶段”；不要直接讲“所有场景都已最终成熟”。
- 先卖 1 条主链路，不先卖大而全
- 先拿真实样本和验收结果，再扩大范围
- 先看当前证据，不用旧截图或旧说法覆盖现状
How To Start
第一次接入，先这样用，不要一上来就自己猜协议。
先开通租户
去官网自助开通，拿到 `tenantId` 和首个 `x-omnimodal-api-key`。这是所有联调的起点。
先用联调台验收
先到开发者页的 `Realtime Playground` 开麦，看 partial、final、ACK 和服务端诊断，不要先盲接业务前端。
再接你的系统
确认公网主链路通后，再把 SDK 或 WebSocket 协议接到你的前端和后端，避免把错误混在一起。
最后做业务优化
当实时链路已经稳定，再补热词、词典、最终精修和错词纠正，把准确率从“可用”拉到“商用”。
优先使用 `pcm16 / 16000 / mono`，`audio.append` 用 `audioBase64`，每片 `sequenceNo` 单调递增，结束时显式发送 `audio.commit`。
不要把所有音频片都发成同一个 `sequenceNo`，不要只关 socket 不发 `commit`，也不要把 `audioBase64` 错写成其他字段。
Current Status
现在已经不只是“能接能测”，而是 9.5 级发布锚点已经形成。
现在已经有公网官网、开发者页、OpenAPI、自助开通、实时语音联调台、浏览器 SDK。
实时语音现状主链路已打通，前端按协议发送后可以实时返回 partial / final transcript。
场景证据现状`daily_life / life_services / business_work` 三条主场景都已有真实 run 和 readiness 证据。
商用门禁现状`quality:commercial`、`quality:hardening`、`stable-candidate` 已通过，release readiness 已达到 `100 / ready_for_9_5_claim`。
发布锚点现状本地 tag `omnimodal-9.5-anchor-20260504` 已形成；当前线上 release 已通过 post-deploy verify。
当前重点优化线上切换记录、真实 provider 长期成本/延迟、真实麦克风样本、OCR 高风险字段和宿主 trace 的持续观察。
发布治理现状后台已支持稳定版、候选版、回退目标和发布结论归档，不再只是手工拍脑袋放量。
适合怎么宣传可以说“9.5 发布锚点已形成，主链路和商用门禁已完成锚定”；不要直接说“所有公网环境都已切到最新 tag”。
Release Strategy
正式商用不是“一次性全量上线”，而是先过门禁，再进稳定版、候选版和回退体系。
当前仓库侧已经形成 `omnimodal-9.5-anchor-20260504` 发布锚点，release readiness 达到 `100 / ready_for_9_5_claim`。
当前线上 release 已通过 post-deploy verify，API、console、worker、MySQL、cache 和 realtime deep probe 均通过本机发布后验收。
稳定版：默认承接生产流量，对外宣传和交付应以当前稳定主链路为准。
候选版：适合少量租户、专项语料和行业场景打磨，不应直接替代稳定版全量放开。
回退目标：一旦准确率、健康分、死信或回调失败明显回落，应优先切回上一个稳定结论对应版本。
发布结论：后台已经支持记录观察结论、准入决定和回退依据，商用交付时不再靠口头判断；线上是否切到最新 tag，仍以正式部署记录为准。
Pilot Readiness
客户愿意试，通常不是因为你功能多，而是因为你把试点怎么交、怎么验、谁负责什么说清楚了。
这一段就是把“愿意聊”推进到“愿意开 PoC”的最小交付清单。
试点只做 1 条主链路
- 先锁 1 个输入场景，如实时语音、物流单据或票据文档
- 先锁 1 套接入方式，不同时铺多条协议和多条业务流
- 先锁 1 套验收口径，再决定是否扩大范围
客户和全模通各自要做什么
- 客户提供真实样本、业务目标、回调地址和接入窗口
- 全模通负责联调、诊断、词包建议、链路验收与边界说明
- 先把链路跑顺，再谈更深行业模板和自动化
试点结束看这几项
- 是否已跑通主链路和真实样本
- 是否已有可复看的量化结果和证据快照
- 是否能明确下一步是扩量、补词包还是继续观察
- 一个明确业务场景和一组真实样本
- 一个接入系统或测试环境
- 一个验收负责人和一个技术联系人
- 如果走回调，要提前准备可达回调地址
- Realtime 是否稳定返回 partial / final
- 异步任务是否有 dead letter / callback failure
- 弱音频、噪声、低置信度是否被明确标记出来
- 证据页能否完整展示当前样板和边界
- 一份受控证据快照
- 一份“可以讲什么/不能讲什么”结论
- 一份下一阶段建议：扩量、补词包、进候选版或继续观察
- 一份客户侧 ROI 或效率改善信号
Flow
给客户、合作方、内部项目，统一按这 4 步接入。
第一步官网自助开通，拿到 `tenantId` 和 `x-omnimodal-api-key`。
第二步先到开发者页 `Realtime Playground` 联调，确认 partial、final、ACK 和服务端事件都正常。
第三步按开发者页 SDK 或协议接你的系统，优先走 `pcm16 / 16000 / mono` 主链路。
第四步联调通过后，再补热词、词典、最终精修和业务纠错，把准确率继续往上推。
FAQ
第一次接入最常见的 4 个问题。
为什么我前端明明发了很多片，但服务端没结果？先看 `audio.ack.lastAckedSequenceNo` 有没有持续增长，很多时候是 `sequenceNo` 没递增或补发逻辑错了。
为什么会“能识别但不够准”？先排除弱音频和协议问题，再看热词、业务词典、最终精修和场景化纠错。
第一次接实时语音，最稳的接法是什么？`pcm16 / 16000 / mono + audioBase64 + 递增 sequenceNo + audio.commit`。
如果只想先证明能跑通怎么办？不要先写业务代码，先去开发者页联调台直接开麦验证公网主链路。
Choose Your Path
不同类型的客户，直接走不同路径，不要把时间花在错误入口上。
你有前后端工程师、能自己调 API、目标是 1-3 天内先跑通体验。建议直接自助开通，先用 `Realtime Playground` 验证，再按 SDK 和协议接入。
你要接 ERP、CRM、客服、订单、文档流，或者要多租户、SLA、私有化、正式商用交付。建议直接走试用申请和商务方案，不要先自己硬接。
如果你只想先证明“语音/图片/文档能不能接进业务”，建议先跑一个最小 PoC：开通租户、接 1 条实时语音、接 1 条文本入口、拿到 1 个真实业务结果。
如果你关心准确率、审计、计费、词典、精修、热词、权限和后台运营，那你需要的已经不是简单试用，而是完整实施路径。官网现在能试，但正式收口要一起做方案。
Apply
提交试用或商机申请，我们把你拉进正式开通流程。
Pilot Summary
根据当前信息，给你一份可直接讨论的试点摘要。
实时语音助手 / 企业助手短句场景
先联调，再进 1 条主链路试点，不要同时铺多个系统和多个输入场景。
3-7 天完成联调和首轮样本验证。
受控证据快照、接入结论、下一阶段建议。
Self Serve