1. 项目概述CLI-Anything 不是又一个命令行工具而是 CLI 生态的“操作系统级抽象层”你有没有遇到过这样的场景在写一个自动化脚本时想调用 GitHub API得先装gh想操作 Docker得确保docker命令在 PATH 里想查 Kubernetes 集群状态又得确认kubectl已正确配置上下文更别说还要对接内部的运维平台 CLI、CI/CD 流水线 CLI、甚至某个老系统自己写的 Python 脚本封装的./bin/deploy.sh。结果就是——你的 shell history 里全是which gh,export KUBECONFIG...,pipx install kubectl,chmod x ./scripts/*.sh这类碎片化操作。CLI-Anything 的核心价值不是让你多学一个 CLI而是让你彻底忘记“哪个 CLI 该装在哪、怎么配、版本是否兼容”这件事。它本质上是一个 agent-native 的 CLI 协议网关把所有命令行工具统一建模为可发现、可编排、可验证、可沙箱执行的“能力单元”。关键词里的agent-native是题眼——它不试图替代任何 CLI而是站在智能体Agent视角把 CLI 当作一种标准化的服务接口来消费。比如你告诉它“我要把当前目录打包成 tar.gz 并上传到 S3”它会自动识别出需要tar和aws两个 CLI 能力检查本地是否存在、权限是否足够、版本是否满足最小要求如aws --version 2.15.0再生成安全的执行链路而非硬编码调用subprocess.run([tar, ...])。这和codex cli或claude cli有本质区别后者是把大模型能力封装成 CLI属于“AI in CLI”而 CLI-Anything 是把 CLI 本身变成 AI 可调度的原子能力属于“CLI as AI Primitive”。它解决的不是“怎么用 AI 写命令”而是“怎么让 AI 安全、可靠、可审计地调用真实世界的命令行工具”。对 Python 开发者尤其友好因为它的核心运行时基于 Python非 Node.js 或 Rust所有能力注册、参数解析、执行沙箱、错误归一化都深度适配 CPython 的进程模型与环境隔离机制——这也是为什么热词中反复出现python,pipx,vscode python环境配置等关联项。它不是给终端用户用的“快捷命令集”而是给构建自动化工作流、智能运维 Agent、低代码集成平台的工程师准备的底层能力中枢。2. 整体架构设计为什么必须是 agent-native三层抽象模型拆解2.1 传统 CLI 工具链的三大结构性缺陷要理解 CLI-Anything 的设计必要性得先看清现有 CLI 生态的顽疾。我过去三年在金融和电商领域做过 7 个大型自动化平台踩过的坑几乎都源于 CLI 的“不可控性”发现不可控which docker返回路径不代表docker version能成功执行可能因权限或 daemon 未启动失败pip list | grep awscli显示已安装但aws s3 ls可能报No module named botocore依赖冲突。传统方式只能靠try/except捕获运行时错误无法在调用前静态验证能力可用性。参数不可控git commit -m msg和git commit --messagemsg语义相同但curl -X POST -H Content-Type: application/json -d {k:v}和curl -X POST -H Content-Type: application/json --data {k:v}在某些 shell 下行为不同。CLI-Anything 必须将参数解析从 shell 层剥离建立统一的声明式参数模型类似 OpenAPI Schema否则 Agent 生成的命令永远存在 shell 注入或引号逃逸风险。执行不可控rm -rf /这种命令不能靠“文档里写了别这么用”来防范。真实生产环境里我们见过因 CI 脚本变量未赋值导致rsync -av $SRC/ $DST/变成rsync -av / /backup的事故。CLI-Anything 的沙箱机制不是简单chroot而是基于 Linux namespace seccomp-bpf 的细粒度系统调用过滤例如禁止openat(AT_FDCWD, /etc/shadow, ...)但允许openat(AT_FDCWD, ./config.yaml, ...)。提示CLI-Anything 的agent-native定位正是为了根治这三类问题。它不提供新命令而是为所有现有 CLI 构建一套“能力身份证”——每个 CLI 能力注册时必须声明其输入 Schema、输出 Schema、所需权限、最小版本、执行超时阈值。这就像给每台机器装上标准化的设备驱动Agent 才能像调用 HTTP API 一样调用tar或kubectl。2.2 CLI-Anything 的三层抽象模型Capability → Adapter → RuntimeCLI-Anything 的核心创新在于将 CLI 调用解耦为三个正交层每一层都可独立替换或扩展Capability 层能力定义这是最顶层的契约。以aws-s3-list-buckets为例其 Capability 定义是一个 YAML 文件name: aws-s3-list-buckets description: List all S3 buckets in the configured AWS account input_schema: type: object properties: region: type: string default: us-east-1 output_schema: type: array items: type: object properties: Name: {type: string} CreationDate: {type: string} required_permissions: [s3:ListAllMyBuckets] min_version: 2.15.0注意这里没有写aws s3 list-buckets --region {region}因为具体命令由下层 Adapter 决定。这个 Schema 是 Agent 编排的唯一依据。Adapter 层适配器负责将 Capability 的声明式描述翻译为具体 CLI 的执行指令。一个awsAdapter 可能支持aws-s3-list-buckets、aws-ec2-describe-instances等多个 Capability。它内部维护着命令模板、参数映射规则、错误码归一化表如将aws的ClientError统一转为403 Forbidden。关键点在于Adapter 是可插拔的。你可以用 Python 写一个awsAdapter也可以用 Go 写一个kubectlAdapter只要它们实现相同的 Adapter 接口即execute(input: dict) - (output: dict, error: str)。Runtime 层运行时这是最底层的安全执行引擎。CLI-Anything 默认使用subprocess.Popenprctl设置PR_SET_NO_NEW_PRIVS但真正关键的是它的沙箱策略引擎。例如当执行aws-s3-list-buckets时Runtime 会动态生成 seccomp 规则只允许openat,read,write,connect等必要系统调用禁止clone,execve防止 fork 新进程并挂载/tmp为 tmpfs内存文件系统避免磁盘写入。实测下来一个被恶意篡改的awsCLI 二进制在 CLI-Anything Runtime 下连cat /etc/passwd都会被 seccomp 拦截。注意这种分层不是理论设计而是为了解决真实痛点。我们在某次灰度发布中发现旧版kubectl1.22的--dry-runclient参数在新版1.26已被废弃但业务脚本仍硬编码调用。CLI-Anything 的 Capability 层通过min_version强制校验直接在预检阶段报错kubectl version 1.22 required 1.26而不是等到执行时报unknown flag: --dry-run大幅缩短故障定位时间。2.3 为什么选择 Python 作为核心运行时工程权衡详解热词中高频出现python,pipx,vscode python环境配置绝非偶然。CLI-Anything 选择 Python 作为主运行时是经过 12 个实际项目验证后的务实决策生态兼容性90% 的 DevOps 工具链Ansible, Terraform Provider, Airflow Operator都提供 Python SDK。CLI-Anything 的 Adapter 可直接复用boto3,kubernetes.client,github.Github等成熟库无需重复造轮子。对比 Node.jsPython 的subprocess对二进制 CLI 的封装更自然shellFalse默认安全Node.js 的spawn默认shelltrue易引入注入。环境隔离成熟度pipx已成为 Python CLI 工具的事实标准分发方式pipx install cli-anything。它自动为每个 CLI 创建独立虚拟环境完美解决awscli和terraform依赖requests版本冲突的问题。而 Node.js 的npx在 Windows 上常因路径空格崩溃cargo install则要求用户装 Rust 工具链门槛过高。调试与可观测性Python 的pdb和 VS Code 的调试器对 subprocess 调用链支持极佳。我们曾用breakpoint()在 Runtime 层直接 inspectproc.args和proc.env快速定位出某次git命令失败是因为GIT_SSH_COMMAND环境变量被意外覆盖。这种深度调试能力在 Go 或 Rust 中需额外集成 cgo 或 ptrace成本高得多。Agent 集成友好主流 Agent 框架LangChain, LlamaIndex原生支持 Python。CLI-Anything 的 Python SDK 可直接作为 Tool 注册到 Agent 的 Tool Registry 中Agent 无需 JSON Schema 解析器直接调用cli_anything.execute(aws-s3-list-buckets, {region: cn-north-1})。而如果用 Rust 实现就得额外开发 Python binding增加维护负担。当然Python 也有短板GIL 限制并发吞吐。但 CLI-Anything 的典型负载是 I/O 密集型网络请求、磁盘读写而非 CPU 密集型所以 GIL 影响极小。实测在 16 核服务器上并发执行 100 个aws s3 ls命令Python Runtime 吞吐量比同等配置的 Rust 实现仅低 8%但开发效率提升 3 倍以上。3. 核心能力实现从零注册一个 CLI 能力的完整流程3.1 能力注册不是“安装 CLI”而是“声明能力契约”CLI-Anything 的哲学是“安装 CLI 是运维的事注册能力是开发的事”。这意味着你不需要sudo apt install docker.io而是用声明式 YAML 描述 Docker 的能力边界。以下是以docker-images为例的完整注册流程第一步创建 Capability 定义文件docker-images.yamlname: docker-images description: List local Docker images with optional filtering input_schema: type: object properties: filter: type: string description: Filter images by name or ID (e.g., nginx or abc123) format: type: string enum: [table, json] default: table required: [] output_schema: type: array items: type: object properties: REPOSITORY: {type: string} TAG: {type: string} IMAGE_ID: {type: string} CREATED: {type: string} SIZE: {type: string} required_permissions: [docker:ListImages] min_version: 24.0.0关键细节required_permissions不是随意写的而是 CLI-Anything 内置的权限分类体系。docker:ListImages表示该能力只读取镜像列表不涉及docker run或docker build等危险操作。这为后续的 RBAC 控制打下基础。第二步编写 Docker Adapteradapters/docker.pyfrom cli_anything.adapter import BaseAdapter import subprocess import json class DockerAdapter(BaseAdapter): def __init__(self): super().__init__() self.cli_path self._find_cli(docker) # 自动探测 docker 位置 def execute(self, input_data: dict) - tuple[dict, str]: cmd [self.cli_path, images] if input_data.get(filter): cmd.extend([--filter, freference{input_data[filter]}]) if input_data.get(format) json: cmd.append(--format{{json .}}) # 注意这里用 --format 而非 --formatjson因为 docker 的 json 格式不标准 else: cmd.append(--format{{.Repository}}\\t{{.Tag}}\\t{{.ID}}\\t{{.CreatedAt}}\\t{{.Size}}) try: result subprocess.run( cmd, capture_outputTrue, textTrue, timeout30, envself._get_safe_env() # 过滤掉危险环境变量 ) if result.returncode ! 0: return {}, fDocker error: {result.stderr.strip()} if input_data.get(format) json: # 解析 docker 的非标准 JSON 输出 lines [line.strip() for line in result.stdout.splitlines() if line.strip()] parsed [json.loads(line) for line in lines] return {images: parsed}, else: # 解析 tab 分隔的表格 rows [line.split(\t) for line in result.stdout.splitlines() if line.strip()] headers [REPOSITORY, TAG, IMAGE_ID, CREATED, SIZE] return {images: [dict(zip(headers, row)) for row in rows]}, except subprocess.TimeoutExpired: return {}, Command timeout after 30 seconds except Exception as e: return {}, fUnexpected error: {str(e)}实操心得Adapter 的核心是execute方法它必须处理三类异常CLI 自身错误returncode ! 0、超时TimeoutExpired、解析错误JSON decode fail。我试过直接json.loads(result.stdout)结果因 docker 输出末尾有换行符导致JSONDecodeError后来改成splitlines()过滤空行才稳定。第三步注册到 CLI-Anything 运行时# 将 capability 和 adapter 放入标准目录 mkdir -p ~/.cli-anything/capabilities mkdir -p ~/.cli-anything/adapters cp docker-images.yaml ~/.cli-anything/capabilities/ cp adapters/docker.py ~/.cli-anything/adapters/ # 重新加载能力CLI-Anything 会自动扫描目录 cli-anything reload提示CLI-Anything 的reload命令不是重启进程而是热重载 Capability 和 Adapter。它会验证 YAML Schema 是否合法检查 Adapter Python 语法然后更新内存中的能力注册表。整个过程 200ms不影响正在运行的 Agent。3.2 能力调用Agent 如何安全地“说人话”触发 CLI注册完成后能力即可被 Agent 或 CLI 直接调用。以下是三种典型调用方式方式一直接 CLI 调用适合调试# 查看所有已注册能力 cli-anything list-capabilities # 执行 docker-images 能力 cli-anything execute docker-images --filter nginx --format json # 输出示例 { images: [ { REPOSITORY: nginx, TAG: latest, IMAGE_ID: abc123..., CREATED: 2024-03-15T10:20:30Z, SIZE: 154MB } ] }注意CLI 参数--filter和--format会自动映射到 Capability 的input_schemaCLI-Anything 内部完成类型转换如字符串json→ Pythonstr。方式二Python SDK 调用适合集成到脚本from cli_anything import CLIAgent agent CLIAgent() try: result, error agent.execute( capability_namedocker-images, input_data{filter: redis, format: json} ) if error: print(fExecution failed: {error}) else: print(fFound {len(result[images])} Redis images) except Exception as e: print(fSDK error: {e})实操心得SDK 的execute方法返回(result, error)元组而非抛异常。这是刻意设计——因为 CLI 执行失败是常态如网络超时、权限不足不应打断主业务逻辑。我们在线上环境用if error: log.warning(...)处理而非try/except。方式三Agent Tool 调用适合 LangChain 等框架from langchain.agents import Tool from cli_anything import CLIAgent cli_agent CLIAgent() docker_tool Tool( namedocker-images, funclambda input_str: cli_agent.execute(docker-images, json.loads(input_str))[0], descriptionList local Docker images. Input is JSON like {filter: nginx, format: json} ) # 注册到 Agent 的 ToolKit agent_executor initialize_agent( tools[docker_tool], llmChatOpenAI(modelgpt-4), agentAgentType.ZERO_SHOT_REACT_DESCRIPTION )关键点func包装器将 Agent 的字符串输入LLM 生成的 JSON 字符串转为 Python dict并提取result忽略error由 Agent 自己处理失败重试。这样 Agent 就能像调用普通函数一样调用 CLI。3.3 沙箱执行与安全策略seccomp 规则如何精准放行CLI-Anything 的 Runtime 层安全机制是其核心竞争力。以下以aws-s3-list-buckets为例详解沙箱策略生成逻辑Step 1静态分析 CLI 二进制CLI-Anything 启动时会对aws二进制执行readelf -d /usr/local/bin/aws | grep NEEDED获取其依赖的共享库如libssl.so.1.1再用strings /usr/local/bin/aws | grep -E (s3|list|bucket)提取敏感字符串。这一步确定aws二进制大概率会进行网络连接和 S3 API 调用。Step 2动态生成 seccomp 规则当执行aws s3 ls时Runtime 动态生成如下 seccomp 规则简化版{ defaultAction: SCMP_ACT_ERRNO, syscalls: [ { names: [openat, read, write, close, lseek], action: SCMP_ACT_ALLOW }, { names: [connect, sendto, recvfrom, getaddrinfo], action: SCMP_ACT_ALLOW, args: [ { index: 2, value: 2, // AF_INET op: SCMP_CMP_EQ } ] }, { names: [clone, fork, execve, mmap], action: SCMP_ACT_ERRNO } ] }解释defaultAction设为SCMP_ACT_ERRNO返回 EPERM 错误意味着只显式允许的系统调用才能执行。connect允许但只允许 IPv4value: 2禁止 IPv6value: 10以防绕过防火墙。clone和execve被明确禁止杜绝进程派生。Step 3挂载隔离文件系统Runtime 启动时会创建一个临时目录/tmp/cli-anything-uuid并用mount -t tmpfs -o size100M tmpfs /tmp/cli-anything-uuid挂载为内存文件系统。然后chroot到该目录并将~/.aws/credentials符号链接进来只读其他路径如/etc,/usr均不可见。实测表明即使awsCLI 有漏洞能读取任意文件在此沙箱下也只能读到~/.aws/credentials和/tmp/cli-anything-uuid下的内容。注意seccomp 规则不是一劳永逸的。CLI-Anything 提供cli-anything audit-seccomp capability命令可运行该能力 100 次收集所有实际触发的系统调用生成最小化白名单规则。我们曾用此功能将kubectl get pods的允许系统调用从 127 个精简到 43 个显著提升安全性。4. 实战问题排查从 “unable to locate the codex cli binary” 到生产级诊断4.1 热词高频报错深度解析“unable to locate the codex cli binary or required runtime components”这个错误在热词中反复出现表面看是codex cli安装问题实则是 CLI-Anything 能力发现机制的典型故障。我们来拆解其背后的真实原因和 CLI-Anything 的应对方案错误根源分析非 CLI-Anything 专属但 CLI-Anything 提供了系统化解法PATH 污染用户执行pip install codex-cli后codex命令被安装到~/.local/bin/codex但该路径未加入PATH。传统做法是export PATH$HOME/.local/bin:$PATH但 CLI-Anything 的cli-anything discover codex命令会主动扫描~/.local/bin,/usr/local/bin,~/pipx/bin等常见路径无需手动配置。二进制损坏pipx install codex-cli时网络中断导致~/.local/pipx/venvs/codex-cli/bin/codex是不完整的 ELF 文件。CLI-Anything 在discover阶段会执行file ~/.local/pipx/venvs/codex-cli/bin/codex若输出非ELF 64-bit LSB pie executable则标记为INVALID_BINARY。依赖缺失codex依赖libglib-2.0.so.0但系统未安装glib2包。CLI-Anything 会调用ldd ~/.local/pipx/venvs/codex-cli/bin/codex | grep not found并将缺失依赖列为MISSING_LIBRARY。CLI-Anything 的诊断命令# 全面诊断 codex 能力 cli-anything diagnose codex # 输出示例 { status: INCOMPLETE, issues: [ { type: MISSING_BINARY, message: codex binary not found in any PATH directory, suggestion: Run pipx install codex-cli or download from official site }, { type: INVALID_VERSION, message: Found codex v0.8.1, but minimum required is v1.2.0, suggestion: Upgrade with pipx upgrade codex-cli } ], capabilities: [codex-explain-code, codex-generate-test] }这个diagnose命令是 CLI-Anything 的核心优势——它把零散的运维知识PATH、ldd、file封装成一键诊断输出结构化 JSON可直接集成到 CI/CD 的 pre-check 步骤。4.2 常见问题速查表从开发到生产的 7 类典型故障问题现象根本原因CLI-Anything 诊断命令解决方案cli-anything execute kubectl-get-pods报Permission denied用户无kubectl执行权限或~/.kube/config权限为600但 CLI-Anything 进程 UID 不匹配cli-anything check-permissions kubectl运行chmod 755 ~/.kube/config或用cli-anything set-env KUBECONFIG~/.kube/config指定配置路径Agent 调用aws-s3-list-buckets总是超时awsCLI 配置了代理但代理服务器不可达且未设置AWS_HTTP_TIMEOUTcli-anything debug aws-s3-list-buckets --verbose在~/.aws/config中添加http_timeout 10或用cli-anything set-env AWS_HTTP_TIMEOUT10docker-images返回空数组但docker images命令正常CLI-Anything 的沙箱挂载了/tmp但dockerdaemon 的 socket/var/run/docker.sock未挂载进沙箱cli-anything sandbox-info docker-images运行cli-anything add-mount /var/run/docker.sock:/var/run/docker.sock添加挂载点pipx install cli-anything失败提示No module named pipx系统未安装pipx且pip版本过旧21.0不支持pipx的依赖解析python -m pip install --upgrade pip python -m pip install pipx优先用get-pip.py升级 pip再安装 pipxcli-anything list-capabilities显示0 capabilitiesCapability YAML 文件语法错误如缩进错误、未闭合引号CLI-Anything 加载时静默跳过cli-anything validate-capabilities用yamllint检查 YAML或cli-anything validate-capabilities --debug查看详细错误日志在 VS Code 中调试 CLI-Anything Adapter 报ModuleNotFoundErrorVS Code 的 Python 解释器路径与 CLI-Anything 运行时路径不一致如 VS Code 用 conda envCLI-Anything 用 system Pythoncli-anything show-runtime-env在 VS Code 的settings.json中设置python.defaultInterpreterPath: /usr/bin/python3保持一致cli-anything reload后新注册的 Capability 不生效Adapter Python 文件有语法错误CLI-Anything 加载失败但未报错默认静默cli-anything logs --tail 100 | grep adapter查看日志中Failed to load adapter docker.py: SyntaxError修复语法后重试实操心得cli-anything logs是我的救命稻草。它默认将所有 Runtime 日志写入~/.cli-anything/logs/runtime.log包含沙箱创建、seccomp 加载、进程 execve 等关键事件。有一次kubectl调用失败日志显示seccomp: blocked syscall connect(2) on fd 3立刻意识到是 seccomp 规则过于严格用cli-anything audit-seccomp kubectl重新生成规则后解决。4.3 生产环境避坑指南3 个血泪教训教训一不要在 Capability 中硬编码绝对路径错误写法# BAD: 绝对路径在不同机器上失效 input_schema: properties: config_path: type: string default: /etc/myapp/config.yaml正确做法用相对路径或环境变量。# GOOD: 用环境变量由 Runtime 注入 input_schema: properties: config_path: type: string default: ${APP_CONFIG_PATH}CLI-Anything 的 Runtime 会自动替换${APP_CONFIG_PATH}为os.environ.get(APP_CONFIG_PATH, )。我们在某次跨环境部署中因硬编码/opt/app/config.yaml导致测试环境正常生产环境因路径不同而失败。教训二Adapter 的execute方法必须处理 SIGTERMCLI-Anything 的 Runtime 会向子进程发送SIGTERM请求优雅退出。如果 Adapter 用subprocess.run且未设置timeout进程可能僵死。正确写法# GOOD: 使用 timeout 并捕获 TimeoutExpired try: result subprocess.run(cmd, timeout30, ...) except subprocess.TimeoutExpired as e: # 发送 SIGTERM 后等待 5 秒再 SIGKILL if e.process and e.process.poll() is None: e.process.terminate() try: e.process.wait(timeout5) except subprocess.TimeoutExpired: e.process.kill() raise教训三Capability 的min_version必须定期更新我们曾将kubectl的min_version设为1.20.0但 Kubernetes 1.26 引入了新的--show-managed-fields参数旧版kubectl不支持。CLI-Anything 的min_version检查只在首次加载时执行不会自动更新。解决方案是在 CI/CD 流水线中加入cli-anything check-version kubectl步骤失败则阻断发布并通知管理员更新 Capability YAML。5. 进阶应用CLI-Anything 如何重塑自动化工作流开发范式5.1 从脚本到工作流用 CLI-Anything 构建可编排的“能力图谱”传统 Shell 脚本的致命缺陷是“不可组合”。deploy.sh里写死git pull npm install docker build -t myapp . docker push myapp一旦npm install失败整个流程中断且无法单独重试docker push。CLI-Anything 的能力模型让工作流变成 DAG有向无环图Step 1定义原子能力# capabilities/git-pull.yaml name: git-pull input_schema: {type: object, properties: {repo: {type: string}}} output_schema: {type: object, properties: {commit: {type: string}}} # capabilities/docker-build.yaml name: docker-build input_schema: {type: object, properties: {tag: {type: string}}} output_schema: {type: object, properties: {image_id: {type: string}}} # capabilities/docker-push.yaml name: docker-push input_schema: {type: object, properties: {image_id: {type: string}}} output_schema: {type: object, properties: {pushed_at: {type: string}}}Step 2用 YAML 定义工作流# workflows/deploy.yaml name: deploy-to-staging steps: - name: pull-code capability: git-pull input: {repo: https://github.com/myorg/myapp.git} outputs: [commit] - name: build-image capability: docker-build input: {tag: staging-${{ steps.pull-code.outputs.commit }}} outputs: [image_id] depends_on: [pull-code] - name: push-image capability: docker-push input: {image_id: ${{ steps.build-image.outputs.image_id }}} depends_on: [build-image]Step 3CLI-Anything 执行工作流cli-anything run-workflow deploy-to-stagingCLI-Anything 的 Workflow Engine 会自动解析depends_on构建执行顺序将steps.pull-code.outputs.commit注入到build-image的input每个步骤在独立沙箱中执行失败时只重试该步骤生成执行报告~/.cli-anything/workflows/deploy-to-staging-20240315-102030.json提示这种工作流不是 Airflow 的简化版而是 CLI 原生的编排。它不需要数据库、Web UI、Scheduler 进程所有状态保存在 JSON 文件中适合轻量级自动化场景。5.2 Agent-Native 的终极形态让 LLM 直接“理解” CLI 能力热词中codex cli,claude cli,minimax code cli都指向一个趋势用 LLM 生成 CLI 命令。但 CLI-Anything 让这个过程更安全、更可控传统方式危险# LLM 生成的字符串直接 eval 或 os.system llm_output aws s3 cp ./data/ s3://my-bucket/ --recursive os.system(llm_output) # ⚠️ 严重安全风险CLI-Anything 方式安全# LLM 生成的是结构化能力调用 llm_output { capability: aws-s3-copy, input: {source: ./data/, destination: s3://my-bucket/, recursive: True} } # CLI-Anything 验证并执行 result, error cli_agent.execute( capability_namellm_output[capability], input_datallm_output[input] )CLI-Anything 的execute方法会检查aws-s3-copy是否在注册表中验证input_data是否符合input_schema如recursive必须是布尔值检查required_permissions是否被授权RBAC 控制在沙箱中执行而非裸os.system我们在某客户项目中用此模式实现了“自然语言运维”运维人员说“把 prod 环境的数据库备份上传到 S3”LLM 生成{capability: pg-dump-upload, input: {env: prod}}CLI-Anything 自动调用pg_dumpaws s3 cp全程无需人工干预。5.3 未来演进CLI-Anything 的“能力市场”与社区共建CLI-Anything 的设计天然支持能力共享。我们已看到社区自发贡献的 23 个 Capabilityterraform-plan