MCP已死，MCP万岁！深度解析企业级 AI Agent 的工程化演进

#ai/agent #software-engineering #infra/ai

本文总阅读量次

译者按

在 AI 编程狂飙突进的今天，技术圈风向比翻书还快。半年前 MCP 还是当红基建，如今舆论却在技术大 V 的裹挟下倒向轻量级 CLI，将 MCP 批驳得一无是处。

本文作者以极具批判性的视角戳破了这场炒作泡沫。文章一针见血地指出：单兵作战的“凭感觉编程（Vibe-coding）”固然能靠 CLI 狂飙，但当团队迈向安全、可控、标准化的“智能体工程”时，服务端 MCP 在集中鉴权、全链路遥测及动态资源下发上的架构级优势，是任何本地脚本无法企及的。

希望这篇译文能为喧嚣工具潮中的开发者与技术管理者，提供一份穿越周期的清醒洞见。

Cite

原文链接：@chrlschn - MCP is Dead; Long Live MCP!
作者：Charles Chen
日期：2026-3-14

Tldr

业界正盲目炒作用 CLI 替代 MCP，但这仅适用个人的“凭感觉编程”。当迈向团队级“智能体工程”时，服务端 MCP 在集中鉴权、全链路遥测及动态资源下发上的优势无可替代。对企业级 AI 而言，MCP 绝非过时累赘，而是核心基建。

摘要

当前，社交媒体和业界正掀起一股狂热追捧 CLI（命令行界面）的风潮……正如就在短短几个月前，大家也曾对 MCP（模型上下文协议）趋之若鹜一样。
诚然，使用 CLI 确实能节省部分 Token，但许多人忽略了：使用自定义 CLI 的 Agent 同样会遭遇 MCP 那样的上下文瓶颈，而且由于缺乏结构化设计，还要以牺牲许多其他特性为代价。
在诸多讨论中，人们往往没有区分基于 stdio 的本地 MCP 和基于 HTTP 的服务端 MCP；这两者在应用场景上有着天壤之别。
许多人只对“MCP 工具 (Tools)”略知一二，却忽略了 MCP 提示 (Prompts) 与资源 (Resources) 的价值。它们是将开发模式从“草莽式的凭感觉编程 (cowboy vibe-coding)”向“组织级对齐的智能体工程 (agentic engineering)”转变的重要企业级机制。
MCP 的鉴权 (Auth) 机制的重要性常常被误解，遥测 (Telemetry) 在掌握全组织工具使用情况上的关键作用也常被忽视。
大家普遍的一个思维盲区是：代码 Agent 的个人单兵使用与组织级规模化采纳截然不同。后者高度强调可见性、遥测、安全性、质量，以及如何让技能水平参差不齐的团队，去运维并管理那些由 Agent 编写的系统。
对于企业和组织级的用例而言，MCP 就是现在与未来，团队必须拥有看透当下技术炒作周期的定力。

技术大 V 驱动的炒作周期

仅仅六个月前，大家三句话不离 MCP，似乎所有人都陷入了发布 MCP 相关产品和工具的狂热之中。在我供职的 Motion 公司，我们也深陷这场漩涡，几乎每个供应商都在变着法儿地想让我们购买或使用他们的 MCP 产品。

“这不过就是个 API 而已；既然我能直接调 API，干嘛还要在外面套一层壳？”

当那些供应商试图向我推销他们的 MCP 方案（通常还卖得很贵！）时，这成了我的标准回答。由于弄不清其真正的附加价值在哪里，我们完全避开了这一波 MCP 炒作，只是站在场外冷眼旁观。

然而，短短六个月后，业界关于 MCP 的风向似乎发生了 180 度的大转弯。到底发生了什么？

首先，大家发现，在大多数场景下，强行用 MCP 去包装 API 根本讲不通，纯属多此一举。与其生搬硬套 MCP，我们还不如直接给 REST API 端点写个轻量级的工具封装。

其次，我们需要退一步看清，如今这个领域在多大程度上是由那些“自我营销”的人和公司在推波助澜。多年来，AI 圈子的生态一直依赖于制造 FOMO（错失恐惧症）和无休止的炒作（而我们这些真正在一线使用和打磨工具的人常常看得满头问号）。这些技术大 V（Influencer）需要不断寻找新噱头来大放厥词，借此保持热度并推销他们自己、产品或服务。因此，你会看到行业风向标总是跟着当下的流量密码来回横跳。

