type
Post
status
Published
date
May 25, 2026
slug
agent50
summary
tags
Agent
category
icon
password
摘要
MCP（Model Context Protocol）可以理解为 Agent 时代的“工具与上下文接入协议”。它解决的不是“模型怎么推理”，也不是“向量检索怎么召回”，而是解决一个更工程化的问题：不同 Agent、IDE、聊天产品、RAG 系统，如何用统一方式连接外部工具、数据库、文件系统、企业应用、知识库和工作流。
官方文档把 MCP 定义为连接 AI 应用与外部系统的开放标准，AI 应用可以通过 MCP 访问本地文件、数据库、搜索引擎、计算器、工作流和专用 Prompt 等能力；最新规范版本是
2025-11-25，其核心通信基于 JSON-RPC 2.0、状态连接和能力协商。(Model Context Protocol)1. 为什么需要 MCP？
在没有 MCP 之前，Agent 系统接入外部能力通常有三种做法：
接入方式 | 问题 |
直接写 Function Calling | 每个模型厂商、每个 Agent 框架都要重复适配 |
在 Prompt 里塞 API 文档 | 容易幻觉、参数错误、上下文膨胀 |
自研工具插件协议 | 只能在自己的系统里用，迁移成本高 |
Anthropic 在发布 MCP 时指出，AI 系统长期受限于数据孤岛和碎片化集成：每接一个数据源都要做一次定制实现，而 MCP 的目标就是用统一协议替代这些零散集成。(Anthropic)
更直观地说：
Function Calling 解决的是“模型如何调用某个函数”；MCP 解决的是“工具、数据源、上下文如何被不同 Agent 标准化发现、授权、调用、返回结果”。
这就是为什么 Claude Code、OpenCode、OpenAI Agents SDK、ChatGPT Apps/Connectors、GitHub MCP Server 等生态都在围绕 MCP 建连接层。Claude Code 文档明确说明，MCP server 可以让 Claude Code 连接外部工具、数据库和 API，避免开发者手动把 issue、监控数据、数据库结果复制进对话。(Claude Code)
2. MCP 在 Agent 架构中的位置
MCP 不直接替代 Agent，也不替代 RAG。它更像是 Agent 与外部世界之间的标准 I/O 层。
MCP 规范中有三个核心角色：
角色 | 作用 |
Host | 发起连接的 LLM 应用，比如 Claude Code、OpenCode、ChatGPT、自研 Agent |
Client | Host 内部的 MCP 连接器，负责和 MCP Server 通信 |
Server | 提供工具、资源、Prompt、数据访问能力的服务 |
官方规范明确说明，MCP 使用 JSON-RPC 2.0 在 Host、Client、Server 之间建立通信；Server 提供 context 和 capabilities，Client 是 Host 内部的连接器。(Model Context Protocol)
3. MCP 的核心能力：Tools、Resources、Prompts
MCP Server 暴露给 Agent 的能力主要分三类：
能力 | 控制方 | 适合场景 |
Tools | 模型控制 | 查数据库、调 API、创建 issue、发消息、执行计算 |
Resources | 应用控制 | 文件内容、Git 历史、数据库 schema、文档片段 |
Prompts | 用户控制 | 代码审查模板、排障流程、固定工作流入口 |
官方 Server Features 文档把三者的控制关系讲得很清楚：Prompts 通常由用户显式触发，Resources 由应用选择如何附加上下文，Tools 则是模型可以根据任务自动选择调用的函数。(Model Context Protocol)
3.1 Tools：让模型能“做事”
Tools 是 MCP 最常用的部分。一个 MCP Tool 需要提供：
字段 | 作用 |
name | 工具唯一标识 |
title | 面向 UI 的可读名称 |
description | 给模型看的工具说明 |
inputSchema | JSON Schema 参数定义 |
outputSchema | 可选，定义结构化输出 |
最新 MCP Tools 规范中，工具通过
tools/list 发现，通过 tools/call 调用；工具定义包含 name、description、inputSchema 等元数据，也支持 outputSchema 来约束结构化返回。(Model Context Protocol)3.2 Resources：让模型能“读上下文”
Resources 更像是“可读取的上下文资产”。它可以是：
Resource 类型 | 示例 |
文件资源 | file:///project/src/main.py |
Git 资源 | 某次 commit diff |
数据库资源 | 表结构、字段说明 |
文档资源 | API 文档、内部知识库文章 |
MCP Resources 规范说明，资源通过 URI 唯一标识，常见场景包括文件、数据库 schema、应用特定信息等，客户端可以通过
resources/list 发现资源，通过 resources/read 读取内容。(Model Context Protocol)3.3 Prompts：把工作流做成可发现模板
Prompts 可以把高频工作流做成模板，例如：
Prompt | 用途 |
code_review | 固定代码审查流程 |
incident_triage | 故障排查流程 |
write_test_plan | 自动生成测试计划 |
rag_eval | 对 RAG 召回结果做评估 |
MCP Prompts 规范说明，Server 可以向 Client 暴露 Prompt 模板，Client 可以发现 Prompt、获取 Prompt 内容，并传入参数进行定制。(Model Context Protocol)
4. MCP 的通信原理
MCP 的底层是 JSON-RPC 2.0。一次典型连接包括三个阶段：
初始化阶段是 MCP 的第一步，Client 会发送协议版本、Client capabilities、Client 信息，Server 返回自身 capabilities、协议版本和 Server 信息；初始化后，Client 发送
notifications/initialized 表示可以进入正常通信。(Model Context Protocol)4.1 Transport：stdio 与 Streamable HTTP
MCP 当前标准 Transport 主要有两种：
Transport | 适合场景 |
stdio | 本地工具、本地文件系统、CLI 工具、开发环境 |
Streamable HTTP | 远程 SaaS、云服务、团队级 MCP Server |
最新 Transport 规范说明，MCP 使用 JSON-RPC 编码消息，标准传输包括
stdio 和 Streamable HTTP；stdio 中 Client 会把 MCP Server 作为子进程启动，通过 stdin/stdout 交换 JSON-RPC 消息；HTTP 传输使用单一 MCP endpoint，并支持 POST、GET 与可选 SSE 流式消息。(Model Context Protocol)5. MCP 与 RAG 的关系
很多人会把 MCP 误解成 RAG。准确说：
RAG 是一种“知识检索 + 生成”的应用模式；MCP 是一种“把检索能力暴露给 Agent 的协议”。
例如你可以把企业知识库做成 MCP Server，暴露两个 Tool：
Tool | 作用 |
search(query) | 从向量库、BM25、混合检索中返回候选文档 |
fetch(id) | 根据文档 ID 返回完整内容、片段、引用 URL |
OpenAI 的 MCP Server 构建文档中就给出了非常典型的 RAG 化设计：用远程 MCP Server 读取私有数据源或 vector store，并要求面向 ChatGPT deep research/company knowledge 的数据型 MCP Server 实现只读的
search 和 fetch 两个工具。(OpenAI开发者)这种模式的好处是：
传统 RAG 接入 | MCP 化 RAG 接入 |
检索逻辑和 Agent 框架强耦合 | 检索服务可以被多个 Agent 复用 |
换模型/换 IDE 要重新适配 | 只要 Host 支持 MCP，就能复用 |
工具描述散落在 Prompt 里 | 工具 schema、权限、结果格式标准化 |
上下文容易一次性塞爆 | 可以按需 search，再按需 fetch |
6. 与 Claude Code、OpenCode、OpenClaw 的实践对比
6.1 Claude Code：MCP 是“开发工具连接层”
Claude Code 支持通过 MCP 连接 issue tracker、监控系统、数据库、Figma、Slack、Gmail 等工具；官方示例包括“根据 Jira issue 实现功能并创建 PR”“查询 Sentry/Statsig 监控数据”“查询 PostgreSQL”“根据 Slack 中的 Figma 设计更新模板”等。(Claude Code)
Claude Code 的 MCP 配置也体现了工程侧的关键点：
能力 | 说明 |
remote HTTP server | 推荐用于云服务 |
SSE server | 旧式远程传输，文档中提示优先用 HTTP |
local stdio server | 适合本地脚本、本地文件、开发机能力 |
local/project/user scope | 区分个人私有、项目共享、用户全局配置 |
permission | MCP 工具需要显式授权才能调用 |
Claude Code Agent SDK 文档还说明，MCP 工具需要显式 permission；工具命名遵循
mcp__<server-name>__<tool-name>，并可以通过 allowedTools 预授权特定工具。(Claude Code)6.2 OpenCode：MCP 是“内置工具之外的扩展工具系统”
OpenCode 文档说明，可以通过 MCP 添加 local 和 remote 外部工具，添加后 MCP 工具会和内置工具一起提供给 LLM 使用；但它也特别提示，MCP Server 会增加上下文，工具太多会迅速膨胀，GitHub MCP 这类工具集很容易接近或超过上下文限制。(OpenCode)
这点非常关键：MCP 解决工具接入标准化，但不自动解决工具爆炸问题。当一个 GitHub MCP Server 暴露几十上百个工具时，Agent 每轮都加载所有工具定义，会带来 token、延迟和选择难度问题。Anthropic 工程博客也提到，开发者现在会给 Agent 接入数百甚至上千个工具，而一次性加载所有工具定义和中间结果会拖慢 Agent 并增加成本。(Anthropic)
6.3 OpenClaw：MCP 既可以是 Server，也可以是 Client Registry
OpenClaw 文档中，
openclaw mcp 有两类职责：一是通过 openclaw mcp serve 把 OpenClaw 作为 MCP Server 暴露出去；二是通过 list/show/set/unset 管理 OpenClaw 自己的 outbound MCP server 定义。(OpenClaw)这说明成熟 Agent 系统不会只把 MCP 当“插件机制”，而会把它放进整体运行时架构：
OpenClaw 的 MCP serve 路径会启动 stdio MCP Server，MCP Client 拥有该进程；桥接层再通过 WebSocket 连接本地或远程 OpenClaw Gateway，把 channel conversations、transcript/history tools、live events 等能力通过 MCP 暴露。(OpenClaw)
7. 源码级理解：一个最小 MCP RAG Server
下面是一个简化版 MCP RAG Server。真实项目中可以把
search_docs 接到 Elasticsearch、Milvus、pgvector、Qdrant、Vespa、OpenSearch 或内部知识库。官方 MCP Server 构建指南使用 Python
FastMCP 作为示例，并说明 FastMCP 可以基于 Python type hints 和 docstring 自动生成工具定义，降低维护工具 schema 的成本。(Model Context Protocol)8. 工程实践：我会如何落地 MCP？
先诚实说明：我不能声称自己在某个真实公司环境中亲自上线过 MCP 项目。但如果按生产系统设计，我会把 MCP 实践拆成下面 7 层，这也是目前成熟 Agent/RAG 系统更稳妥的落地方式。
8.1 第一层：工具分级
等级 | 示例 | 策略 |
L0 只读低风险 | 搜索文档、读 issue、查日志 | 可自动调用 |
L1 只读敏感 | 查用户信息、查订单 | 需要最小权限和脱敏 |
L2 写操作 | 创建 issue、发 Slack、改配置 | 必须确认 |
L3 高危操作 | 删除数据、执行 shell、发外部邮件 | 默认禁用或强审批 |
MCP 规范明确提醒，工具代表任意代码执行路径，Host 必须让用户理解并授权工具行为；OpenAI 的 MCP 指南也建议敏感动作始终要求 approval，并通过
allowed_tools 限制可用工具。(Model Context Protocol)8.2 第二层：工具网关
不要让 Agent 直接连所有 MCP Server，而是加一个 Tool Gateway：
Tool Gateway 负责：
模块 | 职责 |
Tool Registry | 管理工具元数据、版本、owner |
Policy Engine | 判断是否允许调用 |
Audit Log | 记录参数、调用人、结果摘要 |
Rate Limit | 防止 Agent 死循环调用 |
Output Filter | 对工具结果脱敏、截断、压缩 |
Tool Router | 只把当前任务相关工具暴露给模型 |
8.3 第三层：RAG MCP 标准化
企业知识库建议只暴露两个基础工具：
这样做的优势是：
设计点 | 好处 |
search/fetch 分离 | 避免一次性把全文塞进上下文 |
search 返回 snippet | 让模型先判断是否相关 |
fetch 返回完整正文 | 只读取真正需要的文档 |
输出带 url/source | 便于引用和审计 |
只读工具 | 降低安全风险 |
这与 OpenAI MCP 文档中的 data-only app 设计一致：
search 返回相关结果列表，fetch 根据 ID 返回文档内容，并建议使用结构化内容便于客户端验证。(OpenAI开发者)8.4 第四层：工具选择优化
MCP 工具太多时，不应该全量塞给模型。推荐做三步：
可落地策略：
策略 | 说明 |
Tool RAG | 对工具 name、description、schema 建索引 |
按任务加载 | 只注入当前任务相关 MCP Server |
按权限加载 | 用户无权限的工具不进上下文 |
按阶段加载 | plan 阶段只读，execute 阶段再开放写工具 |
缓存 tools/list | 减少每轮重新拉工具定义 |
OpenAI Responses API 的 MCP 指南也提到，工具列表成功导入后会出现
mcp_list_tools 输出项，只要该项保留在上下文中，后续同一会话不必每轮重新拉取工具列表；同时也建议用 allowed_tools 过滤大型 MCP Server 的工具集合。(OpenAI开发者)8.5 第五层：输出截断与结构化返回
MCP Tool 输出过大是常见事故。Claude Code 文档说明，MCP 工具输出超过 10,000 tokens 会提示 warning，默认最大输出限制是 25,000 tokens，并可通过
MAX_MCP_OUTPUT_TOKENS 调整。(Claude Code)生产环境建议：
输出类型 | 处理方式 |
日志 | 默认返回摘要 + top error lines |
SQL 查询 | 限制行数，禁止 SELECT * 大表 |
文档 | search 返回片段，fetch 才返回正文 |
API JSON | schema 化 + 字段白名单 |
文件 diff | 大 diff 分块返回 |
8.6 第六层：安全防护
MCP 的风险主要来自四类：
风险 | 例子 | 防护 |
Prompt Injection | 网页内容诱导模型调用高危工具 | 外部内容隔离、工具调用确认 |
Tool Poisoning | MCP Server 的 tool description 暗藏恶意指令 | 只信任官方 Server，工具描述审查 |
权限扩大 | GitHub token 给了过大 scope | 最小权限 token |
数据外泄 | 工具结果包含密钥、PII | 输出脱敏、审计、DLP |
官方规范强调，MCP 本身不能在协议层强制所有安全原则，Implementor 应实现 consent、authorization、access control、data protection 等机制；OpenAI 文档也建议连接可信服务器、记录发送到第三方 MCP Server 的数据，并警惕 MCP Server 输出中的隐藏指令。(Model Context Protocol)
8.7 第七层：观测与评估
MCP 调用链路必须可观测：
指标 | 用途 |
tool_call_count | 判断是否陷入工具循环 |
tool_latency_p95 | 定位慢工具 |
tool_error_rate | 判断 MCP Server 质量 |
approval_reject_rate | 判断工具描述是否过度触发 |
tokens_per_tool | 控制上下文成本 |
successful_task_rate | 评估 Agent 项目效果 |
human_override_rate | 衡量工具决策可信度 |
9. MCP 与 Function Calling 的区别
维度 | Function Calling | MCP |
抽象层级 | 模型调用函数的接口 | Agent 与外部系统通信协议 |
生命周期 | 通常随一次请求定义 | 有连接、初始化、能力协商、会话 |
工具发现 | 开发者手动传 tools | Client 可通过 tools/list 发现 |
传输方式 | 厂商 API 内部 | stdio / Streamable HTTP / 自定义传输 |
生态复用 | 依赖模型厂商 | 多 Host、多 Client、多 Server 复用 |
适合场景 | 少量内部函数 | 多工具、多系统、跨 Agent 平台 |
一句话总结：
Function Calling 是“模型函数调用机制”；MCP 是“Agent 工具生态协议”。
10. MCP 的最佳实践清单
实践 | 建议 |
工具描述 | 写清楚“什么时候用”，不要只写“能做什么” |
参数 schema | 严格 JSON Schema，枚举值尽量显式 |
输出 schema | 重要工具必须结构化返回 |
权限 | 只读默认开放，写操作审批，高危禁用 |
工具数量 | 不要全量加载，做工具检索和动态注入 |
RAG 工具 | 优先 search/fetch 分离 |
日志 | 记录调用参数、结果摘要、用户确认 |
安全 | 防 Prompt Injection、最小权限、输出脱敏 |
版本 | MCP Server schema 变更要版本化 |
失败处理 | Tool error 要返回可恢复信息，而不是直接抛栈 |
11. 一段可用于面试/博客结尾的“实践回答”
如果被问“你是否有 MCP 实践”，可以这样回答：
我没有把 MCP 当成单纯的插件功能，而是把它作为 Agent 的工具接入层来设计。实践上，我会先把内部知识库封装成只读 MCP Server，暴露search和fetch两个工具，让 Agent 可以按需检索和读取文档；再把 GitHub、Jira、Sentry、数据库等能力按风险等级拆成不同 MCP Server，通过 Tool Gateway 做权限、审计、限流和输出截断。在 Claude Code / OpenCode 这类 coding agent 中，我会优先使用 stdio MCP 接本地开发工具，用 HTTP MCP 接企业 SaaS；对于工具很多的 GitHub MCP 或内部平台 MCP，不会一次性全部暴露给模型，而是做 Tool RAG 和allowed_tools过滤，只注入当前任务需要的工具。从效果上看，MCP 最大的价值不是让模型“更聪明”，而是让 Agent 的外部能力接入变得标准化、可治理、可复用。它把原来散落在 Prompt、插件、SDK、脚本里的工具调用能力，收敛成了可以被不同 Agent 共同使用的协议层。
12. 总结
MCP 的核心价值可以概括为三句话：
第一，MCP 是 Agent 连接外部世界的标准协议，不是 RAG 算法。第二，它通过 Tools、Resources、Prompts、Roots、Sampling、Elicitation 等机制，把工具、上下文、工作流和用户交互标准化。第三，MCP 真正落地时，重点不只是“接上工具”，而是工具治理：权限、审计、限流、输出控制、工具检索、安全确认和可观测性。
对于 RAG/LLM/Agent 项目来说，MCP 最适合放在 工具层、知识库接入层、企业系统集成层和多 Agent 互操作层。如果项目还处在 Demo 阶段，可以先用 Function Calling；如果已经进入多工具、多系统、多 Agent、多 IDE、多模型协作阶段，MCP 就会从“可选项”变成“工程基础设施”。
分享