CLI vs. MCP vs. API：2024终极决策树与权威对比指南

MCP Server的设计有个特点：它会一次性把所有工具的schema都塞进上下文。这导致了一个问题——你只是想查一下仓库的语言构成，它却把43个工具的完整定义全给你加载进来。这种感觉，就像你只想买瓶水，却被要求必须逛完整个超市的每一个货架。

Agent接入层的选型，从来不是信仰之争，而是一个纯粹的工程问题。

一、一个让我重新审视工具栈的瞬间

上周五晚上，我在Claude Code里处理一个批量操作飞书文档的任务。MCP Server连续超时了三次，烧掉了四万多token，任务却依然没跑完。

切换到lark-cli后，一行命令，1500个token，8秒钟，搞定。

那一刻突然意识到，过去半年可能问错了问题。我们总在争论“MCP和CLI哪个更先进”，但真正应该问的是——“在这个具体的场景下，哪种接入形态的投资回报率最高？”

回头翻看自己的工具配置变迁史，很有意思：半年前装了六七个MCP Server，CLI只有三四个。现在反过来了——CLI有七八个，MCP Server只保留了最核心的两个。这不是MCP退步了，而是学会了如何根据场景进行匹配。

图片

这篇文章的目标很明确：提供一套判断框架，让你下次面对任何工具接入选择时，能在30秒内做出决定。

二、你以为的“对Agent友好”，可能完全搞反了

这里有个反直觉的事实：那些为人类精心设计的交互体验，对Agent来说，有时反而是灾难。

Speakeasy团队在2026年的复盘报告中有一段话令人印象深刻——他们花了几个月打磨的交互式引导、彩色进度条、分步确认流程，在接入Agent后，“全部变成了路障”。他们最引以为傲的功能，恰恰成了Agent最大的敌人。

Scalekit的75次基准测试给出了更冷酷的数字：在某些场景下，不同接入方式的token消耗差距达到了32倍。这不是理论推演，而是实测的中位数。

问题出在哪里？根源在于设计理念。MCP Server的设计决定了它要把所有工具定义一次性塞进context。你只想查个仓库语言，它把43个工具的schema全给你装上。这就像你只想买瓶水，却被强制逛完整个超市。

那么，什么才是真正的“对Agent友好”？可以归结为四个硬指标：

✅ 非交互式（不卡在等你按回车）
✅ 结构化输出（支持--json / 标准的POSIX退出码）
✅ 可组合（能pipe进pipe出）
✅ 认证封装（token不泄漏到LLM上下文）

这四条标准，跟你用什么模型无关，跟工具新不新也无关。它是一个设计问题，而不是时代问题。

三、接入栈的真实面貌：两层一模式

图片

CLI、MCP Server、SDK、Skills、Code Execution——这五个词天天出现，但它们其实根本不在同一个维度上。

把方向盘、轮胎、发动机和驾驶模式摆在一起比较，你会觉得荒谬。但很多人选择工具接入方式时，干的就是这事。

让我们把层级拆开来看。

地基：API

API是原子能力，所有上层建筑都构建在它之上。但Agent几乎不会直接裸调API——LLM不熟悉你的私有OpenAPI Spec，而把整个spec全塞进context又贵得离谱。

工具形态层：CLI / MCP Server / SDK

这三者本质上是同一个API的三件不同“外衣”。

以GitHub为例：

gh pr list → 这是CLI形态
github-mcp-server → 这是MCP形态
@octokit/rest → 这是SDK形态

底层调用的都是同一个GitHub REST API。选择穿哪件“衣服”，看的是具体场景，而不是技术信仰。

CLI的优势在于：LLM在预训练时见过海量的命令行模式，子命令可枚举，写起来准确率高。

MCP Server的优势在于：动态发现、协议标准化、任何Host都能接入。

SDK的优势在于：适合批量操作、复杂逻辑和需要类型安全的场景。

知识层：Skills

Skills不是工具本身，而是工具的使用说明书。可以把它理解为Anthropic在2025年推出的标准作业程序包，专门教模型“什么时候该用什么、第一步该跑什么”。

实测数据表明：CLI配合一份800 tokens左右的Skills文档，效果显著优于裸CLI。投入产出比极高。

