OpenCLI 学习 02：CLI、Harness、Skill 的关系

1. 为什么我会觉得这个项目里的 harness 有点奇怪

因为我之前接触过的 harness，更像是：

• 一个黑盒环境
• 给 LLM 设定边界和工具
• 让 LLM 在里面自己探索、执行、达成目标

而这个项目里的 harness 明显不是这个意思。

2. 这个项目里的 harness 是什么

当前我的理解：

这里的 harness 更像是“站在 Agent 视角，为某个具体软件搭建的一整套能力接入系统”。

它不只是一个脚本，也不只是一个 CLI 文件，而是通常包含：

• CLI 入口
• core 业务模块
• backend 真实软件适配
• session 状态管理
• tests
• README
• TEST.md
• SKILL.md

所以它比单纯的 CLI 概念更大。

3. CLI 和 harness 的关系

我当前最认可的说法是：

• CLI 是对外的能力形态
• harness 是背后的完整接入实现

也就是说，这个项目表面上在做 CLI，实际上是在做以 CLI 为外在形式的 agent harness。

4. 为什么说 CLI 只是存在形式

因为项目真正关心的不是“黑框交互体验”，而是：

• 怎么把软件能力抽象出来
• 怎么把能力按命令树组织
• 怎么让 Agent 更容易探索和调用
• 怎么保证结果可测试、可验证

所以 CLI 更像它最终对外暴露的一层皮肤。

5. Skill 在里面扮演什么角色

SKILL.md 不是执行代码，也不是核心实现。

它更像是：

• 给 Agent 看的使用说明书
• 告诉 Agent 这个 harness 是干什么的
• 告诉 Agent 什么时候应该用它
• 告诉 Agent 命令结构、调用范式、注意事项

所以我现在把三者关系理解为：

• core/backend：真正干活
• CLI：把能力暴露出来
• SKILL：帮助 Agent 理解和使用这套能力

6. 命令树为什么关键

这个项目不是把功能平铺成一堆命令，而是做成命令树，例如：

cli-anything-gimp project new
cli-anything-gimp layer add-from-file
cli-anything-gimp filter add
cli-anything-gimp export render

这样做的好处是：

• 领域边界更清晰
• 更像业务模型
• Agent 更容易探索能力地图
• 更适合组合成工作流

所以命令树其实是业务模型在 CLI 层的映射。

7. 当前我的一句话总结

这个项目中，harness 是完整接入系统，CLI 是对外能力形式，Skill 是面向 Agent 的说明层，三者共同构成一个可被 Agent 使用的软件能力包装。