第三方工具集成的两条路：CLI 直调 vs MCP server

第三方工具集成的两条路：CLI 直调 vs MCP server

基础概念

把"让 AI Agent 操作第三方工具（飞书、Obsidian、GitHub、Notion …）"这件事拆开看，2026 年现实里只有两种被反复使用、能撑起生产场景的集成路径：

1. CLI 直调路径：第三方工具方提供一个官方 CLI，Agent 通过它的 Bash 工具 spawn 子进程执行命令、读 stdout 拿结果。
2. MCP server 路径：第三方工具方（或社区）提供一个 MCP server，Agent 所在的 Host 在启动时把它注册进来，模型在上下文里看到一组工具描述，按需调用。

这两条路不是「替代关系」，更像是 「同一个能力，按客户端形态做的两种适配」。它们的工作方式差别很大：

两条路的核心机制差别可以浓缩成三句话：

• 谁知道有什么工具？ CLI 直调下，模型只要在训练里见过常见命令、或在 CLAUDE.md / Skills 里被告知，就知道怎么用；调不动时还能 --help 现场学。MCP 下，工具列表在握手阶段就喂给模型，常驻在每次请求的上下文里。
• 工具描述要不要进 token？ CLI 直调几乎不进，调用就是一行字符串；MCP 的工具 schema 进上下文，工具越多 token 占用越大。
• 跨客户端能不能复用？ CLI 直调只能在能 spawn 子进程的客户端里用（Claude Code / Codex CLI / Gemini CLI 等终端 Agent）；MCP 只要客户端是 MCP Host，就能复用同一个 server（Claude Desktop / Cursor / VS Code Copilot Chat / Windsurf 等）。

这两条路也不是 2026 年才出现的发明。CLI 直调一直是 Unix 工具组合的传统玩法，只是过去 AI Agent 不擅长，最近一年模型对命令行参数的理解能力质变之后才成为主流；MCP 则是 Anthropic 2024-11 发布的开放协议，目标是解决「N 个 AI 应用 × M 种数据源」的 N×M 集成困境。本卡讨论的是站在 CLI Agent 用户的视角，怎么选。

核心要素

基础用法

不要一上来就纠结"哪条路更好"。用下面的五问法跑一遍，答案自然出来：

逐问解释一下：

① 工具有官方 CLI 吗？ 有，且 Agent 能跑 Bash，CLI 就是默认选项。2026 年起官方 CLI 的设计开始大量为 Agent 优化（--help 自描述、--dry-run 预演、结构化输出），调用成功率比早些年高得多。注意"官方"二字——社区 CLI 可以试，但要先看维护活跃度，否则后期升级要痛苦地自己 fork。

② 是否需要跨多个 AI 客户端复用？ 团队里既有 Claude Code 用户、又有 Cursor / Claude Desktop 用户时，「让所有人都能用」往往比「让 CLI Agent 用得最快」优先级更高。MCP 的核心价值就是这个——一个 server 喂所有 Host。如果你只有 Claude Code 一种客户端，这一问可以直接跳过。

③ 调用是否需要 LLM 二次推理结果？ CLI 直调返回的是 stdout 字符串，模型直接读；MCP 返回结构化 content（含 type/mimeType），适合直接当成「另一个工具的输入」继续推理。如果你要做的是"查多维表 → 模型理解 → 再写一行回去"这种链式操作，MCP 的结构化返回更顺；如果只是"列出 5 个文件名给我看看"，CLI 直接 echo 就够用。

④ 是否需要语义检索 / 向量？ 向量检索、跨文档理解这类「重 LLM 推理」的能力，MCP server 内部可以预处理（embed、rerank、压缩），把已经"消化过"的结果回给模型；纯 CLI 通常只能返回 raw 文本，模型自己消化。这种场景 MCP 占优。

⑤ 性能 / 延迟敏感度？ 本地链路（Obsidian、文件系统、git）几乎都是毫秒级，MCP 多一跳的影响很小，但 CLI 链路更短、token 更省（参考 Maksym Prokopov 在 4663 篇 vault 实测：CLI search 0.32s vs grep 1.95s，orphan 检测 token 从 ~7M 降到 ~100，便宜 70000 倍）。远程服务（GitHub、Notion）两条路差别不大，主要看接口质量。

一组速判口诀

记不住流程图也没关系，记住这组口诀就够日常用：

• 本地工具 + 本地 Agent → CLI（Obsidian、git、文件系统、ripgrep）
• 跨客户端复用 → MCP（团队同时用 Claude Code 和 Cursor 时）
• 官方两条都有 → 按客户端分发（飞书 lark-cli 给终端、lark-openapi-mcp 给 Cursor）
• 没有官方 CLI、有官方 MCP → MCP（Notion、Slack）
• 两边都没官方 → 直调 OpenAPI 或自己包一层

具体到主流工具，看下一节的速查表。

同类工具对比

