别在 MCP 服务器后面再放一个大模型：架构反模式警示

近期，一位长期关注 AI 工程实践的资深工程师发文指出，把大语言模型（LLM）藏在 Model Context Protocol（MCP）服务器之后是一种应当被避免的架构反模式。他结合自己在 Claude Code 中调用某知名厂商 CLI 工具的真实经历，描述了这一设计带来的延迟、调试困难与语义混乱等系列问题。

一次实测：把简单查询拖到数十秒

作者描述的触发场景并不复杂：他让 Claude Code 调用一家知名厂商的 CLI 工具（其底层是一个 MCP 服务器），就其自有系统中某条简单数据发起一次查询。按照该厂商原生 API 的能力，这类查询通常在数百毫秒内即可返回。但实际等待时间长达「两位数秒」，期间本地智能体只能坐等远端隐藏的「思考循环」结束。

这一经历并非作者第一次警觉。早在数月前撰写工程战略文件时，他就曾提醒团队，把 LLM 放到 MCP 服务器后面会在直觉上是错误的方向——而这次实测让他的预判落了地。

MCP 的设计契约：传数据，不做决策

MCP 的本意是为智能体客户端提供查询外部系统数据、向模型补充上下文的标准通道，决策权始终掌握在调用方智能体手中。理想状态下，一个工具要么「取回」某样东西，要么「执行」某样动作，行为应当参数化、可预测、可审查。

一旦在工具实现层再嵌入一个 LLM，这层关系就被反过来了：

• 服务器端开始决定调用方智能体能「知道什么」。
• 一行数据库记录可以校验、一条搜索结果自带来源，但一个隐藏模型的摘要只是「穿着数据外衣的观点」。
• 工具结果会以「事实」的权威性进入上下文窗口，调用方智能体会不加分辨地将其当作真值。

双模型叠加：失败模式成倍放大

作者借用《捉鬼敢死队》中「不要交叉数据流」的台词类比这一现象：构建智能体时已经接受了一重概率性推理的「流」，再在工具里放一个 LLM 就等于与第二重流交叉，最终答案出错时将无法定位原因——是调用方误读了正常工具结果，还是隐藏模型生成了错误内容？调用方既看不到内部模型的提示词，也看不到其版本、上下文与实际检索到的数据，于是「为两次推理付费，换回一个零次可调试的答案」。

更直接的代价是速度。一次本应亚秒级完成的查询被拉长到十秒、二十秒甚至三十秒以上，而一个智能体在执行任务过程中可能多次触发此类调用，整体等待时间被成倍放大，用户与智能体都只能干等。

该用什么替代

作者指出，智能体之间直接通信的需求确实存在，针对这一场景业界已出现 A2A、ACP 等协议。它们的定位是让模型与模型、智能体与智能体之间的交互有规范可循，而不是让 MCP 承担本不属于它的职责。

文章结尾的结论很直白：不要在 MCP 服务器后面再放一个大模型。MCP 应当是一条可信赖的数据管道，而不是一处暗藏决策的中间层。