智能盒子-Agent-Skill-执行逻辑架构在 智能盒子的架构中Agent Skill智能插件/工具的执行逻辑是一个从“非结构化语音输入”到“结构化指令执行”再到“感知反馈”的完整闭环。它基于MCP (Model Context Protocol)协议通过Function Calling机制实现。以下是详细的执行逻辑拆解1. 整体执行流程图Agent Skill 的执行不是孤立的它与意图识别、长短期记忆以及情感引擎深度耦合。2. 核心执行阶段第一阶段意图识别与工具匹配 (Intent Routing)语音转文字 (ASR)用户输入如“帮我看看明天武汉要不要带伞”。意图路由 (Router)中台根据用户话术解析意图。如果识别为“查询类”或“控制类”则进入 Skill 匹配流程。可用工具检索 (Discovery)系统从Available Tools库中根据当前上下文检索匹配的 Skill 定义如get_weather。第二阶段参数抽取与指令生成 (Parameter Extraction)大模型推理将用户输入与选定的工具 Meta 信息JSON Schema投喂给 LLM。结构化输出LLM 不直接回答问题而是输出符合标准的JSON 指令。示例{tool: weather_service, params: {city: Wuhan, date: tomorrow}}MCP 插件下沉通过 MCP 协议将该 JSON 指令分发至具体的业务逻辑层或边缘端ESP32。第三阶段任务编排与执行 (Orchestration Execution)原子化拆解对于复杂任务如“先帮我开灯然后查一下最近的新闻”编排引擎会将请求拆分为多个顺序或并行的 Skill 调用。闭环执行外部调用访问天气 API、搜索接口或 IoT 指令。异常处理若工具调用失败如接口超时系统需捕获 Error 并反馈给 LLM 进行自愈或提示用户。第四阶段感知更新与结果润色 (Feedback Response)记忆写入执行结果如“武汉明天有雨”会被存入短期记忆。情绪/亲密度反馈成功执行触发on_skill_success根据 PRD 逻辑增加 AI 的支配感Dominance和用户亲密度Intimacy 0.01。最终回复生成LLM 结合执行结果与当前性格/情绪状态生成拟人化的语音回复。3. 基于 Go-zero 的技术实现细节在你的项目中这套逻辑在代码层面通常表现为以下链路定义层 (Schema)在go-zero的插件服务中定义各 Skill 的输入输出规范。调用层 (Invocation)Go// 简化后的工具调度逻辑 func (s *SkillEngine) Execute(ctx context.Context, call ToolCall) (string, error) { // 1. 意图分发 handler, ok : s.registry[call.FunctionName] if !ok { return , ErrToolNotFound } // 2. 权限/上下文检查 (结合 RAG 记忆) // 3. 业务逻辑执行 result, err : handler.Do(ctx, call.Arguments) // 4. 反馈给情绪引擎更新 PAD 状态 s.moodService.UpdateByAction(call.FunctionName, err nil) return result, nil }4. 关键特性MCP 协议的意义通过引入MCP (Model Context Protocol)你的 Agent Skill 具备了以下优势标准化无论 Skill 是运行在云端天气预报还是边缘端 ESP32红外控制其接口协议是统一的。动态性LLM 可以根据当前对话的上下文动态决定是否需要“增加”某个临时工具实现真正的任务编排。安全隔离大模型只负责“决策”调用哪个工具而“执行”权在受控的插件系统中避免了注入风险。总结Agent Skill 的执行逻辑是“识别 - 拆解 - 执行 - 反馈”。在 智能盒子中它不仅完成了功能交付更通过执行结果的反馈驱动了 AI 长期记忆的更新和情感状态的起伏。
智能盒子-Agent-Skill-执行逻辑架构
发布时间：2026/5/22 9:25:27
智能盒子-Agent-Skill-执行逻辑架构在 智能盒子的架构中Agent Skill智能插件/工具的执行逻辑是一个从“非结构化语音输入”到“结构化指令执行”再到“感知反馈”的完整闭环。它基于MCP (Model Context Protocol)协议通过Function Calling机制实现。以下是详细的执行逻辑拆解1. 整体执行流程图Agent Skill 的执行不是孤立的它与意图识别、长短期记忆以及情感引擎深度耦合。2. 核心执行阶段第一阶段意图识别与工具匹配 (Intent Routing)语音转文字 (ASR)用户输入如“帮我看看明天武汉要不要带伞”。意图路由 (Router)中台根据用户话术解析意图。如果识别为“查询类”或“控制类”则进入 Skill 匹配流程。可用工具检索 (Discovery)系统从Available Tools库中根据当前上下文检索匹配的 Skill 定义如get_weather。第二阶段参数抽取与指令生成 (Parameter Extraction)大模型推理将用户输入与选定的工具 Meta 信息JSON Schema投喂给 LLM。结构化输出LLM 不直接回答问题而是输出符合标准的JSON 指令。示例{tool: weather_service, params: {city: Wuhan, date: tomorrow}}MCP 插件下沉通过 MCP 协议将该 JSON 指令分发至具体的业务逻辑层或边缘端ESP32。第三阶段任务编排与执行 (Orchestration Execution)原子化拆解对于复杂任务如“先帮我开灯然后查一下最近的新闻”编排引擎会将请求拆分为多个顺序或并行的 Skill 调用。闭环执行外部调用访问天气 API、搜索接口或 IoT 指令。异常处理若工具调用失败如接口超时系统需捕获 Error 并反馈给 LLM 进行自愈或提示用户。第四阶段感知更新与结果润色 (Feedback Response)记忆写入执行结果如“武汉明天有雨”会被存入短期记忆。情绪/亲密度反馈成功执行触发on_skill_success根据 PRD 逻辑增加 AI 的支配感Dominance和用户亲密度Intimacy 0.01。最终回复生成LLM 结合执行结果与当前性格/情绪状态生成拟人化的语音回复。3. 基于 Go-zero 的技术实现细节在你的项目中这套逻辑在代码层面通常表现为以下链路定义层 (Schema)在go-zero的插件服务中定义各 Skill 的输入输出规范。调用层 (Invocation)Go// 简化后的工具调度逻辑 func (s *SkillEngine) Execute(ctx context.Context, call ToolCall) (string, error) { // 1. 意图分发 handler, ok : s.registry[call.FunctionName] if !ok { return , ErrToolNotFound } // 2. 权限/上下文检查 (结合 RAG 记忆) // 3. 业务逻辑执行 result, err : handler.Do(ctx, call.Arguments) // 4. 反馈给情绪引擎更新 PAD 状态 s.moodService.UpdateByAction(call.FunctionName, err nil) return result, nil }4. 关键特性MCP 协议的意义通过引入MCP (Model Context Protocol)你的 Agent Skill 具备了以下优势标准化无论 Skill 是运行在云端天气预报还是边缘端 ESP32红外控制其接口协议是统一的。动态性LLM 可以根据当前对话的上下文动态决定是否需要“增加”某个临时工具实现真正的任务编排。安全隔离大模型只负责“决策”调用哪个工具而“执行”权在受控的插件系统中避免了注入风险。总结Agent Skill 的执行逻辑是“识别 - 拆解 - 执行 - 反馈”。在 智能盒子中它不仅完成了功能交付更通过执行结果的反馈驱动了 AI 长期记忆的更新和情感状态的起伏。
