MCP还远未成熟：一位亲历者的冷静告白与务实建议

这不是一篇鼓吹MCP未来无限的文章，而是一位亲手做过MCP服务器的工程师，对现实问题的坦诚复盘。David Cramer 结合自己在 Sentry 的实践，讲清楚了 MCP 真正擅长什么、不擅长什么，以及为什么“现在就押注它”可能是个危险决定。

从“临时上台”到直言不讳：这不是一次精心包装的演讲

理解这场分享的前提，是先理解它的语境。David Cramer 一上来就坦白，这个演讲是“有点临时的”，他是临时顶替了一个空出来的时段。这种随意感，反而成了整场演讲最重要的气质：没有销售话术，也没有路线图承诺。

他调侃自己是“偷偷溜进这个会议，看看能不能填个坑”，也顺势点出了 MCP 在行业里的现状——热度来得很快，但很多人其实并没想清楚它是什么。正因为如此，他反而觉得有必要泼一点冷水。

David 的身份很关键：他并不是旁观者，而是“已经做过一次的人”。他明确说，Sentry 的 MCP server 最初只是一个“fun project”，并不是战略级投入。也正因为动机足够轻，他才能在实践中快速撞上问题，并形成现在这些相当强烈的观点。

这场演讲的基调从一开始就被定下来了：不是要证明 MCP 有多先进，而是要回答一个更现实的问题——当你真的把它接进现有的企业级云服务和工程体系里，会发生什么？

MCP 的本质：它只是 Agent 的“可插拔架构”

在所有讨论之前，David 先给 MCP 下了一个极其克制、但也极其重要的定义：“MCP is a pluggable architecture for agents. Full stop.”

这句话几乎贯穿了整场演讲。MCP（Model Context Protocol）并不是一个智能系统，也不是魔法接口，它本质上只是一个让 Agent 能接入外部能力的协议层。你可以把它理解为：为 Agent 提供上下文和工具的一种标准化方式。

问题在于，很多讨论已经不自觉地“神话化”了 MCP，仿佛只要有了 MCP，Agent 就会自动变得有用。David 明确指出，这是本末倒置。他反复强调，所有 MCP 的讨论，都必须放在一个“enterprise cloud service”的背景下——也就是稳定性、安全性、成本和责任边界都极其重要的环境。

他抛出的关键问题是：我们到底是为了什么而做 MCP？是为了“看起来 relevant”，还是为了真的让系统变得 useful？如果只是前者，那 MCP 很容易变成一层漂亮但危险的抽象。

这一节的核心洞见在于：MCP 的价值上限，永远取决于你 Agent 本身的设计。如果 Agent 不清楚自己要解决什么问题，那 MCP 只是让混乱变得更模块化而已。

亲手接入 MCP：它确实能跑，但问题也很快出现

当话题进入实践层面，演讲开始变得具体而尖锐。David 讲述了他们几个月前搭建 Sentry MCP 的过程：把 MCP 插进来之后，Agent 确实可以查询 Sentry 的数据，甚至在某些情况下“开始修 bug 了”。

他承认，第一印象是：这东西“actually super accessible”。上手并不难，文档也还算友好，以至于他直接对着台下说：“This is you. This was me.”——那种刚跑通 demo 时的兴奋，他完全理解。

但紧接着，他描述了一个很多工程师都会经历的阶段：你开始在各种工具之间“跳舞”，在不同的 OOTB（out-of-the-box）体验里反复尝试，期待它能在 Cursor、VS Code 这些环境里稳定工作。结果是——“it might work， it might not”。

更重要的是，他指出了一个常被忽略的边界问题：当你通过 MCP 暴露能力时，“people might leverage your API. It is not your API.” 一旦 Agent 代表你去调用系统，你对行为的控制权会急剧下降。

这些并不是 MCP 的 bug，而是它作为中介层必然带来的复杂性。问题在于，很多团队在 PoC 阶段就已经被成功案例冲昏了头脑，低估了这些成本。

真正的风险与成本：远程 MCP 不是“即插即用”

演讲最具警示性的部分，来自他对“远程 MCP server”的态度。David 几乎用了恐吓式的语气提醒：“Very very very scary. Do not allow random MCP tools.”

原因并不复杂：当你允许 Agent 动态接入远程 MCP 工具时，本质上是在引入一段你无法完全审计的执行链路。这在企业环境里是灾难级的风险。

他进一步拆解了 MCP 实现中被严重低估的工程细节。例如，返回格式。他们最终选择返回 Markdown，而不是随意的结构化数据，因为你要“treat it as like you are providing context to an agent”。这不是 API 设计，而是认知设计。

同样的逻辑也适用于错误处理。他强调：“You got to design the errors.” 错误信息不是给人看的，而是给 Agent 消化的上下文。如果你随意返回错误，Agent 就会在错误的前提下继续推理。

最终，他给出了自己的总体判断：MCP 绝不是“set and forget”的组件。很多成本——包括推理成本、运维成本、心智负担——都会被悄悄地“passing the cost on”。如果你没有为此预留足够的工程资源，那 MCP 只会放大系统的不稳定性。

回到原点：先把 Agent 做对，再谈 MCP

在结尾，David 明确给出了他的“very very strong belief”。与其把注意力放在 MCP 本身，不如“really focus on building agents”。

他的建议路径很清晰：先设计清楚 Agent 的职责、能力边界和失败模式；然后，再通过 MCP 这种架构去暴露它们，而不是反过来。

他甚至有些厌倦地总结道：“Fancy new words are just new words for the same thing.” MCP、Agent、Context，这些词再新，也无法替代扎实的系统设计。

这并不是否定 MCP 的价值，而是把它放回到一个合理的位置：它是一种工具，而不是方向。真正的竞争力，仍然来自你是否“dial in the thinking around agents”。

这也是他选择以一种克制、甚至略显悲观的语气结束演讲的原因——不是因为他不看好未来，而是因为他已经看过太多过早乐观带来的代价。

总结

David Cramer 的这场分享，价值不在于给出了 MCP 的“最佳实践”，而在于揭示了它的真实成本结构。MCP 并不坏，但它远未成熟，更不是灵丹妙药。对开发者和决策者而言，最大的启发或许是：在被协议和架构吸引之前，先诚实地问自己——我的 Agent，真的准备好了吗？

关键词： MCP， AI Agent， Sentry， Cursor， 企业级AI

事实核查备注： 视频标题：MCP Is Not Good Yet — David Cramer， Sentry；频道：AI Engineer；发布时间：2025-07-03。核心技术名词：MCP（Model Context Protocol）、AI Agent、远程 MCP server。涉及产品：Cursor、VS Code（仅作为接入示例）。关键原话包括："MCP is a pluggable architecture for agents"、"Very very very scary"、"Fancy new words are just new words for the same thing"。