用 AI 写鸿蒙应用时，最容易产生“假完成”的位置不在代码生成，而在代码生成之后：HAP 没有签名、签名配置和本机 SDK 不匹配、安装目标不存在、Ability 启动失败、启动后又 crash。模型一句“已经完成”并不能证明这些环节真的成立。

hmharness 的价值取向是把验证链往前推：不只让代理改代码，还让它在本机工具链里确认设备、读取项目档案、签名、安装、启动，并回读日志。2026-09-09 的公开提交 bdc83d0 记录了一次完整链路验证，同一条会话内工具调用结果为 ok，共 9 次工具调用。

这条链路到底验了什么

公开证据中的会话依次使用了这些工具：

1. harmony_devices：先确认可用的目标设备或模拟器；
2. harmony_project_profile：读取项目与产物上下文，避免在错误目录里猜 HAP 路径；
3. harmony_sign：使用调试签名处理 HAP；
4. harmony_install：把包安装到目标设备；
5. harmony_launch：启动目标 Ability；
6. harmony_logs：回读运行日志，让后续判断基于真实输出。

这条链路的关键不是“多调用了几个工具”，而是把代理的结论从“我认为能跑”推进到“签名、安装、启动和日志回读已经在本次环境完成”。对鸿蒙开发来说，这正好卡在最容易断掉的几段上。

公开证据在哪里看

证据页由真实日志导出，当前公开统计包括：

• 46 个进化轮次；
• 26 个 active 技能；
• 17 个 canary 试验中；
• 18 个 draft 技能；
• 14 个 archived 技能；
• 227 条洞察；
• 120 条长期记忆。

公开提交信息如下：

提交地址：https://github.com/swsgbl/hmharness/commit/bdc83d0e9d40a33858b6fd071cb5059aac2a497f

证据页地址：https://swsgbl.github.io/hmharness/evidence/

影响环不是只会“越学越多”

自进化系统真正危险的地方，是候选技能一旦晋级就很难退出来。hmharness 的 SELFFEED 记录里保留了影响环：候选先进入 canary 小比例暴露，再与对照组比较成本与结果，数据不足时不冒进，表现更差则退回 draft。

这次公开记录中，有 3 个 canary 被判定有害并退回草稿：

• codexhost-offline-upgrade
• continue-hmharness-conversation-workflow
• verify-before-execution-workflow

这比“又晋升了多少技能”更重要。能淘汰变差的候选，才说明进化 loop 不是单向奖励机器。

边界必须说清楚

这条证据证明的是：在本次公开记录的环境里，签名、安装、启动、日志回读链路跑通；影响环能淘汰 3 个表现有害的 canary。

它不证明：

• 所有机器、所有 SDK 版本、所有真机环境都必然成功；
• hmharness 已经在普遍意义上“越用越聪明”；
• 项目获得 Huawei/OpenAtom 官方背书。

hmharness 是独立 MIT 开源项目，Windows 是优先验证平台，macOS/Linux 属于社区支持。环境差异本身就是最重要的数据：如果你试用，欢迎把 OS、Node、DevEco/OpenHarmony SDK、真机或模拟器状态，以及第一条失败命令反馈到 GitHub Discussions。

上手入口

npm install -g @hmharness/cli
hmh init
hmh tui

相关链接：

• GitHub：https://github.com/swsgbl/hmharness
• npm：https://www.npmjs.com/package/@hmharness/cli
• 证据页：https://swsgbl.github.io/hmharness/evidence/
• 提交：https://github.com/swsgbl/hmharness/commit/bdc83d0e9d40a33858b6fd071cb5059aac2a497f