OpenCLI 学习 05:能力暴露与自由组合

1. 我当前最强烈的一个感受

不同 Agent、不同底层模型,对同一套 CLI 的理解能力并不一样。

这意味着:

  • 同样一个 harness
  • 不同 Agent 的使用效果可能差很多

所以真正重要的不只是“有没有这些命令”,而是:

这些能力是如何暴露给 Agent 的。

2. 我目前理解到的关键点

这个项目不是简单把旧软件的功能堆成一堆命令,而是在思考:

  • 怎么让 Agent 更容易理解工具能力
  • 怎么让 Agent 在面对真实任务时更容易选对命令
  • 怎么降低不同模型之间的理解差异带来的问题

也就是说,命令设计、文档、Skill、JSON 输出,这些都不是附属物,而是能力暴露设计的一部分。

3. 我目前觉得这个项目最精髓的地方

它没有把任务流程完全写死。

它做的是:

  • 提供一棵结构化的能力树
  • 让 Agent 根据真实需求去决定调用哪几个命令
  • 让 Agent 自己把这些命令组合成实际工作过程

这一点和固定工作流系统很不一样。

我目前觉得,这恰恰是它最值得学习的地方。

4. 但这里的“自由”不是完全随意

这一点我也逐渐意识到:

  • 它不是纯自由探索
  • 也不是完全没有边界

更准确地说,是:

在被设计过的命令树和接口边界内,让 Agent 自由组合。

也就是说:

  • 命令粒度已经被人设计过
  • 命令分组已经被人设计过
  • 状态接口和输出格式也已经被人设计过

Agent 的自由,是建立在这些结构化边界之上的。

5. 我目前觉得自己最欠缺的经验

不是具体怎么写某个命令,而是:

  • 哪些能力应该暴露
  • 应该如何分组
  • 命令粒度多大才合适
  • 哪些流程要留给 Agent 判断
  • 哪些状态必须显式暴露
  • 怎样降低 Agent 的理解成本

这更像是“给 Agent 设计工具接口”的经验,而不是普通业务代码经验。

6. 我当前的一句话总结

这个项目真正厉害的地方,不只是把能力做成 CLI,而是把复杂能力整理成一棵结构化、可探索、可组合的命令树,并通过 Skill、JSON 输出和状态接口,尽量降低 Agent 的理解成本,同时又不把任务流程固定死。

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号