政务 AI 数字人开发实战：拆解明泰自助易AI数字人的双集成架构与 Agent 交互协议
如何让 AI Agent 与已有应用前端 UI 高效、可靠地交互，是当前 AI 应用开发绕不开的难题。本文基于明泰智能"自助易"AI 数字人开发套件 AVATAR STUDIO 的技术方案，从集成架构、交互协议到核心能力逐层拆解，给正在做政务类系统 AI 化改造的开发者一份可落地的参考。
TL;DR
-
AVATAR STUDIO 提供 WEB 应用集成架构与非 WEB 应用集成架构两条路线，以 API 方式集成，跨操作系统、应用平台和开发语言；
-
两套架构共用同一个后端接口规范（APP AGENT API），不重构已有 APP 流程是贯穿始终的集成原则；
-
在 HTTP / WebSocket 之上，它为智能体设计了一个事件驱动的抽象层，解决长时运行、非确定性 UI 控制、混合 I/O、复杂组合四大挑战；
-
AVATAR STUDIO 是明泰智能推出的数字人开发套件，全栈跑在信创硬件（飞腾 CPU + 昇腾 NPU）上，数据全程留在本地，满足政务场景的安全合规要求。
一、先说清楚：这里的 APP 不是手机 APP
进入技术细节前，先统一术语。本文中的 APP 泛指一切应用程序（APPLICATION）——可以是网页、电脑程序、小程序或者手机 APP，客户侧设计的内容（前端界面、业务服务）均属于 APP 范畴。
要集成的对象，就是明泰智能的"自助易"AI 数字人。它集成了听、说、看、思、行五大 AI 能力，而 AVATAR STUDIO 则是面向开发者的开发平台：开箱即用、全本地信创环境，AI 开发、部署和运维一站式完成。
二、为什么传统 REST API 撑不起 Agent 交互
传统 Web 开发中，客户端和服务端遵循简单的请求-响应模型：客户端发起请求，服务器返回数据，客户端渲染，交互结束。
Agent 智能体打破了这一模型。它的工作过程是持续的、输出是不可预期的、数据形态是混合的、调用关系可能是递归的——这四个特性恰好对应传统 REST/GraphQL API 的四个短板：
| Agent 智能体特性 | 带来的挑战 | AVATAR STUDIO 的解决方案 |
|---|---|---|
| 长时运行与流式传输 | 工作过程持续进行，需要实时反馈中间步骤 | 基于标准的流式通信，实时同步思考过程与状态 |
| 非确定性与 UI 控制 | 行为和输出不可预期，甚至能动态控制前端 UI | 标准化 UI 意图与状态流，支持生成式 UI |
| 混合 I/O | 同时处理非结构化文字、语音、图像与结构化的工具调用、状态更新 | 统一的事件模型，在一个流中处理所有类型的数据 |
| 复杂组合 | 智能体可能调用子智能体，甚至递归调用 | 支持智能体的状态和事件同步 |
AVATAR STUDIO 的解题思路是在 HTTP、WebSocket 等基础协议之上再封装一层专为智能体设计的抽象层，弥合传统客户端-服务器架构与动态、有状态 AI 智能体之间的鸿沟。
三、AVATAR STUDIO 由什么组成
先看全景。作为明泰智能面向开发者交付的自研套件，AVATAR STUDIO 是一套"硬件 + 软件包 + 平台工具"的完整技术栈：
从下往上看：
-
AVATAR SERVER（信创 AI 算力一体机）：飞腾 CPU + 昇腾 NPU，硬件底座国产化；
-
运行与运维层：MANAGE PANEL 管理面板、DOCKER 容器管理平台、KVM 远程运维工具；
-
AVATAR PACKAGE（AI 数字人软件包）：包含 ASR 语音识别、TTS 文本转语音、LLM 大语言模型、VLM 视觉语言、EMBEDDING 嵌入、RARANK 重排等全套模型，以及数字人平台三件套：
-
AVATAR ENGINE（数字人引擎）：负责用户交互界面，包括语音输入输出、文字输入输出、形象输出、导航条输入输出、（自动）交互开始/结束；
-
AVATAR PY（数字人 PIPELINE）：语音识别 → 对话管理智能体 → 语音、文字、导航条输出 → 形象输出的全链路编排；
-
AVATAR AGENT（对话管理智能体）：输入翻译 → 接话判断 → 输入内容审核 → 知识库检索/APP 智能体 → 输出内容审核 → 输出翻译；
-
扩展模块（另付费）：APP AGENT 智能体设计平台、KNOWLEDGE BASE 知识库管理平台、OPS 运行日志平台、HA 人工辅办平台、NEC 语音/CV 会话智能标注纠正工具、AIOT 设备与广告管理平台等，按项目需要选配。
四、WEB 应用集成架构：5 个组件 + 3 种玩法
如果目标应用是网页、自助终端、小程序或基于 H5 套壳的手机 APP，走 WEB 应用集成架构。它的特点是同时提供两种交互方式——原有的应用交互方式 + 新的 AI 数字人交互方式。
整个架构由 5 个组件构成，职责与连接关系如下：
| 组件 | 角色 | 关键连接关系 |
|---|---|---|
| AVATAR UI | AI 数字人用户交互界面 | 与用户直接交互；通过 PostMessage 与 WEB UI 互传消息；与 AVATAR AGENT 通信 |
| WEB UI | 应用用户交互界面（集成商） | 处理业务操作；与 APP SERVER 通信获取处理结果 |
| AVATAR AGENT | "自助易"AI 数字人后端代理 | 接收 AVATAR UI 的用户输入；通过后端 API 与 APP AGENT API 通信 |
| APP AGENT API | 应用智能体接口服务（集成商） | 数字人代理与集成商后端之间的桥梁，处理业务逻辑和数据交换 |
| APP SERVER | 应用服务（集成商） | 执行核心业务逻辑，接收和回复来自 WEB UI 与 APP AGENT API 的请求 |
前后端之间的协议非常轻量：AVATAR UI 与 WEB UI 之间通过浏览器原生的 PostMessage 通信——WEB UI 既能把要播报的内容推给数字人，也能接收用户在数字人侧输入的信息。
// PostMessage 通信示意（实际事件结构以官方 API 文档为准）
// ① WEB UI → AVATAR UI：通知数字人播报
iframe.contentWindow.postMessage({
type: "AVATAR_SPEAK", // 播报指令
text: "您的业务已受理完成", // 播报文本
nav: { label: "返回首页" } // 可选：导航条指令
}, "*");
// ② AVATAR UI → WEB UI：回传用户在数字人侧的输入
window.addEventListener("message", (e) => {
if (e.data.type === "USER_INPUT") {
// 用户语音/文字输入或导航条点击，交由业务前端处理
handleUserInput(e.data.payload);
}
});
基于这套架构，官方给出 3 种典型应用方式，可组合使用，基础原则是不重构已有的 APP 流程：
-
方式1：加播报——在已有应用中加入 AI 数字人的语音播报。用户与 APP UI 交互，WEB UI 通过 PostMessage 通知 AVATAR UI 播报内容；
-
方式2：数字人反向控制界面——用户与 AVATAR UI 交互（如点击数字人导航条），AVATAR UI 发通知给 WEB UI，WEB UI 与 APP SERVER 通讯获取回复并呈现，再通过 PostMessage 通知 AVATAR UI 播报；
-
方式3：数字人作为语音交互入口——用户直接与 AVATAR UI 咨询或查询，请求经 AVATAR AGENT → APP AGENT API → APP SERVER 逐层传递后原路返回。
方式 3 是最完整的链路，也最能体现"数字人是应用的一个语音交互 UI"这一定位。它的完整数据流向如下：
注意一个对集成商非常友好的设计：无论选哪种方式，集成商在后端唯一需要对接的就是 AVATAR AGENT 与 APP AGENT API 之间的后端 API（上报用户音频/文本、导航点击，接收回复文本或导航栏内容）。
五、非 WEB 应用集成架构：两条前端通道
目标应用如果是桌面程序、原生 APP 等非浏览器环境，则走非 WEB 应用集成架构。组件角色与 WEB 版一致（AVATAR UI / APP UI / AVATAR AGENT / APP AGENT API / APP SERVER），区别在于前端通信不再依赖 PostMessage，而是换成了两条专用通道。
-
前端播报 API：APP UI 通过它通知数字人播报应用内容；
-
前端轮询 API：APP UI 通过它查询用户与 AVATAR UI 的交互内容（因为非浏览器环境没有事件推送机制，采用轮询获取）。
对应地也有 3 种应用方式，逻辑与 WEB 版一致：
-
方式1：用户与 APP UI 交互，APP UI 通过前端播报 API 通知 AVATAR UI 播报内容；
-
方式2：用户与 AVATAR UI 交互 → AVATAR UI 发请求给 AVATAR AGENT → APP UI 通过前端轮询 API 获得交互内容 → APP UI 与 APP SERVER 通讯获取回复并呈现 → 通过前端播报 API 通知 AVATAR UI 播报；
-
方式3：与 WEB 版完全一致——AVATAR AGENT 与 APP AGENT API 通讯，APP AGENT API 与 APP SERVER 通讯，回复原路返回 AVATAR UI。
后端接入方式与 WEB 版相同——这是明泰智能在集成设计上给集成商做的一次"降压"：一次后端对接、两类前端复用。
六、一次语音咨询的完整链路
把组件串起来看，一次真实交互在系统内部的流动路径如下。
用户对着终端说出一句话后，数据沿 AVATAR PY 编排的 PIPELINE 单向流动：
-
ASR 语音识别把语音转成文本；
-
AVATAR AGENT（对话管理智能体）接手，内部经过六步处理：输入翻译 → 接话判断 → 输入内容审核 → 知识库检索 / APP 智能体 → 输出内容审核 → 输出翻译。两次内容审核前置拦截违规输入、后置校验输出口径，知识库与客户智能体在中间环节按需调用；
-
产出语音、文字、导航条输出等多形态回复；
-
AVATAR ENGINE 驱动数字人形象完成播报呈现。
这条链路全程在本机信创环境内完成，无公网依赖。
七、八大核心能力：智能体应用的交互积木
AVATAR STUDIO 通过八个核心构建模块，赋予智能体应用完整的交互能力：
| 能力 | 说明 |
|---|---|
| 流式聊天（Streaming Chat） | 实时传输智能体的文本输出 |
| 多模态（Multimodality） | 支持文本、图像、语音等多种形式的消息传输 |
| 生成式 UI（Generative UI） | 智能体可根据需要动态生成或修改用户界面元素 |
| 共享状态（Shared State） | 前端和后端智能体共享和同步应用状态 |
| 思维步骤（Thinking Steps） | 实时展示智能体的思考过程，增强用户信任和可调试性 |
| 工具调用（Tool Calls） | 标准化智能体调用工具的流程，包括前端工具调用和后端工具渲染 |
| 中断感知（Interrupts） | 支持用户在智能体运行过程中进行干预 |
| 自定义事件（Custom Events） | 支持应用特有的事件传输 |
对开发者来说，这八个能力基本覆盖了一个对话式 AI 应用的完整生命周期：从流式输出、思维可视化，到工具编排、异常打断，再到业务自定义事件扩展，不需要再为每个项目临时发明一套连接逻辑。
八、政务场景的底座：安全、合规、标准化
技术方案之外，政务项目还有硬性门槛。"自助易"AI 数字人的联合方案围绕三个关键词构建：
安全
-
软硬件一体化，敏感数据本地运行；
-
内网/专网部署，拒绝公网接口；
-
实时监控和日志审计；
-
符合《AIGC 暂行办法》和《生成式人工智能服务安全基本要求》。
合规
-
国产信创 CPU / 操作系统 / 数据库；
-
AI 算法和模型备案；
-
版权合规。
标准化
-
昇腾技术认证；
-
适配国产大模型；
-
API 标准化集成；
-
智能客服 / 智能导办 / 智能经办均有成熟样板。
落到架构选型上，就是一条原则、两条路线：不重构已有的 APP 流程；WEB 应用走 WEB 集成架构，非浏览器环境走非 WEB 集成架构，两套架构共用同一后端接口规范（APP AGENT API）。
九、给集成商的落地建议
结合方案特点，给准备接入的团队三条建议：
-
先定 APP AGENT API，再选前端路线。两套架构共用同一后端接口规范，接口定义清楚了，WEB 还是走非 WEB 只是前端通道的差异，避免返工；
-
从方式1（加播报）起步。成本最低、不碰已有业务流程，先让数字人以"播报员"身份出现，再逐步开放导航点击、语音咨询等深交互；
-
审核链不要绕过。AVATAR AGENT 内置的输入/输出双重内容审核是政务场景的安全阀，业务定制也应保持在处理链框架内进行。
对政务信息化团队而言，明泰智能"自助易"AI 数字人就像一座桥梁——它规范了在原有应用中接入 AI 交互的方式，让开发者可以快速、可靠地构建具有 AI 能力的产品，而不必处理复杂的临时连接逻辑。
*本文基于明泰智能 AVATAR STUDIO 技术方案整理。文中 PostMessage 通信示例为原理示意，实际对接请以官方 API 文档为准。*
openEuler 是由开放原子开源基金会孵化的全场景开源操作系统项目，面向数字基础设施四大核心场景（服务器、云计算、边缘计算、嵌入式），全面支持 ARM、x86、RISC-V、loongArch、PowerPC、SW-64 等多样性计算架构
更多推荐
1
0- 0
已为社区贡献1条内容
所有评论(0)