把视野放宽一点，"在 Agent 里接入第三方工具"其实有四种可能：CLI 直调、MCP server、直调 OpenAPI、Skills 自定义工具。下面这张表是本卡的主对比表：

核心区别一句话：

• CLI 直调：Agent 时代的"管道哲学"现代版——short、便宜、和已有 Unix 工具链无缝衔接，但只能给"能跑 shell"的 Agent 用。
• MCP server：跨客户端通用菜单——Anthropic 2024-11 提出的开放协议，把"工具发现 + 调用"标准化，代价是工具描述要常驻上下文。
• 直调 OpenAPI / SDK：写自己后端时的兜底方案，Agent 集成场景几乎不会原生走这条路（除非你是工具方在做适配）。
• Skills：Claude Code 生态里"把多步流程沉淀成一条命令"的层，本质是 prompt + 可选脚本。Skills 不是替代 CLI / MCP，而是架在它们之上的"组合层"——一个飞书相关 Skill 内部完全可以同时用 lark-cli 和 lark-openapi-mcp，对 Agent 暴露一个简化的 /feishu-weekly-digest 入口。

主流工具速查表

下面这张表覆盖 10 个最常被问"该走哪条路"的工具，官方 CLI / 官方 MCP / 推荐路径 / 理由四列：

读这张表的方式：先看"有/无官方 CLI"，再看"客户端能不能 spawn shell"，剩下的细节按场景判断。

常见误区

优劣势分析

什么情况下两条路都能选

• 本地有官方 CLI + 又有官方 MCP 的工具（飞书是最典型例子）：按客户端分发即可，终端 Agent 走 CLI、其他客户端走 MCP。同一台机器装两套不冲突。
• GitHub 这种工具方两头投入都很到位：写脚本、CI、本地操作偏 gh CLI；Cursor/Desktop 用户走 MCP。
• 小型团队、单一客户端栈：没有"跨客户端"需求时，两条路对你来说差别只在"哪条更顺手"，按个人偏好选即可。

什么情况下只能选 CLI

• 工具方没出过 MCP，且社区方案不可信（部分小众工具）。
• 极致 token 敏感场景：长会话、多步迭代，每多一组 MCP 工具描述都要钱。
• 完全离线 / 容器内 / CI 环境：MCP 长连接不一定方便维护，CLI 是启动即用。
• 模型对该 CLI 有强先验（git、gh、ls、curl、psql 这类），强行包 MCP 反而增加链路长度。
• Agent 跑在没有 GUI 的远端 Linux：很多工具的 MCP server 依赖本地 GUI（Obsidian、飞书 OAuth），反而 CLI 更跑得通。

什么情况下只能选 MCP

• 工具方根本没有 CLI（Notion、Slack）：CLI 路径不存在。
• 客户端不能 spawn shell（Claude Desktop、Cursor 早期版本）：只剩 MCP 一条路。
• 跨客户端团队，要"一份配置全员可用"：MCP 的 server 配置共享是它的核心价值。
• 需要 server 端预处理 / 长连接状态（浏览器自动化、向量检索、企业级流式数据）：CLI 起停代价太高。
• Agent 输出要消费的是结构化 schema，而不是 raw 字符串：MCP 的 content type / structuredContent 字段比 CLI stdout 友好。

通用判断公式

if 工具方有官方 CLI and 你的 Agent 能 spawn shell:
    if 跨客户端复用是核心需求:
        两条路都装；CLI 给终端 Agent、MCP 给其他客户端
    else:
        默认 CLI（更短、更便宜、更原生）
elif 工具方有 MCP（官方或可信社区）:
    走 MCP
else:
    直调 OpenAPI / 自己包一层 / 写 Skill

思考题

参考资料

1. Model Context Protocol 官方首页：https://modelcontextprotocol.io/（查询日期 2026-04-22）
2. MCP 协议规范最新版：https://modelcontextprotocol.io/specification/latest
3. Claude Code Skills 官方文档：https://code.claude.com/docs/en/skills
4. Maksym Prokopov，《Obsidian CLI: Why Your AI Agent Just Got 70,000× Cheaper to Run》：https://prokopov.me/posts/obsidian-cli-changes-everything-for-ai-agents/
5. 宝玉，《lark-cli 与 AI Agent：CLI vs MCP 的取舍》：https://baoyu.io/blog/2026-03-28/lark-cli-ai-agents
6. larksuite/cli 官方仓库（CLI 范例）：https://github.com/larksuite/cli
7. larksuite/lark-openapi-mcp 官方仓库（MCP 范例）：https://github.com/larksuite/lark-openapi-mcp
8. Obsidian CLI 官方文档：https://obsidian.md/help/cli
9. cyanheads/obsidian-mcp-server（社区 MCP 范例）：https://github.com/cyanheads/obsidian-mcp-server
10. 本 Wiki 同源卡片：CLI 范例（Obsidian）、CLI vs MCP 同源对比（飞书）、MCP 是什么、MCP 三大角色与架构