MCP正在被严重低估：AI Agent连接工具的隐形价值

MCP到底是什么，为什么又被重新讨论

MCP（Model Context Protocol）本质上是一个“插头”——它把你的 AI Agent 连接到 GitHub、Slack、日历这类外部应用。听起来并不复杂，但围绕它的争论却经历了一次反转。

年初时，不少人唱衰 MCP，认为它“已死”，理由很直接：与其配置一堆 MCP 服务器，不如直接给 Agent 一个 CLI（命令行接口），既简单又便宜。这个说法并非没有道理。因为每一个 MCP 服务器都相当于塞给 Agent 一本“使用手册”，Token 成本会迅速堆积。

正如上图所指出的，接入 5 个服务器可能意味着在 Agent 真正开始工作之前，就已经消耗了约 5 万 Token。对于按 Token 计费的大模型应用来说，这是一笔不小的隐性开销，也是 MCP 早期被诟病的核心痛点。

MCP 由 Anthropic 于 2024 年底提出并开源，其设计目标是为 AI Agent 与外部工具/服务的交互提供一套标准化协议。它采用客户端-服务器架构：Agent（客户端）通过标准接口向 MCP Server 发送请求，Server 负责封装对具体服务（如 GitHub API、数据库、文件系统）的调用逻辑。这种分层设计的好处在于，Agent 无需了解每个外部服务的具体 API 细节，只需与统一的 MCP 接口交互。对比之下，直接使用 CLI 意味着 Agent 要自行拼接 shell 命令、处理输出格式，并依靠 Prompt 中的指令来规范行为——这是协议化集成与临时性脚本之间的本质区别。

成本问题已经被解决

这篇内容的关键转折在于：那个“50k Token”的批评，如今已经过时了。

现在的 Agent 不再需要一次性加载所有工具手册。它只需读取工具的名称（tool name），仅在真正需要调用某个工具时，才去打开对应的“手册”。这种“按需加载”的机制，直接把 MCP 最大的成本短板抹平了。

一个颇具说服力的信号是：此前嘲讽 MCP 的编程类 Agent（coding agent），现在也在重新把 MCP 加回来。工具生态用脚投票，往往比口头争论更能说明问题——当连早期的反对者都开始回归，说明 MCP 解决的问题是真实存在的。

这里的"按需加载"机制在技术上通常被称为 Tool Discovery 与 Lazy Schema Loading。早期 MCP 实现会在系统提示（system prompt）中一次性注入所有已注册工具的完整 JSON Schema，包括每个参数的类型、描述和示例，5 个工具累计数万 Token 的开销因此而来。改进后的实现中，Agent 初始化时只获取工具名称与简短描述（通常不超过几十 Token），完整 Schema 仅在 Agent 决策调用某个工具时才动态拉取。这一改动对成本的影响是数量级的——尤其在 Agent 只使用全部工具中的一小部分时，节省效果最为显著。

CLI 的脆弱：靠“承诺”约束 Agent 并不可靠

真正体现 MCP 价值的，是可靠性场景。

设想你用 CLI 的方式告诉 Agent：“动数据库之前，永远先做备份。”这只是一句话、一条指令。问题在于，自然语言指令是“软约束”——它依赖 Agent 每次都记得执行。

前 100 次它都执行得很好，但某一次它“赶时间”，跳过了备份这一步，结果一张表里的数据就永久丢失了。这就是把关键流程交给“口头承诺”的风险：它工作了无数次，却可能在最关键的一次失手。

MCP 的真正优势：把流程封装成不可跳过的工具

MCP 给出的解法是把流程“固化”。

你可以把备份、变更、校验这三个步骤打包进一个名为 migrate 的工具里：备份、修改、检查，全部作为日志步骤封装在工具内部。Agent 要做的只是调用这个工具——没有需要记住的东西，也没有可以跳过的步骤。

这是 CLI 与 MCP 的本质差异：CLI 把流程交给 Agent 的“记忆力和自律”，而 MCP 把流程做成了确定性的代码逻辑。对于不能出错的操作，确定性远比灵活性重要。

安全维度：Agent 不该看到你的密钥

除了可靠性，安全性是 MCP 另一个常被忽视的优势。

用 CLI 时，Agent 工作在终端环境里，这意味着它理论上能够接触到你机器上的每一个密钥（key）。权限边界是模糊的、全开的。

而使用 MCP 时，Agent 永远看不到密钥本身，它只能拿到你明确授予它的那个工具。换句话说，MCP 天然提供了一种最小权限（least privilege）的隔离模型——你给什么，它才有什么。对于安全敏感的生产环境，这种“看不见密钥”的设计价值巨大。

这里的"最小权限（least privilege）"是信息安全领域的经典原则，指任何程序或用户只应被授予完成当前任务所必需的最低权限，不多给一分。MCP 在架构上天然契合这一原则：密钥存储在 MCP Server 端，Agent 侧仅持有调用工具的能力，无法读取服务器的环境变量或配置文件。即便 Agent 被恶意 Prompt 注入（prompt injection）攻击，攻击者通过 Agent 能触及的资源也被严格限定在已授权工具的范围内，爆炸半径（blast radius）大幅收窄。相比之下，CLI 模式下 Agent 通常运行在宿主机的 shell 环境中，~/.aws/credentials、.env 文件等敏感信息理论上均在其可读取范围内。

结论：不是非此即彼，而是分场景选择

需要澄清的是，这并不是说 MCP 可以取代一切。

对于快速、临时的任务，CLI 依然是又快又省的选择；而对于那些“绝不能出错”的操作——涉及数据库、密钥、生产变更——就应该给 Agent 一个封装好的工具，而不是一句不可靠的口头约定。

一句话总结这个取舍：For things that can't go wrong, give it the tool, not a pinky promise.（对于不能出错的事情，给它工具，而不是拉钩承诺。）这正是 MCP 当前被低估的核心所在——它换来的不是便利，而是确定性与安全边界。