鸿蒙 App 如何设计 Tool Calling？一文讲透 MCP 与工具调用架构

网罗开发小红书、快手、视频号同名大家好我是展菲目前在上市企业从事人工智能项目研发管理工作平时热衷于分享各种编程领域的软硬技能知识以及前沿技术包括iOS、前端、Harmony OS、Java、Python等方向。在移动端开发、鸿蒙开发、物联网、嵌入式、云原生、开源等领域有深厚造诣。图书作者《ESP32-C3 物联网工程开发实战》图书作者《SwiftUI 入门进阶与实战》超级个体COC上海社区主理人特约讲师大学讲师谷歌亚马逊分享嘉宾科技博主华为HDE/HDG我的博客内容涵盖广泛主要分享技术教程、Bug解决方案、开发工具使用、前沿科技资讯、产品评测与使用体验。我特别关注云服务产品评测、AI 产品对比、开发板性能测试以及技术报告同时也会提供产品优缺点分析、横向对比并分享技术沙龙与行业大会的参会体验。我的目标是为读者提供有深度、有实用价值的技术洞察与分析。展菲您的前沿技术领航员 大家好我是展菲 全网搜索“展菲”即可纵览我在各大平台的知识足迹。每周定时推送干货满满的技术长文从新兴框架的剖析到运维实战的复盘助您技术进阶之路畅通无阻。文章目录引言一、Tool Calling 的本质是什么Tool Calling 的核心价值二、鸿蒙 App 为什么必须设计 Tool Runtime三、企业级 Tool Calling 架构设计四、Tool Registry工具注册中心五、Tool Dispatcher调度核心六、Permission Layer安全控制核心七、MCPTool Calling 的下一代协议MCP 架构MCP 的核心价值八、Tool Execution Pipeline核心执行链路九、Observation为什么工具返回不能太“脏”十、Context 更新机制十一、Tool Calling 与 State Machine 的关系十二、鸿蒙 Tool Runtime 推荐架构总结引言过去两年大模型能力的提升几乎是指数级的。从ChatGPT → Claude → Gemini → DeepSeek再到LangChain → AutoGen → CrewAI → LangGraph整个行业正在从“聊天模型”快速进入Agent 驱动的应用时代但在真正落地鸿蒙 App 或企业系统时会遇到一个非常现实的问题模型会思考但不会执行例如帮我创建一个会议模型可以回答好的我帮你安排会议但它做不了创建日历事件 调用系统 API 发送通知 写入本地数据原因很简单LLM 只是推理引擎不是执行系统。于是一个关键能力被引入Tool Calling工具调用它的本质是让模型“发起请求”而不是“直接执行”一、Tool Calling 的本质是什么一句话理解Tool Calling LLM 外部执行系统之间的协议层模型输出的不再是最终答案而是{tool:create_calendar_event,args:{title:会议,time:14:00}}然后由 Runtime 执行LLM → Tool Runtime → 系统能力 → 返回结果Tool Calling 的核心价值它解决了三个问题1、 模型不会“直接操作系统”模型只能输出结构化意图。2、 系统能力可控所有能力必须通过 Tool 暴露。3、AI 可以“接入现实世界”从文本生成变成任务执行二、鸿蒙 App 为什么必须设计 Tool Runtime在鸿蒙系统中AI 不再只是一个 SDK而是系统能力调度层的一部分如果直接让 LLM 调用系统 API会出现权限不可控调用路径混乱多 Agent 冲突安全不可审计因此必须引入Tool Runtime工具执行中间层三、企业级 Tool Calling 架构设计一个完整的鸿蒙 AI Tool Runtime 通常包含六层┌──────────────────────┐ │ LLM │ └─────────┬────────────┘ ▼ ┌──────────────────────┐ │ Tool Dispatcher │ └─────────┬────────────┘ ▼ ┌──────────────────────┐ │ Tool Registry │ └─────────┬────────────┘ ▼ ┌──────────────────────┐ │ Permission Layer │ └─────────┬────────────┘ ▼ ┌──────────────────────┐ │ MCP Connector │ └─────────┬────────────┘ ▼ ┌──────────────────────┐ │ HarmonyOS Services │ └──────────────────────┘这套结构的核心思想是LLM 负责“想做什么”Runtime 负责“如何安全地做”。四、Tool Registry工具注册中心所有系统能力必须以 Tool 形式注册exportinterfaceTool{name:string;description:string;execute(args:any):Promiseany;}注册方式registry.register(newCalendarTool());registry.register(newSearchTool());registry.register(newLocationTool());Tool Registry 的作用工具统一管理支持动态扩展支持 MCP 接入支持版本控制五、Tool Dispatcher调度核心Dispatcher 是 Tool Runtime 的“入口层”。负责工具匹配 参数分发 异常处理 超时控制示例consttoolregistry.find(toolName);if(!tool)thrownewError(Tool not found);returnawaittool.execute(args);企业级 Dispatcher 必备能力Retry 机制熔断机制限流FallbackTrace 日志六、Permission Layer安全控制核心AI 最大的问题不是能力而是不可控执行风险例如删除文件 发送短信 访问通讯录 支付操作必须通过权限层控制{tool:sms,permission:SEND_SMS}Runtime 校验User Permission System Policy Context Risk全部通过才能执行。七、MCPTool Calling 的下一代协议MCPModel Context Protocol可以理解为AI 世界的 USB-C 接口标准它解决的问题是Tool 无法互通 模型无法统一调用 系统能力无法标准化MCP 架构LLM │ MCP Client(Runtime) │ ┌─────────┼─────────┐ ▼ ▼ ▼ Calendar Search Browser Server Server ServerMCP 的核心价值工具即服务模型无关Runtime 标准化动态发现能力八、Tool Execution Pipeline核心执行链路一次 Tool Calling 在企业系统中实际是完整流水线User Goal ↓ Intent Parsing ↓ Planner ↓ Tool Selection ↓ Argument Validation ↓ Permission Check ↓ Tool Dispatch ↓ Tool Execution ↓ Observation ↓ Context Update ↓ LLM Continue Reasoning关键点模型只参与一半流程LLM 只负责选择 Tool 生成参数其余全部由 Runtime 完成。九、Observation为什么工具返回不能太“脏”Tool 执行结果如果直接返回3000行JSON模型会直接崩正确做法是结构化 摘要化 关键字段提取例如{status:success,event:会议已创建,time:14:00}十、Context 更新机制Tool 执行完成后必须进入Context Injection包括Tool ResultState UpdateMemory 写入Task Progress 更新否则模型会重复调用 Tool十一、Tool Calling 与 State Machine 的关系Tool Calling 永远运行在 State Machine 之中Idle ↓ Planning ↓ Tool Selecting ↓ Executing ↓ Observing ↓ Completed十二、鸿蒙 Tool Runtime 推荐架构src/ ├── runtime/ │ ├── dispatcher.ts │ ├── stateMachine.ts │ ├── pipeline.ts │ ├── tools/ │ ├── calendar.ts │ ├── search.ts │ ├── system.ts │ ├── mcp/ │ ├── client.ts │ ├── registry.ts │ ├── security/ │ ├── permission.ts总结如果用一句话理解 Tool CallingTool Calling 是 AI 从“语言系统”走向“执行系统”的关键桥梁。在鸿蒙 AI Native App 中LLM 决策层Tool Runtime 执行层MCP 工具生态标准Permission Layer 安全边界最终形成完整结构Goal ↓ LLM ↓ Tool Runtime ↓ MCP Services ↓ HarmonyOS System未来 AI App 的竞争不是模型能力的竞争而是 Tool Runtime 与工具生态的竞争。