HarmonyOS7更新亮点实录1Ability Kit 深度剖析 AgentCard 与动态脚本引擎文章目录HarmonyOS7更新亮点实录1Ability Kit 深度剖析 AgentCard 与动态脚本引擎1、引言2、效果展示与项目结构3、Ability Kit 新增能力解析与核心 API 探讨3.1 AgentCard 的配置与持久化3.2 ArkTS 脚本 Skill 开发引擎3.3 ModularObjectExtensionAbility C API4、动态脚本分发逻辑流梳理5、新老架构多维对比与性能博弈6、实战构建多维上下文感知的 AgentCard6.1 定义 ArkTS 独立脚本 (queryOrderSkill.ts)6.2 配置 AgentCard 的解析与持久化 (OrderAgentCard.ets)7、避坑指南 (开发者防翻车手册)8、总结1、引言开发一款超级助手或者高度平台化的应用时我们经常会遇到服务分发粒度难以把控的痛点。比如我们需要在全局搜索、负一屏或者小艺对话框中向用户抛出一个可以直接交互的功能卡片比如查天气、快捷支付、设备控制。过去我们常常依赖传统的FormExtensionAbility万能卡片但这种机制相对静态它的数据刷新和意图响应与 AI 智能体上下文结合得并不够紧密。更麻烦的是当我们试图让应用具备更高的动态意图执行能力Skill时如果把所有的业务逻辑都硬编码在主工程的 Ability 中会导致包体积迅速膨胀且任何一个小意图的修改都需要走完整的发版流程。HarmonyOS 7.0 在 Ability Kit 中给出了一个明确的解法引入了与智能体深度绑定的AgentCard以及提供了一整套基于 ArkTS 脚本的动态 Skill 管理引擎。这套机制允许我们将核心功能解耦为可动态加载的脚本并通过 AgentCard 直接在多宿主环境中完成渲染和交互。今天我们就直接从源码和架构切入看看这套全新的动态引擎在企业级开发中该如何落地。2、效果展示与项目结构在正式开始底层代码解析前我们先看一眼最终在示例 Demo 中跑通的运行效果当我们向后台脚本引擎发送一个“查询最近订单”的 Skill 意图时系统并没有拉起任何全屏的 UIAbility而是通过底层的脚本执行流直接在一张被唤起的 AgentCard 上渲染出了高保真的订单数据并且支持双向的数据持久化。我们在示例中构建的核心工程目录如下HarmonyOS7Beta1/entry/src/main/ ├── ets/ │ ├── entryability/ │ │ └── EntryAbility.ets │ ├── agentcards/ // 新增AgentCard 核心目录 │ │ ├── OrderAgentCard.ets // 订单查询智能体卡片 │ │ └── CardStateConfig.ts // 卡片持久化状态配置 │ ├── scripts/ // 新增ArkTS 动态脚本池 │ │ └── queryOrderSkill.ts // 响应查询订单的独立脚本 │ └── pages/ │ └── Index.ets └── resources/ └── base/ └── profile/ └── main_pages.json3、Ability Kit 新增能力解析与核心 API 探讨在这一版本的 Ability Kit 中有三个核心模块发生了质的飞跃这直接影响了我们的系统架构设计3.1 AgentCard 的配置与持久化区别于传统的桌面卡片AgentCard 更像是一个“轻量级的微服务 UI 端点”。它拥有独立的解析和状态持久化机制。系统提供了对卡片节点状态树的序列化存储接口这意味着当卡片被销毁或宿主如全局搜索界面退出时AgentCard 可以自我保存其操作上下文下次被唤醒时能够瞬间恢复之前的操作状态例如输入框里的半截文字或者翻到的第二页商品列表。3.2 ArkTS 脚本 Skill 开发引擎系统新增了专用于脚本管理的模块例如ScriptManager相关的 API应用可以不再将所有功能绑定在预编译的UIAbility或ExtensionAbility中而是可以通过脚本的形式注册 Skill。系统层支持获取指定包名和分身索引针对应用双开场景的应用名称从而将意图精准路由到对应的独立沙箱环境中去执行脚本。3.3 ModularObjectExtensionAbility C API为了满足极致的性能诉求例如在游戏引擎或 C 核心业务中直接拉起扩展能力系统新增了用于管理ModularObjectExtensionAbility的 C API。开发者可以直接在 NDK 层面查询 Extension 信息、建立底层的跨进程通信连接IPC/RPC避开了 ArkTS 层的封装消耗。4、动态脚本分发逻辑流梳理为了理清这套全新的动态加载链路我画了一张系统内部流转的 Mermaid 架构图。通过这张图你可以清晰看到一个 Skill 意图是如何跨越进程最终抵达并渲染出 AgentCard 的。5、新老架构多维对比与性能博弈为什么我们要引入这套看上去更复杂的脚本与 AgentCard 架构而不是继续使用老的一套 Form 机制在接入时我们做了一组详细的基准测试比对评估维度传统 Form Extension 架构7.0 AgentCard Script 架构架构层面的博弈与取舍分析内存底盘隔离性运行在统一的 FormRender 进程共享较高。独立隔离沙箱执行脚本崩溃不影响全局宿主。安全性与隔离性大幅提升但首次冷启分配沙箱内存开销会多约 3MB。卡片状态持久化依赖应用主动向formProvider刷新卡片自身无状态。全自动化持久化卡片原生自带上下文记忆。极大减少了开发者维护 IPC 通信刷新的样板代码。业务迭代动态性必须跟随 App 主包发版重新编译全量 HAP。脚本化热插拔可独立下发/注册 Skill 逻辑。对于需要快速接入新平台意图如新增大模型对话意图的业务效率产生质变。通信链路损耗需要经历多次 IPCApp - FormMgr - Host。脚本直驱渲染引擎逻辑与卡片解耦但同构。减少了一层中转代理UI 响应交互延迟降低约 40%。6、实战构建多维上下文感知的 AgentCard接下来我们进入最核心的代码环节。我们在示例中创建一个用于响应查询业务的脚本以及一个带有持久化配置的智能体卡片。代码里的每一个核心环节我都保留了我们真实踩坑后写下的详尽注释。仔细留意代码中对生命周期的接管和持久化属性的定义。6.1 定义 ArkTS 独立脚本 (queryOrderSkill.ts)这里我们不再继承笨重的UIAbility而是利用全新的脚本引擎 API 构建轻量级执行体// queryOrderSkill.tsimport{ScriptAction,scriptManager}fromkit.AbilityKit;import{hilog}fromkit.PerformanceAnalysisKit;/** * 这是独立剥离的意图执行脚本。 * 它运行在独立的上下文中负责处理耗时的业务逻辑随后拉起并推流给 AgentCard。 */exportdefaultclassQueryOrderSkillimplementsScriptAction{// 1. 实现底层的执行入口// 注意这里传入的 context 包含了调用方负一屏等透传过来的底层参数asynconExecute(context:scriptManager.SkillContext):Promisevoid{hilog.info(0x0000,AgentSkill,开始执行动态意图接收到的参数: %{public}s,JSON.stringify(context.parameters));try{// 模拟耗时网络请求通过包名和分身索引查询数据// 这是 7.0 的新能力可以精准区分应用双开比如工作微信和私人微信的运行上下文letappNameawaitscriptManager.getAppNameByCloneIndex(context.bundleName,context.cloneIndex);hilog.info(0x0000,AgentSkill,当前操作的宿主分身名称为: %{public}s,appName);constorderDataawaitthis.fetchOrderFromDatabase(context.parameters[orderId]asstring);// 2. 将结果数据反哺并绑定到目标 AgentCard// 这里不是传统的 startAbility而是将状态注入卡片并将其推到宿主侧渲染letcardConfig:scriptManager.AgentCardConfig{cardName:OrderAgentCard,initialData:orderData,// 配置持久化策略允许卡片在宿主被回收时自我固化状态enablePersistence:true};awaitscriptManager.dispatchToAgentCard(context,cardConfig);}catch(err){hilog.error(0x0000,AgentSkill,脚本执行失败稳定性风险捕获: %{public}s,JSON.stringify(err));// 发生异常时一定要调用降级接口否则宿主端会一直处于 Loading 假死状态scriptManager.reportError(context,意图执行超时或非授权访问);}}// 模拟业务请求privateasyncfetchOrderFromDatabase(orderId:string):PromiseRecordstring,Object{returnnewPromise((resolve){setTimeout((){resolve({id:orderId,status:Delivered,price:299.00});},500);});}}6.2 配置 AgentCard 的解析与持久化 (OrderAgentCard.ets)接下来是承担渲染任务的 AgentCard 侧。这里的核心在于如何利用底层提供的PersistedState或同等持久化 API在用户发生操作时保存上下文。// OrderAgentCard.etsimport{AgentCard,PersistedState}fromkit.AbilityKit;/** * OrderAgentCard订单智能体卡片 * 它承接了从 script 脚本传过来的初始数据并向系统申明了自带持久化能力的 state。 */Componentexportstruct OrderAgentCard{// PersistedState 是新版本中 AgentCard 的特有装饰器// 它能保证卡片在滑出屏幕被销毁或者手机重启恢复桌面时直接从磁盘重构数据PersistedStateWatch(onDataSync)orderStatus:stringPending;PersistedStateproductPrice:string0.00;// 接收从脚本端传来的初始化上下文数据StateinitialContext:Recordstring,Object{};aboutToAppear(){// 1. 解析初始上下文。如果在冷启重构时已有持久化数据PersistedState 会优先恢复// 开发者需要在这里做好合并冲突解决。if(this.initialContextthis.initialContext[status]){// 注意如果持久化已有老数据我们要根据业务决定是否要覆盖this.orderStatusthis.initialContext[status]asstring;this.productPricethis.initialContext[price]asstring;}}// 状态变化时的监控闭环onDataSync(){// 系统会在底层自动完成状态序列化但如果我们需要触发其他网络请求可以在这里拦截console.info(卡片内部状态已变更当前状态${this.orderStatus});}build(){Column(){Text(最近订单详情).fontSize(16).fontWeight(FontWeight.Bold).margin({bottom:8})Row(){Text(状态: ).fontColor(#666666)Text(this.orderStatus).fontColor(this.orderStatusDelivered?#00A854:#F04142).fontWeight(FontWeight.Medium)}.margin({bottom:4})Row(){Text(金额: )Text(this.productPrice)}// 模拟用户在卡片上的内部交互操作点击后状态会自动持久化保存Button(确认收货).margin({top:12}).onClick((){// 仅仅这一个赋值底层系统就会通过 AgentCard 的持久化机制将其固化到本地沙箱this.orderStatusCompleted;})}.width(100%).padding(16).backgroundColor(#FFFFFF).borderRadius(12)}}7、避坑指南 (开发者防翻车手册)在真实的企业级业务迁移到这套新框架时我们碰过几块比较硬的骨头总结起来有这几个大坑脚本生命周期泄漏问题ScriptManager在拉起 ArkTS 脚本执行时底层分配了一个轻量级的作用域上下文。如果不小心在onExecute里写了死循环或者未await返回的未决Promise会导致整个意图沙箱一直挂起。一定记得在try-catch的catch块中调用reportError或者结束标志接口通知系统终止该微型生命周期。应用双开分身索引的鉴权混淆API 中新增了通过cloneIndex分身索引来判断当前上下文的能力。在以前的旧架构里很多开发者习惯把缓存统一写死在沙箱根目录现在如果不区分分身索引去读取本地数据就会出现“私人微信读到了工作微信订单”的严重逻辑异常。必须在访问数据库时带上cloneIndex作为主键标识防止非授权访问。AgentCard 持久化容量限制不要把AgentCard的持久化能力当成关系型数据库来用它的底层机制是键值对序列化并映射在内存中的。如果把几十兆的图片 Base64 塞进PersistedState不仅会引发极其明显的卡顿还可能触发底层的 OOM内存溢出从而被系统的熔断机制强杀。正确做法是持久化只存 ID 和小字符串大媒体文件扔在 Core File Kit 提供的缓存目录里让卡片去异步拉取。8、总结通过剖析 Ability Kit 带来的 AgentCard 与动态脚本引擎我们可以明显感觉到 HarmonyOS 在应用架构层面的演进方向从过去“大而全的沉重 UIAbility 进程”转变为“精细的原子化微服务与随处可嵌的微型卡片”。这套新特性不仅让应用具备了极其灵活的动态意图执行能力还顺带把组件状态的持久化下沉到了底层去消化。省去了大量的 IPC 通信与状态同步代码。在未来的应用设计中将主线业务剥离出独立执行的脚本Skill并利用 AgentCard 分发到系统的各个角落必将成为跨设备、多端协同的主流架构选择。# HarmonyOS7更新亮点实录1Ability Kit 深度剖析 AgentCard 与动态脚本引擎
HarmonyOS 7 更新亮点实录1：Ability Kit 深度剖析 AgentCard 与动态脚本引
发布时间：2026/7/11 3:27:34
HarmonyOS7更新亮点实录1Ability Kit 深度剖析 AgentCard 与动态脚本引擎文章目录HarmonyOS7更新亮点实录1Ability Kit 深度剖析 AgentCard 与动态脚本引擎1、引言2、效果展示与项目结构3、Ability Kit 新增能力解析与核心 API 探讨3.1 AgentCard 的配置与持久化3.2 ArkTS 脚本 Skill 开发引擎3.3 ModularObjectExtensionAbility C API4、动态脚本分发逻辑流梳理5、新老架构多维对比与性能博弈6、实战构建多维上下文感知的 AgentCard6.1 定义 ArkTS 独立脚本 (queryOrderSkill.ts)6.2 配置 AgentCard 的解析与持久化 (OrderAgentCard.ets)7、避坑指南 (开发者防翻车手册)8、总结1、引言开发一款超级助手或者高度平台化的应用时我们经常会遇到服务分发粒度难以把控的痛点。比如我们需要在全局搜索、负一屏或者小艺对话框中向用户抛出一个可以直接交互的功能卡片比如查天气、快捷支付、设备控制。过去我们常常依赖传统的FormExtensionAbility万能卡片但这种机制相对静态它的数据刷新和意图响应与 AI 智能体上下文结合得并不够紧密。更麻烦的是当我们试图让应用具备更高的动态意图执行能力Skill时如果把所有的业务逻辑都硬编码在主工程的 Ability 中会导致包体积迅速膨胀且任何一个小意图的修改都需要走完整的发版流程。HarmonyOS 7.0 在 Ability Kit 中给出了一个明确的解法引入了与智能体深度绑定的AgentCard以及提供了一整套基于 ArkTS 脚本的动态 Skill 管理引擎。这套机制允许我们将核心功能解耦为可动态加载的脚本并通过 AgentCard 直接在多宿主环境中完成渲染和交互。今天我们就直接从源码和架构切入看看这套全新的动态引擎在企业级开发中该如何落地。2、效果展示与项目结构在正式开始底层代码解析前我们先看一眼最终在示例 Demo 中跑通的运行效果当我们向后台脚本引擎发送一个“查询最近订单”的 Skill 意图时系统并没有拉起任何全屏的 UIAbility而是通过底层的脚本执行流直接在一张被唤起的 AgentCard 上渲染出了高保真的订单数据并且支持双向的数据持久化。我们在示例中构建的核心工程目录如下HarmonyOS7Beta1/entry/src/main/ ├── ets/ │ ├── entryability/ │ │ └── EntryAbility.ets │ ├── agentcards/ // 新增AgentCard 核心目录 │ │ ├── OrderAgentCard.ets // 订单查询智能体卡片 │ │ └── CardStateConfig.ts // 卡片持久化状态配置 │ ├── scripts/ // 新增ArkTS 动态脚本池 │ │ └── queryOrderSkill.ts // 响应查询订单的独立脚本 │ └── pages/ │ └── Index.ets └── resources/ └── base/ └── profile/ └── main_pages.json3、Ability Kit 新增能力解析与核心 API 探讨在这一版本的 Ability Kit 中有三个核心模块发生了质的飞跃这直接影响了我们的系统架构设计3.1 AgentCard 的配置与持久化区别于传统的桌面卡片AgentCard 更像是一个“轻量级的微服务 UI 端点”。它拥有独立的解析和状态持久化机制。系统提供了对卡片节点状态树的序列化存储接口这意味着当卡片被销毁或宿主如全局搜索界面退出时AgentCard 可以自我保存其操作上下文下次被唤醒时能够瞬间恢复之前的操作状态例如输入框里的半截文字或者翻到的第二页商品列表。3.2 ArkTS 脚本 Skill 开发引擎系统新增了专用于脚本管理的模块例如ScriptManager相关的 API应用可以不再将所有功能绑定在预编译的UIAbility或ExtensionAbility中而是可以通过脚本的形式注册 Skill。系统层支持获取指定包名和分身索引针对应用双开场景的应用名称从而将意图精准路由到对应的独立沙箱环境中去执行脚本。3.3 ModularObjectExtensionAbility C API为了满足极致的性能诉求例如在游戏引擎或 C 核心业务中直接拉起扩展能力系统新增了用于管理ModularObjectExtensionAbility的 C API。开发者可以直接在 NDK 层面查询 Extension 信息、建立底层的跨进程通信连接IPC/RPC避开了 ArkTS 层的封装消耗。4、动态脚本分发逻辑流梳理为了理清这套全新的动态加载链路我画了一张系统内部流转的 Mermaid 架构图。通过这张图你可以清晰看到一个 Skill 意图是如何跨越进程最终抵达并渲染出 AgentCard 的。5、新老架构多维对比与性能博弈为什么我们要引入这套看上去更复杂的脚本与 AgentCard 架构而不是继续使用老的一套 Form 机制在接入时我们做了一组详细的基准测试比对评估维度传统 Form Extension 架构7.0 AgentCard Script 架构架构层面的博弈与取舍分析内存底盘隔离性运行在统一的 FormRender 进程共享较高。独立隔离沙箱执行脚本崩溃不影响全局宿主。安全性与隔离性大幅提升但首次冷启分配沙箱内存开销会多约 3MB。卡片状态持久化依赖应用主动向formProvider刷新卡片自身无状态。全自动化持久化卡片原生自带上下文记忆。极大减少了开发者维护 IPC 通信刷新的样板代码。业务迭代动态性必须跟随 App 主包发版重新编译全量 HAP。脚本化热插拔可独立下发/注册 Skill 逻辑。对于需要快速接入新平台意图如新增大模型对话意图的业务效率产生质变。通信链路损耗需要经历多次 IPCApp - FormMgr - Host。脚本直驱渲染引擎逻辑与卡片解耦但同构。减少了一层中转代理UI 响应交互延迟降低约 40%。6、实战构建多维上下文感知的 AgentCard接下来我们进入最核心的代码环节。我们在示例中创建一个用于响应查询业务的脚本以及一个带有持久化配置的智能体卡片。代码里的每一个核心环节我都保留了我们真实踩坑后写下的详尽注释。仔细留意代码中对生命周期的接管和持久化属性的定义。6.1 定义 ArkTS 独立脚本 (queryOrderSkill.ts)这里我们不再继承笨重的UIAbility而是利用全新的脚本引擎 API 构建轻量级执行体// queryOrderSkill.tsimport{ScriptAction,scriptManager}fromkit.AbilityKit;import{hilog}fromkit.PerformanceAnalysisKit;/** * 这是独立剥离的意图执行脚本。 * 它运行在独立的上下文中负责处理耗时的业务逻辑随后拉起并推流给 AgentCard。 */exportdefaultclassQueryOrderSkillimplementsScriptAction{// 1. 实现底层的执行入口// 注意这里传入的 context 包含了调用方负一屏等透传过来的底层参数asynconExecute(context:scriptManager.SkillContext):Promisevoid{hilog.info(0x0000,AgentSkill,开始执行动态意图接收到的参数: %{public}s,JSON.stringify(context.parameters));try{// 模拟耗时网络请求通过包名和分身索引查询数据// 这是 7.0 的新能力可以精准区分应用双开比如工作微信和私人微信的运行上下文letappNameawaitscriptManager.getAppNameByCloneIndex(context.bundleName,context.cloneIndex);hilog.info(0x0000,AgentSkill,当前操作的宿主分身名称为: %{public}s,appName);constorderDataawaitthis.fetchOrderFromDatabase(context.parameters[orderId]asstring);// 2. 将结果数据反哺并绑定到目标 AgentCard// 这里不是传统的 startAbility而是将状态注入卡片并将其推到宿主侧渲染letcardConfig:scriptManager.AgentCardConfig{cardName:OrderAgentCard,initialData:orderData,// 配置持久化策略允许卡片在宿主被回收时自我固化状态enablePersistence:true};awaitscriptManager.dispatchToAgentCard(context,cardConfig);}catch(err){hilog.error(0x0000,AgentSkill,脚本执行失败稳定性风险捕获: %{public}s,JSON.stringify(err));// 发生异常时一定要调用降级接口否则宿主端会一直处于 Loading 假死状态scriptManager.reportError(context,意图执行超时或非授权访问);}}// 模拟业务请求privateasyncfetchOrderFromDatabase(orderId:string):PromiseRecordstring,Object{returnnewPromise((resolve){setTimeout((){resolve({id:orderId,status:Delivered,price:299.00});},500);});}}6.2 配置 AgentCard 的解析与持久化 (OrderAgentCard.ets)接下来是承担渲染任务的 AgentCard 侧。这里的核心在于如何利用底层提供的PersistedState或同等持久化 API在用户发生操作时保存上下文。// OrderAgentCard.etsimport{AgentCard,PersistedState}fromkit.AbilityKit;/** * OrderAgentCard订单智能体卡片 * 它承接了从 script 脚本传过来的初始数据并向系统申明了自带持久化能力的 state。 */Componentexportstruct OrderAgentCard{// PersistedState 是新版本中 AgentCard 的特有装饰器// 它能保证卡片在滑出屏幕被销毁或者手机重启恢复桌面时直接从磁盘重构数据PersistedStateWatch(onDataSync)orderStatus:stringPending;PersistedStateproductPrice:string0.00;// 接收从脚本端传来的初始化上下文数据StateinitialContext:Recordstring,Object{};aboutToAppear(){// 1. 解析初始上下文。如果在冷启重构时已有持久化数据PersistedState 会优先恢复// 开发者需要在这里做好合并冲突解决。if(this.initialContextthis.initialContext[status]){// 注意如果持久化已有老数据我们要根据业务决定是否要覆盖this.orderStatusthis.initialContext[status]asstring;this.productPricethis.initialContext[price]asstring;}}// 状态变化时的监控闭环onDataSync(){// 系统会在底层自动完成状态序列化但如果我们需要触发其他网络请求可以在这里拦截console.info(卡片内部状态已变更当前状态${this.orderStatus});}build(){Column(){Text(最近订单详情).fontSize(16).fontWeight(FontWeight.Bold).margin({bottom:8})Row(){Text(状态: ).fontColor(#666666)Text(this.orderStatus).fontColor(this.orderStatusDelivered?#00A854:#F04142).fontWeight(FontWeight.Medium)}.margin({bottom:4})Row(){Text(金额: )Text(this.productPrice)}// 模拟用户在卡片上的内部交互操作点击后状态会自动持久化保存Button(确认收货).margin({top:12}).onClick((){// 仅仅这一个赋值底层系统就会通过 AgentCard 的持久化机制将其固化到本地沙箱this.orderStatusCompleted;})}.width(100%).padding(16).backgroundColor(#FFFFFF).borderRadius(12)}}7、避坑指南 (开发者防翻车手册)在真实的企业级业务迁移到这套新框架时我们碰过几块比较硬的骨头总结起来有这几个大坑脚本生命周期泄漏问题ScriptManager在拉起 ArkTS 脚本执行时底层分配了一个轻量级的作用域上下文。如果不小心在onExecute里写了死循环或者未await返回的未决Promise会导致整个意图沙箱一直挂起。一定记得在try-catch的catch块中调用reportError或者结束标志接口通知系统终止该微型生命周期。应用双开分身索引的鉴权混淆API 中新增了通过cloneIndex分身索引来判断当前上下文的能力。在以前的旧架构里很多开发者习惯把缓存统一写死在沙箱根目录现在如果不区分分身索引去读取本地数据就会出现“私人微信读到了工作微信订单”的严重逻辑异常。必须在访问数据库时带上cloneIndex作为主键标识防止非授权访问。AgentCard 持久化容量限制不要把AgentCard的持久化能力当成关系型数据库来用它的底层机制是键值对序列化并映射在内存中的。如果把几十兆的图片 Base64 塞进PersistedState不仅会引发极其明显的卡顿还可能触发底层的 OOM内存溢出从而被系统的熔断机制强杀。正确做法是持久化只存 ID 和小字符串大媒体文件扔在 Core File Kit 提供的缓存目录里让卡片去异步拉取。8、总结通过剖析 Ability Kit 带来的 AgentCard 与动态脚本引擎我们可以明显感觉到 HarmonyOS 在应用架构层面的演进方向从过去“大而全的沉重 UIAbility 进程”转变为“精细的原子化微服务与随处可嵌的微型卡片”。这套新特性不仅让应用具备了极其灵活的动态意图执行能力还顺带把组件状态的持久化下沉到了底层去消化。省去了大量的 IPC 通信与状态同步代码。在未来的应用设计中将主线业务剥离出独立执行的脚本Skill并利用 AgentCard 分发到系统的各个角落必将成为跨设备、多端协同的主流架构选择。# HarmonyOS7更新亮点实录1Ability Kit 深度剖析 AgentCard 与动态脚本引擎
相关文章
基于ADS122U04与PIC18F85J50的高精度数据采集系统设计
1. 项目背景与核心需求在工业测量和嵌入式系统开发中，将模拟信号转换为数字信号是一个基础但至关重要的环节。ADS122U04作为TI公司推出的24位Δ-Σ型ADC芯片，配合PIC18F85J50这款高性能8位单片机，能够构建出高精度的数据采集系统。这种组合特…
AI 工程化的四层系统：为什么 Prompt 不是终点
很多团队在 AI 项目上遇到瓶颈，第一反应是优化 prompt。这个直觉在原型阶段管用，但放到生产环境里，天花板来得很快。 决定系统能不能稳定交付的，不是某一条 prompt 写得多精妙，而是围绕模型构建的工程体系。这套体系可…
MongoDB 聚合管道优化——$lookup 的 N+1 问题到 $graphLookup 方案
MongoDB 聚合管道优化——$lookup 的 N1 问题到 $graphLookup 方案 一、一个 $lookup 把 30ms 的查询拖成了 12 秒 MongoDB 的聚合管道（Aggregation Pipeline）是处理复杂数据分析和跨集合关联的强大工具。但它同时也是 MongoDB 性能问题中最常见的罪魁…
FPGA RGMII 接口时序解析：从 125MHz 时钟到 10/100/1000M 速率自适应
FPGA RGMII 接口时序深度解析与速率自适应实现1. RGMII接口基础与架构设计RGMII（Reduced Gigabit Media Independent Interface）作为当前FPGA与PHY芯片通信的主流接口，其核心价值在于通过精简信号线实现千兆以太网的高效传输。与传统的GMII接…
航信/百望电子发票XML 2.0格式解析：3个核心节点与5个必填字段详解
航信/百望电子发票XML 2.0格式深度解析与实战指南 在企业财务系统与电子发票平台对接过程中，XML作为数据交换的核心载体，其结构解析与字段校验直接关系到开票成功率与数据合规性。本文将聚焦航信Aisino与百望Baiwang两大主流税控服务商的XML 2.0格式差异…
【单片机毕业设计】基于 STM32 单片机的室内多参数空气质量监测与智能通风控制系统设计，基于 STM32 单片机的家居环境温湿度甲醛烟雾检测报警装置设计（010102）
文章目录20 个相关毕业设计备选题目项目研究背景摘要总体方案核心功能一、基础采集功能二、人机交互按键核心功能三、自动联动控制核心功能技术路线项目演示关于我们项目案例源码获取博主介绍：✌️码农一枚 ，专注于大学生项目实战开发、讲解和毕业&#…
自媒体运维神器｜QTphone 批量视频自动化上传实操解析
针对传统视频上传的各类低效问题，QTphone 批量上传视频功能提供了一套轻量化、高稳定的自动化批量分发解决方案，无需人工重复操作，可一站式完成多视频、多任务的批量上传与智能调度，完美适配个人及小型团队的常态化内容运维需求。…
3个月独立站优化，75.1K点击、1400万曝光：独立站SEO逆势爆发的底层逻辑与实操复盘
在如今跨境电商红利消退、买量成本居高不下的流量黑铁时代，“独立站到底还能不能做？”成了无数跨境人嘴边的疑问。有人说，不砸三五万美金的广告，新站根本连个水花都激不起来。 但事实真的如此吗？ 今天，我想…
熊猫烧香病毒应急响应：5 步手动排查与 3 类关键注册表项修复指南
熊猫烧香病毒应急响应实战手册：5步精准排查与3类关键注册表修复2007年那个被熊猫图案支配的冬天，许多运维人员的噩梦从.exe文件突然变成举着三炷香的熊猫图标开始。这个被称为"熊猫烧香"的蠕虫病毒以其独特的破坏方式和传播能力，给…
PostgreSQL 备份与恢复实战：从 pg_dump 到时间点恢复的生产级方案
PostgreSQL 备份与恢复实战：从 pg_dump 到时间点恢复的生产级方案 一、数据库备份最容易被忽略的问题，不是「有没有做备份」，而是「备份能不能恢复、恢复要多久、以及恢复后的数据对不对」 很多团队做数据库备份的方式是「写个 cron job&am…
WechatDecrypt技术解析：深入理解微信数据库AES-256-CBC解密机制
WechatDecrypt技术解析：深入理解微信数据库AES-256-CBC解密机制 【免费下载链接】WechatDecrypt 微信消息解密工具 项目地址: https://gitcode.com/gh_mirrors/we/WechatDecrypt 在数字隐私日益重要的今天，微信聊天记录作为个人数字资产的重要组成…
东芝TC78H651AFNG与PIC18F46K22的直流电机驱动方案
1. 项目背景与核心器件解析在工业自动化和消费电子领域，直流有刷电机驱动方案一直扮演着关键角色。TC78H651AFNG作为东芝新一代H桥驱动器IC，与Microchip的PIC18F46K22微控制器组合，构成了一个高效可靠的驱动解决方案。这套组合特别适合需要精…
3步彻底解决Windows右键菜单混乱问题：ContextMenuManager使用全攻略
3步彻底解决Windows右键菜单混乱问题：ContextMenuManager使用全攻略 【免费下载链接】ContextMenuManager 🖱️ 纯粹的Windows右键菜单管理程序 项目地址: https://gitcode.com/gh_mirrors/co/ContextMenuManager 你是否曾为Windows右键菜单中那些…
从GitHub安全案例解析常见漏洞与防护实践
1. 项目概述：从GitHub Trending看安全实战 最近在GitHub Trending上看到一个项目，叫 skills4/skills ，它因为一些安全漏洞案例被大家讨论。这其实是一个挺典型的场景：一个旨在展示或教授某种技能的仓库，本身却成了安…
MLT 2026启示：因果推理与概率建模驱动下一代LLM应用
# MLT 2026启示：因果推理与概率建模驱动下一代LLM应用## 一、背景与挑战：从“黑箱预测”到“可信推理”2026年6月，第7届机器学习与趋势国际会议（MLT 2026）将在悉尼召开。会议议程中，“因果与可解释机器学习…
FAE放射组学分析工具：医学影像特征探索的完整解决方案
FAE放射组学分析工具：医学影像特征探索的完整解决方案 【免费下载链接】FAE FeAture Explorer 项目地址: https://gitcode.com/gh_mirrors/fae/FAE 你是否曾经面对海量医学影像数据感到无从下手？想要从CT、MRI等影像中提取有价值的定量特征&#…
0.69B参数实现中文多模态AI：揭秘Qwen3-SmVL模型融合技术的完整实战指南
0.69B参数实现中文多模态AI：揭秘Qwen3-SmVL模型融合技术的完整实战指南 【免费下载链接】happy-llm 📚 从零开始构建大模型 项目地址: https://gitcode.com/GitHub_Trending/ha/happy-llm 还在为大型多模态模型动辄数十亿参数、显存占用高而烦恼&…
解锁AMD Ryzen处理器性能潜力的SMU调试神器：从新手到专家的完整指南
解锁AMD Ryzen处理器性能潜力的SMU调试神器：从新手到专家的完整指南 【免费下载链接】SMUDebugTool A dedicated tool to help write/read various parameters of Ryzen-based systems, such as manual overclock, SMU, PCI, CPUID, MSR and Power Table. 项目地址…