安信可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" / "声音小一点" / "现在音量多少？"