OpenCLI 学习 04:Harness 目录与文件分工

1. 为什么我在这一部分容易混乱

因为一个 harness 目录里通常会同时出现:

  • 设计文档
  • README
  • Skill
  • CLI 入口
  • core 业务模块
  • utils 后端桥接
  • tests

如果不先按职责区分,很容易把这些文件都看成“某种说明文档”或者“某种脚本入口”。

2. 一个标准 harness 的结构

我目前可以把一个标准 harness 粗略理解成:

<software>/
└── agent-harness/
    ├── <SOFTWARE>.md
    ├── setup.py
    └── cli_anything/
        └── <software>/
            ├── __main__.py
            ├── README.md
            ├── <software>_cli.py
            ├── core/
            ├── utils/
            ├── tests/
            └── skills/

3. 每一层是干什么的

<SOFTWARE>.md

例如:

  • GIMP.md
  • LIBREOFFICE.md

它不是主要给 Agent 调用时读的。

它更像:

  • 设计分析文档
  • 软件专项 SOP
  • 说明为什么 harness 要这样设计

通常会写:

  • 软件本体怎么工作
  • GUI 操作怎么映射到 CLI
  • 为什么选这种后端策略
  • 项目模型如何设计

所以它更偏开发者/维护者视角。

setup.py

它负责:

  • 包怎么安装
  • 安装后命令叫什么
  • 依赖有哪些

也就是把这个 harness 变成一个真正可安装的 CLI 工具。

README.md

这是给人类用户看的使用说明。

通常会写:

  • 怎么安装
  • 怎么运行
  • 有哪些命令
  • 示例命令是什么

所以它偏“人类可读”。

<software>_cli.py

这是最关键的运行入口文件。

它负责:

  • 定义命令树
  • 定义参数
  • 解析 CLI 输入
  • 调用 core
  • 输出结果
  • 处理错误

所以它不是“说明怎么用”的文档,而是:

真的被执行的 CLI 入口代码。

core/

这是业务逻辑层。

里面一般按领域拆模块,例如:

  • document.py
  • writer.py
  • export.py
  • session.py

它负责真正的数据处理、状态变化、业务规则和导出策略。

utils/

这是工具层和后端桥接层。

最关键的通常是 backend 文件,例如:

  • gimp_backend.py
  • lo_backend.py

它负责:

  • 找真实软件
  • 组装命令
  • 调用 subprocess
  • 检查输出文件

所以它是 harness 和真实软件之间的桥。

tests/

测试目录一般包括:

  • test_core.py
  • test_full_e2e.py
  • TEST.md

作用分别是:

  • 单元测试
  • 端到端测试
  • 测试计划与测试结果记录

这部分是为了证明 harness 不是“看起来能用”,而是真的可验证。

skills/SKILL.md

这个才是真正偏给 Agent 读的说明文档。

它主要告诉 Agent:

  • 这个 harness 是干什么的
  • 适合什么场景
  • 什么时候应该调用
  • 有哪些命令组
  • 调用时有哪些注意事项

所以它更偏 Agent 视角。

4. 我目前对三个关键文档的区分

<SOFTWARE>.md

  • 回答:为什么这样设计
  • 偏开发/维护视角

README.md

  • 回答:人类怎么使用
  • 偏用户视角

SKILL.md

  • 回答:Agent 什么时候该调用、如何调用
  • 偏 Agent 视角

5. 我目前对 <software>_cli.py 的理解

它不是文档,而是执行入口。

也就是说,当用户或 Agent 真的输入:

cli-anything-libreoffice export render report.pdf

最后就是 libreoffice_cli.py 里对应的命令函数被执行。

所以它负责的是:

  • 接受命令
  • 调用业务逻辑
  • 返回结果

6. 当前我的一句话总结

一个 harness 目录本质上是在把“设计说明、运行入口、业务逻辑、后端桥接、测试验证、Agent 说明”打包到一起。

