一句话：能开终端、网络不设限的智能体，大多可以直接调用有文档的 API 和命令行工具，MCP 并非必需；但一旦你需要限定访问范围、隔离凭据、留出授权入口和审计记录，MCP 依然是成本最低的答案。2026 年 9 月这轮争论，本质上是在争「你愿意让智能体碰多少东西」。
关键事实
| 项目 | 内容 |
|---|---|
| 回答的问题 | 2026 年了，MCP 还值得用吗？ |
| 简答 | 取决于你给智能体多大自由度。如果你用的是能开终端的智能体、网络权限也不设限，让它直接调用有文档的 API 和命令行工具往往更简单——这正是批评方的核心观点。但如果你要限定它能访问哪些外部服务、不让它拿到原始 API 密钥、给人留一个授权入口、事后还要能查清它做了什么，MCP 依然是最省事的做法。不少团队最后是两者并用。 |
| 阅读时长 | ~3 分钟 |
| 最后更新 | 2026-09-23 |
批评的一方：MCP 从设计之初就过时了
2026 年 9 月 14 日，Maharshi Patel 发了一篇 Why MCP Was Always a Bad Idea。论证分三步。
第一，MCP 诞生于 2024 年 11 月，那时候模型还弱、智能体流程也远没现在稳定，协议是为那个阶段设计的。第二，普及之后出现了上下文挤占：每个服务器都带好几个工具、每个工具都有自己的参数结构，装得多了，还没开始干活上下文就被吃掉一大块。第三，也是最关键的一点——模型变了。它们会写脚本、会直接调 API，还会用 –help 摸清命令行工具的用法；而大多数远程 MCP 服务器封装的本来就是现成的 API。所以作者的结论很直接：把大部分 MCP 服务器删掉，改为规范智能体直接调 HTTP API 的方式，比如让服务端支持 Accept: text/markdown，文档站直接返回 Markdown 而不是 HTML。
值得完整读一遍，而不是只看标题。作者同时认为「网关模式」——把凭据集中放一处、只暴露一套刻意做小的工具集——短期内是好事，并提到 Cloudflare 的 Code Mode 是更合理的用法：让模型把多次调用组合成一段脚本再执行。
反驳的一方：MCP 换来的到底是什么
Simon Willison 在2026 年 9 月 20 日回应说，这篇文章「完全忽略了 MCP 今天的价值」。他认同那个窄场景：如果你用的是完整终端智能体、网络又不设限，确实几乎没必要上 MCP，直接让它调 API 就好。
但如果你的环境没这么放开，他列出你最终会想要的四样东西：
- 精确控制它能访问哪些外部服务；
- 一种不让智能体直接拿到原始 API 密钥的鉴权方式；
- 一个让人能自助连接、授权的界面；
- 足够强的审计日志，事后能查清发生了什么。
这四件事，MCP 都更容易做到。它和「给智能体一个终端然后祈祷」是两种不同的设计目标，这也是为什么在需要负责的场景里，协议并没有被直接调 API 取代。
两边其实一致的地方
双方都承认：能开终端的智能体可以顶掉相当多的 MCP 服务器。分歧在于环境——完全不设限，还是收窄到可审计。
所以真正该问的不是「MCP 要不要用」，而是「我愿意让这个智能体碰多少东西」。
五问自检
- 这个服务有没有现成的 API 或命令行工具？有的话，直接调可能就够了。
- 接进来之后，它会不会看到我想隔离的凭据？
- 我需要按服务单独授权，还是一个整体的网络白名单就行？
- 「智能体昨天做了什么」，我能从日志里回答吗？
- 上下文预算紧张吗？那就用一个网关配精简工具集，而不是十几个大而全的服务器。
如果你在「凭据隔离」或「审计日志」这两条上犹豫，说明 MCP 正在替你解决真问题，值得留着。
放到 Windows 桌面智能体上意味着什么
桌面端的同一个取舍，最后会落到权限设计上：一个在你本机执行任务的客户端，需要一条边界清晰的对外通道，也需要留下事后能读的记录——这正是 MCP 补的那块板。
MOOGH 的扩展架构围绕 Skills、Plugins 与 MCP 建设，能力按任务安装，而不是全部写死在客户端里。想先感受一下「执行前先确认」是什么手感，可以从下载页装一个 Windows 版，拿件小事试起。
相关阅读：