从 help 文档到 Function CallingCLI-Anything 怎么给 Agent 搭桥【免费下载链接】CLI-AnythingCLI-Anything: Making ALL Software Agent-Native -- CLI-Hub: https://clianything.cc/项目地址: https://gitcode.com/GitHub_Trending/cl/CLI-AnythingAgent 最擅长推理但面对真实软件时常常寸步难行GIMP、Blender、LibreOffice 这类专业工具没有稳定开放的 API像素级的 GUI 自动化又脆弱得经不起一次窗口抖动。业界为此讨论过两条出路——要么让 Agent 学会看图点鼠标要么把软件的每一个操作都压缩成一行可调用、可校验、可复现的命令。CLI-Anything 选择的是后者并且它用一条几乎零人工介入的流水线回答了那个更关键的问题如何让 Agent 不读 README就能知道某个命令该怎么调、会返回什么本文从源码出发拆解这条「help 文档 → 结构化工具契约 → Agent 可调用」的搭桥链路它如何自动把 Click 命令树翻译成机器可读的 SKILL.md如何用--json把输出变成数据又如何在 CLI-Hub 与 Workflow Matrix 的加持下把单个工具可用升级成多步工作流自动化。一、问题根源Agent 缺的不是推理是操作面AI Agent 的短板从来不是规划能力而是对真实软件的执行能力。CLI-Anything 的 README.md 把这种断层描述得很直白当前的主流方案要么是脆弱的 UI 自动化要么是有限的 API要么是丢掉了 90% 功能的简化重实现。而 CLI 恰好是人与机器之间最古老也最通用的接口——文本命令天然匹配 LLM 的输入输出格式--help自描述特性让工具的能力可以被程序化发现确定性输出则让 Agent 的行为可预测。这正是社区讨论中反复出现的共识CLI 是 Agent 时代的通用遥控器。但遥控器再通用Agent 也得先知道哪个键对应哪个功能。CLI-Anything 的核心工作就是把这个键位表自动生成出来。二、从 help 文档到机器契约SKILL.md 的自动生成链路社区对 CLI-Anything 的早期描述往往浓缩为解析 help 文档、生成 JSON Schema / OpenAI Function Calling 格式的工具描述。这句话没错但真正的工程细节藏在 skill_generator.py 里——它并不真的去读--help的终端输出而是直接对 CLI 源码做 AST 解析。每个生成的 harness 都是 Click 构建的命令树顶层是click.group下面挂着若干click.command。skill_generator.py用 Python 的ast模块遍历函数定义识别click.group与click.command装饰器从装饰器参数中读出声明的命令名再取函数 docstring 作为描述最终组装成CommandGroup/CommandInfo结构# cli-anything-plugin/skill_generator.py def _click_decorator_info(function, kind): Return the owner and declared name for a Click decorator. for decorator in function.decorator_list: target decorator.func if isinstance(decorator, ast.Call) else decorator if not (isinstance(target, ast.Attribute) and target.attr kind): continue ...这些结构化元数据随后通过 Jinja2 模板 templates/SKILL.md.template 渲染成标准 SKILL.md输出到仓库根目录skills/cli-anything-software/SKILL.md。以 WireMock 为例生成的契约长这样--- name: cli-anything-wiremock description: Python CLI harness for WireMock HTTP mock server administration version: 0.1.0 entrypoint: cli-anything-wiremock ---对照 Function Calling 的惯例这个 YAML frontmatter 里的name与description就相当于 tool 的名称与用途声明正文中的 Command Groups 表格相当于参数与子命令的 schemaExamples 与Agent Guidance则是调用约定。换句话说CLI-Anything 把帮助文档翻译成了 Agent 可以直接消费的工具契约——这正是它与 LangChain、AutoGen 等框架集成的接口基础SKILL.md 提供工具定义--json提供结构化返回两端一拼就是一个标准 Tool 对象。三、--json双模输出让 Agent 拿到的不是文本而是数据有了工具契约还差最后一步调用结果必须是机器可解析的。这是所有 CLI-Anything harness 的硬性约定——同一个命令同时支持人读与机读两种输出由全局--json标志切换。以 wiremock_cli.py 为例顶层 group 上声明了--json与连接参数后者还支持从环境变量注入click.group() click.option(--host, defaultNone, envvarWIREMOCK_HOST, helpWireMock host) click.option(--json, json_mode, is_flagTrue, envvarWIREMOCK_JSON, helpOutput as JSON) def cli(ctx, host, port, scheme, user, password, json_mode): ...子命令内部按json_mode分流人读模式走彩色表格与状态文案机读模式直接打印原始 JSONstub.command(list) click.pass_context def stub_list(ctx, limit, offset): client ctx.obj json_mode ctx.meta.get(json_mode, False) data StubsManager(client).list(limitlimit, offsetoffset) if json_mode: print_json(data) else: print_table([ID, Name, Method, URL, Status], rows, ...)模板 templates/SKILL.md.template 里甚至为 Agent 固化了一组调用纪律始终使用--json检查返回码0 成功、非零失败失败时解析 stderr所有文件操作使用绝对路径导出操作后验证产物存在。加上 REPL 模式的会话状态undo/redo、JSON 工程文件持久化Agent 拿到的不再是一段终端输出而是一个有状态、可回滚、可断点续做的执行环境。四、给 Agent 开一座货架CLI-Hub、Meta-Skill 与 Workflow Matrix单条桥搭好了接下来是规模化的问题仓库里有 40 个 harnessAgent 怎么知道该装哪个、装了怎么用答案是三件套。第一件是包管理器 cli-hub。pip install cli-anything-hub之后cli-hub list、cli-hub search、cli-hub info、cli-hub install一整套命令把浏览、筛选、安装、卸载全部收敛到终端且列表命令同样支持--json。背后的目录数据在 registry.json每个条目都带name、version、description、install_cmd、entry_point、skill_md、category、contributors等字段——又是一层结构化的机器契约只是这次描述的是工具的仓库本身。第二件是 cli-hub-meta-skill/SKILL.md。它教 Agent 自主完成搜索 → preflight → 安装 → 阅读 SKILL.md → 执行任务的完整流程相当于把找工具这件事本身变成了 Agent 的一项技能而非人工操作。第三件是 Workflow Matrix见 cli-hub-matrix/video-creation/SKILL.md。它把多步工作流抽象成能力 × 提供方矩阵比如视频创作这条链路里text.transcribe、visual.generate、composite.assemble各是一个能力每个能力可绑定 harness CLI、公共 CLI、Python 库、原生二进制或云 API 中的某一种提供方。Agent 遵循的标准动作是先 preflight 再安装——cli-hub matrix preflight video-creation --json探测当前环境可用性与缺口cli-hub matrix install video-creation --capability text.transcribe则只按需安装任务真正需要的工具避免一次性批量装下 14 个 CLI。这三点恰好回应了社区情报中反复出现的两个关键词批量工具管理与多步工作流自动化。单工具时代Agent 每次调用都要靠提示词硬塞命令而有了结构化目录 能力矩阵Agent 可以像程序员用包管理器一样按任务动态组装自己的工具链。五、桥的另一端不是玩具真实后端与安全边界生成式 AI 很容易生产看起来能用的玩具代码。CLI-Anything 的工程约束在 HARNESS.md 里写得非常强硬第一条规则就是调用真实软件禁止重实现LibreOffice 渲染必须走libreoffice --headlessBlender 必须走blender --backgroundGIMP 走 Script-FuKdenlive/Shotcut 走 MLT XML melt。每个 harness 的utils/software_backend.py负责定位可执行文件、构造 subprocess 参数、处理安装缺失的错误提示并生成合法的中间文件后交给真实引擎渲染。安全上同样有完整的设计CLI 只暴露结构化、白名单式的命令面而不是把任意 shell 交给 LLM测试策略分成四层——单元测试、中间文件 E2E、真实后端 E2E、安装态 CLI 子进程 E2EREADME 里记录了 2,461 个测试全部通过的成绩。社区对沙箱化安全执行的讨论在这里落成了可验证的工程事实。六、案例从一行命令到一件成品纸上谈兵到此为止看两个真实案例。WireMock是最典型的无 GUI 服务型软件——Agent 用它做接口测试编排stub quick GET /api/users 200 --body [...]注册桩request count {method:POST,url:/api/orders}断言请求次数scenario set cart-flow item-added推进状态机record start录制真实后端流量。完整命令表见 skills/cli-anything-wiremock/SKILL.md这些操作全部通过 WireMock 的 Admin REST API 完成Agent 可以用--json拿到每次调用的精确返回。FreeCAD则展示了多步工作流的极限形态Agent 通过cli-anything-freecad增量组装一台火星车每一步操作都发布真实的预览包preview live维持实时预览会话trajectory.json把每条命令与对应的视觉状态绑定——整个构建过程从首块草图到成品展示全程可见、可回放类似的还有 Draw.io——Agent 从零画出一张完整的 HTTPS 握手时序图先 TCP 三次握手、再 TLS 协商、加密数据交换、四次挥手全部由命令驱动这些不是点一下按钮截一张图的演示而是 Agent 在无 GUI、无人工干预的前提下用纯命令链生产出真实工件的全过程。当每一步都建立在结构化的工具契约与 JSON 校验之上时这种自动化就是可审计、可复现、可增量调试的。七、结语回看整条链路CLI-Anything 的搭桥思路其实非常克制它没有试图教 Agent理解软件而是把软件压缩成 Agent 天然擅长的两种东西——结构化契约SKILL.md / registry.json / matrix 能力表与确定性调用--json 退出码。从 Click 装饰器的 AST 解析到自动化生成的 SKILL.md再到按需安装的 CLI-Hub 与按能力组合的 Workflow Matrix每一个环节都在把人读的帮助文档逐步替换为机读的工具定义。当社区还在争论 GUI 与 CLI 谁将胜出时CLI-Anything 用代码给出了更实际的答案未来 Agent 需要的不是某种单一界面而是一套能把世界上所有软件翻译成工具调用的标准化桥梁。桥已经搭起来了剩下的问题只是——今天你想让 Agent 学会用哪一款软件【免费下载链接】CLI-AnythingCLI-Anything: Making ALL Software Agent-Native -- CLI-Hub: https://clianything.cc/项目地址: https://gitcode.com/GitHub_Trending/cl/CLI-Anything创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考