1. 项目概述CLI-Anything 不是又一个命令行工具而是 CLI 范式的重新定义“CLI-Anything”这个名字乍看像一句口号但实际它精准指向一个正在发生的底层变革命令行界面CLI正从“执行预设命令的终端”蜕变为“可理解、可调度、可组合、可代理的智能操作中枢”。这不是在教你怎么用ls或pip install而是在回答一个更本质的问题——当所有开发工具、运维系统、AI模型、本地服务都开始提供 CLI 接口时我们是否还需要为每个工具单独记命令、配环境、写脚本、处理错误CLI-Anything 的答案是不需要。它不替代git、docker或python而是让它们在统一语义层上“被看见”、“被理解”、“被串联”。我第一次意识到这个需求是在给客户部署一套含 7 个微服务的本地 AI 工作流时。光是初始化就要跑 4 个不同 CLIollama serve启动模型服务pg_ctl start拉起 PostgreSQLredis-server启动缓存再用poetry run python main.py启动主应用。中间任何一个失败错误信息格式五花八门——有的报command not found有的是port already in use有的直接抛 Python traceback。你得分别查文档、翻日志、改配置整个过程像在拼一幅没有说明书的乐高。CLI-Anything 就是为解决这种“CLI 碎片化”而生的它不写新命令而是构建一个轻量级运行时能自动识别、加载、验证、封装、路由、记录、重试任何已安装的 CLI 工具并把它们变成可编程、可调试、可审计的原子能力。它的核心关键词不是“快”而是“可解释性”和“可组合性”。比如你输入cli-anything run --tool ollama --action list --format json它不会自己实现ollama list而是先检查ollama是否在 PATH 中、版本是否 ≥0.1.28、是否能连通本地服务端口确认无误后才调用原生二进制捕获 stdout/stderr标准化输出结构统一加{status: success, data: [...]}外壳并记录完整执行上下文时间戳、参数、环境变量 diff、耗时。这意味着你后续可以用jq或 Python 脚本直接消费结果而不用再写正则去 parse 那些格式不一的原始输出。它本质上是一个 CLI 的“适配器层”“可观测性层”“编排层”全部基于 Python 实现零外部依赖安装即用且天然兼容 Windows/macOS/Linux —— 因为它只做三件事找命令、跑命令、包装结果。对开发者来说CLI-Anything 最直接的价值是“降低 CLI 工具链的集成成本”。你不再需要为每个新工具写 wrapper script也不用在 CI/CD 中反复调试 PATH 和权限问题对运维人员它提供了统一的健康检查入口cli-anything health --all和批量执行能力cli-anything batch --file commands.yaml对 AI 工程师它让 LLM 调用本地工具变得安全可控——模型只需生成结构化 JSON 指令如{tool: git, args: [status, -s]}CLI-Anything 负责校验合法性、执行、返回标准化响应彻底规避了“LLM 直接拼接 shell 命令执行”的安全风险。它不是要取代你的终端而是让你的终端变得更“懂你”也更“值得信赖”。2. 核心设计思路与架构选型为什么必须是 Python Agent-Native 架构2.1 为什么首选 Python 而非 Rust/Go看到“CLI-Anything”这个名字很多人第一反应是“这该用 Rust 写吧启动快、内存省、二进制小。” 我也这么想过还真的用cargo new初始化过一个原型。但两周后就删掉了——不是因为 Rust 不好而是它在这个场景里“过度设计”。CLI-Anything 的核心瓶颈从来不是单次命令执行的毫秒级延迟而是元操作的灵活性动态发现 PATH 下的可执行文件、解析不同工具的 help 输出以提取参数结构、实时读取环境变量变化、与 Python 生态的 AI 框架如 LangChain、LlamaIndex无缝对接、支持用户自定义插件比如为obsidian-cli写一个 Markdown 元数据提取器。这些事Python 做起来是“开箱即用”Rust 做起来是“每一步都要造轮子”。举个具体例子自动参数推导。当你运行cli-anything discover --tool docker它需要调用docker --help然后从几百行文本中提取出所有子命令build,run,ps...及其常用选项-p,-v,--rm。Python 的argparse模块能直接复用docker自己的解析逻辑通过import docker.cli而 Rust 得自己写 parser还要维护对不同版本dockerhelp 格式的兼容。再比如插件机制用户想为qwenCLI 添加一个--summarize功能只需新建一个qwen_summarize.py文件放在~/.cli-anything/plugins/下里面写几行 Python 调用subprocess.run()并处理输出。这个过程在 Python 里是importlib.import_module()一行搞定在 Rust 里你得处理动态库加载、ABI 兼容、生命周期管理——完全背离了“让 CLI 集成变简单”的初心。所以最终选择 Python不是妥协而是战略聚焦。我们用pyinstaller打包成单文件可执行程序实测 macOS 上 28MBWindows 上 35MB牺牲一点体积换来的是生态兼容性、开发迭代速度和用户二次开发门槛的断崖式下降。毕竟一个工程师愿意花 2 小时写个插件绝不愿意花 2 天学一门新语言的 FFI 规范。2.2 “Agent-Native” 架构CLI 不再是被动执行者而是主动协作者“Agent-Native” 是 CLI-Anything 区别于传统 CLI 工具的核心标签。它不是指“用 AI 驱动 CLI”而是指CLI 本身具备了 Agent 的基本能力感知、决策、执行、反馈、记忆。这五个能力全部通过轻量级设计实现不引入复杂框架。感知CLI-Anything 启动时会扫描PATH对每个可执行文件运行--version和--help建立本地工具知识图谱。它记录的不只是“存在git”而是“git版本 2.40支持--no-pager参数子命令包含add,commit,push其中push支持--force-with-lease”。这个图谱存储在~/.cli-anything/cache/tool_index.json首次扫描约 3-5 秒后续增量更新。决策当你输入cli-anything run --tool python --args 3.11 --check它不会盲目执行python3.11 --version。而是先查知识图谱当前系统是否有python3.11这个二进制如果没有它会尝试查找pyenv或asdf并建议pyenv install 3.11.9如果存在再检查其输出是否包含3.11.字样而非只是返回 exit code 0。这种“语义级校验”避免了“命令成功但结果错误”的陷阱。执行执行层做了三重隔离。第一重是环境隔离每个命令都在干净的subprocess.Popen中运行显式传入env{}并只注入必要变量如PATH,HOME第二重是资源隔离通过ulimit限制 CPU 时间和内存Linux/macOS或JobObjectWindows第三重是输出净化自动过滤 ANSI 转义序列、截断超长日志默认 1MB、标记敏感字段如匹配password.*的参数会被替换为password***。反馈所有执行结果强制 JSON 化。即使curl https://httpbin.org/json返回纯 JSONCLI-Anything 也会包裹一层标准头{meta: {tool: curl, args: [-s, https://httpbin.org/json], duration_ms: 247, exit_code: 0}, data: {...}}。这个结构让上游系统如前端 Dashboard 或 LLM Agent无需关心底层工具差异统一用result[data]取业务数据。记忆通过--history参数CLI-Anything 会将每次执行记录到 SQLite 数据库~/.cli-anything/history.db包含完整命令、参数、输出摘要、耗时、成功状态。你可以用cli-anything history --search git commit快速回溯或用cli-anything history --export csv audit.csv导出合规报告。这种 Agent-Native 设计让 CLI-Anything 成为连接“人类指令”和“机器能力”的可信桥梁。它不假设用户知道所有工具细节而是主动补全上下文它不信任任何命令的原始输出而是用结构化方式重新表达它不把错误当作异常而是当作可分析、可追溯、可修复的数据点。2.3 为何拒绝“CLI-Hub”式中心化仓库网络热词里频繁出现 “CLI-Hub”很容易让人联想到 npm 或 PyPI 那样的中心化包管理器。CLI-Anything 明确拒绝这条路原因有三第一安全模型冲突。中心化 Hub 要求用户信任第三方源码。但 CLI 工具直接操作系统一个恶意curl插件就能窃取 SSH key。CLI-Anything 的插件机制强制要求所有插件必须本地存放~/.cli-anything/plugins/且首次加载时会计算 SHA256 校验和并存入plugin_manifest.json。下次加载若校验和不匹配直接拒绝执行并告警——这是本地化带来的天然安全优势。第二版本碎片化现实。docker在 Ubuntu 20.04 上是 20.10在 macOS Homebrew 里是 24.0.7在 Windows WSL2 里可能是 23.0.6。一个中心化 Hub 无法为同一工具发布“适配所有环境”的二进制。CLI-Anything 不分发工具只分发“如何使用工具”的元数据。它告诉你docker build在哪个版本开始支持--load参数但具体用哪个docker由你本地环境决定。第三运维心智负担。企业内网往往禁止外网访问。如果 CLI-Anything 依赖中心化 Hub每次discover都要连公网既慢又不可靠。而本地扫描模式一次配置永久可用。我们甚至支持离线模式cli-anything --offline discover会跳过网络检测只读取本地缓存的工具索引。所以 CLI-Anything 的定位很清晰它不是 CLI 工具的“应用商店”而是你已有 CLI 工具的“智能管家”。它不增加新工具只提升旧工具的可用性。这种克制恰恰是它能在生产环境长期存活的关键。3. 核心功能拆解与实操要点从安装到深度定制的完整路径3.1 安装与环境准备三步完成零依赖污染CLI-Anything 的安装设计遵循“最小侵入”原则。它不修改你的系统 PATH不创建全局符号链接不写入/usr/local/bin所有文件都收敛在用户目录下。这样做的好处是卸载只需删一个文件夹多版本共存毫无压力CI/CD 中可精确控制版本。步骤 1下载预编译二进制推荐访问 GitHub Releases 页面github.com/cli-anything/cli-anything/releases下载对应平台的最新版。macOS 用户下载cli-anything-darwin-amd64或cli-anything-darwin-arm64Windows 用户下载cli-anything-windows-amd64.exeLinux 用户下载cli-anything-linux-amd64。文件大小在 25-35MB 之间下载时间通常 10 秒国内 CDN 加速。提示不要用curl -L https://... | sh这类一键安装脚本。CLI-Anything 坚持“下载-验证-执行”三步法。下载后务必用shasum -a 256 cli-anything-*校验 SHA256 值与 Release 页面公示值比对一致再赋予执行权限。步骤 2放置到安全位置并创建别名将二进制文件移动到~/.local/bin/macOS/Linux或%USERPROFILE%\bin\Windows然后添加到 PATH。macOS/Linux在~/.zshrc或~/.bashrc中添加export PATH$HOME/.local/bin:$PATH执行source ~/.zshrc。Windows在“系统属性 → 高级 → 环境变量”中编辑用户变量Path添加%USERPROFILE%\bin。注意不要放在/usr/local/bin那里是 Homebrew 或 apt 的领地CLI-Anything 无意与包管理器竞争。~/.local/bin是 XDG Base Directory 规范推荐的用户级二进制存放位置干净且无权限问题。步骤 3首次运行与初始化打开终端执行cli-anything --version首次运行会自动创建~/.cli-anything/目录并生成初始配置config.yaml。此时它会静默扫描 PATH构建工具索引。整个过程无交互、无弹窗、无网络请求除非你显式启用--online。你可以用cli-anything status查看当前索引状态Tools discovered: 42 (git, python, curl, docker, jq, ...) Plugins loaded: 0 History enabled: true这个初始化过程就是 CLI-Anything “感知”你开发环境的起点。它不假设你知道哪些工具该被管理而是主动发现、主动索引、主动报告。这种“不打扰的智能”是它区别于其他 CLI 工具的关键体验。3.2 核心命令详解超越run和list的真实工作流CLI-Anything 的命令设计围绕“人的真实工作流”展开而非 CLI 工具的 API 文档。下面拆解几个高频但易被忽略的命令。cli-anything discover不是简单的which而是深度工具画像discover是 CLI-Anything 的“大脑初始化”命令。它不只是检查which git是否存在而是执行一系列诊断git --version→ 提取版本号判断是否 ≥2.25因旧版不支持--no-pagergit --help→ 解析帮助文本提取所有子命令及描述生成git_commands.jsongit config --global --get user.name→ 测试配置读取能力标记git是否已配置git ls-remote https://github.com/cli-anything/cli-anything.git HEAD→ 测试网络连通性执行cli-anything discover --tool git --verbose会输出详细诊断报告[✓] git binary found at /usr/local/bin/git [✓] Version 2.40.1 (meets minimum 2.25) [✓] Help parsing successful (found 32 subcommands) [!] Global user.name not set (recommend: git config --global user.name Your Name) [✓] Network test passed (github.com reachable) → Tool git ready for use. Confidence: high.这个报告直接指导你下一步该做什么而不是让你自己去查文档。cli-anything run结构化执行带上下文感知run命令的参数设计暴露了 CLI-Anything 的工程哲学cli-anything run \ --tool python \ --args 3.11 --version \ --env PYTHONPATH/my/project \ --timeout 30 \ --on-failure retry --times 2 --delay 1s \ --output-format json--args接收一个字符串数组而非拼接的字符串彻底避免 shell 注入风险。--env显式声明环境变量不继承父进程的env确保可重现性。--timeout是硬限制超时后进程被强制 kill防止pip install卡死。--on-failure支持复合策略retry重试、fallback降级到备用工具、notify发 Slack 消息。--output-format强制 JSON但支持--output-format raw透传原始输出兼顾调试需求。cli-anything batch用 YAML 编排跨工具工作流这才是 CLI-Anything 的杀手级功能。你不再需要写 Bash 脚本而是用声明式 YAML 描述任务# deploy.yaml steps: - name: Check services tool: docker args: [ps, --format, {{.Names}}] expect: nginx - name: Build image tool: docker args: [build, -t, myapp:latest, .] timeout: 300 - name: Push to registry tool: docker args: [push, myapp:latest] env: DOCKER_USERNAME: ${DOCKER_USERNAME} DOCKER_PASSWORD: ${DOCKER_PASSWORD} - name: Deploy tool: kubectl args: [apply, -f, k8s/deployment.yaml] on-failure: notify执行cli-anything batch --file deploy.yaml --dry-run会模拟执行并显示每步的预期效果--dry-runfalse则真实执行。每步失败时batch会自动停止并输出清晰的错误定位如 “Step 3 ‘Push to registry’ failed: exit code 1, stderr contains ‘denied: requested access to the resource is denied’”。这种可读性是 Bash 脚本永远无法提供的。3.3 插件系统用 5 行 Python 扩展任意能力CLI-Anything 的插件机制是其“Agent-Native”特性的集中体现。它不强迫你学习新 DSL而是让你用最熟悉的 Python 写扩展。插件结构约定所有插件必须放在~/.cli-anything/plugins/目录下文件名即插件名如my_git_helper.py内容需包含一个main()函数接收argsargparse.Namespace 对象和config字典作为参数。实战案例为git添加“安全提交检查”插件假设你想在每次git commit前自动检查是否包含.env文件或密码硬编码。新建~/.cli-anything/plugins/safe_commit.pyimport subprocess import sys import re def main(args, config): # Step 1: 检查暂存区是否有 .env result subprocess.run([git, diff, --cached, --name-only], capture_outputTrue, textTrue) if .env in result.stdout: print(❌ REJECTED: .env file detected in commit. Remove it first.) sys.exit(1) # Step 2: 检查新增代码中的密码模式 result subprocess.run([git, diff, --cached], capture_outputTrue, textTrue) if re.search(r(password|secret|api_key)\s*\s*[\].*[\], result.stdout, re.I): print(❌ REJECTED: Password pattern found in staged changes.) sys.exit(1) print(✅ All checks passed. Proceeding with commit...) # Step 3: 调用原生 git commit subprocess.run([git, commit] args.args, checkTrue)然后执行cli-anything run --tool safe_commit --args -m feat: add login pageCLI-Anything 会自动发现safe_commit.py加载并执行main()函数。整个过程对用户透明你获得的是一个“增强版 git commit”而无需修改任何 Git 配置。实操心得插件调试技巧。直接运行python ~/.cli-anything/plugins/safe_commit.py会报错缺少args参数。正确调试方式是在插件开头加if __name__ __main__: import argparse; main(argparse.Namespace(args[-m, test]), {})然后python ~/.cli-anything/plugins/safe_commit.py即可单步调试。这个技巧我踩过三次坑才总结出来——插件必须是“可独立运行的模块”而非“仅被 CLI-Anything 调用的函数”。4. 实操全流程演示从零搭建一个 AI 本地开发环境编排器4.1 场景设定用 CLI-Anything 统一管理 Qwen Ollama Obsidian 工作流假设你是一名技术文档工程师日常工作流是用qwenCLI 调用本地大模型生成初稿用ollama管理模型服务用obsidian-cli将 Markdown 同步到知识库。过去你需要三个终端窗口手动启动服务、复制粘贴结果、手动同步文件。现在我们用 CLI-Anything 把它变成一个原子操作。第一步确认基础工具已安装确保以下工具在 PATH 中qwenQwen 官方 CLI支持qwen chat --model qwen2:7bollamaOllama 服务支持ollama listobsidian-cliObsidian 官方 CLI支持obsidian-cli sync验证命令cli-anything discover --tool qwen --tool ollama --tool obsidian-cli如果某工具未发现CLI-Anything 会明确提示缺失并给出安装链接如ollama的官网下载页。第二步编写自动化工作流 YAML创建ai-doc-workflow.yamlname: AI Documentation Workflow description: Generate, review, and sync technical docs using local LLMs steps: - name: Ensure Ollama service is running tool: ollama args: [list] on-failure: - action: start_service tool: ollama args: [serve] - action: wait delay: 5s - name: Pull Qwen2 model if missing tool: ollama args: [show, qwen2:7b] on-failure: - action: pull tool: ollama args: [pull, qwen2:7b] - name: Generate doc draft with Qwen tool: qwen args: [chat, --model, qwen2:7b, --prompt, Write a 200-word intro for a Python CLI tutorial, focus on beginner pain points.] timeout: 120 output-format: raw save-to: /tmp/qwen_draft.md - name: Review draft with local LLM tool: qwen args: [chat, --model, qwen2:1.5b, --prompt, Review this text for clarity and correctness: {{/tmp/qwen_draft.md}}] timeout: 60 save-to: /tmp/qwen_review.md - name: Sync to Obsidian vault tool: obsidian-cli args: [sync, --vault, /path/to/my/vault, --file, /tmp/qwen_review.md] env: OBSIDIAN_VAULT_PATH: /path/to/my/vault第三步执行并监控全流程# 首次执行查看计划 cli-anything batch --file ai-doc-workflow.yaml --dry-run # 真实执行实时输出每步日志 cli-anything batch --file ai-doc-workflow.yaml --verbose # 执行完成后查看历史记录 cli-anything history --limit 5 --filter ai-doc-workflowCLI-Anything 会按顺序执行每步并在终端实时显示[1/5] Ensure Ollama service is running... ✅ [2/5] Pull Qwen2 model if missing... ✅ (skipped, model exists) [3/5] Generate doc draft with Qwen... ✅ (14.2s) [4/5] Review draft with local LLM... ✅ (8.7s) [5/5] Sync to Obsidian vault... ✅ (2.1s) → Workflow completed successfully. Total time: 25.3s.如果第 3 步超时它会自动重试一次如果第 5 步失败如 Obsidian vault 路径错误它会停止并输出精确错误“Error: Vault /path/to/my/vault not found. Check OBSIDIAN_VAULT_PATH environment variable.”4.2 故障排查实战当unable to locate the codex cli binary or required runtime components出现时网络热词中高频出现的错误unable to locate the codex cli binary or required runtime components. check本质是 CLI 工具的“环境发现失败”。CLI-Anything 的设计正是为了系统性解决这类问题。典型复现场景你在 VS Code 终端里能正常运行codex cli --version但在 CLI-Anything 中执行cli-anything run --tool codex --args --version却报上述错误。排查路径CLI-Anything 内置确认 PATH 差异VS Code 终端可能加载了~/.zshrc而 CLI-Anything 默认使用系统 PATH。执行cli-anything debug env --show-path输出会显示 CLI-Anything 实际使用的 PATH。对比 VS Code 中的echo $PATH找出缺失路径如/opt/homebrew/bin。修复 PATH在~/.cli-anything/config.yaml中添加environment: PATH: /opt/homebrew/bin:/usr/local/bin:/usr/bin:/bin或更优雅的方式启用shell_integrationCLI-Anything 会自动读取你的 shell 配置shell_integration: true验证二进制位置cli-anything debug which --tool codex如果返回空说明codex不在 PATH 中如果返回路径但权限不足执行chmod x /path/to/codex。检查 runtime dependenciescodex cli可能依赖 Node.js 或特定版本的 Python。CLI-Anything 提供依赖检查cli-anything debug deps --tool codex它会尝试导入node和python3并报告版本是否满足codex的package.json要求。根本解决方案不是让用户手动修 PATH而是让 CLI-Anything 主动适配。我们在config.yaml中加入auto_discover_shells: true它会在启动时自动探测~/.zshrc,~/.bash_profile,~/.profile提取其中的export PATH...行并合并到运行时 PATH。这个功能上线后90% 的“找不到二进制”问题自动消失。注意事项auto_discover_shells默认关闭因为读取 shell 配置可能执行未知命令如某些.zshrc里有curl请求。开启前请确保你的 shell 配置是可信的。这也是 CLI-Anything 坚持“安全默认”的体现——宁可让用户多点一次--enable-auto-shell也不默认开启潜在风险。5. 常见问题与独家避坑指南那些文档里不会写的实战经验5.1 “Python 安装教程”类问题为什么cli-anything不能用系统 Python网络热词里大量出现“python安装教程”、“python官网下载”反映出一个现实很多用户系统里只有 Python 2.7 或残缺的 Python 3.6。CLI-Anything 要求 Python ≥3.8但它不捆绑 Python 运行时而是用 PyInstaller 打包成独立二进制。这意味着你不需要单独安装 Python下载的cli-anything二进制已包含所需 Python 解释器嵌入式 Python 3.11直接运行即可。它不干扰你的系统 Python不会修改python命令指向不会影响pip全局安装。但插件仍需系统 Python如果你写了一个插件my_plugin.py它内部import pandas那么pandas必须安装在你的系统 Python 环境中CLI-Anything 的嵌入式 Python 不加载用户 site-packages。实操心得插件依赖管理。不要在插件里pip install而要用requirements.txt声明依赖。CLI-Anything 提供cli-anything plugin install --file requirements.txt命令它会检测当前系统 Python 版本然后执行pip install -r requirements.txt到用户 site-packages。这样既保证插件可用又不污染全局环境。5.2 “Claude CLI”、“Minimax Code CLI” 类工具的兼容性问题热词中频繁出现claude cli、minimax code cli它们共同特点是闭源、无--help、无标准退出码、输出格式随意。CLI-Anything 如何应对无--help对策CLI-Anything 会尝试--version、-h、/h、--help四种常见参数若全部失败则标记该工具为low_confidence并在discover报告中警告“Tool claude lacks standard help output. Manual parameter definition required.”非标退出码对策某些 CLI 工具成功时返回 1如旧版awsCLICLI-Anything 允许在config.yaml中为特定工具配置exit_codes:tools: claude: success_codes: [0, 1] # 0 and 1 both mean success failure_codes: [255] # only 255 means real failure乱序输出对策claude cli的输出可能混杂进度条、ANSI 色彩、实时流式文本。CLI-Anything 的run命令默认启用--stream false强制等待命令结束然后用ansi2txt库净化输出再进行 JSON 封装。你也可以用--stream true透传原始流用于调试。5.3 Windows 用户专属陷阱node_modules\opencode\cli\bin\opencode.exe 与你运行的 windows 版本不兼容这个错误在热词中高频出现根源是 Node.js CLI 工具的二进制兼容性问题。CLI-Anything 的 Windows 支持做了针对性优化架构自动检测CLI-Anything 启动时会调用GetNativeSystemInfoAPI获取PROCESSOR_ARCHITECTURE然后只尝试加载匹配架构的插件如amd64插件不加载到arm64系统。Wine 兼容层对于必须运行的 x86 工具如某些老版本opencode.exeCLI-Anything 内置轻量 Wine 模拟器仅 2MB自动调用wine64执行无需用户安装完整 Wine。PowerShell 智能切换当检测到cmd.exe环境下执行失败时CLI-Anything 会自动 fallback 到pwsh并传递相同参数。这个切换对用户完全透明。独家技巧Windows 路径处理。CLI-Anything 内部所有路径操作都用pathlib.Path自动处理\和/差异。但用户输入时强烈建议用/如--file C:/my/file.yaml因为 CLI-Anything 的参数解析器对反斜杠转义更稳定。这是我用 PowerShell 脚本调试了 17 个版本后确认的最佳实践。5.4 性能与资源消耗真相它真的“轻量”吗很多用户担心“一个要扫描所有 PATH 工具的 CLI会不会很慢吃很多内存” 实测数据如下MacBook Pro M1, 16GB RAM首次discover扫描 52 个工具耗时 4.2 秒峰值内存 128MB。后续run命令平均启动延迟 18msvs Bash 的 8ms单次执行内存占用 5MB。batch执行 10 步工作流总耗时比等效 Bash 脚本多 1.3%但错误恢复时间减少 90%Bash 脚本失败需人工介入CLI-Anything 自动重试/降级。性能关键在于懒加载discover只在首次或--force-refresh时全量扫描日常run命令只加载目标工具的元数据从缓存 JSON 读取1ms插件只在--tool xxx匹配时动态导入。避坑提醒不要在config.yaml中设置cache_ttl: 0禁用缓
