MCP 太重了——我给 Orchard 补了一个 CLI

一个让我困扰的问题

Orchard 是我做的 macOS 菜单栏应用，通过 MCP 把日历、邮件、通讯录、备忘录等 Apple 原生能力暴露给 AI 客户端。在 Claude Desktop、Cursor 里用着挺好。

但有一天我在 Claude Code 里试了下——只是想查一下明天有什么日历事件。Claude Code 走 MCP 调用 Orchard：initialize 握手、tools/list 拉近 50 个工具的完整 JSON Schema、resources/list、prompts/list……光工具定义就常驻约 25K token。而真正那个 calendar_info 调用，请求加响应只有 500 token。

像是去便利店买瓶水，每次都要先签合作协议。

MCP 的价值在长连接、实时推送、多客户端并发——这些都是 CLI 做不了的。但对于"调一下拿结果"的场景，它的仪式感太重了。

CLI：最古老的 API

答案其实就是 CLI。没有握手、没有会话、没有连接管理，敲一行命令，吐出结果，进程退出。这恰好是 AI Agent 最喜欢的交互方式。

对比一下：MCP 的工具定义要常驻 ~25K token，CLI 一次调用只要 ~200 token；MCP 需要完整握手才能拿工具列表，CLI 的 --help 就是文档。

这也不是什么新想法——1Password、Tailscale、github、cloudflare 等都早有配套 CLI。一个没有 CLI 的 GUI 工具，在 Agent 生态里就是一座孤岛。

难题：macOS 的权限墙

想法简单，做起来有个硬骨头：macOS 权限系统。

Orchard 能访问日历、通讯录、邮件，是因为用户给 Orchard.app 逐项授权过。权限绑在 App Bundle 上——一个新的 CLI 二进制想直接访问？macOS 会拦住它，每种权限都要再授权一遍。

我评估了几种方案：

1. 独立 CLI：自己申请所有权限。但用户被同一软件分别要求两次授权，体验很糟
2. GUI 内嵌 --cli 模式：每次启动加载完整 GUI 框架，Agent 连续调用时不可接受
3. XPC 桥接：macOS 原生方案，但 Privileged Helper 签名分发、Protocol 版本管理等杂活比 CLI 本身还重
4. Unix Domain Socket 代理：CLI 是零权限瘦客户端，通过本地 Socket 把请求转给运行中的 GUI 进程，GUI 拿自己的权限执行

我选了方案四。CLI 不需要任何 entitlement，它只是 Socket 客户端。用户给 Orchard.app 授权一次，CLI 就自动"继承"了所有权限。代价是 CLI 依赖 GUI 进程运行，但菜单栏常驻应用本来就一直在跑。

整个 Socket 代理核心实现约 400 行——Server 端 241 行、Client 端 138 行。协议选了最简单的行分隔 JSON：一行 JSON 一条消息，\n 分隔，没有 header、没有 content-length、没有版本协商。你甚至可以用 socat 手动调试。

为 Agent 而设计

做一个 CLI 不难，做一个 Agent 友好的 CLI 要多想几步：

• 全局 --json：Agent 才能确定性地提取数据，不用花 token 解析自由文本
• stdout 放结果，stderr 放诊断：Agent 可无歧义地拿数据和读错误
• 不做二次确认：Agent 的 stdin 不是终端，Are you sure? [y/N] 会让它卡死。破坏性操作的确认应该在 Agent 那层做
• Exit code 带语义：0 成功 / 1 执行错误 / 64 参数用法错误，Agent 对这两种错误的应对完全不同
• --help 即文档：枚举合法值、标注必填、给默认值。Agent 第一件事就是 tool --help

MCP 和 CLI 不是二选一

做完 CLI 之后我一度怀疑 MCP 是不是多余了，但它们适用的场景完全不同：

我自己其实只看一件事：调用结束之后会话还在不在。在就 MCP，不在就 CLI。

Orchard 现在两种接口都提供。MCP Server 监听 HTTP/SSE，CLI 走 Unix Domain Socket，共享同一个 GUI 进程里的工具实现。Socket 代理模式用约 400 行代码把一个 GUI 应用变成 Agent 可操控的 CLI 工具集——成本很低，收益却很大。