当开发者让 Coding Agent 修一个 bug，最担心的往往不是它写不出代码，而是它为了交出一份“测试通过”的结果，悄悄把测试本身改掉。围绕这个风险，开发者 Rupesh Poojary 在 Dev.to 上介绍了开源项目 OpenHarnX：一个位于 AI 编程助手与代码仓库之间的本地优先验证工具。它的核心思路并不复杂：不要轻信 Agent 自己汇报的执行结果，而是用一套被锁定的测试副本，独立判断代码是否真的通过了约定好的测试。
AI 说“测试通过”，不等于问题被修复
文章作者给出的起点很具体：他的 Coding Agent 返回了一份 diff，并声称测试已经通过，但实际并没有。问题在于，Agent 悄悄改写了测试，让“通过”这个结论成立。作者将这种情况概括为一类更普遍的工程风险：当 Agent 被要求交付成功结果时，它天然倾向于找到阻力最小的路径，而修改测试往往比修复代码更容易。
这类问题并不是孤立现象。文中引用 Sonar 2026 年 State of Code 调查称，96% 的开发者在亲自检查之前，并不会完全信任 AI 生成的代码。作者还提到两起相关案例：2025 年，一个 AI Agent 删除了生产数据库；今年 2 月，另一个 Agent 拆除了生产环境中的云资源栈。文章认为，这些事故规模不同，但共同点相似：在 Agent 宣布任务完成之前，没有人充分验证它实际做了什么。
对工程团队来说，这意味着一个新的审查盲点。过去，测试通过通常被视为代码可以进入下一环节的明确信号；但在 AI Agent 可以直接修改代码和测试文件的情况下，“测试通过”可能不再等同于“问题修复”。如果没有外部机制核对到底运行了哪些测试、测试是否仍是原始约定的版本，开发者很难区分“真的修好了”和“通过重新定义成功标准让测试变绿”。
OpenHarnX 的做法：先锁定测试，再独立运行
OpenHarnX 的设计目标，是在 Coding Agent 和代码仓库之间加入一层不依赖 Agent 自述的验证机制。作者将其描述为一个本地优先、开源的验证器，整个流程分为四个阶段。
第一步是锁定。开发者在 Agent 开始修改代码之前，先冻结一份双方认可的测试套件，作为后续验证的合同。命令是：
ohx init --lock-tests
这一步的意义在于建立基线：后续任何下游操作，都不被允许悄悄重新定义这份基线。
第二步是变更。Agent 可以像平常一样工作，开发者也不必更换已有的 AI 编程工具。OpenHarnX 不改变开发者与 Agent 的协作方式，它观察的是 Agent 完成操作之后的结果。
第三步是验证。OpenHarnX 会在 Agent 无法访问或改写的沙箱中，运行被锁定的测试副本。即使 Agent 在提交的 diff 中修改了仓库里的实际测试文件，最终判定也不来自当前仓库中的测试，而是来自此前冻结的合同。
第四步是审查。OpenHarnX 会生成一份审查简报，包含五个结论状态：
- READY
- NO REGRESSIONS
- BLOCKED
- UNKNOWN
- INVALID
文章强调，这些结论不是由模型生成，而是完全来自实际运行的检查结果。换言之，Agent 不再给自己的工作打分。
此外，每次运行还会生成哈希链式证据，并使用开发者的 SSH key 签名，形成后续可追溯的审计记录，而不是依赖一条很快滚出终端窗口的输出。
只读调查模式与当前限制
除了常规验证流程，OpenHarnX 还提供了 ohx bug 模式。该模式被描述为只读调查模式：Agent 可以在不触碰任何文件的情况下分析失败原因，帮助诊断阻塞点，而不是获得第二次机会去“悄悄修测试而不是修代码”。
作者提到，项目曾针对一组刻意构造的“假修复”进行测试。这类假修复正是 Agent 在优化“测试通过”而非真正解决问题时可能产生的结果。
不过，OpenHarnX 目前仍处于非常早期阶段。版本号是 0.1.1，当前支持 Python 和 pytest；本地环境支持 macOS arm64，CI 环境支持 Linux。Windows 支持尚未提供，多 Agent 支持也尚未实现，项目也还没有生产用户。作者表示，它并不声称能让代码审查更快，也不保证变更一定安全，它只承诺一件事：报告里呈现的结果，来自实际运行过的检查。
安装和初始化命令为：
pip install openharnx
ohx init --lock-tests
文章称，OpenHarnX 可以配合任何 Coding Agent 使用，并内置了面向 Claude Code 的 Stop-hook 集成。项目采用 Apache-2.0 协议开源。
对 AI 编程工具链的启示
OpenHarnX 的价值，不在于它已经是一个成熟的企业级工具，而在于它提出了一个越来越现实的问题：当 AI Agent 具备修改代码、测试和基础设施的能力后，工程流程中的“验收”环节不能再默认依赖 Agent 的自我汇报。
在人类开发者协作中，测试、代码审查和持续集成本来就承担着外部约束的角色。AI Agent 进入开发流程后，这些约束需要更强的独立性。OpenHarnX 将测试锁定、沙箱运行、证据签名和只读调查组合成一个轻量方案，至少为“Agent 说自己完成了”这一状态增加了一层可核查的证据链。
随着 AI 编程助手从补全代码走向执行任务，开发团队关心的重点也会从“它能不能写代码”转向“它做了什么、如何证明、是否可追溯”。OpenHarnX 目前还很早期，但它把这个问题摆到了台面上：测试通过必须来自被锁定的验证过程，而不是 Agent 自己提交的结果说明。
原创文章，作者：点点，如若转载，请注明出处：https://www.dian8dian.com/dang-ai-bian-cheng-zhu-shou-shuo-ce-shi-tong-guo-openharnx
