跳到主要内容

MCP在Agent中的位置

核对日期：2026-10-27（按 MCP 2026-07-28 规范更新）。

1. 定义与边界​

MCP（Model Context Protocol）是连接 AI 应用与外部工具、资源、提示词的开放协议。它定义 Host、Client、Server 之间如何发现能力、协商能力、传输消息和调用工具。

MCP 不是 Agent 框架，也不是模型能力本身。它解决的是“上下文和工具如何标准化接入”的协议层问题。

2. 为什么重要​

没有 MCP 时，每个 AI 应用都要为每个外部系统写专用插件。MCP 提供统一连接模型：

AI Host 1 ─┐
AI Host 2 ─┼── MCP Client ── MCP Server ── External System
AI Host 3 ─┘

它的价值在于：

  • 工具、资源、提示词暴露方式标准化。
  • 本地 stdio 和远程 Streamable HTTP 都有规范。
  • Host 可以同时连接多个 Server。
  • Server 可以复用于不同 IDE、桌面端、Agent 平台。

3. 核心机制​

3.1 角色模型​

角色职责
Host用户直接使用的 AI 应用，负责界面、模型、权限和用户意图
ClientHost 内部的协议客户端，通常一个 Client 连接一个 Server
Server暴露 tools、resources、prompts 等能力

3.2 能力类型​

能力说明Agent 中的用途
Tools可执行动作查询系统、执行写操作、触发工作流
Resources可读取上下文文件、文档、数据库记录、知识源
Prompts可复用提示模板固定任务模板、团队工作流
ElicitationServer 向用户请求额外信息工具执行中需要补充输入时使用；2026-07-28 起通过 Multi Round-Trip Requests 实现
Sampling（已废弃）Server 请求 Host 侧模型采样新实现不要再接入；Server 需要模型能力时直接对接模型厂商 API
Roots（已废弃）Client 告知 Server 可访问的文件边界改为通过工具参数、resource URI 或 Server 配置传递目录
Logging（已废弃）Server 向 Client 推送日志stdio 写 stderr，远程服务用 OpenTelemetry

基本协议仍基于 JSON-RPC 2.0。2026-07-28 规范把 Roots、Sampling、Logging 标记为 Deprecated，按新的特性生命周期策略至少保留 12 个月废弃窗口，期间仍可用但不应新增支持。Tasks 从核心协议移到官方扩展 io.modelcontextprotocol/tasks，通过 capabilities 里的 extensions 字段协商。

3.3 2026-07-28 规范的关键变化​

这一版的主线是“无状态化”：远程 MCP Server 变成普通 HTTP 工作负载，可以直接放在负载均衡后面横向扩展。对 Agent Runtime 的影响如下：

变化旧行为（2025-11-25）新行为Agent 侧要做什么
去掉握手initialize / notifications/initialized 协商一次每个请求在 _meta 携带 protocolVersion、clientCapabilities；版本不符返回 UnsupportedProtocolVersionErrorClient Adapter 不再维护“已初始化”状态，按请求注入元数据
发现能力握手返回 capabilitiesServer 必须实现 server/discover，Client 可先调用做版本选择注册 Server 时调用 server/discover 并把结果入库版本化
去掉协议会话Mcp-Session-Id 绑定连接状态跨调用状态用 Server 签发的 handle，作为普通工具参数传递不要依赖连接保存业务上下文；handle 要进 trace，便于回放
服务端主动请求Server 发起 elicitation/create、sampling/createMessageMRTR：Server 返回 resultType: "input_required" 和 inputRequests，Client 带 inputResponses 重试原请求工具调用状态机新增“等待输入”分支，前端 HITL 要能挂起再重放
结果类型无显式字段所有结果必须带 resultType（complete / input_required）；旧 Server 缺省视为 complete解析层先判 resultType，再取 content
流恢复SSE Last-Event-ID 断点续传移除；流断开即丢失在途请求，必须用新 request ID 重发写操作必须带幂等键，否则重发可能重复执行
变更订阅HTTP GET 端点 + resources/subscribe统一为 subscriptions/listen 长连接工具列表变更走订阅，触发重新审查
列表缓存无标准tools/list 等结果必须带 ttlMs、cacheScope；建议工具顺序稳定按 TTL 缓存工具清单，稳定顺序还能提升 prompt cache 命中率
可观测性无约定_meta 中约定 traceparent / tracestate / baggage把 Agent trace 上下文透传给 Server，打通跨服务链路

不适用的情况：只用本地 stdio Server、且依赖的 SDK 尚未升级时，可以继续跑旧版本协议，server/discover 也可以作为 stdio 上的向后兼容探测。混合部署时以 SDK 支持的版本为准，不要手写协议层。

4. 架构模式​

4.1 Agent Runtime + 内置工具​

适合工具少、强业务耦合的系统。MCP 不是必须。

4.2 Agent Runtime + MCP Adapter​

Agent Runtime 保留内部工具，同时通过 MCP Adapter 连接外部 Server。

4.3 MCP-first Host​

IDE、桌面助手、企业 Agent 平台适合 MCP-first。Host 管理多个 Client，Server 由不同团队或供应商提供。

5. 工程实现​

5.1 MCP 工具到内部 ToolCall 的映射​

type InternalTool = {
  name: string;
  description: string;
  inputSchema: JsonSchema;
  outputSchema?: JsonSchema;
  source: {
    kind: "mcp";
    serverId: string;
    originalName: string;
  };
  risk: ToolRisk;
};

5.2 连接生命周期​

1. Host 启动 MCP Client
2. Client 调用 server/discover，选择双方都支持的协议版本
3. list tools/resources/prompts，按 ttlMs 缓存
4. 用户任务触发工具调用
5. Client 发送 tools/call，_meta 携带版本、能力和 trace 上下文
6. Server 返回 resultType=complete 的结果或错误
   - 若返回 input_required：向用户/Host 收集输入，带 inputResponses 重试原请求
