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

把 Codex CLI 的登录态"搬"到一台新服务器

场景:你在一台老机器上早就登录好了 Codex CLI,现在开了台新服务器、装好了 codex,但它没登录。你不想在新机上重新走一遍 OAuth 网页授权(有时候服务器上根本打不开浏览器),只想把老机器上那份"已经登录好的身份"复制过去。 这篇讲的就是这个搬运动作的完整方法论——为什么能搬、怎么搬、有哪些坑。命令里所有隐私都用占位符,照着换成你自己的即可。 一、先理解一件事:Codex 的登录就是一个文件 这是整个操作的地基。Codex CLI(ChatGPT OAuth 登录模式下)的登录状态,不在什么系统钥匙串里,也不在环境变量里,就是家目录下一个单独的 JSON 文件: ~/.codex/auth.json 它长这样(字段名是真的,值我打码了): { "auth_mode": "

By ladydd

哨兵机制:让 Agent 一触即醒

0. 一句话点破本质 **让"等"发生在便宜的子进程里,让贵的 agent 只在有事时醒。**心跳解决"最迟多久必有人查岗",探针解决"事情一发生几乎立刻有人到场"——两个机制回答的是两个不同的问题,谁也替代不了谁。 1. 机制全貌:会自杀的轮询进程 + 宿主的"尸体通知" 我的实现只有两块积木: 积木一:一个有明确死法的后台循环 # 放行任务的同时,后台挂上(run_in_background) for i in $(seq 1 20); do 信号=$(ssh data "tmux capture-pane -t dna

By ladydd

Agent 心跳机制·设计与实现

0. 一句话点破本质 **心跳不是闹钟,是"带着完整世界快照的自我唤醒"。**闹钟只解决"什么时候醒";心跳真正要解决的是你点出的那个问题——醒来的那个瞬间,清楚自己是谁、任务到哪了、这一跳该干什么。我所有跑得好的心跳,提示词都写得像给一个失忆的陌生人看的;所有出过事的心跳,都是因为假设"我还记得"。 1. 第一性原理:为什么"醒来知道干啥"这么难 一个长期任务里的 agent 面临三重失忆: 1. 上下文会被压缩——多轮之后早期细节只剩摘要,心跳打进来时,那条心跳提示词可能是上下文里唯一高保真的任务描述 2. 世界在你睡着时变了——下属可能干完了、卡死了、跑偏了,你脑子里的"进度"从睡着那刻就开始过期 3. 任务本身会变—

By ladydd

我没手动映射 3000,公网为什么还能访问?一次 UPnP 误开孔复盘

写在前面:标题里的“自己打开”只是当时的主观感受。路由器没有失控,也不存在神秘穿透。真正发生的是:排障自动化从局域网主动调用了 UPnP AddPortMapping,路由器按协议新增了公网映射。 1. 原本的设计边界 家里的 Open WebUI 跑在一台 Ubuntu 主机的 Docker 中: 内网主机 192.168.x.x:3000 路由器上手动配置的入口是: 公网 TCP 13000 → 内网主机:3000 外部用户不直接访问家宽端口,而是先到云端 Caddy: 用户浏览器 → https://ai.example.com (云端 Caddy) → http://home.example.com:13000 (DDNS → 家宽公网

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