OpenCLI 学习 01:项目总览与核心问题

1. 我最开始看到的现象

这个仓库根目录下有很多不同的软件目录,例如:

  • gimp/
  • blender/
  • libreoffice/
  • drawio/
  • zotero/

所以它不是单一应用,而是一个多软件、多 harness 的总仓库。

2. 项目在做什么

我目前的理解:

CLI-Anything 想把原本主要通过 GUI 使用的软件,整理成 Agent 也能稳定调用的 CLI 接口。

它不是简单做几个命令,而是在做一套标准化的软件能力接入方案。

3. 这里的 CLI 到底是什么意思

我一开始容易把 CLI 理解成“黑框里的自由互动”。

后面逐渐明确:

  • 终端/黑框:只是运行环境
  • CLI:是能力暴露出来的命令接口
  • 脚本:是实现 CLI 的一种方式

所以这里的 CLI 更接近“面向终端的函数调用接口”。

例如:

cli-anything-gimp project new --width 800 --height 600

它不是自由聊天,而是在调用一个被明确组织好的能力。

4. 为什么会让我联想到 REST API

因为两者本质上都在做“能力暴露”:

  • REST API:通过 HTTP 暴露能力
  • CLI:通过命令行暴露能力

区别在于:

  • API 更偏网络服务
  • CLI 更偏本地软件、本机工具、桌面应用

这个项目选择 CLI,不是因为 CLI 比 API 更高级,而是因为很多真实软件并没有天然的 REST API,但有脚本接口、命令参数、批处理模式或插件机制。

5. 这个项目真正统一的是什么

不是统一所有软件的功能本身,而是统一:

  • 软件能力如何暴露给 Agent
  • CLI 应该如何组织
  • 文档、测试、打包怎么做
  • Skill 怎么告诉 Agent 何时调用、如何调用

所以它更像是在统一一种“接入规范”和“工程方法”。

6. 当前我的一句话理解

CLI-Anything 的核心目标,是把复杂软件或复杂能力系统化地整理成可被 Agent 调用的命令树接口。

7. 当前我的疑问是如何逐步被澄清的

我最初模糊的是:

  1. CLI 到底是不是黑框互动
  2. 这个项目到底是在做命令行工具,还是在做更大的东西
  3. Agent 到底靠什么知道何时调用这些工具

当前得到的阶段性答案:

  1. CLI 不是黑框互动,而是能力接口
  2. 这个项目不只是做 CLI,而是在做以 CLI 为形态的 harness
  3. Agent 主要通过 SKILL.md、命令树、帮助信息、JSON 输出理解和使用这些 harness

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号