Hello folks，我是 Luga，今天我们来聊一下人工智能应用场景中大语言模型（LLM）标准协议 - MCP
在大模型工程化落地的浪潮中，MCP（Model Context Protocol）正在经历一个典型的技术扩散周期：
从“解决具体问题的协议设计”，迅速演变为“被寄予厚望的架构银弹”。甚至，在一些讨论中，MCP 被赋予了过高的预期：
-
用 MCP 统一 Agent 工具调用
-
用 MCP 解决上下文混乱
-
用 MCP 构建通用 Agent 平台
这些判断并非完全错误，但隐含了一个危险前提：把“协议能力”误当成“系统能力”…… 最近跟一位社区的朋友在探讨 MCP 在生产环境中落地的场景时，他来了一句：
“MCP violates several assumptions we rely on for building reliable systems.”
故此，写文叙之……
本文将从架构层级、系统职责与工程落地三个维度，对 MCP 进行一次彻底“去神话化”的拆解，并给出一个清晰结论：MCP 是一块必要但有限的拼图，而不是完整答案 ……
—01 —
架构透视：MCP 本质上是“倒置控制权的 RPC”
众所周知，在经典微服务体系中，调用链的控制权始终掌握在确定性代码手中：
即便是复杂的服务编排（Saga、Workflow），决策逻辑仍然是可审计、可回放、可测试的代码路径。
而 MCP 引入之后，调用链则变为：
MCP 架构的核心变化，并不在于 JSON-RPC 这种传输形式，而在于“谁决定要调用什么”。因此，在 MCP 中：
-
调用发起者不再是代码，而是 LLM
-
调用条件不是 if/else，而是概率推断
-
调用参数不是结构化输入，而是自然语言解析结果
这是一种典型的控制反转（Inversion of Control），但控制权并没有交给框架，而是交给了一个不可预测的模型。
我们来
看一段典型的 MCP JSON-RPC 请求：
{
"jsonrpc": "2.0",
"method": "tools/call",
"params": {
"name": "database_query",
"arguments": {
"sql": "DELETE FROM users WHERE id = 'U123'; -- Oops"
}
},
"id": 1
}
从协议视角看，这没有任何问题：
- JSON-RPC 合法
- 方法名正确
- 参数结构清晰
但从架构视角看，这是一次严重的责任缺失。MCP 协议只承担了一件事，即
“把 LLM 生成的意图，原样搬运到后端。”
它不做、也无法做：
- 参数语义校验
- 权限校验
- 业务上下文一致性验证
问题却恰恰在这里……
一旦后端服务默认信任 MCP Server 的转发行为，整个系统就发生了一个危险的等价变换：
你并不是在“给 LLM 接工具”，而是在把内部 RPC 接口暴露给一个不可控的决策者 。
—02 —
MCP 生产落地的 3 大陷阱解析
1、陷阱一：信任边界塌陷 —— MCP 天生是 Confused Deputy
Confused Deputy（混淆代理）并不是 MCP 独有的问题，但 MCP **天然放大了这个风险** 。在传统系统设计中：
-
用户身份清晰
-
权限与接口强绑定
-
调用路径可控
而在 MCP 中，调用路径变成了：User Intent → Prompt → LLM 推断 → Tool
Call 中间这一跳，是不可验证的。
于是，出现如下场景：
从实际的架构设计中，MCP Server 无法判断：这是用户的真实意图 or 还是 LLM 的幻觉 亦或是 还是一次攻击成功的结果。
2、陷阱二：可观测性断裂 —— LLM 是天然的 Trace 黑洞
在云原生 Kubernetes 体系中，我们依赖如下假设：
-
Trace Context 可以跨进程传播
-
每个调用都有确定的 Span 边界
-
时间消耗可被精确归因
而 MCP 的调用链实际上是：
User
→ HTTP Request (Trace A)
→ LLM Gateway
→ 模型推理（不可观测）
→ MCP JSON-RPC（Trace 丢失）
→ 后端服务（新 Trace）
因此，在某种场景下，我们往往看到的只是数据库报错，却永远找不到是哪一次用户提问触发的。
3、陷阱三：无状态协议 vs 有状态业务的结构性冲突
MCP 是 Stateless 的，这是优点，而业务是 Stateful 的，这是现实。当你让 LLM 承担“上下文维护”职责时，本质上是在：
-
用 Token 换状态
-
用 Prompt 堆叠替代事务管理
-
用概率推断模拟状态机
这在工程上是不可持续的。正确的设计原则应该是：
-
状态永远由服务端维护
-
LLM 只负责意图表达
-
MCP Server 是“富客户端”，而非函数转发器
我们以航班机票为例，需求为：“帮我订一张明天从北京到上海的机票，预算2000元以内。” 此时，需要：
-
查询航班（MCP 调用）；
-
过滤价格（LLM 决策）；
-
调用支付（MCP 调用）；
-
处理失败回滚（状态协调）。
MCP 协议本身 不提供状态机、不支持事务、不记录中间结果 。所有状态必须由 LLM 在上下文中“记住”，极易因 Token 截断或生成错误而丢失。
这就像让一个人用便签纸记账，而不是用数据库。
—03 —
那么，该如何理解 MCP 在生产环境中的落地呢 ？
MCP 要在生产环境可用，不能只实现协议，而必须构建一套 **完整的治理架构** 。因为：协议只是表象，治理才是核心。
MCP 的本质，是一个 **轻量级的工具调用协议，** 解决的是“如何让 LLM 调用函数”的语法问题，但远未解决“如何在生产环境中安全、可靠、可观测地集成 AI 与系统”的架构问题。
因此，在云原生 K8s 环境中，若要落地 MCP，必须做到如下：
- 协议之上建治理：注册、鉴权、校验、审计缺一不可；
- 网络与执行隔离：MCP Server 必须运行在受限沙箱中；
- 可观测性贯通：Trace ID 必须贯穿 LLM → MCP → 后端；
明确使用边界：只用于低风险、只读、封闭场景。
否则，MCP 非但不能“增强智能”，反而会成为 **系统中最危险的单点** 。毕竟，真正的 AI 原生架构，不在于引入多少新协议，而在于 **如何将 AI 能力嵌入现有工程体系，而不破坏其可靠性根基** 。
因此，毫不避讳的说：MCP 可以是其中一环，但绝不是灵丹妙药。
今天的解析就到这里，欲了解更多关于 “大模型技术”相关技术的深入剖析，最佳实践以及相关技术前沿，敬请关注我们
的微信公众号或视频号：架构驿站（ArchHub），获取更多独家技术洞察！
Happy Coding ~
Reference ：
[1] https://www.iweaver.ai/blog/mcp-explained-i-breaking-ais-context-limits-for-collab/
[2] https://blog.sshh.io/p/everything-wrong-with-mcp
Adiós !
··································
Hello folks，我是 Luga，AI 创业者，资深架构师，Traefik Ambassador，Jakarta EE Ambassador， 一个 15 年+ 技术老司机，从 IT 屌丝折腾到码畜，最后到“酱油“架构师。如果你喜欢技术，不喜欢呻吟，那么恭喜你，来对地方了，关注我，共同学习、进步、超越～