MCP 已死，CLI 万岁 转载与翻译说明：本文根据原文《MCP is dead. Long live the CLI》翻译整理。原文发布于 2026-02-28，链接：https://ejholmes.github.io/2026/02/28/mcp-is-dead-long-live-the-cli.html。 我先抛一个大胆判断：MCP 已经在走下坡路了。我们可能还没有完全意识到，但信号已经出现了。OpenClaw 不支持它，Pi 也不支持它。而且理由很充分。 Anthropic 宣布 Model Context Protocol 之后，整个行业几乎集体上头。每家公司都在抢着上 MCP server，拿它来证明自己“AI first”。大量资源砸进了新的 endpoint、新的传输格式、新的授权方案，只为了让 LLM 去调用那些它本来就能调用的服务。 我承认，我一直没完全理解这件事的必要性。你知道 LLM 真正擅长什么吗？自己把事情摸清楚。给它一个 CLI，再给一点文档，它就能一路跑起来。 我拖了很久才写这篇，但我现在确信：MCP 在真实世界里并没有带来实质收益，我们没有它反而会更好。下面我来展开说。LLM 并不需要特殊协议 LLM 很擅长使用命令行工具。它们见过几百万份 man page、Stack Overflow 回答，以及 GitHub 里的 shell 脚本。比如我让 Claude 执行 gh pr view 123，它通常就能直接跑通。 MCP 承诺了一个更“整洁”的接口，但在实践中我还是得写同样的文档：每个工具做什么、参数是什么，最重要的是在什么场景该用它。LLM 并不需要一个新协议才能理解这些。CLI 也是给人用的 如果 Claude 在 Jira 上做了奇怪操作，我可以直接跑同一条 jira issue view 命令，看它当时到底看到了什么。相同输入、相同输出，没有黑箱。 换成 MCP，工具只存在于 LLM 对话上下文里。一旦出错，你就得钻进 JSON 传输日志里排查，而不是自己把命令跑一遍。调试不应该需要一个协议解码器。可组合性 这里差距会迅速拉大。CLI 天生可组合。你可以接 jq，链 grep，重定向到文件。这不只是方便，很多时候还是唯一可行的办法。 比如分析一个很大的 Terraform plan：terraform show -json plan.out | jq '[.resource_changes[] | select(.change.actions[0] == "no-op" | not)] | length' 在 MCP 模式下，你的选择通常是：把整个 plan 塞进上下文窗口（昂贵，且常常不可能），或者把定制过滤逻辑写进 MCP server 本身。两条路都更费劲，结果还更差。CLI 方案直接复用现有工具，文档完善，人和 agent 都能看懂。认证早就能用 MCP 在认证问题上显得过度“有主见”。一个给 LLM 提供工具调用能力的协议，为什么要顺带规定认证方式？ CLI 工具并不关心这个。aws 用 profiles 和 SSO，gh 用 gh auth login，kubectl 用 kubeconfig。这些认证流程已经在大量生产场景里验证过，无论是我手动操作还是 Claude 驱动，行为都一致。认证坏了，我就按老办法修：aws sso login、gh auth refresh，不需要 MCP 专用排障。没有额外活动部件 本地 MCP server 是进程。它们要能启动、要持续运行、还不能默默卡死。在 Claude Code 里，这些 server 作为子进程拉起，能跑是能跑，但并不总是稳定。 CLI 工具只是磁盘上的二进制文件。没有后台进程、没有状态管理、没有初始化舞步。你需要它时它就在，不需要时它不会打扰你。现实中的摩擦成本 除了设计理念之外，MCP 在日常使用里还有很多真实摩擦： 初始化不稳定。 我已经记不清为了等某个 MCP server 启起来而重启 Claude Code 多少次了。有时重试就好，有时只能清状态重来。 反复重新认证。 你用了多个 MCP 工具？那就准备给每个都重新认证。CLI 配合 SSO 或长效凭证通常不会这样。认证一次，后面就能持续使用。 权限控制过于粗糙。 Claude Code 可以按工具名 allowlist MCP 工具，但也仅此而已。你没法把权限限定为只读操作，也很难限制参数范围。CLI 则可以更细：我能放行 gh pr view，但让 gh pr merge 必须人工审批。这种粒度很关键。那么 MCP 什么时候有意义？ 我不是说 MCP 完全没用。如果某个工具确实没有 CLI 等价物，MCP 可能就是正确选择。真到“只有它可用”的…