2026年9月中旬，一篇名为《Why MCP Was Always a Bad Idea》的博客在Hacker News冲上首页，短时间内积累了183分与134条评论。作者Maharshi Patel的主张非常直接：开发者应该删掉大部分MCP server，转而让智能体直接通过HTTP API和CLI工作。这种观点的爆发点在于大模型能力的显著跃升。曾经被视为Agent标准外设的Model Context Protocol，在满权限的终端智能体面前，似乎正在变成一层多余的抽象。
模型自己看文档写脚本，中间层显得多余
MCP于2024年11月25日由Anthropic正式发布，并在2025年12月9日正式捐赠给Linux Foundation旗下的Agentic AI Foundation。在协议初创的时期，大模型展现出的自主规划能力还不够成熟，业界甚至连Claude Code这样的原生工具都未大量普及。在那种技术背景下，通用智能体工作流在复杂工程环境里远不够可靠。开发者迫切需要MCP这层标准协议，将复杂多变的外部服务接口，包装成模型能够稳定理解和调用的Schema格式。
图：Anthropic 2024 年 11 月发布 MCP 时的官方配图。来源：Anthropic 官方公告页
模型智力水平跨代升级后，业界采纳度陡增，但随之而来的是严重的上下文膨胀问题。由于每个服务器都会带入多个工具，而每个工具又自带繁琐的属性声明，模型宝贵的上下文很快被各种Schema塞满。为了缓解这种内存压力，工程侧不得不引入诸如Composio、MintMCP或Pipedream等框架侧的通用搜索与执行模式。模型阅读原始文档和现学现卖的能力，已经足以覆盖人工编写中间层协议的大部分机械劳动。
进一步观察发现，新一代模型变得非常擅长直接调用未经深度封装的原生API。Cloudflare在2025年9月26日发布的Code Mode，展示了让大语言模型把多次跨域调用组合成一段代码，直接在沙箱里执行的场景。现在的模型能够熟练使用--help命令自己发现CLI工具的用法，并直接与系统底层交互。这些变化让前端和协议开发者开始反思接口封装的必要性。
图：原文作者开篇使用的电影台词截图，表达”我受够 MCP 了”。来源：maharship.com 原文
基于这些观察，作者Maharshi Patel抛出了引发争议的主张：大多数远端服务的MCP server说到底只是包了一层已经存在的API，不如直接跳过。他建议社区标准化智能体直连HTTP API的方式，比如广泛采用Accept: text/markdown请求头，让各大文档站直接返回适合模型阅读的文本格式。Vercel工程师Malte Ubl提议将智能体的首选编程语言放进Accept-Language头中，Shopify的Tobi Lutke当场表示会在自家文档系统上支持。只要接口自身足够语义化，去中间层化正在成为一线开发者的共识。
放任直接调API，安全与审计底线全面失守
面对删掉MCP的呼声，开源领袖Simon Willison在Hacker News给出了最高赞的反驳。他一针见血地指出，原文漏掉了MCP今天在工程架构上提供的最核心价值。如果你在本地跑的是像Claude Code或Codex这样的全权限终端智能体，并且毫无保留地对它们放开了互联网访问权限，那确实没必要再搭建一层MCP。在这种极限单兵作战的YOLO场景下，模型直接用Python脚本调用各种API拥有高得多的执行效率。
但Simon强调，一旦我们要做的系统涉及严肃的企业流程，合规要求与安全红线就会立刻阻断直连方案。他提出了四项支撑企业级部署的核心需求：第一是精确控制智能体能访问哪些外部服务，第二是一种避免让智能体直接拿到明文API密钥的认证方式。在严肃的生产环境中，系统权限的物理隔离与访问控制，始终比模型调用的便利度具有更高的工程优先级。
除了权限隔离，第三项需求是必须提供让终端用户连接并进行二次授权的合理界面，第四项则是能够记录所有操作细节的强审计日志。如果像原文主张的那样，放任模型自行组装网络请求去调用零散的HTTP接口，想要实现集中式的认证管理和防篡改审计，是一项不可能落地的防御任务。MCP通过设立一个必须经过的集中式服务端代理，让这四件繁琐的防御工作具备了标准解法。
从防御工程的角度来看，网络安全原则向来不信任任何黑盒客户端，而大语言模型智能体本身就是一个充满不可预见性的巨大黑盒。把高权凭证直接下发给这个黑盒，等同于在企业内网部署了一个随时可能失控的脚本引擎。Simon的四项要求，本质上是将现代微服务架构中的API网关理念，重新应用到了大语言模型驱动的自动化系统中。
限制工具箱边界，让智能体在确定性轨道上运行
在这场论战中，反对原文一派的开发者频繁抛出一种经典的工程悖论：所谓MCP多余，无非是你只要用别的方式把MCP做的事全做一遍，你就不需要MCP了。这种充满火药味的说法，精准点出了中间层协议不可替代的基础逻辑。大型团队要在生产环境上线的系统，恰好必须去完成统一鉴权、接口收敛与行为监控这些MCP原生支持的基础设施建设。
另一条更激烈的社区意见认为，如果同一种系统交互行为能够提前写成确定性的程序逻辑，系统就不应该为模型的冗余推理反复消耗昂贵的Token。公司内部把常见系统运维工具做成MCP服务的理由非常务实，即把最常用的99%标准操作全部固化。让智能体在不够理想的遗留API上反复摸索试错，直接拔高了输出不稳定的风险，这在工程经济学上缺乏合理的解释。
部分评论还指出，引入诸如Linear等SaaS服务的标准MCP链接，能够让工具发现、调用传参以及上游API版本变更，在智能体侧自动保持同步。这种本地无需安装环境、无需繁琐配置的即插即用体验，大幅削减了跨系统的集成门槛。集中维护协议抽象边界的模式，在规模化部署时，依然优于让每一个散养式的智能体单独摸索原始接口。
从业务逻辑收敛的角度看，并不是所有的后端API都适合全盘暴露给大语言模型。有些接口涉及高危的数据库表写入，有些涉及敏感的客户隐私字段。通过MCP编写特定的Server，开发者实际上给模型定制了一套只暴露白名单动作的受限工具箱。这种裁剪过的工具集，能够降低模型面对海量接口时的选择瘫痪，在统计学层面提升了多步任务的成功率。
虚拟化基础设施隔离，终端智能体有另一种解法
在进阶的工程实践中，许多资深工程师把MCP当作工具调用的对立面，即作为终端智能体的安全沙箱与虚拟化隔离层。终端智能体由于内建了WebSearch、Bash命令执行和Grep等基础能力，它们本质上也在进行跨系统的操作调用。在没有任何约束的企业内网部署中赋予模型原生Bash执行能力，其代价是运维团队丧失对系统变更的控制权。
一位参与讨论的系统工程师分享了一个极具代表性的沙箱化部署案例。他在云端跑着一批被严格隔离的Claude Code实例，这些实例之间并不直接通信，而是通过一组特定的MCP工具相互协作，并共享项目数据文件。这些文件在物理层面存储在AWS S3对象存储上，但通过MCP的协议隔离层，智能体无从得知文件存放于外部网络，更不了解AWS的底层细节。
在这个虚拟化架构中，模型只能通过类似agentfiles://这样的抽象URI前缀发起读写请求，而外层协调器拦截这些请求并负责处理所有真实的网络传输。这种设计的精妙之处在于，外层协调器在静默代理请求的同时，完成了从租户权限校验、流量阻断到日志记录的所有后备工作。通过协议层制造信息差，能够有效约束模型的物理行动边界。
如此严格的隔离机制，将智能体牢牢限制在一个虚拟化的文件系统上下文中。即使模型在长程任务中出现了严重的幻觉，或者遭受了恶意的提示词注入攻击，其破坏范围也被物理锁死在当前的虚拟沙箱内。这不仅展示了MCP存在的价值远超方便接口调用，更证明了它如何作为基础设施安全隔离的一道厚重防火墙，横在失控模型与核心业务数据之间。
剥离部署前提谈优劣，只会陷入无效论战
横跨近两年的技术路线之争，表面上探讨一种通讯协议的生与死，实则是针对大模型工程化落地路径的严重分歧。随着多层工具堆叠导致的上下文资源过度消耗，前端和原型开发者切实感受到了协议抽象层带来的性能阻力。但在另一面，诸如Composio等框架通过优化搜索模式缓解性能下降，生态系统本身依然具备自我演进的生命力。
“MCP过时”这个夺人眼球的论断，从始至终只在”满权限终端Agent”这一个非常具体的特定前提下才站得住脚。**当模型进化到能自己分析数据流、直接拼装复杂的HTTP请求后，额外的协议约束对于追求极限迭代速度的开发者而言确实退化成了多余的中间件。**在本地电脑跑一个高权限代码助手，确实不再需要重度集成的后端架构。
只要系统的部署目标从原型验证阶段的单点突破，转变为企业级生产环境的严格可控，一切技术选型的天平就会瞬间反转。**当业务系统必须物理隔离API密钥并要求所有调用可溯源审计时，这层看似累赘的抽象就重新变成最安全的落点。**大公司不会允许一台能够随意组装HTTP包的AI机器在生产网内自由漫游。
这场论战的核心分歧根源在于两种截然不同的部署前提，并非底层协议机制本身的功能短板。原文作者关注的是模型如何打破结构束缚去主动探索世界，而以Simon为代表的工程派，考虑的则是如何在失控的边缘建立稳固的制动机制。决定我们是否需要MCP的核心要素，在于不同工程团队对部署前提的根本分歧。
参考链接：
- Why MCP Was Always a Bad Idea（原文博客）
- Hacker News 讨论帖
