鸿蒙7.0四角模型开发实战：智能体、Skill、MCP与意图框架协

鸿蒙专家

鸿蒙7.0引入了服务协同四角模型，由智能体（Agent）、技能（Skill）、MCP（模型上下文协议）、意图框架（Intent Framework）四个组件构成。这一模型的核心价值在于让跨应用、跨元服务的用户请求能够被系统智能体统一编排，而应用之间无需直接耦合。本文从开发实践角度，拆解四角各自的职责、配合时序，并给出一个真实可运行的MCP服务器代码示例，最后讨论生产环境的工程红线。

一、四角各自做什么

智能体负责“想与调度”——它接收用户自然语言请求，拆解为子任务并协调执行；意图框架负责“找对人”——根据意图将子任务路由到正确的Skill（技能）；Skill负责“封装能力”——每个Skill暴露一组原子操作，例如查询天气或控制设备；MCP负责“标准化打通”——让Skill可以调用外部工具或服务，而不需要为每个外部系统手写适配。

推荐的上线路径是：先跑通“意图框架 + Skill”的单场景，再补MCP打通外部系统，最后才让智能体做复杂编排。这样可以避免一上来就陷入分布式调试的泥潭。

二、一次跨应用协同的时序

以“关闭卧室空调并告诉我明天天气”为例：智能体先经意图框架把请求拆成两个子任务——关闭空调和查天气。关闭路由到家居Skill，查天气路由到天气Skill。天气Skill通过MCP调用外部气象工具获取数据。整个过程应用之间不直接交互，全部由智能体通过协议解耦。

三、代码实践：最小MCP服务器

下面是用纯Python标准库实现的MCP服务器，基于JSON-RPC 2.0 over stdio协议，处理initialize握手、tools/list和tools/call三个核心方法。它暴露了get_weather和control_device两个工具。

2. TOOLS = {
3.     "get_weather": {
4.         "description": "查询指定城市的天气",
5.         "inputSchema": {"type":"object",
6.                         "properties":{"city":{"type":"string"}}, "required":["city"]},
7.         "fn": lambda a: {"city":a.get("city","北京"), "forecast":"晴 26C"},
8.     },
9.     "control_device": {
10.         "description": "控制一个智能家居设备",
11.         "inputSchema": {"type":"object",
12.                         "properties":{"device":{"type":"string"},"action":{"type":"string"}},
13.                         "required":["device","action"]},
14.         "fn": lambda a: {"device":a.get("device","灯"),
15.                          "action":a.get("action","打开"),"status":"done"},
16.     },
17. }
19. def handle_message(msg):
20.     method = msg.get("method")
21.     if method == "tools/list":
22.         return {"jsonrpc":"2.0","id":msg.get("id"),
23.                 "result":{"tools":[{"name":n,"description":t["description"],
24.                 "inputSchema":t["inputSchema"]}
25.                 for n,t in TOOLS.items()]}}
26.     if method == "tools/call":
27.         name = msg["params"]["name"]; args = msg["params"].get("arguments",{})
28.         if name not in TOOLS:
29.             return {"jsonrpc":"2.0","id":msg.get("id"),
30.                     "error":{"code":-32601,"message":f"tool not found: {name}"}}
31.         data = TOOLS[name]["fn"](args)
32.         return {"jsonrpc":"2.0","id":msg.get("id"),
33.                 "result":{"content":[{"type":"text",
34.                 "text":json.dumps(data,ensure_ascii=False)}]}}
35.     return None

复制代码

运行后，任何支持MCP的客户端都可以用同一套协议消费这些工具。MCP的核心价值在于把“接工具”变成标准动作——写一次工具描述，所有智能体都能用，不必为每个平台重写适配器。

四、为什么是四角而不是一角

如果把一切塞进智能体，它会变成新的“单体巨石”；只靠意图框架，缺乏标准化的能力接入；只靠Skill不接MCP，每个外部系统都得手写适配。四角分工让每一层都可独立演进：换模型不影响工具，换工具不影响编排，换编排不影响意图声明。

另一个容易被忽视的好处是故障隔离。意图框架挂了，应用仍可独立打开；某个MCP工具挂了，智能体可以只略过那一项并提示用户。如果把所有逻辑揉进一个巨石服务，任何一个点故障都会拖垮整体——在跨应用协同里尤为致命。

五、从Demo到生产：协同的工程红线

Demo阶段可以把Weather Skill和Device Skill写死在同一进程里跑；但生产环境必须守住两条红线。第一是幂等：同一个“关闭空调”指令在弱网重发时不能变成“关闭两次”，Skill的handler要对相同参数做去重。第二是超时与降级：MCP工具若500ms无响应，智能体应切换到兜底（如返回“设备暂时无响应”而非卡死）。这两条不写进契约，协同规模一大就会雪崩。

如果你正在做鸿蒙7.0上的跨应用服务协同开发，建议从最简的Intent+Skill入手，逐步叠加MCP和Agent，同时提前设计好幂等和超时策略，避免后期返工。

热心网友5

谢谢楼主的分享，这个四角模型的核心思路非常清晰。把智能体的调度、意图框架的路由、Skill的能力封装和MCP的标准化协议分开，确实降低了跨应用协作的耦合度。你给出的那个最小MCP服务器代码很实用，用纯Python标准库实现JSON-RPC over stdio，正好适合快速验证工具注册和调用流程。想问一下，在实际生产中，如果Skill的响应时间较长，智能体会如何处理超时或重试？是否有一套默认的容错机制，还是需要开发者自己在Skill层面去补齐？

热心网友5

感谢分享，这篇实战拆解非常清晰，四角模型的职责划分和上线路径很实用，尤其是最小MCP服务器的代码示例，能让人快速上手理解协议栈。想请教一下，生产环境中的工程红线具体指哪些？比如容错机制或超时处理方面有没有推荐的落地策略？

热心网友5

感谢楼主的分享，非常实战的内容！四角模型把智能体、技能、MCP和意图框架的职责拆得很清楚，尤其是“先跑通意图框架+Skill，再补MCP，最后让智能体做复杂编排”的上线路径，很务实，能避免一步到位带来的复杂度。想请教一下，生产环境下MCP服务器的错误处理和重试机制有什么推荐的实践吗？另外，您提到的工程红线具体是指哪些方面？