数字人API和二次开发：企业怎么集成

公司已经有了自己的应用，会员在里头查订单、约服务，现在想在页面里放一个会说话的数字人客服。产品经理问了几个供应商，对方都说可以提供接口。接口这两个字听起来简单，真做起来涉及形象怎么传、声音怎么回来、网络断了怎么办。这篇不讲代码，只讲决策：数字人接进自有系统有几种深度、每一步会遇到什么、怎么判断供应商的接口是不是能用。

接口到底是什么

用餐厅打比方最容易懂。订阅式工具是自己去餐厅吃饭，你坐在店里，菜端上来就吃，厨房怎么运作你不用管。接口则是餐厅给你开了一个外卖窗口，你下单、它出餐，你把餐拿走，摆在哪儿卖是你的事。技术上，接口就是一套约定：你按格式发一段文字或一段语音过去，对方按格式回一段音频或一段视频流回来。二次开发则是在这个窗口之外，还要改造自己的店面，比如菜单要重做、收银要打通、配送路线要规划。理解这一层，你就知道接口本身不难，难的是把它嵌进现有业务。

三种集成深度

第一种最轻，叫嵌入播放。供应商给你一个网页地址或一段小程序组件，你把它放进页面里，用户点开就能对话。改动最小，通常几天能上线，缺点是界面和交互都得按对方的来，样式改不了。第二种是接口调用，你自己做界面，只调用对方的能力，文字进去、音频或视频出来。灵活度高，但要自己处理网络、重试、状态管理。第三种是深度定制，形象、话术、资料库、业务流程全部按你的要求改造，甚至把模型部署到你自己的环境里。这三种的成本和周期差着数量级，选之前先想清楚：你要的是一个能对话的窗口，还是一个属于自己产品的角色。选深度时也可以倒着想：先确定用户在哪儿看见它、要它干什么，再倒推需要哪种深度，比从技术能力出发更容易收敛。

接进应用和小程序的真实链路

一条完整的链路大概是这样：用户在小程序里按住说话，前端把录音上传，服务端做语音识别转成文字，文字送到大模型结合你的资料库生成回答，回答再送去合成语音、驱动形象，最后把音视频流推回前端播放。中间任何一环慢了，用户就会觉得卡。小程序还有额外限制，比如包体积、后台运行、音视频权限，实时视频流在小程序里的表现往往不如原生应用。所以很多团队的做法是降级：小程序里只做语音加静态形象，原生应用或网页端才上完整视频。降级不是偷懒，是对体验负责。

四个容易翻车的地方

第一是延迟，文字回答很快，但合成语音加驱动形象可能要一两秒，加起来超过三秒用户就开始怀疑是不是坏了。第二是并发，测试时一个人用很流畅，上线后十个人同时问就排队。第三是异常处理，网络断了、模型超时了、识别错了，界面要给出人话提示，而不是一直转圈。第四是内容边界，用户会问各种奇怪的问题，没有兜底策略就会答出不该答的话。这四点里，前两点靠压测发现，后两点靠设计解决。签合同前一定要做一次真实流量的压测，别只看演示。还有一笔隐形成本常被漏算，就是对接人力，联调往往要占掉一个后端一到两周，排期时别只算采购周期。

评估接口的五个问题

和供应商谈的时候，把这五个问题挨个问一遍，答案能筛掉一大半。

• 接口是同步返回还是异步回调，最长要等多久
• 并发上限是多少，超出后是排队还是拒绝
• 形象和声音的资产归谁，能不能迁移到别家
• 资料库支持什么格式导入，更新后多久生效
• 出故障时有没有状态码和日志，能不能追溯

这五个问题都不涉及价格，但都决定项目能不能顺利上线。愿意认真回答的供应商，通常工程能力也不会太差，值得往下谈。

集成这件事，先做一条最短的链路跑通，再谈优化。给自己定一个两周的小目标：让一个真实用户在你的页面里问出一句话，并且听到回答。跑通之后再谈并发和体验优化。