apexe：用MCP协议把现有CLI安全接入AI Agent

你的组织大概率已经拥有了智能体所需的各种能力。它们存在于 git、kubectl、jq、curl、运维脚本和内部 Unix 命令行工具中。

常规的选型往往让人左右为难：要么给智能体开放 shell 访问权限，要么把每个有用的命令重新封装成 API 或 MCP server。

apexe 走的是中间路线。它扫描现有的 CLI，将每个命令转化为 schema 驱动的 apcore 模块，再通过 MCP 或 A2A 以执行时受控的方式对外提供这些模块。

existing CLI → module contract + reviewed policy → governed Executor → many agent clients

当前支持范围

在智能体基础设施中，精确性至关重要。当前产品的能力边界如下：

功能项	apexe 0.8 状态
PATH 上的 Unix CLI 工具	由 apexe scan 支持
macOS/Linux 系统工具（ls、cat、cp、sort …）	作为 CLI 工具支持，含 BSD 感知解析
内置解析器（Man、BSD Usage、GNU、Click、Cobra、Clap）	已支持的扫描器特性
扫描后 CLI 模块的 ACL	随 --acl 传入时支持
MCP	由 apexe serve 支持（stdio、HTTP、Explorer）
A2A	由 apexe a2a 支持
OpenAPI 输入	apexe CLI 当前不支持

OpenAPI 值得单独说明一下。apcore 工具包确实有 OpenAPI 相关功能，但 apexe 并未调用其 OpenAPIScanner。apexe 目前是 CLI 到智能体的桥接层，所以不应该把 OpenAPI 支持作为已交付功能来宣传。

从一个真实的 CLI 开始

apexe scan git curl jq
apexe list
apexe serve --show-config claude-desktop --acl ~/.apexe/acl.yaml

扫描过程是确定性的：依赖帮助文本、man 页面和 shell 补全——不经过 LLM。它为每个命令创建一个绑定（如 cli.git.log 或 cli.curl），每个绑定包含 flags 和 operands 的 JSON Schema。

智能体调用的是一个 JSON 对象，而不是拼装命令字符串：

{ "url": "https://httpbin.org/get", "silent": true }

apexe 验证这个对象，构建 argv，然后直接启动程序。没有 shell 来解析这些参数。

一种能力配置，多种智能体客户端

目标不是为每个智能体产品单独创建工具定义和安全策略。绑定和 ACL 才是信任的源头：

~/.apexe/bindings/ + ~/.apexe/acl.yaml → apexe → Claude / Codex / Pi / 其他 MCP 客户端

这并不意味着每个客户端共享同一种配置文件格式。每个 host 仍然需要自己的 MCP 连接条目。共享的是命令或 HTTP 端点、扫描得到的模块绑定，以及经过审核的 ACL。

apexe 可以为 Claude Desktop 和 Cursor 生成连接片段：

apexe serve --show-config claude-desktop --acl ~/.apexe/acl.yaml
apexe serve --show-config cursor --acl ~/.apexe/acl.yaml

Codex 可以注册同一个本地 stdio server：

codex mcp add apexe -- apexe serve --acl ~/.apexe/acl.yaml

Pi 及其他支持 MCP 的客户端通过各自的 MCP 配置机制连接。apexe 目前不会生成 Pi 专用的文件，所以客户端必须支持你选择的传输方式。对于共享部署场景，可以运行一个带认证的 HTTP server，让兼容的客户端连接到这个端点。

为什么模块契约重要

正是这个契约让同一种能力在不同交付面上保持语义一致：

apexe serve 通过 MCP 暴露模块，默认走 stdio，也可选择 HTTP + 浏览器 Explorer。apexe a2a 将同一套受治理的模块以 agent skill 的形式对外提供。--prefix 和 --tags 可以在客户端发现或调用之前缩减注册表面。

策略不需要针对每个协议单独重写，因为 MCP 和 A2A 共享同一个 Executor。

治理是产品特性，不是打勾

apexe scan 写入的是默认拒绝型 ACL。这是一个起始策略，而非隐形决策：只有当操作员用 --acl 提供策略文件时，强制执行才会生效。

apexe serve --acl ~/.apexe/acl.yaml

ACL 控制哪些 capability 可以被调用。全程路径守护回答的是另一个问题：这次特定调用可以触及文件系统的哪个位置？它在解析符号链接和路径遍历之后检查路径类型的输入，保护系统路径不被写入，保护凭证位置不被读写。

apexe policy apexe policy --path /etc/nginx/conf.d --mode write

每个子进程都无 shell 环境运行、以清空的 environment 启动、有超时和输出上限，并且可以产生私有的审计记录。这些都是有意义的安全保障，但它们不是沙箱。将暴露的工具运行在你风险模型所要求的容器、VM、账户和网络边界内。

为什么 0.7 和 0.8 很重要

当前这两个版本让边界在实践中更加有用：路径保护、参数敏感的审批、拒绝已验证的命令执行参数、二进制可用性检查、网络可达工具的显式默认拒绝层级，以及外部维护的已验证 CLI 覆盖层。

绑定默认落在 ~/.apexe/bindings/ 下，并记录生成它们的 apexe 版本。现有用户升级后应重新扫描：

apexe scan git curl jq --no-cache
apexe list --available-only

接下来：本地执行，再到原生终端工作流

下一个提案特性是 F8 本地执行。它被刻意拆成两个阶段，而不是把 shell 包装当成捷径。

阶段 1，apexe run，是针对单个扫描模块的结构化本地入口点：

apexe run cli.ls --input '{"long": true, "paths": ["/tmp"]}' --acl ~/.apexe/acl.yaml

它复用 MCP 和 A2A 使用的同一个 Executor，产生捕获的输出，并让预检决策可在终端中审查。它不是原生 shell 语法，也不提供流式 stdin 或管道。

阶段 2，apexe env 配合 PATH shim，是面向最终用户的预期终端体验。符合条件的外部命令保留其正常名称和 argv 语法，因此已有的管道如 ls -l /tmp | grep ERROR | head -20 可以保持不变。

每个阶段都独立解析到一个扫描模块，并获得 schema 验证、已验证 cli-permissions 事实、ACL、路径守护、超时、输出限制和审计日志——全程不使用 sh -c。

目前此特性尚未可用。它的安全性依赖于仍在敲定的契约：直通 I/O、流式 stdin 读取模块的显式人工审核白名单、PATH 隔离，以及拒绝率和 shim 延迟的测量。它也无法拦截 shell 内建命令、别名/函数或绝对路径调用。请阅读 F8 设计文档了解确切边界。

参与设计讨论

有趣的问题不是"智能体能否运行命令？"它能。真正的问题是：哪些现有的能力来源应该共享契约、治理层和协议交付模型？

我们很期待你的意见：

• 你会首先暴露哪个 CLI 或内部工具？
• 哪些 agent hosts——Claude、Codex、Pi 或其他 MCP 客户端——需要同一套受治理的工具面？
• 哪些现有脚本或管道应该首先支持受治理的 PATH-shim 模式？
• OpenAPI 接入在同一个工作流中是否有价值？
• 在智能体可以使用新发现的 capability 之前，操作员必须审核什么？

项目地址：aiperceivable/apexe