先说工具全貌：hmharness 是一个开源的 HarmonyOS/OpenHarmony 开发智能体框架，把工程创建、检查、构建、签名、安装、启动、日志读取和结果验证接成本地工具链，让 AI 不只是生成代码，还要用本机环境证明结果；自进化行为受审批、预算、canary 和回滚约束。它不是 DevEco Studio 的替代品，而是开发智能体和鸿蒙工具链之间的验证层。本文只展开其中一环：edit_file 精确编辑。

仓库：https://github.com/swsgbl/hmharness

让 AI 改鸿蒙工程时，最让人不放心的往往不是它不会写，而是它“太会重写”：明明只想改一个按钮状态、一个签名配置或一个 ArkTS 方法，模型却把整个文件重新生成一遍。格式、注释、相邻逻辑甚至别人未提交的改动，都可能被顺带改掉。

hmharness 的 edit_file 对这个问题给出的约束很直接：模型必须提供 old_string 和 new_string，且 old_string 在目标文件里必须出现且只能出现一次；否则在写入前直接拒绝。

先看判断链：拒绝优先，写入最后

edit_file 不是把字符串替换当成一个普通便利函数，而是当成一道编辑门禁。它的执行顺序如下：

公开实现里有四类前置失败：

1. old_string 为空：没有定位点，拒绝；
2. old_string == new_string：没有实际变化，拒绝；
3. 目标文件里找不到 old_string：说明模型没有读到真实上下文，拒绝；
4. old_string 出现第二次：目标不唯一，拒绝，并返回两个 offset，要求补充更多上下文。

只有全部通过，才会用 slice(before) + new_string + slice(after) 拼出新内容并写入。换句话说，它改变的是被声明的那个片段，而不是模型的“整份文件想象”。

一个最小例子：只动命中的那一行

公开测试里有一个很典型的样例：

const x = 1;
const y = 2;

如果把：

const x = 1;

替换成：

const x = 42;

返回结果会报告替换的字符数和 offset。文件变成：

const x = 42;
const y = 2;

这听起来简单，但对 AI 编辑很关键：const y = 2; 这一行没有被重新生成，也没有被格式化重排。小改动保持小范围，后续 review 和回滚都更容易。

遇到重复片段时，它会主动停下来

假设文件里有两个 foo()，模型只想改其中一个，却只提供了：

old_string: "foo()"
new_string: "bar()"

edit_file 不会猜“ probably 是第一个”，而是返回 not unique，并给出两个命中位置。模型下一步应该扩大 old_string，把函数名、所在方法或相邻配置带上，直到能唯一定位。

这个设计特别适合 ArkTS / ArkUI 工程：同名组件、相似 builder、重复的样式属性和配置片段并不少见。越是重复代码，越不能让代理靠猜来做破坏性修改。

权限不是一刀切，路径决定爆炸半径

edit_file 的另一个重点是审批分层。它不是简单地“文件写入都要弹卡片”，也不是“所有写入都放行”：

当前公开实现分成三层：

• 在当前工作区内改代码：这是代理的正常工作，不需要每次编辑都打断用户；
• 写 HMH_HOME：配置、工作区档案、审批规则所在的位置，永远需要审批，避免代理改写自己的权限边界；
• 工作区外或没有足够上下文：需要审批，按 fail-closed 处理。

同时，write_file 仍然保持审批约束，run_command 仍然是高风险能力，包含进程执行、文件系统和网络权限。edit_file 降低的是“小范围修改”的摩擦，不是放开整个执行面。

我复核过的公开证据

发布本文前，我重新核对了当前公开状态：

• GitHub main：739b3b944954cc75512784a1b4b7a4c9962748af
• npm latest：@hmharness/cli@0.14.2，要求 Node >=22
• 目标测试：edit-file.test.ts 与 capability.test.ts 共 8 个测试，8 通过，0 失败

源码入口：

• 实现：https://github.com/swsgbl/hmharness/blob/739b3b944954cc75512784a1b4b7a4c9962748af/packages/agent/src/tools.ts
• 测试：https://github.com/swsgbl/hmharness/blob/739b3b944954cc75512784a1b4b7a4c9962748af/packages/agent/src/__tests__/edit-file.test.ts

这条证据只说明当前公开提交的目标行为，不表示所有机器、所有 SDK 环境都必然可用，更不表示 hmharness 已经在普遍意义上“越用越聪明”。环境差异本身就是这个项目最需要回收的数据。

上手与反馈

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

如果你正在试鸿蒙开发智能体，欢迎把 OS、Node、DevEco / OpenHarmony SDK、真机或模拟器状态，以及第一个阻塞点反馈到环境讨论区：https://github.com/swsgbl/hmharness/discussions/4

相关入口：

• GitHub：https://github.com/swsgbl/hmharness
• npm：https://www.npmjs.com/package/@hmharness/cli
• B 站演示：https://www.bilibili.com/video/BV1xGY56TExa