1. 从“协议热”到“工具冷”MCP的喧嚣与CLI的静默最近在AI开发圈子里MCPModel Context Protocol这个词的热度有点高。随便翻翻技术社区就能看到各种关于如何搭建MCP服务器、如何集成到Claude Code CLI的讨论甚至出现了“搜索类MCP服务器添加进Codex的详细步骤”这类非常具体的操作指南。这股热潮让我想起了技术圈里一个反复出现的现象当一个新协议、新框架出现时大家会一拥而上讨论它的“可能性”却常常忽略了手边那些已经能解决实际问题的“老工具”。MCP协议本身作为一个旨在标准化LLM大语言模型与外部工具、数据源交互的桥梁其设计理念无疑是先进的。它试图解决AI Agent智能体在调用不同功能时面临的接口碎片化问题愿景是美好的。但当我们抛开那些宏大的叙事回归到日常的开发、运维、数据处理这些具体场景时一个冷静的问题浮现了我们真的需要为每一个简单的数据查询、文件操作或系统调用都去构建和维护一个MCP服务器吗或者说在追求“智能体”的优雅交互之前我们是否低估了那个一直躺在终端里、随叫随到的老朋友——命令行界面CLI——的真实价值这并非要全盘否定MCP或类似协议的未来。相反我认为清晰地界定它们的适用边界恰恰是为了让它们能在正确的场景下发挥最大价值。当前很多关于MCP的讨论在我看来陷入了一种“为协议而协议”的伪需求陷阱。大家热衷于讨论协议的细节、服务器的实现、客户端的集成却很少去追问一个更根本的问题我要解决的这个问题是否真的复杂到了必须引入一个中间协议层的地步很多被包装成“MCP用例”的场景比如查询天气、搜索网页、操作本地文件用一个精心编写的Shell脚本或Python CLI工具可能只需要几十分钟就能稳定可靠地跑起来并且拥有完全可控的逻辑和清晰的错误处理。而构建一个符合MCP规范的服务器你需要处理协议定义、序列化/反序列化、认证、长连接管理等一系列复杂度这其中的投入产出比需要打一个巨大的问号。因此这篇文章我想做一次“降温”和“正名”。降温是给过热的MCP讨论泼一点冷水帮大家识别哪些是真正的需求哪些是追逐技术潮流产生的伪需求。正名则是重新审视被我们可能视为“老旧”或“不够AI”的命令行工具CLI挖掘它在AI时代被低估的、极其坚实的价值。你会发现一个设计良好的CLI其威力、灵活性与自动化能力远超许多人的想象它本身就是连接人类意图与机器能力最高效的桥梁之一。我们接下来就深入解构这两个方面。2. MCP协议理想很丰满但当前落地骨感首先我们必须客观地认识MCP。Model Context Protocol 的核心目标是提供一个标准化的方式让LLM能够发现、描述并安全地调用外部工具和数据源。你可以把它想象成给LLM用的“插件系统”或“驱动协议”。一个MCP服务器对外暴露一系列“工具”Tools和“资源”Resources而像Claude Code CLI这样的MCP客户端则能动态地发现这些能力并让LLM如Claude在对话中根据需要去调用它们。这个设计针对的痛点很明确当你想让一个AI助手帮你完成涉及多个外部系统的复杂任务时比如“从Jira拉取最新的Bug列表分析后生成一份报告并发到Slack频道”如果没有统一协议你需要为Jira和Slack分别编写适配代码并硬编码到AI系统中。MCP的理想状态是Jira和Slack都提供了标准的MCP服务器AI客户端只需配置连接就能自动获得这些能力实现“即插即用”。2.1 MCP可能适用的真场景那么MCP的价值究竟在哪里我认为在以下几个方向它是有长期潜力的企业级复杂系统的标准化集成在一个大型组织内部可能存在数十个关键系统CRM、ERP、监控、CI/CD。为每个系统都开发一个MCP服务器虽然前期投入大但一旦完成就能为整个公司的AI助手无论是面向员工还是面向客户提供一个统一、安全、可控的能力接入层。这比为每个AI项目重复造轮子要经济得多。商业SaaS服务的AI能力开放像Tavily搜索、Brave Search这样的服务提供MCP服务器是一种很好的商业模式。它降低了用户将其服务接入AI工作流的门槛相当于提供了“AI原生”的API。用户无需理解其底层REST API的细节只需在Claude等工具中配置一下就能直接使用。需要高安全性和权限管控的场景MCP协议可以设计完善的认证、授权和审计机制。对于操作数据库、云资源或敏感数据的工具通过MCP服务器进行代理可以集中实施安全策略比如哪些AI可以访问、能执行什么操作、记录所有日志这比让AI直接持有高权限凭证要安全。2.2 当前常见的MCP“伪需求”陷阱然而在当前的社区实践中我看到大量案例落入了伪需求的陷阱主要体现在“手里有锤子看啥都是钉子”因为学了MCP就想把所有东西都“MCP化”。比如写一个MCP服务器来操作本地文件系统读/写/列表文件。这完全是用高射炮打蚊子。系统原生的ls,cat,find命令或者Python的os、pathlib模块不仅零延迟、功能全、文档丰富而且与你的脚本逻辑可以无缝集成。为其包装一个MCP服务器引入了网络延迟、序列化开销、额外的依赖和潜在的故障点收益几乎为零。忽视复杂度转移MCP并没有消除复杂度而是将其从“AI应用逻辑”转移到了“MCP服务器实现与运维”上。你现在需要关心服务器的生命周期管理、版本兼容性、错误处理、性能监控。对于一个个人或小团队项目维护一个随时可能被LLM调用的服务其心智负担和运维成本可能远高于写一段直接的调用代码。混淆了“协议”与“实现”的价值大家追捧MCP很多时候是追捧像claude-code-cli这样优秀的客户端实现所带来的流畅体验。但这份体验的核心是Claude模型强大的代码理解能力和claude-code-cli本身良好的设计。MCP只是它支持的一种扩展方式。很多需求直接通过claude-code-cli与本地脚本或CLI工具交互同样能获得优秀体验且路径更短、更可控。为尚未存在的需求构建基础设施很多开发者是在“预构建”能力想着“万一以后我的AI要用到这个呢”。在需求不明确、使用频率极低的情况下过早引入协议层会导致资源浪费和架构僵化。正确的做法应该是等到AI工作流中某个手动环节重复出现且确实繁琐时再考虑自动化方案而方案的首选不应默认是MCP。注意评估一个功能是否需要MCP化一个简单的判断方法是这个功能如果让你写一个传统的命令行工具CLI来提供会不会觉得很奇怪或很麻烦如果答案是“不会这很自然”那么你应该先考虑CLI。CLI是经过时间检验的、人机交互与机机交互的完美结合点。3. CLI的复兴被低估的AI时代核心枢纽当我们的目光从飘在云端的“协议”拉回实实在在的“终端”命令行工具CLI的价值便熠熠生辉。CLI不是过时的产物相反在AI时代它正成为连接人类自然语言指令与机器精确操作的最关键、最可靠的枢纽。为什么这么说3.1 CLI是“可编程性”的终极体现一个设计良好的CLI工具本质是一个具有清晰接口命令、子命令、参数、标志的函数库。它具备以下无可替代的优势无状态与幂等性CLI命令通常是独立的执行完即结束。输入相同的命令和参数期望得到相同的输出。这种特性使得它极易被脚本化、自动化也极易被AI理解和预测。AI只需要生成正确的命令字符串无需管理复杂的会话状态。丰富的生态系统从系统管理awk,sed,grep,jq到版本控制git到容器化docker,kubectl到云服务aws,gcloud,az再到包管理npm,pip,cargo几乎所有重要的软件和平台都提供了功能强大的CLI。这意味着通过CLIAI几乎可以操作整个数字世界。明确的错误流CLI通过退出码exit code和标准错误输出stderr提供了机器可读的、明确的成功/失败信号。AI可以很容易地判断一个命令是否执行成功并在失败时从stderr中获取诊断信息从而决定重试、回退或尝试替代方案。极低的集成成本在自动化脚本或AI Agent中调用一个CLI命令通常只需要一行 shell 调用或 subprocess 调用。没有额外的依赖安装工具本身除外、没有复杂的SDK初始化、没有网络连接开销。3.2 如何为AI交互设计一个“AI友好型”CLI既然CLI如此重要我们如何设计它才能让它更好地与AI协作甚至成为比MCP服务器更优的选择以下是一些关键原则命令结构清晰且一致采用工具名 动词 对象 [选项]的通用模式。例如git clone repo,docker build path -t tag。避免歧义和特例。提供详尽的--help和--version--help输出应该结构化清晰列出命令、参数、选项及其描述、默认值。这是AI理解工具能力的主要文档来源。可以考虑支持--help-json输出机器更易解析的格式。输出面向机器和人类同时支持易于人类阅读的格式默认和易于机器解析的格式如通过--output json或-o json标志。JSON输出是AI处理结果的黄金标准。稳健的错误处理与有用的错误信息不仅返回非零退出码还要在stderr中提供足够具体、可操作的错误信息。避免“Something went wrong”这种对AI和人类都无用的提示。错误信息应能指导下一步动作。支持干运行Dry Run和模拟Simulation模式对于有破坏性或代价高的操作如删除数据、创建云资源提供--dry-run选项让AI可以安全地“演练”并确认将要执行的操作再实际执行。良好的可组合性Composability遵循Unix哲学——“只做一件事并做好”。让工具的输出能通过管道|轻松成为另一个工具的输入。这使得AI可以将简单工具组合成复杂工作流。一个反例是某些交互式CLI需要不断根据提示输入或者有复杂的终端UITUI。这类工具对AI极不友好应提供非交互式模式或真正的API。4. 实战对比用CLI vs. MCP解决一个真实问题让我们通过一个具体的场景来感受一下CLI方案的直接与高效。假设我们需要让AI助手帮忙完成一个任务“检查当前Git仓库的状态如果有未提交的更改则创建一个以当前时间戳命名的分支并将更改提交上去提交信息为‘Auto-save: 时间戳’。”4.1 方案一编写一个专用的MCP服务器设计协议我们需要定义Tools比如get_git_status,create_branch,commit_changes。每个Tool需要定义输入输出schema。实现服务器用Python假设用mcpSDK编写服务器内部调用subprocess或gitpython库来执行真正的git命令。需要处理启动、信号、错误转换、日志等。部署与运行需要确保这个MCP服务器进程常驻运行或者有方式随AI客户端启动。客户端配置在claude-code-cli的配置文件中添加这个MCP服务器。AI交互AI需要理解这些自定义的Tool并组合调用它们。它可能会这样思考“先调用get_git_status如果有变化再调用create_branch最后调用commit_changes。”整个过程我们为了一个本质上只是包装了git status,git checkout -b,git add -A,git commit -m这几个简单命令的功能引入了一整套新的协议、服务器程序和运维负担。4.2 方案二编写一个精致的CLI脚本我们可以创建一个名为git-autosave的脚本可以是Shell脚本也可以是Python脚本。#!/bin/bash # git-autosave.sh # 检查是否有未提交的更改 if [[ -n $(git status --porcelain) ]]; then timestamp$(date %Y%m%d_%H%M%S) branch_nameautosave/$timestamp commit_messageAuto-save: $timestamp git checkout -b $branch_name git add -A git commit -m $commit_message echo Successfully created branch $branch_name and committed changes. echo Branch name: $branch_name else echo No uncommitted changes. Nothing to do. fi然后赋予执行权限chmod x git-autosave.sh甚至可以把它放到PATH路径下。4.3 方案三直接让AI生成并执行命令序列最直接在与claude-code-cli交互时我们完全可以直接提出需求。一个足够聪明的LLM如Claude-3.5-Sonnet完全能够理解这个任务并生成正确的、可安全执行的Bash命令序列。它可能会生成如下代码块# 检查是否有未提交的更改 if [[ -n $(git status --porcelain) ]]; then # 生成时间戳和分支名 TIMESTAMP$(date %Y%m%d_%H%M%S) BRANCH_NAMEautosave/$TIMESTAMP COMMIT_MSGAuto-save: $TIMESTAMP # 执行Git操作 git checkout -b $BRANCH_NAME git add -A git commit -m $COMMIT_MSG echo 操作成功。已创建分支: $BRANCH_NAME else echo 当前仓库没有未提交的更改无需操作。 fi然后你可以直接复制这段代码在终端运行或者如果环境安全甚至可以让claude-code-cli在沙盒中直接执行它。4.4 对比分析开发效率方案二和三明显胜出。方案二写一个脚本可能只需5分钟。方案三甚至无需预先开发AI即时生成。可理解性与可控性方案二和三的逻辑一目了然任何开发者都能看懂、修改、调试。方案一的逻辑被隐藏在了MCP服务器内部需要额外追溯。维护成本方案二的脚本易于维护。方案一的MCP服务器需要维护其协议兼容性、依赖库版本和运行状态。灵活性方案三最灵活AI可以根据每次对话的上下文生成略微不同的命令逻辑。方案二和一是固定的。安全性在可信环境下三者均可接受。在不可信环境下方案三直接执行AI生成的代码风险最高方案二和方案一需审查脚本或服务器代码更可控。但MCP服务器如果设计不当也可能成为攻击面。对于这个特定、明确、逻辑简单的任务方案二自制CLI脚本和方案三AI生成命令是更优解。MCP服务器方案一显得过度设计。只有当这个“git自动保存”功能需要被多个不同的、异构的AI客户端例如Claude、ChatGPT插件、自定义的Agent框架以标准化方式频繁调用时为其开发一个MCP服务器才可能具有规模经济效应。5. 理性选择何时该用CLI何时考虑MCP经过前面的分析我们可以得出一个更清晰的决策框架。这不是一个非此即彼的选择而是一个基于场景的频谱。5.1 坚定不移地选择CLI或让AI直接操作CLI的场景操作本地系统文件管理、进程查看、日志分析、包安装等。find,grep,jq,ps,apt-get/brew等原生工具是王者。与成熟平台交互使用云厂商官方CLIAWS CLI, gcloud、基础设施工具Terraform, Ansible、容器编排kubectl, docker。它们的CLI通常是最权威、功能最全的接口。一次性或低频的自动化任务写一个脚本Shell/Python就能干净利落解决的问题。需要极高性能或低延迟的操作CLI调用是本地进程间通信速度远超任何网络协议包括MCP。作为复杂任务的“原子操作”封装你可以先为复杂任务编写一个健壮的CLI工具这个工具本身就可以被AI调用。如果未来真有跨平台、跨AI客户端的调用需求再考虑为这个CLI工具包装一个MCP服务器这时服务器逻辑也会非常薄。5.2 可以考虑评估MCP的场景为第三方SaaS服务提供AI入口如果你是一家提供API服务的公司开发一个MCP服务器可以降低用户集成成本是很好的增值服务。企业内部需要统一AI能力平台公司内有多个AI项目客服助手、编程助手、数据分析助手需要安全、可控、统一地接入内部的财务、HR、CRM等核心系统。这时开发一组标准的内部MCP服务器比每个项目重复对接要高效和安全。功能本身就是一个长期运行的、有状态的网络服务例如一个实时监控告警系统AI需要从中订阅事件。这种情况下服务本身就是服务器为其增加MCP接口的边际成本较低。社区生态与工具链成熟之后如果未来MCP协议像REST API一样普及开发工具链SDK、调试工具、监控框架极其成熟那么为新服务增加MCP支持可能会像今天为服务增加Swagger文档一样自然。但这不是现在。5.3 一个务实的混合策略对于绝大多数开发者和团队我推荐的策略是CLI优先MCP备选。首先将你的能力封装成优秀的CLI工具。遵循前文所述的设计原则让它变得强大、可靠、AI友好。然后在AI工作流中优先通过调用这些CLI工具来完成任务。无论是直接让AI生成命令还是在自动化脚本中调用这都是最直接的路径。最后只有当出现“多个不同的AI客户端需要频繁调用此功能”的明确需求且维护多个直接集成方式成本过高时再考虑为你的CLI工具开发一个轻量的MCP包装服务器。这个服务器的大部分逻辑仅仅是转发请求到你的本地CLI工具。这个策略确保了你的核心逻辑始终位于最简单、最稳定的层次CLI而将协议层作为可选的、应对特定集成需求的适配器避免了本末倒置。6. 超越争论聚焦于“意图”到“执行”的可靠转化归根结底无论是CLI还是MCP抑或是其他协议如OpenAI的Function Calling它们都是工具目的是为了更顺畅地将人类的意图Intent转化为机器的执行Execution。这场讨论的意义不在于争出孰优孰劣而在于提醒我们不要被新奇的技术概念迷惑忘记了解决问题的本质。当前AI应用落地的核心瓶颈往往不在于缺少一个华丽的协议而在于任务分解的可靠性AI能否将模糊的人类指令准确分解为一系列可执行的具体步骤工具使用的正确性对于每一步AI能否选择正确的工具CLI命令、API等并生成正确的调用参数错误处理的鲁棒性当某一步执行失败时AI能否理解错误信息并采取合理的恢复或替代策略在这些问题上投入精力比过早地纠结于是否采用MCP协议更有价值。例如你可以精心编写工具的--help文档这是AI学习使用工具的最重要资料。为你的CLI工具添加--dry-run和--output json选项大幅提升AI使用的安全性和便利性。在AI提示词Prompt中提供常用操作的范例教AI如何正确地组合使用你的工具。建立工具能力的“地图”或“目录”用一个结构化的文件如JSON或YAML描述你所有CLI工具的功能、参数和示例让AI在规划任务时可以查询参考。这些实践能立即提升你现有工作流的智能化水平而且不依赖于任何特定的协议或框架。它们直指核心让AI更可靠地成为我们与复杂数字系统之间的“翻译官”和“执行者”。技术潮流总是一波未平一波又起。MCP协议代表了AI Agent领域基础设施标准化的重要探索有其长远价值。但作为一名常年在一线解决实际问题的开发者我的切身经验是在追求“智能”之前先确保“可靠”在引入“协议”之前先用好“工具”。命令行CLI这个诞生了半个多世纪的交互方式因其极致的简洁、灵活与可组合性在AI时代不仅没有过时反而被赋予了新的生命力。它或许不够“性感”但绝对是你能握在手里最坚实、最趁手的那把“瑞士军刀”。下次当你被一个新协议的光环所吸引时不妨先问一句我要做的事用几个脚本和CLI命令是不是已经可以做得又快又好了