1. 是什么
MCP（Model Context Protocol）是 Anthropic 提出的开源标准化协议，采用 Client-Server 架构，把 AI 客户端和底层数据/工具彻底解耦。
- MCP Server：暴露工具（搜索/本地文件/数据库/TTS）。
- MCP Client：各种 IDE、Agent 框架、模型接口（Cursor/Claude Desktop/自研 Agent）。
- 像 Type-C 接口：一个接口通吃所有设备，"一处编写到处运行"。
2. 三位一体核心
规范了三类能力：
- Resources 只读资源：本地文件、数据库 Schema。
- Tools 主动操作：外部 API、本地 TTS、执行代码。
- Prompts 模板：标准提示词预设。
- 传输方式：SSE / Stdio。
3. vs Function Calling
FC 是模型自主决定"调什么"（模型侧能力）；MCP 是解决"工具与数据无缝连接的标准通信网关"（工具侧协议）。FC 与代码耦合切模型要重写；MCP 解耦可迁移跨平台复用。
4. vs Skills（Claude/Agent 生态）
- Skills（传统工具封装）：功能级局部补丁，解决"能不能做某件事"。强绑定特定平台的 Python 函数/Prompt 集合。优点开发快即插即用；缺点紧耦合碎片化，堆多了引发 Prompt 冲突（Skills 地狱），换框架重写。
- MCP：架构级标准协议，解耦。优点一处编写到处运行、动态按需索取上下文省 Token；缺点前期要按规范写 Server、有 IPC 延迟。
💡 深入理解 · Skills 底层怎么执行？ Skills 本质是大模型的 Function Calling 能力。Markdown 只定义工具 Schema 喂给模型判断何时调用；真正执行体是本地 Python/JS 脚本。模型输出含函数名+参数的 JSON，框架引擎解析后在本地或通过 MCP 触发脚本，结果返还模型。
💡 深入理解 · Skills 渐进式加载：技能过多会撑爆窗口。三层——① 元数据加载（启动只加载名称+简短描述）② 按需激活（需要时读详细指令/API 定义）③ 执行。
5. MCP 缺点
① 安全性：易受 Prompt Injection，工具描述可能被篡改 ② 延迟：分布式多 Server 通信增 IPC 延迟 ③ 成熟度：协议新缺治理标准和大规模压测 ④ 运维成本：每数据源维护一个 Server。
6. 使用方式
① 定义工具 ② FastMCP 调用或手动拼 JSON 初始化 ③ 先查 DB 所有工具判断 ④ 通过 MCP SSE 方式手动调用。项目里独立完成本地 TTS/ASR 服务部署 + MCP Server 开发，封装火山引擎语音能力供客户端动态调用。
7. 高频追问速答
❓ 常见追问 · 你在哪用了 MCP？ → 商学项目对接总部 TTS/ASR 语音服务，封装成 MCP Server 供客户端动态调用；企业 RAG 里做 Agent 工具链。
❓ 常见追问 · MCP 安全风险怎么防？ → Docker 沙箱隔离，限制挂载目录/网络出站，对 Tool Call JSON 正则校验+白名单，防 Prompt Injection 越权。
深度拆解:容易踩坑的点
维度一：架构设计
⚠️ MCP Server 一旦接入多个 Client，就成了公共依赖——它挂了所有接入方一起挂，它升级一个 Breaking Change 所有 Client 一起崩，你怎么做高可用和版本管理？
高可用：Server 无状态化+多副本部署，前面挂负载均衡，健康检查+自动重启（K8s liveness probe）；关键 Server（如 TTS/ASR）做熔断降级，Client 侧调用失败要有 fallback（重试/跳过该工具而不整体阻塞对话）。版本管理：Server 走语义化版本，工具 Schema 变更（尤其是参数增减、语义变化）视为破坏性变更走新的 major 版本或新增工具名而非原地改；Client 侧在握手阶段做能力协商（capability negotiation），不兼容就降级到旧工具集或提示不可用，而不是硬崩。本质是把 MCP Server 当成微服务治理，而不是本地函数调用。
多一层 Client-Server 协议就多一层网络开销和序列化/反序列化成本，什么场景其实不值得上 MCP？
三类场景不值得：① 工具集小且固定、只服务单一 Client、几乎不会跨平台复用——直接 FC 本地绑定更快，MCP 的"一处编写到处运行"红利兑现不了。② 强实时低延迟场景（比如语音打断、逐字流式判断要不要调工具），IPC/SSE 往返的延迟不可接受。③ 工具逻辑本身极简单（比如就是格式化一下字符串），维护一个独立 Server 进程的运维成本远超收益。判断标准就是"复用性和解耦收益 是否大于 多一跳的延迟+运维成本"，不是所有工具调用都要 MCP 化。
维度二：安全防护
⚠️ 接入第三方 MCP Server 本质上是把模型的"眼睛和手"交给了别人写的代码，它返回的内容可能包含恶意指令（间接 Prompt Injection），甚至工具描述本身就可能被篡改诱导模型误用，你怎么建立工具信任边界？
分层建信任边界：① 供应链层——只接入来源可信/经审计的 Server，工具 Schema 和描述做签名或哈希校验，防止运行时被篡改；② 输入输出隔离层——把工具返回的内容当作"不可信数据"处理，不直接拼进 System Prompt，而是用明确的分隔符/角色标记包裹，并在关键动作前加二次确认；③ 执行沙箱层——Server 本身跑在 Docker 沙箱里，限制文件系统挂载范围、网络出站白名单、无关权限一律拒绝；④ 输出过滤层——对模型基于工具结果生成的下一步动作做正则/白名单校验，尤其是涉及再次调用其他工具或写操作时，防止"工具返回的注入指令"被模型当成用户指令执行导致连锁调用。核心思路是零信任：不因为是"自己配置的 MCP Server"就默认它返回的内容安全。
MCP Server 暴露的工具权限怎么控？谁能调用、能调用到什么程度，怎么防止越权？
权限控制分两层：Client 到 Server 的认证鉴权（API Key/OAuth，区分不同 Client 身份，Server 端按身份返回不同的工具列表，而不是所有 Client 看到同一份全量工具）；工具本身的操作权限最小化（比如数据库工具只开只读查询接口，不暴露 DELETE/UPDATE，文件工具限制在指定目录树内，避免路径穿越）。另外工具调用要有审计日志，记录谁在什么时间调了什么参数，方便事后追溯异常调用。
维度三：部署运维
MCP Server 的调用链路、失败率、耗时怎么观测？线上出问题了，怎么快速定位是 Server 侧的锅还是模型侧决策错了？
观测上给每次工具调用打统一的 trace id，贯穿"模型决定调用→Client 发起请求→Server 执行→返回结果→模型消费结果"全链路，接入链路追踪（如 OpenTelemetry）看每一跳耗时；关键指标监控工具调用成功率、P95/P99 延迟、超时率，按 Server/工具维度拆分看板。定位问题时先看 trace：如果模型根本没触发工具调用或调用参数就是错的，是模型侧（Prompt/工具描述没写清楚导致误判）；如果调用发出去了但 Server 超时/报错/返回异常数据，是 Server 侧，进一步看 Server 自己的日志和依赖的下游服务状态。区分的关键就是把"决策"和"执行"两段分开打点，而不是笼统看一个对话失败了。
维度四：工程实现
简单场景用 Function Calling 就能搞定，硬上 MCP 属于过度设计，你怎么判断一个工具该不该抽成独立的 MCP Server？
判断维度：① 复用性——这个工具/数据源是否会被多个 Client（不同 Agent 框架、不同产品线）反复用到，只用一次就不值得；② 变更频率与所有权——工具逻辑是否由独立团队维护、迭代节奏和主应用不同步，解耦成 Server 能减少发布耦合；③ 隔离需求——工具涉及的凭证、网络访问、执行环境是否需要和主应用隔离（比如访问内网数据库、执行不受信代码），MCP Server + 沙箱天然适合承载这类高风险操作；④ 延迟容忍度——是否能接受多一跳 IPC/网络延迟。只有当复用性或隔离性收益明显大于多一层协议开销时才上 MCP，单一场景、低复用、低风险的工具直接用 FC 本地绑定最省事。
评论