大语言模型擅长理解文字和生成内容，但它本身不知道电脑里刚修改的文件，也不能天然读取公司的数据库。要让 AI 真正参与工作，应用通常需要为它接入搜索、文件系统、业务接口等外部能力。MCP（Model Context Protocol，模型上下文协议）所解决的，正是这些连接如何用较统一的方式建立。
它连接的不是模型与整个世界
一套常见的 MCP 结构里，可以先记住四个角色。模型负责理解意图和生成答案；客户端承载对话，决定何时向外请求能力；MCP 服务端把某个系统的能力按协议提供出来；工具与资源则是服务端具体开放的内容。
工具通常表示可执行的动作，例如查询天气、创建工单或运行一段受限脚本。资源更接近可读取的上下文，例如项目文档、数据库结构或一份配置文件。有些实现还会提供可复用的提示模板。模型提出调用建议，客户端负责组织请求，服务端实际访问外部系统，再把结果送回客户端和模型。模型并不是直接获得了服务器的全部权限。
可以类比 USB，但不要把类比当成定义
人们常把 MCP 比作 AI 世界的 USB：设备遵守同一种接口后，不必为每台电脑重新设计插头。这个类比适合说明“统一连接方式”的价值。以前每个 AI 应用都可能为每个数据源单独开发适配代码；采用协议后，客户端和服务端可以围绕共同约定协作，重复劳动会减少。
不过，MCP 不是一根传输任意内容的万能线，也不会自动解决兼容性、权限和数据质量问题。客户端支持哪些能力、服务端开放什么内容、参数如何设计，仍然需要开发者明确约定。遵守同一协议，只代表双方更容易开始交流，不代表所有组合都能无缝工作。
一次调用大致如何发生
假设用户问：“帮我找出项目中本周修改过的说明文档。”模型先识别任务需要文件信息，客户端发现已连接的文件服务，并把可用工具及参数描述提供给模型。模型选择合适工具，生成目录、时间范围等参数；客户端在允许的范围内发出请求，服务端完成检索并返回文件清单，最后模型依据结果整理回答。
这段流程的关键是“能力可被描述”。模型不必预先记住某个系统的私有调用方式，而是根据服务端提供的名称、说明和参数结构决定如何使用。开发者也可以独立更新连接层，不必把每一种外部能力都写死在对话应用里。
授权与安全比连接本身更重要
能连接不等于应该放行。设计 MCP 服务时，应遵循最小权限：只开放完成任务所需的目录、数据表和操作，并区分只读与写入。删除文件、发送消息、执行命令、修改业务数据等高影响动作，最好要求用户再次确认，而不是让模型在后台静默完成。
客户端还应清楚展示正在连接哪个服务、将发送哪些数据，并允许用户随时撤销授权。服务端需要验证身份、校验参数、限制访问范围并保留必要的审计记录。来自外部资源的文本也不能天然视为可信指令，否则恶意内容可能诱导模型调用不该调用的工具。协议提供的是通道，风险控制仍是应用和服务双方的责任。
什么时候值得用，什么时候不必用
当团队需要让多个 AI 客户端重复接入同一套知识库、代码仓库或内部系统时，MCP 很有价值。它也适合把能力拆成可维护的服务，让不同模型在相同授权边界下使用。个人工作流中，如果经常跨文件、日历、笔记和开发工具处理任务，统一接口同样能降低整合成本。
但如果应用只调用一个固定接口，功能简单且短期不会扩展，直接集成往往更省事。纯文本问答、一次性脚本以及对延迟极为敏感的链路，也未必需要再增加一层协议。MCP 不是让模型变聪明的魔法，而是一种工程协作方式：当连接数量、复用需求和治理要求开始增长时，它的价值才会真正显现。