鸿蒙7.0接入系统AI：意图框架让应用被智能体主动调用

鸿蒙专家

在HDC 2026上，HarmonyOS 7将智能体升级为操作系统的一等公民。对应用和元服务开发者而言，最实质的变化是：你的业务能力第一次能被系统级智能体主动发现、编排与调用。本文聚焦如何把应用或元服务的能力接入系统AI体系，让功能从“被动等待用户点击”变为“主动被智能体调度”。

一、系统AI能力的四层架构
鸿蒙7.0的智能化是一套分层体系。应用和元服务处于“能力供给”层，向上被意图框架与系统智能体消费。开发者不再仅仅编写UI流程，而是编写一组可被编排的能力契约。意图框架本质上是“自然语言→能力”的路由器：将用户的自然语言查询，路由到已注册的意图单元，并抽取参数，最终执行对应handler。

二、元服务与原子化能力声明
元服务（Meta Service）是鸿蒙的原子化形态：免安装、跨端、可被打散重组。在智能化语境下，最佳实践是将核心业务封装成一个个意图（Intent），声明清楚：领域归属、触发关键词、参数契约、执行函数。系统智能体通过意图注册表发现可用能力，并基于用户输入进行打分路由。

三、最小可运行的意图框架模拟
下面这段Python代码复刻了“应用声明意图→系统路由→参数抽取→调用”的最小闭环，可直接用python intent_framework_sim.py跑通。注意：实际鸿蒙开发中，注册意图使用ArkTS或C++ API，但原理一致。

2. import re
4. class Intent:
5.     def __init__(self, name, domain, description, triggers, params, handler):
6.         self.name = name
7.         self.domain = domain
8.         self.description = description
9.         self.triggers = triggers
10.         self.params = params
11.         self.handler = handler
13. class IntentFramework:
14.     def __init__(self):
15.         self.intents = {}
16.     def register(self, intent):
17.         self.intents[intent.name] = intent
18.     def route(self, query):
19.         best, best_score = None, 0
20.         for it in self.intents.values():
21.             score = sum(1 for kw in it.triggers if kw in query)
22.             if score > best_score:
23.                 best, best_score = it, score
24.         if best is None or best_score == 0:
25.             return None, {}
26.         extracted = {}
27.         for p in best.params:
28.             m = re.search(p.get("pattern", r""), query)
29.             extracted[p["name"]] = m.group(1) if m else (None if p.get("required") else None)
30.         return best, extracted
32. def handler_bill(params):
33.     card = params.get("card") or "尾号默认卡"
34.     if params.get("card") is None:
35.         return {"need_fill": "card", "reply": "请问要查询哪张银行卡的账单？"}
36.     return {"reply": f"已为您拉取 {card} 的本月账单：应还 ￥3,280.50，最低还款 ￥328.05。"}
38. fw = IntentFramework()
39. fw.register(Intent("query_bill",
40.                    domain="finance",
41.                    description="查询信用卡或银行卡账单",
42.                    triggers=["账单","还款","信用卡","银行卡"],
43.                    params=[{"name":"card","required":False,"pattern":r"(尾号\d{4}|储蓄卡|信用卡)"}],
44.                    handler=handler_bill))
46. it, params = fw.route("帮我看看这月信用卡账单")
47. print(it.name, params, it.handler(params))

复制代码

运行结果将正确命中query_bill，参数card被抽取为“信用卡”，handler返回结构化结果。若用户没说清哪张卡，契约会标记need_fill，由智能体反问补全——这正是“确定性交给意图，不确定性交给模型”的落地实践。

四、接入要点与三个常见坑
**接入要点**：
- 使用意图框架API声明意图时，准确填写domain、triggers、params。
- triggers的措辞直接影响路由命中率，建议用“领域词+动作词”组合。
- 参数缺省时，应当返回need_fill标记，让系统智能体交互补全，而非直接报错。

**常见坑**：
1. handler过度封装业务逻辑：正确做法是handler只做归一化、授权校验、调用后端服务、返回结构化结果，业务逻辑留在后端。
2. triggers写得过窄或过宽：导致漏命中或误命中，应持续用真实用户语料校准。
3. 忽略参数缺省体验：用户没说清就报错失败页，应仿照示例让智能体反问，把不确定性留在对话层。

五、小结
接入系统AI能力的核心，是将“我能做什么”用机器可理解的方式讲清楚：领域、触发词、参数契约、执行函数。元服务+意图框架让应用从被动功能变为主动可被编排的能力单元。在鸿蒙7.0中，尽早为业务注册意图，是让应用被系统智能体优先调用的关键一步。

热心网友5

楼主这篇文章讲得太清楚了！之前一直不太理解鸿蒙智能体怎么跟应用交互，看完这个“意图框架”的拆解瞬间明白了——把应用能力抽象成意图，让系统AI按需调度，确实是“被动点击”到“主动服务”的质变。那个Python模拟代码虽然简单，但把注册、路由、参数抽取、缺省补全的闭环都跑通了，很直观。想问下鸿蒙实际开发中，ArkTS的意图注册API是不是也类似这样以domain/triggers/params来声明？另外triggers里如果用同义词组会不会自动匹配，还是需要开发者自己穷举？谢谢分享！

热心网友5

感谢楼主分享，写得非常清晰！那个意图框架的 Python 模拟让我对“自然语言→能力路由”有了很直观的理解。特别是 need_fill 的设计，让智能体通过反问补全参数，确实比直接抛错优雅很多。我有个小问题：实际鸿蒙开发中，triggers 的措辞需要开发者自己调研整理吗？还是系统会提供一些行业通用的预置词库做参考？

热心网友5

感谢分享！看完这篇对鸿蒙7.0的意图框架有了比较直观的理解，尤其是那段Python模拟代码，把“声明→路由→参数抽取→回调”闭环跑通了，对理解核心概念很有帮助。 有一个小问题想请教：你提到的`need_fill`标记让智能体反问补全，实际应用中如果用户连续多次说不清参数，智能体会不会陷入无限反问循环？系统内部有没有类似“超时降级”或“默认值兜底”的机制来保证体验？ 另外，元服务注册意图时，不同开发者可能定义相似的`triggers`，系统打分路由是如何避免冲突的？是在注册阶段做冲突检测，还是路由阶段靠意图的domain或优先级来区分？