鸿蒙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，但原理一致。
import re
class Intent:
def __init__(self, name, domain, description, triggers, params, handler):
self.name = name
self.domain = domain
self.description = description
self.triggers = triggers
self.params = params
self.handler = handler
class IntentFramework:
def __init__(self):
self.intents = {}
def register(self, intent):
self.intents = intent
def route(self, query):
best, best_score = None, 0
for it in self.intents.values():
score = sum(1 for kw in it.triggers if kw in query)
if score > best_score:
best, best_score = it, score
if best is None or best_score == 0:
return None, {}
extracted = {}
for p in best.params:
m = re.search(p.get("pattern", r""), query)
extracted] = m.group(1) if m else (None if p.get("required") else None)
return best, extracted
def handler_bill(params):
card = params.get("card") or "尾号默认卡"
if params.get("card") is None:
return {"need_fill": "card", "reply": "请问要查询哪张银行卡的账单？"}
return {"reply": f"已为您拉取 {card} 的本月账单：应还 ￥3,280.50，最低还款 ￥328.05。"}
fw = IntentFramework()
fw.register(Intent("query_bill",
domain="finance",
description="查询信用卡或银行卡账单",
triggers=["账单","还款","信用卡","银行卡"],
params=[{"name":"card","required":False,"pattern":r"(尾号\d{4}|储蓄卡|信用卡)"}],
handler=handler_bill))
it, params = fw.route("帮我看看这月信用卡账单")
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中，尽早为业务注册意图，是让应用被系统智能体优先调用的关键一步。
Re: 鸿蒙7.0接入系统AI：意图框架让应用被智能体主动调用
楼主这篇文章讲得太清楚了！之前一直不太理解鸿蒙智能体怎么跟应用交互，看完这个“意图框架”的拆解瞬间明白了——把应用能力抽象成意图，让系统AI按需调度，确实是“被动点击”到“主动服务”的质变。那个Python模拟代码虽然简单，但把注册、路由、参数抽取、缺省补全的闭环都跑通了，很直观。想问下鸿蒙实际开发中，ArkTS的意图注册API是不是也类似这样以domain/triggers/params来声明？另外triggers里如果用同义词组会不会自动匹配，还是需要开发者自己穷举？谢谢分享！Re: 鸿蒙7.0接入系统AI：意图框架让应用被智能体主动调用
感谢楼主分享，写得非常清晰！那个意图框架的 Python 模拟让我对“自然语言→能力路由”有了很直观的理解。特别是 need_fill 的设计，让智能体通过反问补全参数，确实比直接抛错优雅很多。我有个小问题：实际鸿蒙开发中，triggers 的措辞需要开发者自己调研整理吗？还是系统会提供一些行业通用的预置词库做参考？Re: 鸿蒙7.0接入系统AI：意图框架让应用被智能体主动调用
感谢分享！看完这篇对鸿蒙7.0的意图框架有了比较直观的理解，尤其是那段Python模拟代码，把“声明→路由→参数抽取→回调”闭环跑通了，对理解核心概念很有帮助。 有一个小问题想请教：你提到的`need_fill`标记让智能体反问补全，实际应用中如果用户连续多次说不清参数，智能体会不会陷入无限反问循环？系统内部有没有类似“超时降级”或“默认值兜底”的机制来保证体验？ 另外，元服务注册意图时，不同开发者可能定义相似的`triggers`，系统打分路由是如何避免冲突的？是在注册阶段做冲突检测，还是路由阶段靠意图的domain或优先级来区分？
页:
[1]