2023年12月5日

MCP

MCP 是一个开放协议，用统一的客户端-服务端接口把模型运行时与外部工具、资源和提示模板连接起来，解决 Agent 生态里重复接入、重复适配的问题。

知识库大模型智能体与工具调用agentmcptool-use

MCP（Model Context Protocol）

先说结论

MCP 是一个开放协议，用统一的客户端-服务端接口把模型运行时与外部工具、资源和提示模板连接起来，解决 Agent 生态里重复接入、重复适配的问题。

为什么我会单独记这一篇

在没有 MCP 之前，不同 IDE、桌面客户端和 Agent 框架通常都要为每个工具各接一套私有协议，导致：

集成碎片化，工具能力无法复用。
宿主与工具强耦合，迁移成本高。
权限、审计和可观测性难统一。

MCP 的目标是让 Host、Client、Server 之间有统一协议层，使工具、资源和提示模板可以跨宿主复用。

核心机制

架构角色

Host：真正运行 Agent 的应用，如 IDE、桌面客户端或工作台。
MCP Client：负责连接某个 MCP Server。
MCP Server：对外暴露能力。

三类核心能力

Tools：可执行动作，适合副作用操作或外部 API。
Resources：可读取上下文，适合文件、数据库 schema、知识条目。
Prompts：参数化提示模板，可复用任务入口。

典型生命周期

initialize
capability 协商
tools/list、resources/list、prompts/list
tools/call 或读取资源
结果回传给 Host，再作为上下文给模型

协议底层通常使用 JSON-RPC 2.0，传输层常见是 stdio 和 streamable HTTP。

与相邻概念的区别

MCP vs Function Calling：Function Calling 更像模型输出结构化参数，宿主自己调用函数；MCP 是把能力统一暴露成协议接口，供多个宿主复用。
MCP vs 插件系统：插件通常绑定单个平台；MCP 目标是跨宿主、跨客户端的通用能力层。
MCP vs 传统 API 集成：传统 API 是点对点耦合；MCP 更像能力抽象层。

设计时真正要权衡什么

Tools vs Resources：读取上下文更适合 resources，有副作用的动作才适合 tools。
本地 stdio vs 远端 HTTP：本地实现简单，远端更利于共享和集中治理。
能力丰富度 vs 安全边界：暴露的能力越多，权限和审计越复杂。

容易踩的坑

把所有外部能力都做成 tool，导致只读上下文和执行动作混在一起。
tool 描述含糊，模型不会选或误选。
server 返回内容过长，污染上下文并推高 token 成本。
权限边界不清，本地文件、shell、浏览器自动化暴露过宽。
工具或资源返回夹带恶意指令，触发间接提示注入。

工程落地时我会怎么做

优先把“读”和“写”分离：只读能力放 resources，副作用能力放 tools。
tool schema 要少而强约束，并写清楚何时使用、何时不要使用。
在 Host 层做权限门控、超时、重试、速率限制和人工确认。
对工具返回做裁剪与净化，避免把大块非结构化文本原样塞进上下文。
先从本地 stdio server 起步，稳定后再扩展到远端 HTTP server。
对 list/call/result 全过程做 tracing，方便定位是模型不会用还是 server 不稳定。

如果要对外讲，可以怎么概括

“MCP 的意义不在于多一个工具调用协议，而在于把工具、资源和提示模板统一抽象成可被多宿主复用的能力层。它解决的是 Agent 生态的集成碎片化问题。真正落地时，关键不只是协议本身，而是 tools 和 resources 的边界、权限控制以及对返回内容的治理。”

最后记几条

MCP 解决的是能力集成标准化，而不是单次函数调用。
Host、Client、Server 是三层角色。
Tools、Resources、Prompts 是三类核心能力。
stdio 适合本地，HTTP 适合远端共享。
MCP 一定要和权限、审计、注入防护一起设计。

参考资料

延伸阅读

大模型总索引