【HarmonyOS学习笔记】2026-08-05 | 端插件卡片绑定与跨上下文判断date: 2026-08-05tags: [HarmonyOS, 端插件, InsightIntentEntry, 小艺开放平台, 卡片绑定, 长期记忆, LLM]type: 实战笔记一、小艺结果卡片绑定规则卡片参数类型与绑定关系小艺结果卡片绑定端插件返回值时卡片参数类型决定了能绑定什么卡片参数类型能否绑定端插件result说明string❌类型不匹配result是object不是stringnumber❌同上object✅需要声明子项子项名与result字段名一致正确绑定方式卡片参数 result 定义为object 类型在 object 内声明子项子项名与端插件返回值 result 中的字段名完全一致子项按名称自动匹配端插件 result 的字段卡片参数定义 result (object) ├─ actionId (string) ├─ _source (string) └─ _timestamp (string) 端插件返回 { code: 0, result: { actionId: act_11, _source: MyEndPlugin, _timestamp: ... } } 绑定结果 卡片result(object) ← 端插件result(object) ✅ 自动匹配 卡片result.actionId ← 端插件result.actionId ✅ 子项自动对应关键规则每个端插件的返回值 result 字段必须在卡片参数 object 子项中完整声明否则绑不到code 是顶级字段与 result 同级卡片参数可直接定义为 number 类型绑定如果卡片 result 定义成 string 类型永远绑不上端插件的 object 类型 result二、端插件返回值设计返回值结构InsightIntentEntryExecutorT的返回类型是insightIntent.IntentResultT结构固定{code:number,// 0成功非0失败result:T// 泛型由开发者自定义}返回值是端侧代码决定的不需要在平台配置。LLM 调用工具后会收到端侧的返回值基于真实数据回复用户。返回值中的可观测标记_source/_timestamp用于确认端侧真实执行细节我在上一篇端插件笔记中写过这里不重复展开。输入参数 vs 返回值两个方向方向1平台 → 端侧输入参数 平台工具配置的parameters → LLM填充值 → 框架注入端侧public属性 方向2端侧 → LLM返回值 onExecute()返回IntentResult → 系统传给LLM → LLM基于返回值回复用户平台工具配置只管输入参数方向1返回值方向2是端侧代码自己决定的。三、上下文内 vs 上下文外的判断问题场景LLM 智能体在调用端插件时需要判断数据是新建还是更新已有。但 LLM 的判断能力受限于对话上下文场景1上下文内同一轮对话 ───────────────────────────── 用户我有C1驾照 LLM上下文中有之前存的条件列表 → 判断有C1驾照不存在 → 调用工具(actionupsert) 场景2上下文外新一轮对话/重启后 ───────────────────────────────── 用户我有C1驾照 LLM上下文中没有历史数据 → 不知道已存在 → 可能重复创建解决方案搜索先行提供 Search 类工具让 LLM 在不确定时先查本地数据再决定操作提示词引导不确定数据是否已存在时先搜索再操作upsert 语义存储操作本身做成幂等的按 title 去重更新即使 LLM 不搜索也不会产生重复长期记忆辅助未来方向小艺 LLM 模式的长期记忆能力可以存储总结性信息辅助跨上下文判断长期记忆存储用户已有 X 条条件这类摘要信息新对话开始时 LLM 先查看长期记忆了解用户大致情况再调用 Search 工具精确查询避免重复操作结构化数据仍走端插件存本地长期记忆只做总结性参考不做主存储判断策略总结场景判断依据操作上下文内LLM记得已有LLM上下文记忆直接判断新建/更新上下文外不确定先调Search查本地根据搜索结果决定长期记忆有摘要参考长期记忆再调Search精确确认upsert操作不确定时直接upsert幂等操作按title去重学习小结这次补充了端插件开发中两个之前没写透的点。一是小艺结果卡片绑定有硬规则——卡片参数必须是 object 且子项名与返回值 result 字段完全一致才能自动匹配string 类型永远绑不上 object 的 resultcode 作为顶级字段可直接绑定 number。二是返回值设计上平台只管输入、端侧决定输出IntentResult 的 result 由泛型自定义。最核心的收获是跨上下文的新建 vs 更新判断上下文外 LLM 没有历史数据容易重复创建解决要靠搜索先行Search 工具 提示词引导 upsert 幂等语义长期记忆存摘要做跨上下文的辅助参考但结构化数据的主存储仍在端插件本地。懿路向前 · AI辅助整理2026-08-05 【HarmonyOS学习笔记】2026-08-05 | 端插件卡片绑定与跨上下文判断
【HarmonyOS学习笔记】2026-08-05 | 端插件卡片绑定与跨上下文判断date: 2026-08-05tags: [HarmonyOS, 端插件, InsightIntentEntry, 小艺开放平台, 卡片绑定, 长期记忆, LLM]type: 实战笔记一、小艺结果卡片绑定规则卡片参数类型与绑定关系小艺结果卡片绑定端插件返回值时卡片参数类型决定了能绑定什么卡片参数类型能否绑定端插件result说明string❌类型不匹配result是object不是stringnumber❌同上object✅需要声明子项子项名与result字段名一致正确绑定方式卡片参数 result 定义为object 类型在 object 内声明子项子项名与端插件返回值 result 中的字段名完全一致子项按名称自动匹配端插件 result 的字段卡片参数定义 result (object) ├─ actionId (string) ├─ _source (string) └─ _timestamp (string) 端插件返回 { code: 0, result: { actionId: act_11, _source: MyEndPlugin, _timestamp: ... } } 绑定结果 卡片result(object) ← 端插件result(object) ✅ 自动匹配 卡片result.actionId ← 端插件result.actionId ✅ 子项自动对应关键规则每个端插件的返回值 result 字段必须在卡片参数 object 子项中完整声明否则绑不到code 是顶级字段与 result 同级卡片参数可直接定义为 number 类型绑定如果卡片 result 定义成 string 类型永远绑不上端插件的 object 类型 result二、端插件返回值设计返回值结构InsightIntentEntryExecutorT的返回类型是insightIntent.IntentResultT结构固定{code:number,// 0成功非0失败result:T// 泛型由开发者自定义}返回值是端侧代码决定的不需要在平台配置。LLM 调用工具后会收到端侧的返回值基于真实数据回复用户。返回值中的可观测标记_source/_timestamp用于确认端侧真实执行细节我在上一篇端插件笔记中写过这里不重复展开。输入参数 vs 返回值两个方向方向1平台 → 端侧输入参数 平台工具配置的parameters → LLM填充值 → 框架注入端侧public属性 方向2端侧 → LLM返回值 onExecute()返回IntentResult → 系统传给LLM → LLM基于返回值回复用户平台工具配置只管输入参数方向1返回值方向2是端侧代码自己决定的。三、上下文内 vs 上下文外的判断问题场景LLM 智能体在调用端插件时需要判断数据是新建还是更新已有。但 LLM 的判断能力受限于对话上下文场景1上下文内同一轮对话 ───────────────────────────── 用户我有C1驾照 LLM上下文中有之前存的条件列表 → 判断有C1驾照不存在 → 调用工具(actionupsert) 场景2上下文外新一轮对话/重启后 ───────────────────────────────── 用户我有C1驾照 LLM上下文中没有历史数据 → 不知道已存在 → 可能重复创建解决方案搜索先行提供 Search 类工具让 LLM 在不确定时先查本地数据再决定操作提示词引导不确定数据是否已存在时先搜索再操作upsert 语义存储操作本身做成幂等的按 title 去重更新即使 LLM 不搜索也不会产生重复长期记忆辅助未来方向小艺 LLM 模式的长期记忆能力可以存储总结性信息辅助跨上下文判断长期记忆存储用户已有 X 条条件这类摘要信息新对话开始时 LLM 先查看长期记忆了解用户大致情况再调用 Search 工具精确查询避免重复操作结构化数据仍走端插件存本地长期记忆只做总结性参考不做主存储判断策略总结场景判断依据操作上下文内LLM记得已有LLM上下文记忆直接判断新建/更新上下文外不确定先调Search查本地根据搜索结果决定长期记忆有摘要参考长期记忆再调Search精确确认upsert操作不确定时直接upsert幂等操作按title去重学习小结这次补充了端插件开发中两个之前没写透的点。一是小艺结果卡片绑定有硬规则——卡片参数必须是 object 且子项名与返回值 result 字段完全一致才能自动匹配string 类型永远绑不上 object 的 resultcode 作为顶级字段可直接绑定 number。二是返回值设计上平台只管输入、端侧决定输出IntentResult 的 result 由泛型自定义。最核心的收获是跨上下文的新建 vs 更新判断上下文外 LLM 没有历史数据容易重复创建解决要靠搜索先行Search 工具 提示词引导 upsert 幂等语义长期记忆存摘要做跨上下文的辅助参考但结构化数据的主存储仍在端插件本地。懿路向前 · AI辅助整理2026-08-05