CLI-Anything × Hermes Agent让 Hermes 成为 CLI-Anything Harness 构建者的完整技能指南【免费下载链接】CLI-AnythingCLI-Anything: Making ALL Software Agent-Native -- CLI-Hub: https://clianything.cc/项目地址: https://gitcode.com/GitHub_Trending/cl/CLI-Anything导读本篇文章聚焦 hermes-skill/SKILL.md 这一份面向 Hermes Agent 的技能Skill定义它把 CLI-Anything 的为 GUI 应用 / 源码仓库构建 Agent 原生 CLI方法论完整适配到 Hermes Agent 之上。读完本文你将掌握如何在 Hermes Agent 中安装并触发该技能、构建 / 精炼 / 测试 / 校验 harness 四种模式各自的产出标准、cli_anything命名空间包与console_scripts的打包规则以及如何通过 registry.json 检索全部既有 harness 作为参考基线。一、技能定位把 CLI-Anything 方法论装进Hermes Agentcli-anything-hermes技能的本质是让 Hermes Agent 扮演 CLI-Anything 的构建器角色。技能文档在 YAML frontmatter 中声明了触发条件description当用户希望 Hermes Agent build、refine、test 或 validate 一个针对 GUI 应用或源码仓库的 CLI-Anything harness时被触发其关键约束是只适配 Hermes 的操作流程不改动最终生成的 Python harness 格式。也就是说最终产物与其他 AgentClaude Code、Codex 等生成的 harness 完全同构可放入同一cli_anything命名空间生态。该技能还配套了供 Hermes 界面展示的元数据文件 hermes-skill/agents/hermes.yaml其中定义了显示名display_nameCLI-Anything、简短描述short_description与默认提示词default_prompt让 Hermes 在技能装载后能通过Use CLI-Anything to build, refine, test, or validate a harness for the users target software or source repository这类自然语言请求直接唤起。二、方法论唯一事实来源Source of Truth的读取顺序技能文档明确规定在执行构建前优先读取完整方法论而不是直接依赖本技能里被压缩的规则。其优先级如下若技能运行在 CLI-Anything 仓库内部先读取../cli-anything-plugin/HARNESS.md相对本技能路径即本仓库中的 cli-anything-plugin/HARNESS.md。这份文件是整个 CLI-Anything 的标准作业程序SOP与工具包全集包含把任意 GUI 应用变成 Agent 可用的 CLI的完整流程。若本地文件不可用则从外部仓库克隆或下载cli-anything-plugin再使用其HARNESS.md及周边资源。本文仅讲解仓库内可查证的路径clone 指令可在确实需要时参考 cli-anything-plugin/README.md。仅当本地与网络两种途径都失败才回退到本文下方提炼的精简规则Hermes Tool Bindings、Modes、Backend / Packaging Rules 等。这一先取完整 SOP、后降级为精简规则的阶梯设计保证了 Hermes 执行时遵循的方法论与 Claude Code / Codex 技能所遵循的完全一致只是工具调用语法不同。三、输入约定与 Hermes 工具绑定3.1 接受的输入该技能接受两类输入本地源码路径例如./gimp或/path/to/softwareGitHub 仓库 URL。若从远程克隆软件名可从本地目录名推导。仓库中gimp/、blender/、freecad/等顶层目录名与最终 harness 命名cli-anything-gimp、cli-anything-blender、cli-anything-freecad一一对应可在 registry.json 中核实。3.2 工具绑定表Hermes 通过组合以下内置工具完成 harness 构建下表为技能文档原文表ToolRole in Harness WorkflowterminalRun shell commands, install packages, execute CLI tools, run testsexecute_codeGenerate and write Python files (Click CLI, backend modules, tests)delegate_taskParallelize analysis or generation subtasksread_file/write_fileRead and write harness source filespatchMake targeted edits to generated code从这里可以读出与仓库实际实现相呼应的分工terminal对应 harness 中utils/software_backend.py以subprocess调用真实软件的做法execute_code负责生成 Click CLI、后端模块与测试read_file/write_file/patch则贯穿测试迭代过程。四、四种工作模式Build / Refine / Test / Validate4.1 Build产出标准目录骨架当用户需要新 harness 时技能要求生成如下结构software/ └── agent-harness/ ├── SOFTWARE.md ├── setup.py └── cli_anything/ └── software/ ├── README.md ├── __init__.py ├── __main__.py ├── software_cli.py ├── core/ ├── utils/ └── tests/这一骨架在仓库中得到完全落地验证。以 GIMP 为例gimp/agent-harness 下存在 GIMP.md项目专属分析与 SOP、setup.py以及cli_anything/gimp/子包gimp_cli.py主 CLI 入口、core/含 project、layers、filters、canvas、media、export、session 各领域模块、utils/含gimp_backend.py后端封装与repl_skin.pyREPL 皮肤、tests/含 TEST.md、test_core.py、test_full_e2e.py、skills/SKILL.md与README.md。同时Build 模式要求实现一个stateful Click CLI具体包括one-shot 子命令供脚本与管道使用未提供子命令时默认进入REPL 模式--json机器可读输出在目标软件支持时提供带 undo/redo 的会话状态。仓库中 gimp_cli.py 展示了click.group(invoke_without_commandTrue)的标准写法即无子命令时由主命令组接管并默认进入 REPL--json全局开关与统一output()函数则把所有命令输出收口为 JSONclick.echo(json.dumps(...))或人类可读两种形式。这与 cli-anything-plugin/HARNESS.md 中无参数执行cli-anything-software即进入 REPL的要求互为印证。4.2 Refine先盘点再做差距分析当 harness 已存在时技能要求先盘点现有命令与测试针对目标软件做差距分析gap analysis优先补齐高影响缺失功能、对既有后端 API 或 CLI 的轻量封装、能与现有命令良好组合的新增项除非用户明确要求破坏性变更否则不删除既有命令。4.3 Test先计划后编写测试模式要求在动手写测试代码前先做计划且同时保留两层测试文件test_core.py单元覆盖用合成数据测试每个核心函数无外部依赖test_full_e2e.py工作流与后端验证真实文件、真实软件后端。技能特别强调尽可能通过 subprocess 测试已安装的命令cli-anything-software而不只做模块导入级测试。这对应 HARNESS.md 中定义的_resolve_cli()辅助函数模式优先使用 PATH 中的已安装命令支持CLI_ANYTHING_FORCE_INSTALLED1强制使用已安装版在开发环境下回退到python -m。真实场景可参考 gimp/agent-harness/cli_anything/gimp/tests/test_full_e2e.py。4.4 Validate五项检查清单校验模式逐项核对 harness使用cli_anything.software命名空间包布局具备可安装的setup.py入口点支持 JSON 输出存在默认 REPL 路径对用法与测试有文档说明。五、后端规则优先包装真实软件禁止玩具式重实现技能文档的后端规则是全项目的第一铁律原文为Prefer the real software backend over reimplementation. Wrap the actual executable or scripting interface inutils/software_backend.pywhen possible. Use synthetic reimplementation only when the project explicitly requires it or no viable native backend exists.这条规则在 cli-anything-plugin/HARNESS.md 中被进一步定性为Use the Real Software — Dont Reimplement It并明确反例用 Pillow 重造 GIMP、只生成 bpy 脚本却从不调用 Blender与正确做法LibreOffice →--headless --convert-to、Blender →--background --python script.py、GIMP →gimp -i -b、Inkscape →--actions、Shotcut/Kdenlive →melt、Audacity →sox、OBS →obs-websocket。底层支撑即shutil.which()查找可执行文件 subprocess.run()调用缺失时报出清晰安装指引。六、打包规则PEP 420 命名空间包 console_scripts技能规定三条打包规则使用find_namespace_packages(include[cli_anything.*])保持cli_anything/为没有顶层__init__.py的命名空间包通过console_scripts暴露cli-anything-software。这三条规则在 gimp/agent-harness/setup.py 中得到逐字落地packagesfind_namespace_packages(include[cli_anything.*]), ... entry_points{ console_scripts: [ cli-anything-gimpcli_anything.gimp.gimp_cli:main, ], }, package_data{ cli_anything.gimp: [skills/*.md], },其中package_data保证skills/SKILL.md随 pip 包一同分发对应 HARNESS.md 中已安装 harness 也携带本地 skill 副本的要求。命名空间包机制的意义在于多个独立安装的包cli-anything-gimp贡献cli_anything/gimp/、cli-anything-blender贡献cli_anything/blender/可互不冲突地共存于同一 Python 环境。仓库中大部分软件目录下的cli_anything/都没有__init__.py而各子包目录gimp/等内部有自己的__init__.py正是这一设计。从源码结构可推断子包的__main__.py承担python3 -m cli_anything.software的入口职责配合 README 中pip install -e .的本地安装验证步骤Workflow 第 7 步。七、七步工作流技能文档定义的标准执行流程Acquire the source tree locallyclone 或使用既有路径Analyze architecture、data model、existing CLIs、GUI-to-API mappingsDesign command groups and state modelImplement the harnessWriteTEST.md再写测试并运行Update README usage docsVerify local installation withpip install -e .。第 2 步在 HARNESS.md 的 Phase 1Codebase Analysis中有更细的操作指引识别后端引擎如 GIMP 的 GEGL/Babl、Shotcut 的 MLT、把 GUI 动作映射为 API 调用、识别数据模型XML/JSON/二进制/数据库、寻找随后端附带的既有 CLI 工具、盘点命令 / undo 系统。第 5 步先写 TEST.md 再写测试对应 HARNESS.md 的 Phase 4测试计划先行测试清单计划、单测计划、E2E 计划、真实工作流场景与 Phase 6运行后把pytest -v --tbno结果追附加到 TEST.md 作为结果文档。第 7 步的pip install -e .已在各 harness 的 setup.py 头部注释中明示。八、既有 Harness 参考Registry技能文档将仓库根目录的registry.json指定为支持的 harness 及其后端模式的最新清单。在本仓库中 registry.json 记录了数量庞大的 CLI 条目每个条目包含名称与显示名、版本、描述、运行前置条件requires、安装命令install_cmd、入口点entry_point、对应 skill 文件路径skill_md与类别category。例如jumpserver堡垒机资产 / 用户 / 权限 / 审计管理入口cli-anything-jumpserver类别 devopsgimp光栅图像处理依赖gimp -i -b批处理模式类别 imageblender3D 建模与渲染依赖blender --background --python类别 3dopenrefine基于本地 HTTP API 的导入 / 清洗 / 行检查 / 导出与会话 undo/redo类别 databasezoteroCLI 与 MCP 服务器双形态类别 office。目录结构上仓库同时维护两套 SKILL.md 生态软件专属技能集中在skills/cli-anything- /SKILL.md以cli-anything-gimp/SKILL.md等为代表而 Agent 适配技能则分散在hermes-skill/、codex-skill/SKILL.md、cursor-plugin/skills/cli-anything-generator/SKILL.md 等目录中本文档即为 Hermes 的这一适配层。九、报告与输出预期技能文档要求在汇报进度或最终结果时包含四类信息目标软件与源码路径target software and source path新增或修改的文件files added or changed运行过的校验命令validation commands run存在的风险或后端局限open risks or backend limitations。这四条与仓库中大量SOFTWARE.md文档例如 GIMP.md项目专属分析与 SOP的定位呼应——每份 harness 都要说明后端策略与局限如 GIMP 的 .xcf 二进制格式导致采用项目文件 外部工具而非直接操作原生格式的策略。十、在 Hermes Agent 中安装该技能本技能目录自带跨平台安装脚本均以 Hermes 的 skills 目录为目标并拒绝覆盖已存在安装macOS / Linuxhermes-skill/scripts/install.sh — 目标目录默认${HERMES_HOME:-$HOME/.hermes}/skills/cli-anything-hermes若目标已存在则报错退出需手动移除后才可重装Windowshermes-skill/scripts/install.ps1 — 逻辑相同目标目录取HERMES_HOME或$USERPROFILE\.hermes\skills。安装完成后需重启 Hermes Agent 使技能生效两个脚本都打印了对应的重启提示。安装后可参考 hermes-skill/agents/hermes.yaml 中的默认提示词直接发起构建请求。作为对照仓库中 cursor-plugin、codex-skill 等目录也遵循agents 元数据 安装脚本 SKILL.md的同构布局可在需要跨 Agent 复用时相互参考。结语hermes-skill/SKILL.md是整个 CLI-Anything 方法论矩阵在 Hermes Agent 侧的关键一环。它没有另起炉灶定义新的 harness 格式而是通过完整 SOP 优先、精简规则兜底的读取策略把 cli-anything-plugin/HARNESS.md 定义的标准作业程序翻译成 Hermes 的工具调用语言。无论是 Build 时对 stateful Click CLI 与 REPL 默认路径的要求、Refine 时的差距分析纪律还是 Test / Validate 的测试分层与五项检查清单最终都能在仓库内gimp/等既有 harness 的目录结构与 setup.py 中找到逐一对应的实现证据——这也正是多 Agent 共享同一套方法论、产物完全互操作这一设计意图的最佳注解。【免费下载链接】CLI-AnythingCLI-Anything: Making ALL Software Agent-Native -- CLI-Hub: https://clianything.cc/项目地址: https://gitcode.com/GitHub_Trending/cl/CLI-Anything创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考