核心結(jié)論：安信可 PalChat 系列（V1/V2）支持 MCP（模型上下文協(xié)議），工程師只需寫幾十行 C 代碼，就能讓 AI 模型直接控制硬件設(shè)備。V1 基于 Ai-WB2-12F，適合快速驗(yàn)證；V2 基于 Ai-M61-32S，新增屏幕、支持多 AI 平臺(tái)，MCP 參數(shù)類型也更豐富。兩款都把"AI 理解人話→執(zhí)行設(shè)備操作"這條鏈路做成了開箱即用的能力。

01 MCP 是什么，為什么工程師應(yīng)該關(guān)注

最近兩年，AI 大模型的能力進(jìn)步飛快，但有一個(gè)問題一直沒解決好：模型怎么控制真實(shí)的物理設(shè)備？

傳統(tǒng)方案里，工程師要自己寫一套"語義解析→指令映射→設(shè)備控制"的邏輯。用戶說"把燈調(diào)暗一點(diǎn)"，設(shè)備要能聽懂這句話，還要知道"暗一點(diǎn)"是把 PWM 調(diào)低多少——這中間有很多脆弱的對(duì)應(yīng)關(guān)系需要人工維護(hù)。

MCP（Model Context Protocol，模型上下文協(xié)議）換了一個(gè)思路：讓 AI 直接調(diào)用你定義的工具函數(shù)。你告訴 AI "有個(gè)叫 Light 的工具，能開關(guān)燈"，AI 就會(huì)在用戶說"關(guān)燈"的時(shí)候，直接調(diào)用這個(gè)工具，傳入?yún)?shù)enabled=false，你的回調(diào)函數(shù)處理剩下的事情。

換句話說，MCP 把設(shè)備控制從"自然語言解析"變成了"函數(shù)調(diào)用"。前者很難維護(hù)，后者是工程師最熟悉的模式。

MCP 是 Anthropic 提出的開放協(xié)議，目前已被多個(gè) AI 平臺(tái)支持。安信可將其集成進(jìn) PalChat 系列 SDK，開發(fā)者不需要自己對(duì)接協(xié)議層，只需要關(guān)注工具的定義和回調(diào)實(shí)現(xiàn)。

02 PalChat V1 與 V2：先搞清楚是哪兩款板子

在聊 MCP 功能之前，先把兩款產(chǎn)品的差異說清楚，避免選錯(cuò)。

兩款都支持 MCP，但 V2 的 MCP 能力更完整——特別是新增了字符串類型參數(shù)，意味著你可以傳"播放古典音樂"這類文本型指令，而不只是開關(guān)和數(shù)字。

03 MCP 開發(fā)流程：就三步

不管是 V1 還是 V2，MCP 工具的開發(fā)邏輯是一致的：

第一步：定義工具

用mcp_server_tool_t結(jié)構(gòu)體描述你的工具：叫什么名字、干什么事、接受什么參數(shù)。

mcp_server_tool_t light_tool = {
.name = "Light",
.description = "控制是否打開燈光",
.setRequestHandler = light_set_callback, // 控制回調(diào)
.checkRequestHandler = light_check_callback, // 查詢回調(diào)
.inputSchema = { ... } // 參數(shù)定義
};

第二步：注冊(cè)到 MCP 服務(wù)

一行代碼把工具加進(jìn)去：

mcp_server_add_tool_to_toolList(&light_tool);

第三步：實(shí)現(xiàn)回調(diào)函數(shù)

寫兩個(gè)函數(shù)：一個(gè)處理"控制"，一個(gè)處理"查詢"。

// 控制回調(diào)：AI 說"關(guān)燈"時(shí)觸發(fā)
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 = 成功
}

// 查詢回調(diào)：AI 問"燈開著嗎"時(shí)觸發(fā)
void light_check_callback(void *params) {
bool state = gpio_get_level(LIGHT_PIN);
set_response_bool("enabled", state);
}

這三步完成后，用戶對(duì)著 PalChat 說"打開燈"，AI 就會(huì)調(diào)用light_set_callback，傳入enabled=true，燈就亮了。你不需要寫任何自然語言解析的代碼。

