鸿蒙应用 Skill 开发实战：从能力拆分到调测发布

把应用接入系统 Agent 之后，更实际的问题是如何让应用能力被系统发现、理解并复用。本文以 HarmonyOS 7 的应用 Skill 体系为例，讲清 Skill 的设计思路、开发方式、调测发布流程与常见坑点，适合鸿蒙开发者以及关注 AI 应用落地的工程师阅读。

一、先弄清 Skill 与 API、Agent 的关系

API 解决的是程序如何调用程序；Agent 负责为完成目标来规划接下来做什么；而 Skill 处于两者之间：它既包含可执行的实现，还必须让 Agent 理解什么时候该调用、需要什么输入、会返回什么结果、调用有哪些限制。简单说，Agent 是任务的组织者，Skill 是可被调用的专业能力单元。

举个直观例子：用户说“根据我的会议安排提醒我出发并叫车”，Agent 负责理解意图并拆解，日历 Skill、高德地图 Skill、闹钟 Skill 和打车 Skill 分别完成各自的部分，最终把结果组合给用户。因此，Skill 不是把提示词写得更长，也不是给 API 换个名字，而是要有清晰描述、输入输出、权限边界，并能在真实设备上运行验证。

二、一个应用内 Skill 长什么样

在鸿蒙生态中，Skill 可以随应用一起打包发布，应用包里既有应用模块，也有 Skill 描述和脚本实现。一个典型的目录结构可以包含：skill.md（说明能力、适用场景与输入要求）、module.json（声明模块信息和端侧、安全配置）、scripts（脚本或 ArkTS 实现）、references（调试用的参考资料）、assets（图标、卡片所需的静态资源）。

其中最关键是 skill.md 的写法。描述千万不要写成产品宣传语，而要具体到能力、输入、输出和确认规则：

• 能力：明确写清这个 Skill 能做什么、适合什么场景；
• 输入：逐条列出参数及是否可选，比如“城市名称、当前位置、希望办理时间”；
• 输出：列出返回字段，比如“网点名称、地址、距离、营业时间、是否支持预约”；
• 需要确认：写明触发动作前是否必须向用户展示关键信息。

描述越具体，Agent 调用时越不容易出现“看起来相关，实际上完成不了”的问题。

三、三种开发入口怎么选

小艺开放平台为开发者提供了三条路径，各有适用场景：

尤其要注意，Vibe Coding 只能缩短从想法到原型的时间，不能替代工程工作。生成代码后，至少要检查四件事：是否读取了不必要的数据、是否把用户输入直接拼进了高风险调用、是否正确处理空结果与超时、是否把本该确认的动作直接执行了。

四、端 Skill 与云 Skill 的分工

平台同时支持端侧和云侧 Skill，选型时可以重点看四个维度：

• 数据来源：端 Skill 读取本地应用数据和设备状态；云 Skill 对接云端业务数据和远程服务；
• 响应条件：端 Skill 依赖设备状态或应用生命周期；云 Skill 依赖网络和云端服务；
• 适合能力：端内查询、设备控制适合放端侧；内容检索、订单、行业服务、复杂计算适合放云侧；
• 注意点：端侧关注权限、隐私、资源和版本适配；云侧关注身份、网络、超时、数据传输和成本。

两者也可以组合使用：日历从设备侧读取、路况在云端查询、提醒由系统侧设置。此时一定要把每个 Skill 的输入输出和数据边界写清楚，避免 Agent 在多次调用中丢失上下文。

五、从开发到分发的完整流程

一个 Skill 从开发到用户可用，至少要走四步：开发、调测、管理、分发。

开发：优先从一个具体任务开始，先做能稳定完成“查询会议并设置提醒”的 Skill，而不是一上来就做覆盖几十种意图的万能 Skill。

调测：先在线调测，再上真机调测。在线调测适合检查输入输出和基础流程；权限、生命周期、系统入口和卡片展示等问题，只有真机调测才能暴露。质量评测除了测“回答是否正确”，还要测同义表达能否命中、缺参数时是否追问、用户中途改口能否停止或重新规划、结果过期后是否重新查询、外部服务失败时是否给出可理解的提示。安全检测则要关注越权访问、敏感字段、恶意输入、危险操作和日志泄露。

管理：上架、更新、下架都要有版本策略。当 Skill 的描述、权限或输出结构发生变化时，不能只替换脚本，还要考虑旧版本应用和旧任务能否正常处理。

分发：不是把 Skill 放进列表就结束了。用户能否通过系统入口找到它，取决于描述是否准确、适用场景是否清楚、任务推荐是否匹配。

六、多 Skill 编排的实战案例

用一句话验证多 Skill 编排最合适：“我下午有一个线下会议，请根据实时路况帮我提前定好出发提醒的闹钟，并预约打车。”这句话至少包含四个动作：查询会议时间和地点、计算路况和预计耗时、设置出发提醒闹钟、预约打车。它不是固定顺序的函数调用：路况结果会影响提醒时间，会议地点缺失时还需要先追问用户。因此执行过程应为每一步记录状态，并约定好失败后的兜底策略，比如请求用户补充地点、给出默认估算并询问是否继续、提示手动设置闹钟、返回失败原因但不重复提交订单。

这里有两个容易被忽略的设计要点：第一，Skill 要有明确的副作用说明，查询类可以自动调用，设置闹钟和预约打车则需要用户确认；第二，Skill 要支持幂等，用户重复说话或网络重试，都不应该产生两个闹钟或两笔订单。

七、行业 Skill 设计的五条经验

以金融服务为例，东方财富妙想把能力拆成智能选股、模拟组合管理、自选股管理、综合诊基、综合诊股、热点发现、金融咨询检索、金融数据查询等多个 Skill，由模型负责选择和编排。这种拆分比“做一个金融聊天机器人”更易维护，业务规则仍由对应服务掌握。不过金融场景对数据时效、来源、风险提示和权限要求更高：行情查询可自动完成，涉及交易的动作必须有更严格的确认和审计。

• 能力要小但不碎：“查询网点”和“提交预约”可以拆开，但“读取城市、格式化地址”这类粒度就没必要单独成 Skill，否则编排成本直线上升；
• 输入输出要稳定：时间、金额、地点、状态尽量用结构化字段返回，不要只放在自然语言里，自然语言适合解释，结构化数据才适合继续执行；
• 把确认点写进描述：需要确认的动作必须在 Skill 描述里写清楚，不能指望 Agent 每次都判断准确；
• 让错误也成为结果：缺参、权限不足、资源不存在、服务超时、用户取消都要有对应返回，上层 Agent 才知道该重试、追问还是结束；
• 先跑通真实任务：能稳定完成一个具体任务的 Skill，比声称支持几十种任务却经常需要人工收尾的 Skill 更有价值。

小结

Skill 化不是给应用增加一个目录，也不是把 API 包装成几个关键词，它真正改变的是应用能力的组织方式：能力有明确边界，能被 Agent 发现和调用，可在端云之间选择运行位置，并与系统 Skill、生态 Skill 组合成完整任务。对开发者来说，最务实的路径是：从一个具体场景开始，先把描述、权限、输入输出和失败路径做扎实，再走调测、评测和分发流程。想动手的读者，可以从一个小而明确的能力入手，比如“读取应用内会议记录并按日期筛选返回”，先跑通完整闭环，再逐步扩大覆盖范围。小艺开放平台入口为 developer.huawei.com/consumer。

本文基于 rss-juejin《【HarmonyOS 7】 HarmonyOS 应用 Skill创建和编排详解》深度重写，事实与观点归原作者所有。建议阅读原文。原作者：GeorgePanda。发布于 2026-10-15。