从这个意义上讲，我把这些技术大 V（甚至包括 Garry Tan 和 Andrew Ng 这样本该更有见识的人）看作和那些推销伊维菌素包治百病或鼓吹反疫苗阴谋论的网红没什么两样：纯粹是无知。

现在，这股由大 V 驱动的风向又变成了“踩 MCP，捧 CLI”。必须澄清，这并非毫无根据，因为在许多场景下，CLI 作为 Agent 调用工具的接口确实更加合理……除了一些它不管用的特定场合。

厘清误区

在深入探讨之前，我想先亮明观点：对于某类特定的用例，MCP 确实是糟糕的选择。 但正如标题所暗示的，目前大众对于 CLI 工具究竟在哪能省成本、怎么省，以及 MCP 在推动企业向结构化“智能体工程”转型中的关键作用，存在极深的误解。

目前关于 CLI 与 MCP 之争的核心，其实都绕不开这两点：

CLI 到底能不能节省 Token 并提升效率。
MCP 是不是真的臃肿、复杂且一无是处。

Token 真的能省下来吗？

能。有三种模式确实能节省 Token，但效果远没有社交媒体上吹嘘的那么夸张。

训练集里自带的 CLI 工具

第一种情况是，像 jq、curl、git、grep、psql、aws、s3、gcloud 等常用 CLI 工具，它们极大地受益于大模型庞大的训练数据集。模型在训练时早已“阅码无数”，见识过海量使用案例。正因如此，Agent 不需要额外的指令、Schema（这在调用自定义 REST API 时是免不了的）或上下文提示就能熟练操作；在许多情况下，它可以直接一次性调用成功 (one-shot)。这比 MCP 能省下可观的 Token，因为在 MCP 中，所有工具都必须在 tools/list 响应里预先完整声明。

对于这些已经印在 Agent 脑子里的 CLI 工具，绝对要优先使用它们而不是 MCP（但如果是自定义的 REST API，那就不一定了）。

然而，如果是你自己写的、高度定制的 CLI 工具，这招就不灵了。LLM 根本不知道该用哪个 CLI 以及怎么用……除非你在 AGENTS.md、CLAUDE.md 或 README.md 的某个角落，为每个工具都写上了说明。你必须给 LLM 提供明确的指令，告诉它何时、如何使用这个它从未见过的定制 CLI。

你当然可以建一个 /cli-tools 目录，指望 Agent 靠那些见名知意的命名来自己挑工具。但任何每天和 Agent 打交道的人都清楚，如果没有明确指示，Agent 经常会在这上面翻车。它一犯错，你就得去更新你的 AGENTS.md，一次次地往里面塞更多的描述性文字。

除此之外，即便是 curl 这样的常见工具，一旦 Agent 需要去理解一个定制的 OpenAPI Schema 才能正确发请求，之前的 Token 优势也就荡然无存了。因为你必须把整个 OpenAPI Schema 塞进上下文，或者给 Agent 提供海量的上下文示例来教它怎么用。哎呀，你辛辛苦苦省下的上下文就这么没了。

链式提取与转换

在某些工作流中，可以通过串联多个 CLI 命令先检索数据，再通过转换或提取来过滤掉无用信息，从而减少挤占上下文窗口的数据量。这种情况确实能省下不少空间，但这也不是 CLI 独有的绝招：几乎所有格式化内容（HTML、JSON、XML 等）都可以通过标准库的选择器（如 DOM/CSS、JSONPath、XPath 等）进行提取。我不认为这是 CLI 方案不可替代的能力，只是一种常常被大家忽视的手段罢了。毕竟，直接把数据一股脑塞进上下文让 LLM 自己去悟，事后再优化，通常要省事得多。

渐进式上下文消耗

确实，当 Agent 试图摸索某个工具的用法时，CLI 允许它进行渐进式的上下文消耗。MCP 会强制在一开始就丢出全部的工具集和 Schema（这也正是它被骂“臃肿”的原因），而 CLI 工具则可以让 Agent 逐步把 --help 信息加载到上下文中。

