基于MCP协议的AI主播工具链：构建标准化可扩展的智能体应用

1. 项目概述当AI主播遇见MCP一个开源工具链的诞生最近在捣鼓AI数字人直播和智能体应用开发的朋友可能都绕不开一个核心痛点如何让AI主播的“大脑”和“身体”高效、灵活地协同工作传统的开发模式往往是“烟囱式”的语音合成、大模型对话、形象驱动、场景渲染等模块各自为战集成起来费时费力调试更是噩梦。就在这个背景下我注意到了GitHub上一个名为aituberapp/aituber-mcp的开源项目。这个名字本身就很有意思它把“AI主播”AITuber和“模型上下文协议”Model Context Protocol MCP这两个当下最热的概念结合在了一起。简单来说aituber-mcp是一个旨在为AI主播应用构建标准化、可插拔工具链的开源框架。它的核心思想是借助MCP协议将AI主播所需的各种能力——比如联网搜索、读取文件、调用特定API、控制虚拟形象动作等——抽象成一个个独立的“工具”Tools。然后通过一个统一的“服务器”Server来管理和调度这些工具而AI主播的“大脑”通常是大型语言模型只需要学会调用这些标准化工具就能完成复杂的直播任务。这就像给AI主播配备了一个万能工具箱和一套标准的工具使用说明书无论它需要拧螺丝还是锯木头都能快速找到对的方法。这个项目解决的正是AI主播乃至更广泛的AI智能体开发中的“集成复杂度”和“能力扩展性”难题。它非常适合以下几类人一是AI应用开发者尤其是专注于数字人、虚拟主播、智能客服具象化方向的团队可以基于此快速搭建原型二是对MCP协议感兴趣想寻找一个具体、有趣落地场景的技术爱好者三是希望自己的AI助手能拥有更强大、更可控外部能力的个人开发者。接下来我将深入拆解这个项目的设计思路、核心组件并分享如何从零开始搭建和扩展属于你自己的AI主播工具链。2. 核心架构与MCP协议深度解析2.1 为什么是MCP协议选型的背后逻辑在深入代码之前我们必须先理解为什么aituber-mcp选择基于MCP来构建。这并非追逐热点而是基于深刻的工程现实考量。AI主播是一个典型的“智能体”Agent应用它需要感知环境用户提问、直播评论、进行决策生成回复内容、执行动作驱动嘴型、播放语音、展示信息。在传统架构中大语言模型LLM往往被期望“全知全能”不仅要有知识还要懂得如何调用各种外部API这导致了提示词Prompt极其复杂、输出格式难以控制、错误处理链路冗长。MCP协议的出现提供了一种优雅的解耦方案。它的核心是定义了三种基本角色客户端Client通常是LLM或智能体运行时它负责决策和发起工具调用请求。服务器Server提供一系列“工具”和“资源”的集合。每个工具都有严格的输入输出JSON Schema定义。协议Protocol基于JSON-RPC的标准化通信方式规定了Client和Server之间如何发现工具、调用工具、传递结果。对于AI主播项目采用MCP带来了立竿见影的好处关注点分离LLM客户端只需要理解“有什么工具可用”以及“为了达成某个目标应该调用哪个工具并传入什么参数”而无需关心工具内部如何实现。这极大简化了提示词工程。工具标准化与复用一个提供“天气查询”的MCP服务器不仅可以给AI主播用也可以给代码助手、写作AI用。工具实现了“一次编写多处运行”。动态扩展与热插拔新的能力如接入一个新的支付系统API可以通过开发一个新的MCP Server来提供无需修改核心的AI主播客户端代码。直播过程中也可以根据需求动态加载或卸载工具服务器。开发与调试友好由于协议标准化我们可以使用通用的MCP客户端调试工具如mcp-cli来单独测试服务器确保每个工具都工作正常后再集成到主系统中。aituber-mcp项目正是扮演了这样一个“MCP服务器”的角色但它不是通用的而是专门为AI主播场景量身定制了一套工具集。2.2 aituber-mcp 项目结构拆解浏览项目的仓库结构我们可以清晰地看到其模块化设计的思想。一个典型的aituber-mcp项目可能包含以下核心部分具体文件结构可能随版本迭代但思想不变aituber-mcp/ ├── server/ # MCP服务器核心实现 │ ├── __init__.py │ ├── main.py # 服务器启动入口工具注册点 │ ├── tools/ # 工具实现模块 │ │ ├── __init__.py │ │ ├── web_search.py # 联网搜索工具 │ │ ├── file_read.py # 读取提词器/脚本文件 │ │ ├── tts_control.py # 语音合成控制工具 │ │ └── avatar_control.py # 虚拟形象驱动工具 │ └── resources/ # 资源定义可选 ├── config/ # 配置文件 │ └── server_config.yaml # 定义工具参数、API密钥等 ├── clients/ # 示例客户端可选 │ └── demo_client.py # 演示如何连接并使用该MCP服务器 ├── requirements.txt # Python依赖列表 └── README.md # 项目说明与快速开始指南核心文件解读server/main.py这是心脏。它使用MCP的SDK如mcp[cli]库初始化一个服务器实例并从各个工具模块导入具体的工具函数通过mcp.tool()装饰器将其注册为MCP工具。同时它还会处理服务器生命周期和配置加载。server/tools/*.py这是肌肉。每个文件实现一个或多个具体的工具。例如web_search.py可能封装了对Serper API或Google Custom Search API的调用tts_control.py可能封装了对接Azure TTS、Google TTS或本地VITS模型的代码。config/server_config.yaml这是神经。所有可配置的项集中于此如API密钥、搜索引擎ID、TTS语音选择、虚拟形象服务地址等。这实现了代码与配置的分离便于部署和管理。注意在实际开发中avatar_control形象驱动工具的实现复杂度可能最高因为它需要与不同的虚拟形象引擎如Live2D Cubism、Unity、Unreal Engine或者国内的一些数字人SaaS平台进行通信。MCP层的作用是将其抽象为一个简单的工具例如move_avatar(emotion: str, gesture: str)而将底层的Socket、WebSocket或HTTP通信细节隐藏起来。3. 核心工具实现与实操要点3.1 工具设计范式从需求到接口设计一个MCP工具关键在于定义清晰的输入和输出。以“联网搜索”工具为例我们不应该设计一个叫do_search的模糊工具而应该设计一个功能明确、参数具体的工具。一个反例不推荐mcp.tool() async def search(query: str): 执行搜索 # ... 实现这个工具太笼统LLM调用时可能不清楚它能搜什么、返回什么格式。正例推荐from pydantic import BaseModel import httpx class SearchResult(BaseModel): title: str link: str snippet: str mcp.tool() async def search_web( query: str, num_results: int 5, search_domain: Optional[str] None ) - list[SearchResult]: 在互联网上搜索最新信息。 Args: query: 搜索关键词。 num_results: 需要返回的结果数量默认为5。 search_domain: 可选的域名限制例如 wikipedia.org。 Returns: 一个包含搜索结果标题、链接、摘要的列表。 # 1. 构建搜索请求这里以Serper API为例 api_key settings.serper_api_key payload { q: query, num: num_results, } if search_domain: payload[gl] us # 假设区域设置 # 更精细的域名过滤可能在API层面或结果后处理实现 headers {X-API-KEY: api_key, Content-Type: application/json} async with httpx.AsyncClient() as client: response await client.post(https://google.serper.dev/search, jsonpayload, headersheaders) response.raise_for_status() data response.json() # 2. 解析并标准化结果 results [] for organic in data.get(organic, [])[:num_results]: results.append( SearchResult( titleorganic.get(title, ), linkorganic.get(link, ), snippetorganic.get(snippet, ) ) ) return results设计要点解析工具名search_web比search更具体暗示了工具的范围。参数文档使用Python类型提示和详细的docstring。LLM尤其是GPT-4等高级模型能很好地理解这些信息来决定如何调用。num_results提供了默认值简化了调用。返回类型使用Pydantic模型SearchResult明确定义返回的数据结构。这确保了输出格式的稳定性和可解析性。错误处理在工具内部response.raise_for_status()会抛出HTTP错误。MCP服务器通常会捕获这些异常并将其转化为标准的JSON-RPC错误响应客户端可以据此进行重试或降级处理。3.2 关键工具实现详解TTS与形象控制对于AI主播TTS文本转语音和形象控制是两个最核心的工具。它们的实现直接关系到直播的最终效果。TTS控制工具的实现思路TTS工具的目标是将文本转换为音频流或文件并可能触发播放。考虑到不同的部署环境云端、本地工具设计需要有灵活性。from enum import Enum from pathlib import Path import asyncio class TTSVoice(str, Enum): 可用的语音角色 FRIENDLY_FEMALE zh-CN-XiaoxiaoNeural PROFESSIONAL_MALE zh-CN-YunxiNeural mcp.tool() async def synthesize_speech( text: str, voice: TTSVoice TTSVoice.FRIENDLY_FEMALE, output_dir: Path Path(./audio_cache) ) - dict: 将文本合成为语音文件。 Args: text: 需要合成的文本。 voice: 选择的语音角色。 output_dir: 音频文件输出目录。 Returns: 包含音频文件路径和元数据的字典。 # 确保输出目录存在 output_dir.mkdir(parentsTrue, exist_okTrue) # 生成唯一文件名 import hashlib text_hash hashlib.md5(text.encode()).hexdigest()[:8] filename output_dir / ftts_{voice}_{text_hash}.mp3 # 如果已缓存直接返回节省成本和时间 if filename.exists(): return {file_path: str(filename), cached: True, text_preview: text[:50]} # 调用TTS服务这里以Azure Speech SDK为例 import azure.cognitiveservices.speech as speechsdk speech_config speechsdk.SpeechConfig( subscriptionsettings.azure_speech_key, regionsettings.azure_speech_region ) speech_config.speech_synthesis_voice_name voice.value audio_config speechsdk.audio.AudioOutputConfig(filenamestr(filename)) synthesizer speechsdk.SpeechSynthesizer(speech_configspeech_config, audio_configaudio_config) # 注意SDK可能是同步的这里用asyncio.to_thread在异步环境中运行 result await asyncio.to_thread(synthesizer.speak_text_async, text).result() if result.reason speechsdk.ResultReason.SynthesizingAudioCompleted: return {file_path: str(filename), cached: False, text_preview: text[:50]} else: cancellation_details result.cancellation_details raise RuntimeError(fTTS合成失败: {cancellation_details.reason} - {cancellation_details.error_details})实操心得TTS API调用通常有频率和字数限制。在生产环境中务必添加队列机制和速率限制避免并发请求导致失败。此外音频文件的缓存策略至关重要对于重复的问候语、固定回复缓存能极大提升响应速度并降低API成本。虚拟形象控制工具的实现思路形象控制工具的实现高度依赖于你选择的数字人驱动方案。这里以通过WebSocket发送指令给一个标准的驱动服务为例。import json from websockets.client import connect as ws_connect from contextlib import asynccontextmanager class AvatarEngine: 管理虚拟形象连接的单例或资源池 _connection None _uri ws://localhost:8765 # 假设形象驱动服务地址 classmethod async def get_connection(cls): if cls._connection is None or cls._connection.closed: cls._connection await ws_connect(cls._uri) return cls._connection mcp.tool() async def drive_avatar( action: str, intensity: float 1.0, duration: float 1.0 ) - dict: 驱动虚拟形象执行动作。 Args: action: 动作名称如 nod, shake_head, wave_hand, smile, surprise。 intensity: 动作强度范围0.0到1.0。 duration: 动作持续时间秒。 Returns: 包含执行状态的字典。 # 验证参数 valid_actions [nod, shake_head, wave_hand, smile, surprise, idle] if action not in valid_actions: raise ValueError(f无效动作 {action}。可选动作: {valid_actions}) intensity max(0.0, min(1.0, intensity)) # 钳制范围 duration max(0.1, duration) # 最小持续时间 # 构建驱动指令 command { type: action, name: action, params: { intensity: intensity, duration: duration, timestamp: asyncio.get_event_loop().time() } } try: ws await AvatarEngine.get_connection() await ws.send(json.dumps(command)) # 可以等待一个确认回复 # response await asyncio.wait_for(ws.recv(), timeout2.0) return {status: success, action: action, sent_command: command} except (ConnectionRefusedError, TimeoutError) as e: # 连接失败可能驱动服务未启动 AvatarEngine._connection None # 重置连接 return {status: error, message: f无法连接形象驱动服务: {e}, action: action} except Exception as e: return {status: error, message: str(e), action: action}注意事项虚拟形象驱动是实时性要求很高的操作。网络延迟、指令队列堆积都可能导致音画不同步或动作卡顿。建议保持长连接使用WebSocket长连接而非每次调用都建立HTTP连接。指令合并与优化LLM可能会快速连续调用多个drive_avatar工具如“微笑”然后“点头”。可以在MCP服务器上层或客户端添加一个指令缓冲与合并层将短时间内连续的微小动作合并为一个连贯的动画指令再发送给驱动引擎。超时与重试设置合理的超时时间并对可重试的错误如网络抖动实现简单的重试机制。4. 服务器部署与客户端集成实战4.1 配置、启动与调试MCP服务器假设我们已经按照上述结构完成了工具的开发下一步就是让服务器跑起来。1. 依赖安装项目根目录的requirements.txt应包含所有必要依赖。pip install -r requirements.txt # 典型依赖可能包括mcp[cli], pydantic, httpx, websockets, pyyaml, azure-cognitiveservices-speech 等2. 配置文件准备创建config/server_config.yaml并填入你的密钥和配置。# config/server_config.yaml api_keys: serper: your_serper_api_key_here azure_speech: your_azure_speech_key_here azure_region: eastus server: host: 0.0.0.0 port: 8000 # MCP over STDIO 是更常见的与客户端集成的方式但HTTP/SSE也可用于调试 transport: stdio # 或 sse tools: web_search: enabled: true default_num_results: 5 tts: enabled: true default_voice: zh-CN-XiaoxiaoNeural cache_dir: ./audio_cache avatar: enabled: true websocket_uri: ws://localhost:87653. 启动服务器以STDIO传输为例MCP服务器通常设计为通过标准输入输出STDIO与客户端通信这是与Claude Desktop、Cline等客户端集成的标准方式。你的server/main.py需要支持这种模式。# server/main.py import asyncio import sys from mcp.server import Server from mcp.server.models import InitializationOptions import server.tools.web_search import server.tools.tts_control import server.tools.avatar_control # ... 导入其他工具 from .config import load_settings async def main(): settings load_settings() # 加载配置 # 创建MCP服务器实例 app Server(aituber-tools) # 注册所有工具 app.add_tool(server.tools.web_search.search_web) app.add_tool(server.tools.tts_control.synthesize_speech) if settings.tools.avatar.enabled: app.add_tool(server.tools.avatar_control.drive_avatar) # ... 注册其他工具 # 支持STDIO传输 async with app.run_stdio() as (read_stream, write_stream): await app.run( read_streamread_stream, write_streamwrite_stream, initialization_optionsInitializationOptions( server_nameaituber-tools, server_version0.1.0 ) ) if __name__ __main__: asyncio.run(main())然后你可以通过命令行直接运行服务器它会等待通过STDIO传入的JSON-RPC请求。python -m server.main4. 使用MCP CLI进行调试在集成到AI主播主程序前强烈建议使用官方mcpCLI工具测试服务器。# 首先全局安装mcp-cli如果尚未安装 # pip install mcp[cli] # 通过STDIO模式测试服务器 npx modelcontextprotocol/inspector python -m server.maininspector会启动一个本地调试界面通常是一个网页你可以在其中看到服务器提供的所有工具列表并手动输入参数进行调用测试非常直观。4.2 在AI主播客户端中集成MCPAI主播的“大脑”主程序现在需要扮演MCP客户端的角色。这里以使用Pythonmcp客户端库为例。# client/aituber_client.py import asyncio from mcp import ClientSession, StdioServerParameters from mcp.client import stdio_client class AITuberBrain: def __init__(self, llm_client, mcp_server_path): self.llm llm_client # 你的LLM客户端如OpenAI, Anthropic等 self.mcp_server_path mcp_server_path # 例如[python, /path/to/server/main.py] self.mcp_session None self.available_tools [] # 缓存工具列表 async def connect_to_tools(self): 连接到MCP工具服务器 server_params StdioServerParameters(commandself.mcp_server_path) stdio_transport await stdio_client.connect_to_server(server_params) self.mcp_session ClientSession(stdio_transport) await self.mcp_session.initialize() # 获取服务器提供的工具列表 list_tools_result await self.mcp_session.list_tools() self.available_tools list_tools_result.tools print(f已连接工具服务器可用工具: {[t.name for t in self.available_tools]}) async def process_user_input(self, user_message: str) - dict: 核心处理循环LLM决策 - 调用工具 - 整合回复 if not self.mcp_session: await self.connect_to_tools() # 1. 为LLM构建包含工具描述的提示词 tools_description \n.join([ f- {tool.name}: {tool.description} (输入参数: {tool.inputSchema}) for tool in self.available_tools ]) system_prompt f你是一个AI主播可以调用以下工具来获取信息或执行动作 {tools_description} 当用户的问题需要最新信息、文件内容或特定动作时请决定调用哪个工具。 你的回复格式应为 最终回复[你的直接回复文本] 如果需要调用工具请额外注明 调用工具[工具名称] 工具参数[JSON格式的参数] # 2. 调用LLM获取决策 llm_response await self.llm.chat.completions.create( modelgpt-4, messages[ {role: system, content: system_prompt}, {role: user, content: user_message} ], temperature0.7, ) assistant_message llm_response.choices[0].message.content # 3. 解析LLM回复判断是否需要调用工具 final_reply if 调用工具 in assistant_message: # 简单解析实际应用中可能需要更健壮的解析逻辑 lines assistant_message.split(\n) for line in lines: if line.startswith(调用工具): tool_name line.replace(调用工具, ).strip() elif line.startswith(工具参数): import json try: tool_args json.loads(line.replace(工具参数, ).strip()) except json.JSONDecodeError: tool_args {} # 4. 执行工具调用 if tool_name and tool_args: print(f正在调用工具: {tool_name} 参数: {tool_args}) result await self.mcp_session.call_tool(tool_name, argumentstool_args) # result.content 是一个列表包含工具返回的文本或图像等内容 tool_output \n.join([item.text for item in result.content if item.type text]) print(f工具返回: {tool_output}) # 5. 将工具结果再次喂给LLM生成最终回复 follow_up_prompt f 用户原问题{user_message} 你刚才决定调用工具 {tool_name}并获得以下结果 {tool_output} 请基于以上信息生成对用户的最终回复。 final_llm_response await self.llm.chat.completions.create( modelgpt-4, messages[ {role: system, content: 你现在是AI主播请根据工具返回的信息生成友好、自然的回复。}, {role: user, content: follow_up_prompt} ], temperature0.7, ) final_reply final_llm_response.choices[0].message.content else: # LLM认为无需调用工具直接使用其回复 final_reply assistant_message.replace(最终回复, ).strip() # 6. 最终回复可能包含需要驱动形象或TTS的指令可以进一步解析 # 例如检测到[微笑]标签则调用 drive_avatar 工具 # 这里简化处理直接返回文本 return { text_reply: final_reply, # 可以附加解析出的动作指令、TTS文本等 actions: self._extract_actions(final_reply), tts_text: final_reply # 或者清洗后的版本 } def _extract_actions(self, text: str) - list: 一个简单的从文本中提取动作标签的函数示例 actions [] if [微笑] in text: actions.append({action: smile, intensity: 0.8}) if [点头] in text: actions.append({action: nod, intensity: 0.6}) return actions # 使用示例 async def main(): brain AITuberBrain(llm_clientopenai_client, mcp_server_path[python, server/main.py]) await brain.connect_to_tools() user_q 今天的北京天气怎么样适合出门吗 response await brain.process_user_input(user_q) print(AI主播回复:, response[text_reply]) # 根据 response[“actions”] 驱动形象 # 根据 response[“tts_text”] 调用TTS工具合成语音 if __name__ __main__: asyncio.run(main())这个客户端示例展示了最基本的集成流程连接服务器、获取工具列表、让LLM根据上下文决定是否及如何调用工具、处理工具结果并生成最终回复。在实际生产环境中你需要一个更强大的智能体框架如LangChain、LlamaIndex、或自定义的状态机来管理复杂的多轮对话、工具调用历史和维护对话状态。5. 进阶优化与常见问题排查5.1 性能、稳定性与扩展性优化当工具链跑通后接下来就要面对真实场景的挑战性能、稳定性和如何方便地扩展新能力。1. 工具调用的超时与重试网络请求和外部API调用可能失败。必须在工具实现和客户端调用侧添加超时和重试逻辑。# 在工具实现内部以搜索为例 import httpx from tenacity import retry, stop_after_attempt, wait_exponential, retry_if_exception_type retry( stopstop_after_attempt(3), waitwait_exponential(multiplier1, min2, max10), retryretry_if_exception_type((httpx.ConnectTimeout, httpx.ReadTimeout, httpx.HTTPStatusError)) ) async def search_web_with_retry(query: str, num_results: int): # ... 原有的搜索逻辑 pass2. 工具结果的缓存对于更新不频繁的信息如某个城市的今日天气在几分钟内可以在MCP服务器层面添加缓存层避免重复调用API提升响应速度并节省成本。可以使用cachetools库实现一个简单的内存缓存或使用Redis作为分布式缓存。3. 工具权限与安全性不是所有工具都应对所有请求开放。例如“发送微博”或“控制智能家居”这类高权限工具需要在调用前进行身份验证或上下文权限检查。可以在工具函数开头添加校验逻辑或利用MCP协议中正在演进的权限声明特性。4. 扩展新工具这是MCP架构最大的优势。要添加一个新工具例如从Notion数据库读取直播日程第一步在server/tools/下创建notion_reader.py实现具体的函数。第二步在server/main.py中导入并注册这个新工具。第三步重启MCP服务器或实现热加载。第四步AI主播客户端在下次初始化时会自动发现这个新工具LLM即可根据描述在合适的场景调用它。无需修改客户端核心决策逻辑。5.2 常见问题与排查实录在开发和运行aituber-mcp过程中你肯定会遇到一些典型问题。以下是我踩过的一些坑和解决方案问题1MCP客户端连接服务器失败报“Connection refused”或“Invalid handshake response”。可能原因A服务器启动命令或传输方式配置错误。确保StdioServerParameters中的command路径正确且服务器脚本本身可以独立运行。排查单独运行python -m server.main看是否有Python错误输出。确保服务器没有立即退出。可能原因B服务器和客户端使用了不兼容的MCP协议版本。排查检查mcp库的版本客户端和服务器应使用相同的主要版本。查看MCP协议的版本声明。问题2LLM无法正确调用工具总是忽略或错误格式化参数。可能原因A工具的描述docstring不够清晰。LLM依赖描述来理解工具用途。解决优化docstring明确说明工具功能、每个参数的意义、类型和示例。使用Pydantic模型定义参数和返回类型效果最佳。可能原因B提供给LLM的工具列表过长或描述过于复杂干扰了其判断。解决对工具进行分组或分层。在系统提示词中可以先让LLM判断问题类型再提供相关工具。或者实现一个“工具路由”层由简单的规则或分类模型先筛选出最相关的几个工具再交给LLM做最终决策。问题3工具调用成功但AI主播的最终回复生硬像是直接拼接了工具结果。可能原因LLM在生成最终回复时没有充分“消化”工具返回的原始数据。解决优化“后续提示词”follow-up prompt。不要简单地说“根据以下信息回复”而要给出更具体的指令例如“你是一个活泼的主播请将以下天气信息用轻松口语化的方式总结一下并给出是否适合出门的建议。天气信息[工具结果]”。让LLM进行信息提炼和风格化转换。问题4虚拟形象动作与语音不同步。可能原因TTS合成需要时间尤其是云端API而形象驱动指令是瞬时发送的。解决实现一个简单的同步调度器。流程改为1. 生成最终文本回复。2.同时开始TTS合成和解析动作指令。3. 等待TTS音频文件生成完毕。4.同时播放音频和按解析出的动作时间序列发送驱动指令。对于更精细的控制可能需要TTS服务返回音素级别的时间戳如Azure的SSML标记从而驱动口型同步。问题5服务器在高并发下不稳定或工具调用缓慢。可能原因工具函数内部是同步阻塞的如某些SDK或者没有限制对外部API的并发请求。解决将所有可能的同步操作如文件IO、某些网络请求用asyncio.to_thread()包装避免阻塞事件循环。为每个有速率限制的API工具如搜索、TTS实现一个信号量Semaphore或令牌桶Token Bucket限制最大并发数。考虑使用anyio或asyncio的任务组来管理并发任务并设置全局超时。这个基于MCP的AI主播工具链框架将复杂的多模态交互拆解为一系列可管理、可测试、可扩展的标准化工具。它可能不是性能极限最高的方案但在开发效率、维护成本和系统灵活性上带来了质的提升。你可以从实现一个最简单的搜索工具开始逐步将你的AI主播能力模块化最终构建出一个既能闲聊、又能查资料、还能做表情的强大数字人助手。