网罗开发 （小红书、快手、视频号同名）

  大家好，我是 展菲，目前在上市企业从事人工智能项目研发管理工作，平时热衷于分享各种编程领域的软硬技能知识以及前沿技术，包括iOS、前端、Harmony OS、Java、Python等方向。在移动端开发、鸿蒙开发、物联网、嵌入式、云原生、开源等领域有深厚造诣。

图书作者：《ESP32-C3 物联网工程开发实战》
图书作者：《SwiftUI 入门，进阶与实战》
超级个体：COC上海社区主理人
特约讲师：大学讲师，谷歌亚马逊分享嘉宾
科技博主：华为HDE/HDG

我的博客内容涵盖广泛，主要分享技术教程、Bug解决方案、开发工具使用、前沿科技资讯、产品评测与使用体验。我特别关注云服务产品评测、AI 产品对比、开发板性能测试以及技术报告，同时也会提供产品优缺点分析、横向对比，并分享技术沙龙与行业大会的参会体验。我的目标是为读者提供有深度、有实用价值的技术洞察与分析。

展菲：您的前沿技术领航员
👋 大家好，我是展菲！
📱 全网搜索“展菲”，即可纵览我在各大平台的知识足迹。
每周定时推送干货满满的技术长文，从新兴框架的剖析到运维实战的复盘，助您技术进阶之路畅通无阻。

引言

过去两年，大模型能力的提升几乎是指数级的。

从：

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 形式注册：

export interface Tool {
  name: string;
  description: string;

  execute(args: any): Promise<any>;
}

注册方式：

registry.register(new CalendarTool());
registry.register(new SearchTool());
registry.register(new LocationTool());

Tool Registry 的作用

• 工具统一管理
• 支持动态扩展
• 支持 MCP 接入
• 支持版本控制

五、Tool Dispatcher：调度核心

Dispatcher 是 Tool Runtime 的“入口层”。

负责：

工具匹配
参数分发
异常处理
超时控制

示例：

const tool = registry.find(toolName);

if (!tool) throw new Error("Tool not found");

return await tool.execute(args);

企业级 Dispatcher 必备能力

• Retry 机制
• 熔断机制
• 限流
• Fallback
• Trace 日志

六、Permission Layer：安全控制核心

AI 最大的问题不是能力，而是：

不可控执行风险

例如：

删除文件
发送短信
访问通讯录
支付操作

必须通过权限层控制：

{
  "tool": "sms",
  "permission": "SEND_SMS"
}

Runtime 校验：

User Permission + System Policy + Context Risk

全部通过才能执行。

七、MCP：Tool Calling 的下一代协议

MCP（Model Context Protocol）可以理解为：

AI 世界的 USB-C 接口标准

它解决的问题是：

Tool 无法互通
模型无法统一调用
系统能力无法标准化

MCP 架构

           LLM
            │
     MCP Client(Runtime)
            │
  ┌─────────┼─────────┐
  ▼         ▼         ▼
Calendar  Search   Browser
Server    Server    Server

MCP 的核心价值

• 工具即服务
• 模型无关
• 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 Result
• State Update
• Memory 写入
• 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 Calling：

Tool Calling 是 AI 从“语言系统”走向“执行系统”的关键桥梁。

在鸿蒙 AI Native App 中：

• LLM = 决策层
• Tool Runtime = 执行层
• MCP = 工具生态标准
• Permission Layer = 安全边界

最终形成完整结构：

Goal
 ↓
LLM
 ↓
Tool Runtime
 ↓
MCP Services
 ↓
HarmonyOS System

未来 AI App 的竞争，不是模型能力的竞争，而是 Tool Runtime 与工具生态的竞争。