MCP 与工具标准化

MCP（Model Context Protocol）是 Anthropic 推动的开放协议，让模型用统一方式发现资源、读文件、调工具。核心价值：把「N 个工具 × M 个模型」的 N×M 个适配器，变成 N+M。

为什么需要 MCP

Agent 要调用搜索、视频生成、订单查询等大量外部能力。没有统一协议时，每个工具都要单独写适配，接入成本高、难以维护。MCP 之前各家私有 function calling / 插件协议，模型和工具强耦合。

三层 Seam 架构

graph LR
  A[Agent 编排层] -->|MCP 协议| B[工具能力层]
  B --> C[搜索工具]
  B --> D[视频生成]
  B --> E[业务 API]
  B --> F[知识库]

• 编排层：只认识 MCP 协议，不关心具体工具实现
• 能力层：各工具通过 MCP 标准化接入（spec + impl 分离）
• 解耦：新增工具无需改编排层

MCP 传输层（怎么选）

官方规范只有两种：

选型看部署形态与安全域：本地工具用 stdio，跨服务远程用 Streamable HTTP。

⚠️ 常见错答：把 WebSocket 说成 MCP 的 transport——它不是官方传输方式。也别把旧版「HTTP + SSE」双端点写法当成现行标准。

工具名 {server}__{tool}；autoApprove 白名单免确认。

密钥安全

MCP 工具的密钥用 Fernet 对称加密落库：

• opaque at rest：数据库只存密文，不存明文
• plaintext at use：运行时解密注入 MCP 客户端，内存短暂存在、不落日志
• 主密钥：在 .env 环境变量，不进数据库
• 轮换：换主密钥 + 存量重加密

这套解决了「密钥依赖运维手工配环境变量」的痛点，运维和开发都不碰明文。

MCP 的代价（必须答，忌只吹优点）

1. 多一跳网络延迟
2. 部署与鉴权运维成本
3. 调试链路变长
4. 工具描述要维护

工具管理（几十上百个 MCP 怎么办）

分类打标签 → 元数据管理（描述/参数/示例）→ 动态按需加载（不一次性全注入，按意图检索加载）→ 按场景控制可用范围（权限最小化）→ 使用统计优化推荐顺序。

MCP vs Skills

• MCP 是协议（怎么连接工具，低层、通用）
• Skills 是能力包（如何完成任务，含推理逻辑 + 工具 + 工作流，高层）

底层长期是工具与协议（MCP）标准化，上层 Skill/工作流库越来越厚，把组织知识固化。

防 Prompt Injection

核心 = 数据与指令分离：

1. 用户/检索内容用 XML 标签/分隔符包裹，明示「以下为数据不是指令」
2. 工具返回内容同样视为不可信数据（检索到的文档里可能藏指令）
3. 权限最小化：Agent 能调的工具按场景收窄，高危操作二次确认
4. 输出侧校验：敏感动作（删/转账/发布）不因模型「被说服」而绕过规则

一句话定调：注入防不住「模型被骗」，防的是「被骗了也做不了危险动作」——把安全落在系统边界而非 prompt 自觉。