MCP死了吗？真相没那么简单

想象一下你花了整整一个下午好不容易把Claude Code和日常使用的工具连接起来以为从此终于可以告别重复操作。结果第一次执行正式任务它就卡住了。你开始检查身份验证、翻服务器日志、核对工具返回内容一项接一项地排查。而最初的任务不过是更新一条Issue。折腾到这里你意识到如果一开始自己动手这件事可能早就做完了。对MCP的热情往往就是从这一刻开始慢慢消失的。MCP描绘了一幅很诱人的图景为AI提供一种统一标准让它能够直接操作我们已经在使用的软件。然而成功建立连接只能证明它“连上了”。真正投入使用之后一连串问题才刚刚出现模型能选对工具吗一次交互会消耗多少上下文如果它拥有修改权限而我原本只想让它读取数据会发生什么这些问题并不意味着MCP一定不好。但它们足以说明“这个软件有MCP服务器”并不是安装它的充分理由。在继续给Claude Code增加连接器之前我们不妨先冷静看看MCP会带来哪些成本容易在哪些地方失败以及什么时候一条熟悉的命令或一次直接的API调用反而能用更少的麻烦完成同样的工作。一个很香的 AI 平台GPT-5.6 0.08 倍率 和 Claude Code 4.8 只要 0.25倍率包含 image-2生图。重点是 首字请求都在 5s 内。入口[https://ai.aiyuhub.com]Token到底被谁吃掉了你只是让Claude修复一个小Bug。为了完成这项任务它究竟需要了解多少其他工具的信息大多数时候并不多。然而一个外部集成可能在模型真正开始工作之前就已经占用了大量上下文。每项工具都附带名称、功能描述和参数结构。如果客户端在启动时一次性加载这些定义它们就会成为模型需要处理的信息。工具执行结束后返回结果又可能塞进更多内容服务器日志、长篇文档或者一份体积夸张的JSON响应——字段多得惊人却唯独没有解释为什么要返回这么多数据。模型甚至不需要执行多么复杂的任务。很多时候真正的问题只是你一次交给它的东西太多了。一项工具可以很有用但这不代表每次任务都要附上它的整本使用说明书。不过“关闭所有MCP服务器”这种常见建议也存在一个容易被忽略的问题。Claude Code支持工具搜索。它可以在真正需要时再发现并加载相关工具而不是预先把所有工具定义全部塞入每轮对话。因此“只要连接了MCP服务器它就一定会在每条消息中加载全部工具”的说法并不准确。然而工具发现机制也只解决了部分问题。即使系统能够高效找到一项真正相关的工具如果该工具在你只需要三条记录时一口气返回了一万行数据上下文依旧会迅速膨胀。更合理的做法是先确认当前任务究竟需要哪些集成再检查这些工具实际会返回什么内容。尽量使用精确查询、限制响应规模并在数据进入模型上下文之前完成过滤。当然换成CLI也不会自动解决所有问题。如果你把一份巨大无比的命令行输出完整塞进对话只不过是给同一个问题换上了终端的外衣。工具发现可以减少前期上下文消耗但过大的返回结果依然需要单独治理。一个简单任务背后却有好几层假设你想让Claude Code读取一条Issue并在下面发布评论。团队已经为这个平台配置好了CLI身份验证也能正常工作。此时再添加一个MCP服务器相当于为同一个任务增加了另一条路径。这条新路径是否值得采用取决于它解决了什么问题以及你从此又要维护多少东西。在MCP架构中宿主应用负责管理客户端客户端再与MCP服务器通信。服务器对外公开工具并可能在内部继续调用目标服务的API。模型负责选择工具外围软件则负责真正执行操作。MCP规定了工具应该如何被发现和调用也定义了工具所需的参数。模型并不是临时猜测这些调用规则。协议规范明确描述了工具发现、输入Schema以及调用过程。可是接口被标准化并不代表运维麻烦会自动消失。如果评论发布失败是模型选错了工具吗还是服务器拒绝了某个参数身份验证是不是已经过期又或者下游API拒绝了请求你原本只是想留一条评论。现在却意外开启了“排查集成故障”的支线任务。对于范围明确、步骤固定的工作流直接调用API通常更容易追踪。因为应用程序明确控制着发出的请求也能自行处理返回结果。如果团队现有的CLI已经把这些细节封装成一条人人都能理解的命令那么直接使用它往往更加省事。这也是某些场景下不需要MCP服务器的最有力理由你需要的集成其实早已存在而且运行良好。不过当多个兼容的AI应用都需要访问同一组能力时MCP的价值就会明显提升。一个共享服务器可以避免团队为每个AI客户端分别维护一套集成。在这种情况下多出来的组件确实承担了明确职责。所以在安装MCP服务器之前应该先问一句它到底简化了我的哪一段真实工作流通往同一项服务的两条路径需要维护的组件并不相同。工具调用成功了任务却失败了假设你让Claude在“登录按钮损坏”的Issue下面发布一条评论。系统搜索后找到了两个内容相似的工单。模型没有选择当前正在处理的那一个而是打开了一条更早的记录并把评论发到了那里。服务器成功接收请求所有参数都符合Schema评论也确实发布了。唯一的问题是——发错了Issue。这正是工具可靠性最容易让人混淆的地方。接口返回成功只能证明某项操作已经执行却不能证明这项操作真正完成了你的意图。MCP工具已经能够通过JSON Schema声明预期输入。Schema可以要求模型提供Issue ID和评论正文却无法独自判断这个ID对应的Issue是不是你真正想修改的那一个。参数完全正确也可能描述了一次错误操作。因此模型外围的应用程序仍然需要承担一部分校验工作。以这个假设场景为例在正式写入评论之前可以先读取目标Issue的标题、所属项目和当前状态再展示给用户确认。这样一来即使模型选错了记录也多了一次发现问题的机会。如果操作可能造成明显影响那么在执行之前展示拟议变更并请求批准虽然会中断自动流程却往往值得。失败后的恢复机制同样需要提前设计。假设请求在服务端成功保存评论之后发生超时。如果客户端不知道实际结果直接重试请求就可能重复发布同一条内容。当目标服务支持时可以使用幂等键避免重复操作如果不支持集成层至少应该具备检查操作是否已经完成的能力。需要强调的是这些问题并非MCP独有。当智能体选择CLI命令或自行构造API请求时它一样可能误解用户意图。改变调用接口并不会让模型突然失去犯错的能力。对于步骤固定的工作流那些根本不需要语言理解的决策完全可以交给普通代码处理。例如让程序提前确定Issue ID只让模型负责起草评论内容。少给模型一个需要猜测的地方就少一次发生错误的机会。操作通过了真正的任务却依然没有完成。演示很成功然后维护开始了一次成功运行当然令人兴奋。真正的维护账单通常要等其他人开始依赖这套集成之后才会慢慢寄到你手里。继续使用前面的Issue跟踪器作为例子。这套集成在你的电脑上工作正常于是另外三名同事也安装了它。其中一人连接的是另一个工作区一人只有只读权限还有人升级了服务器版本而其他成员仍然停留在旧版本。到了这一步“昨天明明还能用”已经不足以描述问题。你还必须追问一句是谁的昨天MCP确实提供了一套统一接口但实际工作流仍然依赖多个会发生变化的环节MCP服务器本身的行为用户凭据和权限下游服务的API模型对现有工具的理解与选择不同客户端或服务器版本之间的兼容情况。协议统一并不会让这些依赖永远冻结。就连工具描述也应该被当作接口的一部分认真维护。如果某项工具的描述变得更加宽泛或模糊模型就可能在原本不该使用它的场景中调用它。因此工具描述不只是写给人看的说明文字它也会直接影响模型行为应该纳入测试范围。对于“给Issue发表评论”这条工作流一个有价值的回归测试至少应该验证智能体是否选择了正确的项目面对两条内容相似的Issue时能否找到目标记录缺少写入权限时是否会安全停止请求成功后评论是否真的出现在正确位置。如果测试只检查MCP服务器能不能连上那么真正任务中的大多数环节其实都没有被验证。日志也要保留足够的执行信息以便区分“模型选错了目标”和“服务器拒绝了请求”。通常可以记录所选工具、关键参数、错误信息和最终确认结果同时避免把不必要的敏感数据写入日志。当然直接集成同样需要维护。API会变化CLI版本可能逐渐偏移身份凭据也会过期。但在范围较小的工作流中直接集成的优势在于需要排查的组件可能更少由模型负责的决策也更有限。因此维护成本最终取决于使用范围。如果一个MCP服务器可以支持整个团队的多个重要工作流那么持续维护它可能非常值得。可如果你维护一整台服务器只是为了包装两条原本已经很好用的命令它的收益就很难解释了。绿色的连接状态远没有一次完整通过的工作流测试更有说服力。你究竟给了智能体多大权限读取一条Issue听起来似乎没有什么危险。然而Issue描述属于外部内容而外部内容可能包含专门写给模型的恶意指令。设想一种攻击场景某条工单声称为了完成故障排查智能体必须读取一份内部文档并把它作为附件发布到公开评论中。这段恶意要求就隐藏在模型原本应该检查的材料里。如果智能体相信了它同时又拥有读取内部文件和发布公开评论的权限那么一次普通的Bug检查就可能演变成数据泄漏。Claude Code的官方文档也明确指出通过外部内容实施提示词注入是一项真实存在的风险。而且连接运行得再完美也无法自动阻止这种攻击。安全设计的第一步是确认这项集成实际上可以做什么。负责审查Issue的智能体也许只需要读取权限根本不应该拥有发布评论、修改设置或导出内部文档的能力。这些限制应该通过凭据范围和服务器端授权强制执行而不是只在提示词里提醒模型。“请不要修改重要内容”只是一句话。只读权限才是真正的限制。MCP还会带来一些专门的信任问题服务器由谁运营它能够获得哪些凭据它又如何验证访问权限MCP安全最佳实践明确禁止Token Passthrough也就是服务器不验证令牌是否签发给自己就直接把凭据转发给下游服务。当然改用CLI也不会自动解决安全问题。如果智能体能够使用权限过大的身份凭据执行Shell命令它同样可能按照恶意内容的指示做出危险操作。无论最终选择MCP、CLI还是直接API都应该遵循几项基本原则权限只覆盖当前任务真正需要的范围从外部获取的内容一律按照不可信数据处理高成本或不可逆操作必须增加人工确认安全限制应由权限系统强制执行不能只依赖模型自觉。即使模型作出了错误判断权限边界也必须依然有效。即使模型作出错误决定权限检查也必须挡住危险操作。CLI或API会不会更省事在安装另一个MCP服务器之前不妨先把任务重新描述一遍而且不要提到AI。例如“读取这条Issue并在下面添加评论。”如果GitHub CLI已经安装完成而且当前环境也配置好了身份验证那么可以先直接使用现有命令查看指定Issuegh issue view42--repoOWNER/REPO\--jsonnumber,title,state,body请把OWNER/REPO和42替换成实际目标。该命令只读取选定字段而不是返回完整的Issue数据。详见GitHub CLI参考文档。接下来可以让模型负责起草评论由人工审阅后保存到comment.md再执行gh issue comment42--repoOWNER/REPO\--body-file comment.md这条命令会把文件中的内容发布到指定Issue。详见命令文档。这里真正有价值的设计是应用程序可以提前固定仓库名称和Issue编号。模型只负责自己擅长的文字工作不需要猜测结果究竟应该被发送到哪里。如果是在产品功能中实现一条顺序固定的工作流直接调用API可能更加合适# 需要安装 jq并准备拥有 Issues: write 权限的 GITHUB_TOKEN。jq-n--rawfilebody comment.md{body: $body}|curl--fail-with-body--silent--show-error\--requestPOST\--headerAccept: application/vnd.githubjson\--headerAuthorization: Bearer${GITHUB_TOKEN}\--headerContent-Type: application/json\--data-binary -\https://api.github.com/repos/OWNER/REPO/issues/42/comments这是使用GitHub创建Issue评论接口的示例请求。jq会把文件内容正确编码成JSON其中包括引号与换行符。采用这种方式你依然需要负责身份验证、失败处理和重试策略。它并没有消灭工程工作。只是把这条范围明确的流程保持在了一个容易理解的状态一条已经选定的Issue一份经过审阅的评论以及一次明确的请求。这些方案并非完全对立。MCP工具同样使用Schema服务器底层也可能继续调用API。当共享集成确实能够减少大量重复工作时MCP自然有存在价值。但如果整个工作流只涉及一两个简单操作那么一条大家已经熟悉的命令可能就是全部所需。所以MCP真的死了吗一条GitHub命令当然不可能取代所有MCP集成。可是它确实提出了一个令人有些尴尬的问题完成眼前这项任务究竟需要多少基础设施如果只是读取一条Issue再发布一份经过人工审阅的评论现有CLI或许已经足够。如果同一套工具能力需要在多个AI应用之间共享那么一个MCP服务器可能比多套独立集成节省更多工作。两种选择都应该用实际结果证明自己而不是仅凭概念决定胜负。我的建议是不要一开始就彻底改造整套开发环境。先挑选一条具体工作流再把MCP方案与现有的最简单替代方案放在一起比较。重点检查几个问题它能否稳定完成整个任务它会向模型上下文返回多少内容出现故障后需要排查多少环节团队能否理解并长期维护它它带来的收益是否足以覆盖新增组件的成本最后保留那套你真正能够理解、测试和维护的方案。把一条评论绕道另一台服务器发布并不会让你额外获得“工程技术分”。反过来删除一项有用的集成再换成几段下个月还要天天维护的脚本同样算不上胜利。那个下午原本只应该以一条更新完成的Issue结束。无论是MCP、CLI还是直接API只要它能可靠地把你带到终点就有资格留在你的工具箱里。所以MCP没有死。真正应该被淘汰的是为了使用MCP而使用MCP。