// 截取自 MCP 官网的示例
{
  name: "searchFlights",
  description: "Search for available flights",
  inputSchema: {
    type: "object",
    properties: {
      origin: { type: "string", description: "Departure city" },
      destination: { type: "string", description: "Arrival city" },
      date: { type: "string", format: "date", description: "Travel date" }
    },
    required: ["origin", "destination", "date"]
  }
}

但现实很骨感：除非这是个在大模型训练集里大名鼎鼎的工具，否则 Agent 只能老老实实地（并且多轮交互地）一层层深挖 CLI 工具的帮助文档，去搞懂那些命令、子命令和参数。

这是绕不开的死结，不然 Agent 根本无从得知该如何使用你定制的 CLI 工具。

# CLI 的 --help 输出大概长这样：

command: searchFlights     Search for available flights
                           input: JSON object with origin, destination, date
                           example:
                           {
                              origin: "(string; required) departure city",
                              destination: "(string; required) arrival city",
                              date: "(date:yyyy-MM-dd; required) travel date"
                           }

不知你怎么想，但在我看来，这长得跟 MCP 的 Schema 简直一模一样……只不过失去了结构化约束。

你可能会说，我们可以不一口气加载完整 Schema，而是先列出所有命令，让 Agent 只对它想用的命令执行 --help，以此来避开沉重的负载描述：

# 渐进式加载，而不是一次性甩出完整 Schema

For usage:

flights <command> [--help]

commands: searchFlights      Search for available flights
          bookFlight         Book a flight
          ...

对此，我有 5 点要反驳：

一旦流程稍微复杂点，Agent 无论如何都会把整棵命令树遍历个遍。
如果 MCP 工具集一开始就设计得很合理，CLI 能省下的上下文其实微乎其微；Agent 反而在用 CLI 逐步探索命令和参数时，浪费了更多的交互轮次（Turns）。
如果不提前给 Agent 完整的 Schema，它用对工具的概率就会下降。就像 [Vercel 发现只要把完整的文档索引塞进 AGENTS.md，Agent 对文档的利用率就会提升] 一样，直觉也应该告诉我们：如果 Agent 一开始就手握所有可用工具和参数的全局视野，它自然能更精准地选中合适的工具。
为什么一开始要塞给 Agent 那些复杂又无用的 MCP 工具呢？CLI 和 MCP 并非水火不容。无论用哪个，保持工具集的精简克制才是王道。
在 Anthropic 现已提供 100 万 Token 上下文窗口的今天，这还能算作核心论点吗？

如果你依然觉得我说的缺乏细节，认为这一切并非炒作，那恭喜你成功沦为了当下 AI 网红 FOMO 炒作周期里的一颗鲜嫩韭菜；咱们半年后再见，等这些大 V 为了维持热度、博取你的眼球和钞票又开始鼓吹下一个“颠覆性概念”时，咱们再接着聊。

MCP 的双面性

在这波 MCP 狂热刚掀起时，我其实和所有人一样是个怀疑论者。当时，Motion（像其他追逐热点的团队一样）正忙着打造我们的“AI 员工”并搞各种集成。

当供应商们争相向我们推销他们的 MCP 集成方案时，我们不为所动，只是自己写了 REST API 的工具封装，然后用标准的 Bearer 令牌在 Header 里传递 API Key 或鉴权信息。那种狂热显得毫无道理，我当时极其怀疑 MCP 到底有没有未来可言。

特别是在 stdio（标准输入输出）模式下，MCP 显得累赘又多余。确实，在大多数场景中，基于 stdio 的 MCP 纯属画蛇添足，它比直接写个简单的 CLI 要复杂得多。

但是，基于流式 HTTP (streamable HTTP) 的 MCP 呢？这绝对是一个颠覆游戏规则的神器，它将成为企业和组织从“凭感觉编程 (vibe-coding)”跨入正规“智能体工程 (agentic engineering)”的关键支柱。

为什么中心化至关重要

（我需要提前声明，这主要是针对团队和企业的痛点；对于单打独斗的“草莽极客”来说没有任何意义）

大多数谈论 MCP 的大 V 都犯了一个致命错误：他们没有区分 MCP 在本地通过 stdio 模式通信，和通过流式 HTTP 通信这两种截然不同的形态。

在 stdio 模式下，MCP Server 和 Agent 一起跑在本地。既然都在本地，写个简单的 CLI 不香吗，搞这么复杂干嘛？