錯(cuò)誤碼規(guī)范：V1/V2 均統(tǒng)一使用0表示成功，-32602表示參數(shù)錯(cuò)誤?；卣{(diào)函數(shù)里記得處理異常，避免設(shè)備進(jìn)入未定義狀態(tài)。

04 V1 與 V2 的 MCP 能力對(duì)比：差在哪里

兩款的 MCP 架構(gòu)一致，差異主要體現(xiàn)在參數(shù)類型和開發(fā)結(jié)構(gòu)上。

參數(shù)類型：V2 多了字符串

字符串類型的加入，讓 V2 能處理更復(fù)雜的語義。比如"切換到睡眠模式"——這個(gè)"睡眠"是個(gè)字符串，V1 沒法原生傳遞，V2 可以直接把"sleep"傳進(jìn)回調(diào)函數(shù)，你的設(shè)備再根據(jù)字符串值做對(duì)應(yīng)的操作。

開發(fā)文件結(jié)構(gòu)：V2 更規(guī)范

V1 的 MCP 工具開發(fā)在 SDK 內(nèi)靈活定義；V2 則固定了開發(fā)入口：

• project/Xiaozhi-AI/mcp_server/user_mcp_tools.c — 工具實(shí)現(xiàn)
• project/Xiaozhi-AI/mcp_server/user_mcp_tools.h — 工具聲明

固定的文件結(jié)構(gòu)對(duì)團(tuán)隊(duì)協(xié)作更友好——新人知道去哪里找代碼，代碼審查也更容易。

AI 平臺(tái)：V2 多一個(gè)選擇

V1 目前對(duì)接小智 AI；V2 額外支持火山引擎語音平臺(tái)。兩者的 MCP 接口兼容，切換 AI 平臺(tái)不需要重寫工具代碼，只改配置就行。

05 對(duì)工程師來說，MCP 省掉了什么

做過傳統(tǒng)語音控制的工程師都知道有多麻煩：

• 寫關(guān)鍵詞匹配（打開/開啟/亮起來……都得枚舉）
• 維護(hù)指令表（產(chǎn)品迭代一次，指令表就要更新一次）
• 處理語義歧義（"大聲一點(diǎn)"是加10還是加20？）
• 對(duì)接云端 ASR + NLU + 設(shè)備端控制三層邏輯

有了 MCP，這些全省了。你只需要關(guān)心兩件事：工具怎么定義（說清楚 AI 能用什么功能），以及回調(diào)怎么寫（功能觸發(fā)了做什么）。自然語言的理解交給 AI 模型，指令的分發(fā)交給 MCP 協(xié)議，你只管設(shè)備控制邏輯。

量化對(duì)比：傳統(tǒng)方案下，一個(gè)"燈光 + 音量 + 模式切換"三功能語音控制系統(tǒng)，關(guān)鍵詞枚舉 + 邏輯處理大約需要 300-500 行代碼，且隨產(chǎn)品迭代持續(xù)膨脹。用 MCP 實(shí)現(xiàn)同樣功能，工具定義 + 回調(diào)函數(shù)約 80-120 行，后續(xù)新增功能只需追加工具，不影響已有邏輯。

06 內(nèi)置工具示例：燈光 + 音量

兩款 PalChat 的 SDK 里內(nèi)置了兩個(gè)示例工具，可以直接參考：

示例一：燈光控制（Light）

最簡(jiǎn)單的布爾控制場(chǎng)景。用戶說"開燈"或"關(guān)燈"，AI 調(diào)用工具，傳入enabled參數(shù)。

示例二：音量控制（Speaker）

數(shù)值型參數(shù)場(chǎng)景。用戶說"把音量調(diào)到 70"，AI 解析出 70 這個(gè)數(shù)字，直接傳入。

這兩個(gè)示例覆蓋了 MCP 里最常見的兩種參數(shù)類型。實(shí)際開發(fā)時(shí)，基于這兩個(gè)例子做擴(kuò)展，能快速上手。

07 選 V1 還是 V2：一個(gè)判斷框架

兩款都支持 MCP，硬件差異決定了適用場(chǎng)景不同。

選 PalChat V1，如果你：

• 需要快速跑通 MCP 的 demo，驗(yàn)證概念可行性
• 控制邏輯簡(jiǎn)單（只需要布爾型和數(shù)值型參數(shù)）
• 只對(duì)接小智 AI 平臺(tái)
• 預(yù)算有限，用開源版本做前期探索

選 PalChat V2，如果你：

• 需要字符串類型參數(shù)（模式切換、文本類指令）
• 產(chǎn)品需要屏幕顯示交互狀態(tài)
• 需要同時(shí)評(píng)估小智 AI 和火山引擎兩個(gè)平臺(tái)
• 對(duì)代碼規(guī)范性有要求，后續(xù)需要團(tuán)隊(duì)協(xié)作
• 做產(chǎn)品級(jí)開發(fā)而非原型驗(yàn)證

經(jīng)驗(yàn)建議：如果你的產(chǎn)品控制點(diǎn)超過 5 個(gè)，或者涉及模式切換這類"文本型"指令，直接上 V2。V2 的字符串參數(shù)類型和規(guī)范化開發(fā)結(jié)構(gòu)，在產(chǎn)品迭代時(shí)會(huì)省很多麻煩。

08 MCP 的上限在哪里

PalChat 的 MCP 工具數(shù)量受MCP_SERVER_TOOL_NUMBLE_LEN這個(gè)常量限制（V2 文檔中有提及）。實(shí)際上，一個(gè)中等復(fù)雜的智能家居產(chǎn)品——燈光、窗簾、溫度、模式、音樂——五個(gè)工具就能覆蓋大部分控制需求，不會(huì)遇到上限問題。

更重要的是，MCP 協(xié)議本身是開放的，工具的能力邊界取決于你的回調(diào)函數(shù)寫了什么。燈光控制是一個(gè)工具，調(diào)用外部 HTTP API 可以是另一個(gè)工具，讀取傳感器數(shù)據(jù)同樣可以包裝成工具。只要能寫成函數(shù)的操作，都能接進(jìn) MCP。

安信可官方也列出了參考資料：

• MCP 中文站 — 協(xié)議規(guī)范文檔
• 小智 AI MCP 交互流程 — 具體實(shí)現(xiàn)參考

09 總結(jié)

PalChat V1 和 V2 都把 MCP 做成了開箱即用的能力：三步開發(fā)流程、兩個(gè)內(nèi)置示例、標(biāo)準(zhǔn)化的回調(diào)接口。對(duì)工程師來說，最直接的價(jià)值是省掉了自然語言解析這層復(fù)雜度，讓設(shè)備控制回歸到熟悉的"函數(shù)定義 + 參數(shù)處理"模式。

兩款的核心差異在于：V1 輕量、適合驗(yàn)證；V2 更完整，多了屏幕、字符串參數(shù)類型、多 AI 平臺(tái)支持。項(xiàng)目處于探索期，選 V1；準(zhǔn)備做成產(chǎn)品，選 V2。

MCP 這條路，安信可鋪好了基礎(chǔ)設(shè)施。剩下的，就是你的設(shè)備要做什么了。這正是"安信可，可安心"的意思——底層的通信和協(xié)議對(duì)接已經(jīng)幫你做完，你只管專注產(chǎn)品邏輯。