7. Host 记录 trace 并回填模型

2026-07-28 之前的版本第 2 步是 initialize 握手，且连接级会话会保存状态；对接旧 Server 时由 SDK 负责降级。

6. 生产实践​

  • Host 侧仍然负责最终权限和用户确认，不把安全责任完全交给 Server。
  • 对每个 MCP Server 建立 trust level：官方、内部、合作方、未知。
  • stdio 适合本地开发工具；远程多用户服务优先 Streamable HTTP + OAuth。
  • 连接第三方 Server 前展示其工具列表、权限范围和数据访问说明。
  • 对 Server 版本、schema 变化、工具新增做审查。
  • 不同租户的 MCP 连接、token、缓存和日志必须隔离。

7. 常见反模式​

反模式问题
把 MCP 当安全边界MCP 是协议，不自动完成业务授权
任意安装第三方 MCP Server工具投毒和数据泄露风险
Server 暴露一个万能 shell 工具Host 无法做细粒度审批
忽视能力协商客户端假设 Server 支持某能力导致运行时失败
stdio Server 往 stdout 打日志干扰 JSON-RPC 通信
依赖连接会话保存业务状态2026-07-28 起协议级会话已移除，负载均衡后状态丢失
新实现继续接 Sampling / Roots已进入废弃窗口，后续版本会移除
写操作没有幂等键流断开后必须重发请求，可能重复执行副作用

8. 评测方法​

  • 协议兼容：server/discover、list、call、error、resultType 是否符合规范；旧版本 Server 能否降级。
  • 能力发现：工具列表和 schema 是否稳定，ttlMs 是否被遵守。
  • 权限联动：Host 是否能对 MCP 工具应用本地策略。
  • 安全测试：恶意 Server 描述、恶意工具返回是否被隔离。
  • 断连恢复：Server 重启、网络中断、OAuth 过期后的行为；流断开重发时写操作是否被幂等键拦住。
  • 多轮输入：input_required 结果能否正确挂起、收集输入并重试。

9. 安全与治理​

MCP Server 是新的供应链入口。治理重点：

  • Server 来源验证和 allowlist。
  • 工具描述审查。
  • OAuth audience 和 scope 校验。
  • 授权响应中存在 iss 时，Client 必须校验其与记录的 issuer 一致（RFC 9207）。
  • Client 凭证按 issuer 存储，不跨授权服务器复用；授权服务器变更需重新注册。
  • 客户端注册优先用 Client ID Metadata Documents（CIMD），OAuth 动态客户端注册（DCR）已废弃，仅为兼容保留。
  • 企业场景可用已稳定的 Enterprise-Managed Authorization 扩展，由企业 IdP 统一授权。
  • token 不透传给无关服务。
  • 工具返回作为不可信输入处理。
  • 远程 Server 必须使用 HTTPS。

路线图（2026-08-22）把“Agent 身份”列为优先方向：无人值守的云上 Agent、代表离线用户执行、向子 Agent 委托更窄权限，计划基于 DPoP、Workload Identity Federation 和 token exchange 标准化，而不是粘贴 API key 和长期 token。这部分尚未进入正式规范，设计时先按服务身份 / 用户委托身份分离处理，见 ../12-安全与治理/权限最小化.md。

10. MCP 与内部工具网关的关系​

MCP 解决“外部能力如何被发现和调用”，工具网关解决“这些能力是否能被当前用户安全使用”。两者不应混淆。

层负责什么不负责什么
MCP Server暴露 tools/resources/prompts，按协议返回结果替 Host 做最终业务审批
MCP Client与单个 Server 建立连接、发送 JSON-RPC 请求决定用户能否访问所有资源
Host/Agent Runtime组织上下文、调用模型、展示审批直接信任工具返回内容
Tool Gatewayschema 校验、权限、审计、限流、输出过滤替模型完成语义推理

11. 远程 MCP 接入流程​

12. MCP 接入评测方案​

评测项用例通过标准
能力发现Server 返回 tools/resources/promptsHost 正确登记并版本化
协议错误Server 返回 JSON-RPC errorAgent 不崩溃，错误可审计
授权边界token audience 不匹配连接被拒绝
工具投毒工具描述含隐藏指令注册审查拦截
断连恢复Server 重启、流断开或 OAuth 过期用新 request ID 重发，不重复执行写操作
多轮输入Server 返回 input_requiredHost 挂起并收集输入，重试后得到 complete
版本不匹配Server 返回 UnsupportedProtocolVersionErrorClient 降级或明确报错，不静默失败
多租户隔离A 租户 Server 不可被 B 使用trace 中无串租户

13. 安全补充：MCP 不是信任豁免​

连接 MCP Server 后，Host 仍要：

  • 对工具列表做 allowlist 和风险标注。
  • 对工具 schema 做安全扫描和人工审查。
  • 对工具调用做本地 policy check。
  • 对工具结果作为不可信内容处理。
  • 对 OAuth token 做 audience、scope、过期时间校验。
  • 对第三方 Server 变更建立重新审核流程。

14. 不适用场景​

  • 只有一两个强业务耦合内部工具时，直接内部工具注册更简单。
  • 工具需要严格事务和低延迟，远程 MCP 可能增加复杂度。
  • 组织没有 Server allowlist 和审计能力时，不应开放用户任意安装。
  • 高风险生产写操作不应直接暴露为无审批 MCP tool。
  • 需要把「怎么做这类任务」版本化时，用 Skill 编排 MCP，而不是再发明一层 RPC。见 ../19-Skills与能力平台/Skill与MCP集成.md。

15. 权威资料​