Anthropic公司推出的Model Context Protocol（模型上下文协议，简称MCP）正走向终结，命令行接口（Command Line Interface，简称CLI）重新成为智能体交互的黄金标准。
作者通过亲身实践发现，大型语言模型（Large Language Model，简称LLM）凭借对海量技术文档的训练，已具备直接操控传统CLI工具的能力，无需额外协议层。CLI工具在人类可读性、调试便捷性、管道组合能力、身份验证兼容性以及系统稳定性方面全面超越MCP方案。MCP服务器存在启动故障频发、重复认证繁琐、权限控制粗糙等现实痛点。企业应优先投资CLI工具开发，让智能体自主学习和适配现有生态。
那个让全行业疯狂的协议正在凉透!
我要说一个可能让你惊掉下巴的事实：MCP正在死去。OpenClaw（一款开源AI辅助编程工具）不支持它，Pi（一款个人AI助手产品）也不支持它，而且这背后有着充分的技术逻辑支撑。当Anthropic这家以Claude系列模型闻名的AI公司在2024年底宣布MCP规范时，整个科技行业仿佛被按下了集体狂欢按钮。每一家公司都在疯狂冲刺，争相发布自家的MCP服务器，仿佛没有MCP就不配被称为AI原生企业。海量工程资源被投入到全新的API端点开发、全新的数据传输格式设计、全新的授权认证方案构建中，所有这一切努力的目标，竟然只是为了让那些本来就能直接对话的大语言模型能够以另一种方式对话。
我必须坦白，从一开始我就没搞懂这玩意的必要性在哪里。你知道大语言模型最擅长什么吗？自主学习和理解事物。给它们一份文档，给它们一个命令行工具，它们就能像老司机一样直接上路狂奔。我憋了很久不想写这篇文章，因为唱反调总是需要勇气。但经过长时间观察和实践，我越来越确信MCP并没有带来任何现实世界的好处，我们反而因为引入这层不必要的抽象而变得更加麻烦。让我慢慢给你拆解这里面的门道，看看为什么一个看似美好的协议反而成了开发者的负担。
LLM根本不需要什么特殊协议来干活
大语言模型使用命令行工具的能力简直强到离谱。这些模型在训练过程中啃下了数以百万计的技术手册页面、Stack Overflow（一个程序员问答社区）上的解决方案、以及GitHub（全球最大的代码托管平台）上密密麻麻的Shell脚本仓库。当你告诉Claude（Anthropic开发的AI助手）去执行gh pr view 123这条命令时，它立刻就能明白这是在查看编号为123的Pull Request（代码合并请求），而且执行起来毫无障碍。MCP当初承诺要提供更清晰的接口规范，但在实际工作中我发现自己还是得写一大堆说明文档：每个工具是干嘛用的，接受哪些参数，更重要的是在什么场景下应该调用它。这层新协议没有减少任何工作量。
大语言模型具备强大的上下文理解能力和工具使用直觉，它们能够从自然语言描述中准确映射到对应的命令行操作。MCP试图通过结构化JSON（一种数据交换格式）来规范工具调用，但这种规范化反而增加了学习成本。开发者需要同时维护CLI文档和MCP工具描述，而LLM其实只需要前者就能完美工作。这种重复劳动让整个开发流程变得臃肿，却没有换来相应的生产力提升。我们给AI套上了一层又一层的技术枷锁，却忘了它们本来就是为理解人类指令而生的。
CLI工具是人类和AI都能读懂的共同语言
当Claude在处理Jira（一款项目管理软件）任务时出现了意外行为，我可以立即在终端里输入完全相同的jira issue view命令，亲眼看到Claude刚才看到的内容。同样的输入产生同样的输出，没有任何黑箱操作，没有任何神秘感。这种透明度让调试工作变得异常轻松，我能够一步步复现AI的决策路径，找出问题到底出在哪里。CLI工具就像一座桥梁，让人类开发者和AI智能体站在同一片土地上观察世界，我们共享着完全相同的视角和信息来源。
MCP把工具调用封装在LLM对话的密闭空间里，一旦出了问题，你就得像个考古学家一样在JSON传输日志里挖掘线索。那些密密麻麻的协议数据包让人眼花缭乱，你需要理解MCP的通信机制才能排查故障。这种调试体验简直是一场噩梦，你本可以直接运行命令验证结果，现在却不得不先学习一套全新的协议解码技能。好的工具设计应该降低认知负担，而不是强迫开发者成为协议专家。CLI的简洁性让问题定位变得直观，这才是符合人性的工程实践。
管道组合能力是CLI的杀手锏
这里才是真正的技术鸿沟所在。CLI工具天生支持管道组合，你可以把多个命令像乐高积木一样拼接起来。通过jq（一款JSON处理工具）进行数据过滤，通过grep（文本搜索工具）进行模式匹配，通过重定向符号把输出保存到文件。这种能力不仅仅是方便而已，在很多场景下这是唯一可行的工程方案。想象一下你需要分析一个庞大的Terraform（基础设施即代码工具）执行计划，这个JSON文件可能包含成千上万行资源变更记录。使用CLI管道，你可以精准提取所需信息，而不用把整个文件塞进AI的上下文窗口。
看看这条命令的威力：
terraform show -json plan.out | jq '[.resource_changes[] | select(.change.actions[0] == "no-op" | not)] | length' |
这行代码先把Terraform计划转换成JSON格式，然后通过jq过滤掉那些无变更的操作，最后统计真正会发生改动的资源数量。整个过程行云流水，利用了现有生态系统中成熟稳定的工具链。如果换成MCP方案，你的选择只有两个：要么把整个庞大的计划文件塞进上下文窗口（这会产生昂贵的token消耗，而且经常超出长度限制），要么在MCP服务器里重新实现一套自定义过滤逻辑。无论选哪条路，你都在做更多的工作，却得到更差的结果。CLI方案使用现成工具，文档齐全，人类和智能体都能轻松理解。
身份验证这套东西早就已经很成熟了
MCP在身份验证方面表现得过于自以为是。一个用来给LLM提供工具调用的协议，为什么要深度介入认证流程的设计？这完全超出了它的职责范围。CLI工具对此采取了一种更聪明的姿态：它们只管提供功能，认证的事情交给专门的机制去处理。aws命令行工具使用配置文件和SSO（单点登录）方案，gh命令行工具使用gh auth login进行GitHub账号授权，kubectl（Kubernetes集群管理工具）使用kubeconfig文件管理集群凭证。这些都是经过生产环境千锤百炼的认证流程，无论是我坐在键盘前手动操作，还是Claude在后台自动驱动，它们的工作方式完全一致。
当认证出现问题时，我可以用熟悉的方式修复：执行aws sso login刷新令牌，或者运行gh auth refresh更新授权状态。我不需要学习任何MCP特有的故障排查技巧，不需要理解协议层的认证状态机，不需要面对一套全新的错误代码体系。这种一致性极大地降低了运维复杂度，让AI集成变得无缝且可靠。好的架构设计应该复用现有基础设施，而不是为了创新而创新，把简单问题复杂化。CLI生态 decades 积累下来的认证最佳实践，正是MCP所缺乏的工程智慧。
没有后台进程就没有稳定性烦恼
本地运行的MCP服务器本质上是一个持续驻留的进程。它需要成功启动，需要保持运行状态，不能悄无声息地卡死。在Claude Code（Anthropic推出的编程助手工具）中，这些服务器以子进程的形式被 spawned（生成），这种机制在大部分时间里工作正常，直到它突然不正常。进程管理引入了全新的故障模式：内存泄漏可能导致服务变慢，网络波动可能导致连接断开，状态同步可能出现竞态条件。这些问题在简单的命令调用中根本不存在，现在却成为了日常开发中的不稳定因素。
CLI工具只是磁盘上的二进制可执行文件。当你需要它们时，操作系统加载程序到内存，执行完毕后立即释放资源。没有后台守护进程占用内存，没有状态文件需要清理，没有初始化仪式需要执行。它们在你需要时即刻可用，在你不需要时完全隐形，不会消耗任何系统资源。这种简单性带来了极高的可靠性，符合Unix哲学中"只做一件事并做好"的设计原则。MCP引入的进程模型看似提供了更强大的能力，实际上却带来了更多的运维负担和故障点，让本可以简单的工具调用变得脆弱且不可预测。
日常使用中的真实痛苦远超想象
抛开设计理念层面的讨论，MCP在实际工作中带来的摩擦感是具体而尖锐的。初始化过程充满不确定性，我已经数不清有多少次因为MCP服务器没能正常启动而被迫重启Claude Code。有时候重试一次就能解决问题，有时候却需要清除状态缓存从头开始，这种不可预测性严重干扰了开发心流。每一次工具调用前的等待都伴随着焦虑，你不知道这次会不会又卡在启动阶段。
重复认证简直是无休止的折磨。当你需要同时使用多个MCP工具时，就得为每一个单独完成认证流程。相比之下，配置了SSO或长期凭证的CLI工具只需要认证一次，之后就能无缝工作数月之久。权限控制也是一团糟，Claude Code允许你按名称允许或禁止某个MCP工具，但粒度就到此为止。你无法限制只能执行读取操作，无法约束特定参数的范围，无法实施最小权限原则。使用CLI方案时，我可以精细配置允许gh pr view（查看代码请求）但要求人工确认才能执行gh pr merge（合并代码），这种颗粒度的控制对安全生产至关重要。
MCP在什么时候确实能派上用场
我并不是说MCP毫无价值可言。如果某个工具确实没有对应的CLI实现，MCP可能就是唯一可行的集成方案。在我日常工作中，当面对那些只有API接口没有命令行工具的服务时，我依然会选择使用MCP。在某些特定场景下，标准化的接口规范确实能够简化集成工作，特别是当需要统一封装多个异构系统时，MCP提供了一层有用的抽象。
我甚至愿意承认，在少数使用案例中，MCP可能比CLI方案更合适。比如当工具需要维护复杂的会话状态，或者需要流式传输大量数据时，MCP的长连接模型可能比频繁的进程启动更高效。但这些场景相对罕见，不足以支撑MCP成为行业标配的野心。对于绝大多数开发工作而言，简单的命令调用已经绰绰有余，额外的协议层只会带来不必要的复杂性和开销。
真正的教训：好工具应该同时服务人类和机器
最优秀的工具是那些对人类和机器同样友好的工具。CLI经历了数十年的设计迭代和优化，沉淀出一套成熟的使用范式。它们具备强大的组合能力，调试过程直观透明，能够无缝接入现有的身份验证基础设施。这些特性不是偶然得来的，而是无数开发者在使用过程中不断反馈和改进的结果。MCP试图从零开始构建一个更好的抽象层，却忽视了CLI生态已经解决的那些基础问题。
事实证明，我们已经拥有了一个相当优秀的工具形态。CLI的设计哲学强调文本流、管道组合、单一职责，这些原则让工具之间能够无缝协作。大语言模型恰好擅长理解和生成文本，这与CLI的接口设计完美契合。我们不需要为了AI时代重新发明轮子，只需要确保现有的工具保持良好的文档和一致的接口设计，智能体就能自然而然地学会使用它们。技术的演进应该是渐进式的改进，而非革命式的替换。
给工具开发者的肺腑之言
如果你所在的公司正在投入资源开发MCP服务器，却还没有提供官方的CLI工具，请立即停止并重新思考你们的优先级。正确的做法是先发布一套设计良好的API，然后基于这套API构建高质量的命令行工具。让API成为能力的唯一真实来源，让CLI成为人类和AI共同的操作界面。当CLI存在且文档完善时，大语言模型完全有能力自主学习和适配，它们会搞清楚如何调用这些工具来完成任务。
不要低估LLM的理解能力和适应性。它们能够从帮助文档中推断出正确的使用方式，能够从示例代码中学习到最佳实践，能够在遇到错误时根据提示信息自我修正。与其为AI专门设计一套协议，不如把精力放在提升CLI的用户体验和文档质量上。这样做不仅服务了AI开发者，也服务了所有使用命令行的工程师。一个优秀的CLI工具能够同时满足人类和智能体的需求，这才是面向未来的正确投资方向。