但如果是基于流式 HTTP 传输，我们就可以将同样的逻辑运行在中心化的服务器上。一旦在这个模式下被 Agent 调用，将会解锁一系列全新的能力。

更深厚的基础能力

如果你的业务场景需要访问 Postgres 数据库怎么办？如果还需要启用 Apache AGE 并对建立了索引的上下文执行 Cypher 图查询呢？只要把工具集中部署在服务端，然后让瘦客户端去访问，这一切就变得轻而易举。由于分发方式简化到了只需让 Agent 指向一个 HTTP 端点并附上鉴权 Token，我们完全可以为工具构建更强大的底层平台能力。

诚然，像 SQLite 这样的本地数据库或许也能应付，但它的上限很低，且要在整个组织内共享状态会变得异常困难。

短暂的/无状态的 Agent 运行时

基于 HTTP 的远程 MCP Server 还能在特定的运行环境中展现出巨大优势。

比如，当你需要将远程工具和 API 暴露给跑在 GitHub Actions 里的 Agent 时。GitHub Actions 的环境是短暂且用完即毁的（ephemeral）。借由 MCP，你可以极其轻松地调用那些依赖复杂后端的工具，免去了繁琐的安装过程，也彻底摆脱了短生命周期环境的束缚。

它完美地将无状态、瞬态环境下的“有状态负载”管理任务，剥离并下放给了中心化服务器。

鉴权与安全

将工作负载移至服务端，也从根本上优化了鉴权和安全策略。举个例子，如果用 CLI 结合 curl 去访问加密的 API 端点，就意味着每个开发人员的电脑上都得存有这些 API 的密钥（除非你在中间又搭一个代理服务器）。傻子都能看出来这有多不安全，运维团队更是会为此抓狂。

将这些能力隐藏在 MCP 之后，每个开发者只需通过 OAuth 登录 MCP Server。敏感的 API 密钥和凭证就像普通服务端 REST API 一样，被安全地封锁在服务器后端，用标准的 OAuth 体系进行管控。密钥暴露的风险被大幅压缩、限制，并且极度便于审计。

哪怕有工程师离职了？没关系，直接撤销他的 OAuth Token 和对 MCP Server 的访问权限即可；反正他从头到尾也没摸到过底层真正的密钥。

遥测与可观测性

对于研发团队而言，中心化流式 MCP 的另一个巨大杀手锏是它的遥测和可观测性。到底哪些工具真管用？团队究竟在用哪些 Agent 运行时？哪些工具完全是鸡肋？工具报错是在哪一步、因为什么报错？如果没有一套中心化、标准化的遥测体系，工程团队根本两眼一抹黑。

而有了中心化的 MCP Server，这不过是顺手吐出 OpenTelemetry（OTel）链路追踪和指标，然后拿现成的工具收集一下的常规操作罢了。

尽管用 CLI 也能做到这点，但只要部署单点服务器就能解决的事，何必自找麻烦？因为本地分发意味着你得强迫用户去更新，以往只需在中心节点搭一次的基础设施，现在得在团队发版的每一个 CLI 工具上重复造轮子。

标准化、即时同步的最新内容交付

分布式工具（比如通过包管理器分发）和分布式应用面临着同样的痛点：如何保证用户的部署永远是最新的，并且 API 兼容器不出岔子。更新一台服务器来增加新功能很容易，但如果这些功能是打包成一个个本地 CLI 工具发给用户，那 API 版本兼容性就会成为一个大雷。

MCP 在协议层面就考虑到了这一点：它提供了订阅与通知机制，允许服务器主动回调客户端以推送更新。

绝大多数人都听过 MCP 工具 (Tools)，但只有极少数人懂得利用 MCP 提示 (Prompts) 和 MCP 资源 (Resources)。

仔细研究一下规范，你会发现：

MCP Prompts 本质上就是服务端下发的 SKILL.md（技能设定）
MCP Resources 本质上就是服务端下发的 /docs（文档库）

组织、团队或企业为什么会需要这个？

好处简直不言而喻：

