Agent 生态的工具爆炸带来了一个尴尬的现实：每接入一个新工具都要开发对应的 MCP Server，成本线性增长。HKUDS 开源的 CLI-Anything 项目提出了一个更务实的思路 —— 与其为每个工具重写协议层，不如通过统一的 CLI 包装层，让现有命令行工具直接具备 Agent 调用能力。这种 "CLI-Hub" 架构正在成为连接传统软件生态与 Agent 世界的重要桥梁。
工具接入的困境：MCP Server 的规模化瓶颈
当前 Agent 系统的能力扩展主要依赖 MCP（Model Context Protocol）协议，它定义了标准化的工具发现、参数 schema 描述和权限管理机制。理论上，任何软件只要实现 MCP Server，就能被 Claude、Cursor、OpenClaw 等 Agent 直接调用。但实践中，为每个工具开发 MCP Server 意味着重复劳动：分析 CLI 参数、设计 JSON Schema、处理权限边界、维护版本兼容性。
更棘手的是存量软件。数以万计的开源 CLI 工具、企业内部的脚本集合、第三方 SaaS 的 API 客户端 —— 它们大多没有原生 MCP 支持，却承载着业务的核心能力。CLI-Anything 的解决思路是：与其等待上游改造，不如在 Agent 侧构建一个通用包装层，通过标准化的 CLI 调用约定，让任意工具都能被 Agent 安全地驱动。
CLI-Hub 架构：三层包装模型
CLI-Anything 的核心架构可以拆解为三个层次：
第一层是 CLI 生成引擎。它接收任意软件描述（桌面应用、代码库、Web API 文档），自动生成结构化的命令行接口。关键能力在于参数 schema 的推导 —— 通过静态分析或运行时探测，将工具的输入输出映射为 Agent 可理解的类型系统。生成的 CLI 遵循 Unix 哲学：文本输入、文本输出、退出码明确、可组合。
第二层是 CLI-Hub 注册中心（clianything.cc）。这是一个分布式的 CLI 工具仓库，提供cli-hub list、cli-hub search、cli-hub install等命令管理工具生命周期。每个注册的 CLI 都附带 SKILL.md 描述文件，声明其功能边界、参数示例和权限需求。Agent 可以通过自然语言查询 Hub，自动发现适合当前任务的 CLI 工具。
第三层是 Agent 集成层。CLI-Anything 支持 SKILL 协议，可与 OpenClaw、Nanobot、Claude Code、Codex 等主流 Agent 框架对接。Agent 通过统一的接口调用 CLI-Hub 中的工具，无需关心底层是原生 MCP Server 还是包装后的 CLI。这种设计让 Agent 的 "手"（执行能力）与 "脑"（推理能力）解耦，工具接入不再阻塞 Agent 迭代。
技术实现要点
将传统 CLI 转化为 Agent-Native 形态，需要解决几个关键工程问题。
参数 schema 的动态生成。传统 CLI 的参数解析通常依赖 argparse、click 等库，运行时才能确定完整的参数结构。CLI-Anything 通过两种途径获取 schema：对 Python/Node 等脚本进行静态 AST 分析提取参数定义；对二进制工具则通过--help输出解析结合 LLM 辅助理解。生成的 schema 以 JSON 格式存储，Agent 调用时进行类型校验和自动补全。
stdout 的结构化解析。CLI 的输出通常是面向人类的自由文本，Agent 需要从中提取关键信息。CLI-Anything 在生成的 CLI 中内嵌输出格式化器，支持--output=json模式将结果转为机器可读格式。对于无法修改的第三方工具，则通过输出捕获 + LLM 后处理的方式提取结构化数据，虽然增加了一次模型调用，但避免了为每个工具写解析器的成本。
权限沙箱与隔离。Agent 调用 CLI 意味着授予其执行任意命令的权限，安全风险不可忽视。CLI-Anything 采用多层隔离策略：通过 Linux namespace 限制文件系统访问范围；使用 seccomp 白名单过滤危险系统调用；对网络请求进行代理审计。每个 CLI 在注册时声明其权限需求（文件读写、网络访问、子进程执行），Agent 在调用前进行显式授权。
SKILL.md 协议标准化。这是 CLI-Anything 与 Agent 框架对接的契约。SKILL.md 包含工具描述、输入参数 schema、输出示例、错误码定义、依赖环境要求等元信息。Agent 通过解析 SKILL.md 理解工具能力，无需硬编码即可支持新工具。这种设计借鉴了 MCP 的 Capability 机制，但以更轻量的 Markdown 形式落地。
CLI 包装 vs 原生 MCP：适用场景分界
CLI-Anything 并非要取代 MCP，而是提供一种更轻量的替代方案。两者的选择取决于具体场景：
CLI 包装层适合快速确定性自动化，特别是已有成熟 CLI 的工具（如 git、docker、kubectl）。Unix 进程模型 "文本进文本出" 的简洁性，让 Agent 调用成本极低，无需维护长连接或状态同步。对于一次性任务、批处理作业、CI/CD 流水线集成，CLI 包装是更务实的选择。
原生 MCP Server 适合需要动态发现、持久上下文、复杂状态管理的场景。MCP 的 Resources 机制允许工具暴露可订阅的数据源，Prompts 机制支持模板化交互，Sampling 机制让 Server 能主动请求 LLM 补全。这些能力在需要多轮对话、上下文累积的工具（如数据库客户端、IDE 插件）中至关重要。
CLI-Anything 的设计哲学是 "CLI 是 Agent 的手，MCP 是协议层"。两者可以共存：CLI-Hub 中的工具既可以被 Agent 直接调用，也可以包装为 MCP Server 暴露给其他系统。这种灵活性让团队能够渐进式改造存量工具，而非推倒重来。
落地实践：从安装到调用
CLI-Anything 的使用流程体现了其 "零配置" 设计理念。
安装 CLI-Hub 客户端：pip install cli-anything-hub或npx skills add HKUDS/CLI-Anything --skill cli-hub-meta-skill。
浏览可用工具：cli-hub list列出注册中心的所有 CLI，cli-hub search keyword按关键词检索。每个工具条目显示名称、版本、描述、权限需求摘要。
安装并调用：cli-hub install tool-name将工具下载到本地隔离环境，Agent 随后可通过自然语言指令调用，如 "使用 ffmpeg 将 video.mp4 转为 720p"，Agent 会自动解析意图、查找匹配的 CLI、填充参数、执行命令、解析输出。
对于企业私有化部署，CLI-Anything 支持自建 Hub 实例，将内部工具注册到私有仓库。通过配置镜像源和权限策略，实现与公网 Hub 相同的使用体验，同时满足合规要求。
局限与风险
CLI 包装层架构并非万能。首先，文本解析的可靠性低于结构化 schema，复杂交互场景（如需要多轮确认、动态菜单选择的 TUI 工具）难以通过 CLI 包装优雅处理。其次，权限沙箱增加了系统调用开销，高频调用场景下性能劣于原生 MCP 的持久连接。最后，CLI-Anything 依赖上游工具的 CLI 稳定性，若工具更新导致输出格式变化，可能需要同步更新包装层。
结语
CLI-Anything 的 CLI-Hub 架构为 Agent 生态提供了一个务实的工具接入方案。它承认存量软件的现实，通过包装层而非重写的方式实现 Agent-Native 化，降低了工具集成的边际成本。在 MCP Server 尚未普及的过渡阶段，这种 "CLI 优先、MCP 兼容" 的混合策略，或许是连接传统软件世界与 Agent 未来的最优路径。
参考来源
- CLI-Anything GitHub 仓库：https://github.com/HKUDS/CLI-Anything
- CLI-Hub 注册中心：https://clianything.cc/
- The Sequence Opinion #848: The Agent's Hands: CLI or MCP? - CLI 与 MCP 架构对比分析
内容声明：本文无广告投放、无付费植入。
如有事实性问题，欢迎发送勘误至 i@hotdrydog.com。