安信可AI语音模组支持MCP模型上下文协议

核心结论：安信可 PalChat 系列（V1/V2）支持 MCP（模型上下文协议），工程师只需写几十行 C 代码，就能让 AI 模型直接控制硬件设备。V1 基于 Ai-WB2-12F，适合快速验证；V2 基于 Ai-M61-32S，新增屏幕、支持多 AI 平台，MCP 参数类型也更丰富。两款都把"AI 理解人话→执行设备操作"这条链路做成了开箱即用的能力。

01 MCP 是什么，为什么工程师应该关注

最近两年，AI 大模型的能力进步飞快，但有一个问题一直没解决好：模型怎么控制真实的物理设备？

传统方案里，工程师要自己写一套"语义解析→指令映射→设备控制"的逻辑。用户说"把灯调暗一点"，设备要能听懂这句话，还要知道"暗一点"是把 PWM 调低多少——这中间有很多脆弱的对应关系需要人工维护。

MCP（Model Context Protocol，模型上下文协议）换了一个思路：让 AI 直接调用你定义的工具函数。你告诉 AI "有个叫 Light 的工具，能开关灯"，AI 就会在用户说"关灯"的时候，直接调用这个工具，传入参数 enabled=false，你的回调函数处理剩下的事情。

换句话说，MCP 把设备控制从"自然语言解析"变成了"函数调用"。前者很难维护，后者是工程师最熟悉的模式。

MCP 是 Anthropic 提出的开放协议，目前已被多个 AI 平台支持。安信可将其集成进 PalChat 系列 SDK，开发者不需要自己对接协议层，只需要关注工具的定义和回调实现。

02 PalChat V1 与 V2：先搞清楚是哪两款板子

在聊 MCP 功能之前，先把两款产品的差异说清楚，避免选错。

对比项	PalChat V1	PalChat V2
主控模组	Ai-WB2-12F	Ai-M61-32S
屏幕	无	1.69 寸 TFT 彩屏
AI 平台支持	小智 AI	小智 AI + 火山引擎
语音打断	支持离线唤醒	插话打断 + 唤醒词打断
供电	Type-C / 电池	Type-C / 电池
MCP 参数类型	布尔型、数值型	布尔型、数值型、字符串型
开发文件位置	SDK 内自定义	user_mcp_tools.c / .h
适合场景	快速原型验证、开源项目	产品级开发、多平台集成

两款都支持 MCP，但 V2 的 MCP 能力更完整——特别是新增了字符串类型参数，意味着你可以传"播放古典音乐"这类文本型指令，而不只是开关和数字。

03 MCP 开发流程：就三步

不管是 V1 还是 V2，MCP 工具的开发逻辑是一致的：

第一步：定义工具

用 mcp_server_tool_t 结构体描述你的工具：叫什么名字、干什么事、接受什么参数。

 

mcp_server_tool_t light_tool = {
    .name        = "Light",
    .description = "控制是否打开灯光",
    .setRequestHandler   = light_set_callback,   // 控制回调
    .checkRequestHandler = light_check_callback, // 查询回调
    .inputSchema = { ... }  // 参数定义
};

 

第二步：注册到 MCP 服务

一行代码把工具加进去：

 

mcp_server_add_tool_to_toolList(&light_tool);

 

第三步：实现回调函数

写两个函数：一个处理"控制"，一个处理"查询"。

 

// 控制回调：AI 说"关灯"时触发
returnValues_t light_set_callback(void *params) {
    bool enabled = get_bool_param(params, "enabled");
    gpio_set_level(LIGHT_PIN, enabled ? 1 : 0);
    return MCP_SUCCESS;  // 0 = 成功
}

// 查询回调：AI 问"灯开着吗"时触发
void light_check_callback(void *params) {
    bool state = gpio_get_level(LIGHT_PIN);
    set_response_bool("enabled", state);
}

 

这三步完成后，用户对着 PalChat 说"打开灯"，AI 就会调用 light_set_callback，传入 enabled=true，灯就亮了。你不需要写任何自然语言解析的代码。

错误码规范： V1/V2 均统一使用 0 表示成功，-32602 表示参数错误。回调函数里记得处理异常，避免设备进入未定义状态。

04 V1 与 V2 的 MCP 能力对比：差在哪里

两款的 MCP 架构一致，差异主要体现在参数类型和开发结构上。

参数类型：V2 多了字符串

参数类型	V1 支持	V2 支持	典型用途
BOOLEAN			开关控制、状态查询
NUMBER			音量、亮度、温度等数值
STRING			模式名称、播放列表、文本指令

字符串类型的加入，让 V2 能处理更复杂的语义。比如"切换到睡眠模式"——这个"睡眠"是个字符串，V1 没法原生传递，V2 可以直接把 "sleep" 传进回调函数，你的设备再根据字符串值做对应的操作。

开发文件结构：V2 更规范