而我现在最重要的区分是:

  • <SOFTWARE>.md 不是给 Agent 主要调用时读的
  • SKILL.md 才是更偏给 Agent 使用的说明
  • <software>_cli.py 是真正执行命令的入口代码

Read more

三台机器部署 ClickHouse 高可用集群实战记录

本文是一份可发布版部署记录。真实 IP、域名、账号、密码、下载链接、业务目录名、机器唯一标识等敏感信息已经替换为占位符。命令中的 <...> 需要按自己的环境替换。 目标与拓扑 这次目标是用三台数据节点部署一套 ClickHouse 高可用集群,拓扑采用: 1 shard x 3 replicas 含义是:集群只有一个逻辑分片,三台机器都保存同一份数据的完整副本。任意一台数据节点宕机时,只要 ClickHouse Keeper 仍然有多数派,剩余节点仍可继续提供读写服务。 规划节点如下: 主机名示例地址角色ch-01<ch-01-ip>ClickHouse Server + ClickHouse Keeperch-02<ch-02-ip>ClickHouse Server + ClickHouse Keeperch-03<ch-03-ip&

By ladydd

折腾记(二):接入火山引擎实时语音 API,家庭语音助手体验直接拉满

接上篇 上一篇用全开源组件(Whisper + Hermes + Edge-TTS)搭了个语音助手,能跑,但体验就是"能用"二字: * 中文识别只有 70 分,方言基本歇菜 * 英文唤醒词"Alexa"喊着别扭 * 说完到回复要等 4-8 秒 * 它说话的时候你插不了嘴 这些问题靠堆开源组件很难根治。于是我去试了火山引擎(字节跳动)的语音服务,结果直接换了条路。 这篇分两段:先讲怎么用火山引擎的 ASR/TTS 替换掉开源组件(小改),再讲怎么上端到端实时语音模型(大改)。 第一段:先把 ASR 和 TTS 换成火山引擎 为什么换 我用豆包输入法的时候发现它语音识别准得离谱。一查,豆包用的就是字节自家的火山引擎 Seed-ASR。开通后有免费额度(

By ladydd

折腾记(一):用全开源组件给家里搭一个语音助手,对接自己的 Hermes Agent

起因 事情是从一块 ESP32-S3 开发板开始的。 我手上有一块 Seeed Studio XIAO ESP32-S3 Sense,带摄像头和麦克风。最初的想法很美好:用这块板子做一个无线语音终端,对着它说话,连到我服务器上跑的 Hermes Agent(一个自托管的 AI agent),让它回答我。 但折腾到一半我突然意识到一件事:我的麦克风、音响、服务器全在家里,为什么要绕一圈用 ESP32?直接把麦克风和音响插到服务器上不就行了? ESP32 那条路(做无线拾音终端)当然也有价值,但那是"为了学嵌入式而学",不是解决问题的最短路径。于是这个项目就从"嵌入式项目"变成了"在服务器上拼一个语音助手"。这篇就记录后者。 教训零:先想清楚你要解决的是什么问题。很多时候最优解比你最初设想的简单得多。 目标

By ladydd

Kiro 的三种代理设置方法:本地、服务端、Remote

作为kiro的骨灰级用户,这篇是我自己折腾 Kiro / Kiro Remote / Ubuntu Server 代理问题后的复盘。 核心不是“怎么配一个代理”,而是先判断:到底是谁在访问外网? 谁访问外网,代理就要配给谁。 0. 先说结论 Kiro 相关代理大概分三类: 场景真正访问外网的进程在哪里代理应该配在哪里本地 KiroWindows / Mac 本机本机 Clash / Proxifier / 系统代理服务端 Kiro / CLIUbuntu Server 上的 shell、CLI、node、kiro 进程Ubuntu 的环境变量,比如 HTTP_PROXY / HTTPS_PROXYKiro Remote远程 Ubuntu 上的 ~/.kiro-server 和 extensionHost远程 Ubuntu 的 Kiro Server

By ladydd
陕公网安备61011302002223号 | 陕ICP备2025083092号