动态内容分发。代码仓库里的 *.md 只是静态文本，需要人工维护和同步。但服务器生成的 Prompts 和 Resources 则彻底挣脱了这层枷锁。你完全可以即时动态拼装文本来赋能 Agent。文档呢？如果有些文档只在特定上下文有用怎么办？如果文档能在不发起工具调用的前提下，自动注入动态数据（如实时报价、系统当前状态等）岂不是美哉？
强制的自动一致性。当 *.md 文件跟着代码库或安装包一起下发时，最大的隐患就是版本脱节，需要开发者在本地手动拉取同步。而基于 MCP 下发的技能和资源则永远保持最新。那官方的第三方文档和技能库呢？你打算在自己的仓库里徒手 copy-paste 并维护它们吗？直接通过服务器代理不是香得多吗？
对齐组织级知识库。有些内容是全公司通用的。比如，应用安全红线、遥测埋点规范，或者基础设施的部署规范。如果你们用的是微服务架构，A 团队常常需要查阅 B 团队的接口文档怎么办？如果服务团队能在每次发版时，动态对外输出他们服务的最新“调用技能”呢？把这些文档复制粘贴到几十上百个仓库里真的合理吗？整个公司要怎么保证它们不出现版本撕裂？

MCP，就是这一切的终极答案。

如果你希望跨越所有代码库、所有工作流、所有团队、所有 Agent 前端（Claude Code、Codex、VS Code Copilot、GitHub Agents、OpenCode 等），稳定地下发标准的规划 Prompt（技能）和文档，保证它们永远最新，并且能通过服务端遥测来监控全公司的使用规范与频率——那么 MCP 的 Prompts 和 Resources 就是你唯一需要的基建。

上述这些资源的本质，都是动态生成的可用文档的“虚拟索引”（类似于 Vercel 放在 AGENTS.md 里的设计），但它的降维打击在于：我们可以将这些文档丝滑注入任何项目，永不落后，并且自带详尽的服务端遥测追踪。

在所有这些场景中，你所需要做的，仅仅是配置一下 MCP 的客户端；配置完即可撒手不管 (fire and forget)，客户端不需要承担任何维护更新的压力。

结语

我懂，现在的技术圈一天一个样，那些社交媒体大 V 如果不赶紧蹭点新热点，观众就要跑光了。半年前，MCP 还是当红炸子鸡；转眼间，它就成了昨日黄花，被扣上“导致上下文膨胀”的帽子，而人们在跟风唾骂时，却压根没仔细权衡自定义 CLI 方案背后潜藏着一模一样的天坑。盲从的群众似乎在工程纪律方面丧失了基本的批判性思考能力。

但只要静下心来推演一下：团队该如何将研发模式从“草莽式凭感觉编程 (vibe-coding)”平稳过渡到正规的“智能体工程 (agentic engineering)”？只要推演过，你就会无可救药地落在 MCP 的设计理念和使命上。只要脱离了单兵作战的范畴，MCP 自带的遥测能力、极简的安全管理模型、内容的自动同步、基于 Schema 和标准的统一架构，以及唾手可得的可观测性（不然你怎么评估哪些工具真有效？），都在说明一件事：那些为了追逐当前 CLI 狂热而抛弃 MCP 的团队，在搭建智能体工程基建时，正在犯下一个巨大的错误。

我们目前仍处于 AI Agent 在软件研发中挑大梁的极早期阶段。因为技术迭代太快，行业内弥漫着一种“唯快不破”的氛围。但正如亚马逊 AWS 部门最近暴露出的事故所警示的那样，团队迟早得站出来，去接手、运维和管理这些由 AI Agent 搓出来的系统代码。

对于 Garry Tan 或 Andrew Ng 等人关于 Agent 的建议和轶事，听听就好，别全信 (take with a grain of salt)：对他们个人在同质化环境中管用的绝招，放到异构环境中的团队和组织里往往会水土不服。因为企业级环境的终极目标，是保证一群技术水平、经验背景各异的工程师，能稳定输出高质量的代码底座。

如果在系统上线后，我们的核心目标依然是交付可靠且易于维护的软件——那么哪怕代码是 AI Agent 写的，我们同样需要一套死磕一致性、安全性、高质量和准确性的工程纪律。组织必须跳出“野生牛仔式”的编码作坊，搭建起能够对齐整个组织的“智能体工程”架构和流程。

而在当下，MCP 就是组织和企业实现这一目标的唯一正解。

MCP 万岁！