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

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

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

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

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

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

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

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

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

兩款都支持 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ù)定義
};

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

一行代碼把工具加進去：

mcp_server_add_tool_to_toolList(&light_tool);

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

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

// 控制回調(diào)：AI 說"關(guān)燈"時觸發(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 問"燈開著嗎"時觸發(fā)
void light_check_callback(void *params) {
  bool state = gpio_get_level(LIGHT_PIN);
  set_response_bool("enabled", state);
}

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

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

04 V1 與 V2 的 MCP 能力對比：差在哪里

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

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

字符串類型的加入，讓 V2 能處理更復(fù)雜的語義。比如"切換到睡眠模式"——這個"睡眠"是個字符串，V1 沒法原生傳遞，V2 可以直接把"sleep"傳進回調(diào)函數(shù)，你的設(shè)備再根據(jù)字符串值做對應(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 — 工具實現(xiàn)

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

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

AI 平臺：V2 多一個選擇

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

05 對工程師來說，MCP 省掉了什么

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

寫關(guān)鍵詞匹配（打開/開啟/亮起來……都得枚舉）

維護指令表（產(chǎn)品迭代一次，指令表就要更新一次）

處理語義歧義（"大聲一點"是加10還是加20？）

對接云端 ASR + NLU + 設(shè)備端控制三層邏輯

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

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

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

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

示例一：燈光控制（Light）

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

示例二：音量控制（Speaker）

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

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

07 選 V1 還是 V2：一個判斷框架

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

選 PalChat V1，如果你：

需要快速跑通 MCP 的 demo，驗證概念可行性

控制邏輯簡單（只需要布爾型和數(shù)值型參數(shù)）

只對接小智 AI 平臺

預(yù)算有限，用開源版本做前期探索

選 PalChat V2，如果你：

需要字符串類型參數(shù)（模式切換、文本類指令）

產(chǎn)品需要屏幕顯示交互狀態(tài)

需要同時評估小智 AI 和火山引擎兩個平臺

對代碼規(guī)范性有要求，后續(xù)需要團隊協(xié)作

做產(chǎn)品級開發(fā)而非原型驗證

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

08 MCP 的上限在哪里

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

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

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

MCP 中文站— 協(xié)議規(guī)范文檔

小智 AI MCP 交互流程— 具體實現(xiàn)參考

09 總結(jié)

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

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

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