V1 的 MCP 工具开发在 SDK 内灵活定义；V2 则固定了开发入口：

project/Xiaozhi-AI/mcp_server/user_mcp_tools.c  — 工具实现

project/Xiaozhi-AI/mcp_server/user_mcp_tools.h  — 工具声明

固定的文件结构对团队协作更友好——新人知道去哪里找代码，代码审查也更容易。

AI 平台：V2 多一个选择

V1 目前对接小智 AI；V2 额外支持火山引擎语音平台。两者的 MCP 接口兼容，切换 AI 平台不需要重写工具代码，只改配置就行。

05 对工程师来说，MCP 省掉了什么

做过传统语音控制的工程师都知道有多麻烦：

写关键词匹配（打开/开启/亮起来……都得枚举）

维护指令表（产品迭代一次，指令表就要更新一次）

处理语义歧义（"大声一点"是加10还是加20？）

对接云端 ASR + NLU + 设备端控制三层逻辑

有了 MCP，这些全省了。你只需要关心两件事：工具怎么定义（说清楚 AI 能用什么功能），以及回调怎么写（功能触发了做什么）。自然语言的理解交给 AI 模型，指令的分发交给 MCP 协议，你只管设备控制逻辑。

量化对比：传统方案下，一个"灯光 + 音量 + 模式切换"三功能语音控制系统，关键词枚举 + 逻辑处理大约需要 300-500 行代码，且随产品迭代持续膨胀。用 MCP 实现同样功能，工具定义 + 回调函数约 80-120 行，后续新增功能只需追加工具，不影响已有逻辑。

06 内置工具示例：灯光 + 音量

两款 PalChat 的 SDK 里内置了两个示例工具，可以直接参考：

示例一：灯光控制（Light）

最简单的布尔控制场景。用户说"开灯"或"关灯"，AI 调用工具，传入 enabled 参数。

要素	内容
工具名称	Light
属性	enabled （布尔型）— 当前灯光状态
控制方法	SetEnabled （true=开，false=关）
触发语句示例	"打开灯光" / "关灯" / "灯开着吗？"

示例二：音量控制（Speaker）

数值型参数场景。用户说"把音量调到 70"，AI 解析出 70 这个数字，直接传入。

要素	内容
工具名称	Speaker
属性	volume （数值型，0-100）— 当前音量
控制方法	SetVolume （传入 0-100 整数）
触发语句示例	"音量调到50" / "声音小一点" / "现在音量多少？"

这两个示例覆盖了 MCP 里最常见的两种参数类型。实际开发时，基于这两个例子做扩展，能快速上手。

07 选 V1 还是 V2：一个判断框架

两款都支持 MCP，硬件差异决定了适用场景不同。

选 PalChat V1，如果你：

需要快速跑通 MCP 的 demo，验证概念可行性

控制逻辑简单（只需要布尔型和数值型参数）

只对接小智 AI 平台

预算有限，用开源版本做前期探索

选 PalChat V2，如果你：

需要字符串类型参数（模式切换、文本类指令）

产品需要屏幕显示交互状态

需要同时评估小智 AI 和火山引擎两个平台

对代码规范性有要求，后续需要团队协作

做产品级开发而非原型验证

经验建议：如果你的产品控制点超过 5 个，或者涉及模式切换这类"文本型"指令，直接上 V2。V2 的字符串参数类型和规范化开发结构，在产品迭代时会省很多麻烦。

08 MCP 的上限在哪里

PalChat 的 MCP 工具数量受 MCP_SERVER_TOOL_NUMBLE_LEN 这个常量限制（V2 文档中有提及）。实际上，一个中等复杂的智能家居产品——灯光、窗帘、温度、模式、音乐——五个工具就能覆盖大部分控制需求，不会遇到上限问题。

更重要的是，MCP 协议本身是开放的，工具的能力边界取决于你的回调函数写了什么。灯光控制是一个工具，调用外部 HTTP API 可以是另一个工具，读取传感器数据同样可以包装成工具。只要能写成函数的操作，都能接进 MCP。

安信可官方也列出了参考资料：

MCP 中文站 — 协议规范文档

小智 AI MCP 交互流程 — 具体实现参考

09 总结

PalChat V1 和 V2 都把 MCP 做成了开箱即用的能力：三步开发流程、两个内置示例、标准化的回调接口。对工程师来说，最直接的价值是省掉了自然语言解析这层复杂度，让设备控制回归到熟悉的"函数定义 + 参数处理"模式。

两款的核心差异在于：V1 轻量、适合验证；V2 更完整，多了屏幕、字符串参数类型、多 AI 平台支持。项目处于探索期，选 V1；准备做成产品，选 V2。

MCP 这条路，安信可铺好了基础设施。剩下的，就是你的设备要做什么了。这正是"安信可，可安心"的意思——底层的通信和协议对接已经帮你做完，你只管专注产品逻辑。