横切模式：Tool Use vs Code Execution

这不是另一种工具，而是模型调用工具的两种不同方式。

Tool Use：一次调用一个工具，返回结果，再决定下一步。

Code Execution：模型写一段代码，批量调用SDK。Cloudflare就把2500多个API端点压缩成只暴露search()和execute()两个工具，token消耗从150K降到了2K，降幅高达98.7%。

四、五个问题，一棵决策树

图片

理论讲完，进入实操。面对任何一个工具接入选择，顺着问自己下面这五个问题：

❶ 我的Host能跑本地命令吗？

Claude Code、Cursor、Codex CLI——可以。ChatGPT网页版的Code Interpreter——不行（沙箱环境看不到本地工具）。Claude Desktop——默认不行，但安装shell-mcp后可以。

如果Host不支持本地工具，CLI选项就直接出局，只能走MCP或SDK路线。

❷ 这个服务有最新的CLI吗？

GitHub有gh，Vercel有vercel，飞书有lark-cli。但Notion就没有官方的最新CLI，Salesforce的sf CLI则背负着沉重的历史包袱。没有CLI时，退而求其次选择MCP Server或SDK。

❸ 我对token成本敏感吗？

偶尔问一句话、跑个简单查询——MCP Server完全没问题，多花的那点token可以忽略不计。

但如果你是重度用户，每天在Claude Code里跑几十个任务——32倍的差距就意味着每月几百块的真金白银。只有算过账的人，才有资格说“无所谓”。

❹ 需要批量组合吗？

单次调用，什么形态都行。

批量场景下主要有两条路：

本地Host → 采用CLI + pipe组合：gh pr list --json | jq | xargs gh pr review
沙箱Host → 采用SDK + Code Execution：让Agent写代码来批量调用

这两条路都比“逐个调用MCP工具”更稳定，也更省钱。

❺ 这是不是高频重复劳动？

每周做三次以上、市面上又没有现成CLI——那就自己写一个。50行shell脚本，每周能省下半小时，而且能持续用好几年。在LLM时代，制作工具早已不再是程序员的特权。

五、三种设计哲学的真实碰撞

图片

把gh、lark-cli、Salesforce sf放在一起对比，差异不在于命令的多少，而在于设计者如何看待Agent这个“用户”。

gh：把Agent当作第一公民

GitHub CLI团队在2026年1月的一个Issue标题写得很明白：“Explore: making gh better for agents”。他们坦承：“gh的大量使用增长来自agentic software。”

设计上近乎教科书：子命令最深三层、全部命令支持--json、OAuth内置、pipe天然成立。这不是运气，而是主动经营的结果。

lark-cli：生在Agent时代

2026年3月28日才开源，没有历史包袱。覆盖12个业务域、200多条命令、内建skill文档。更聪明的是，飞书同时做了lark-openapi-mcp——CLI和MCP不是二选一，而是用来覆盖不同的人群和场景。

这个认知，很多团队到现在还没有。

Salesforce sf：工具层没大改，平台层在重启

sf CLI本身的问题依然存在：命令深度达5层、schema不一致、历史迁移包袱重。对LLM来说，每多一层深度，错误率就会叠加。

但Salesforce在另一个维度发力了——Agent Script、ADLC Skills、Headless 360。工具层是一回事，平台层是另一回事。评价一家公司，不能只看它的CLI。

六、设计CLI的七项体检清单

无论你是开发商业产品，还是给自己写脚本，这七项都是设计时的“回头尺”：

七项中能勾上五项，你就在agent-friendly的第一梯队了。

七、今晚就能做的三件事

1️⃣ 列出你最高频使用的5个工具，标注它们现在走的是CLI、MCP还是SDK形态。发现形态错配的，本周就着手迁移。

2️⃣ 挑出你每天最重要的3条Agent任务，算一次token消耗。很多人算完会发现：原来每天浪费的token，都够跑一个新项目了。

3️⃣ 找到那个“每周重复三次以上、却没有现成工具”的杂活。把它记下来。下一篇，我们就动手解决它。

说到底，选型不是技术信仰，而是场景匹配。用对的工具做对的事，远比用最新的工具做所有事，重要一百倍。