---
url: 'https://aisee.wiki/learn/mcp/index.md'
---
# MCP：让 Agent 连接外部能力

MCP 是 Agent 连接外部工具、数据和服务的桥梁，让模型能在受控接口下使用外部能力。

## 为什么 Agent 需要 MCP

模型本身不能天然访问你的浏览器、Figma、数据库、文档系统或企业内部工具。真实工程任务却经常需要这些能力：打开页面检查 UI、读取设计稿、查文档、读测试数据、接企业内部系统。

MCP 的价值就在这里：它把这些外部能力变成 Agent 可以理解和使用的受控入口。它解决的不是“模型会不会写代码”，而是“模型怎么安全地接到外部世界”。

## 基本角色

| 角色 | 作用 | 更像什么 |
|---|---|---|
| MCP Client | Agent 所在应用，负责发起连接和消费能力 | 连接发起方 |
| MCP Server | 把外部系统能力包装成可调用接口 | 能力暴露方 |
| Tool | 让 Agent 执行动作，例如查数据、读设计、操作浏览器 | 动作接口 |
| Resource | 让 Agent 读取外部上下文，例如文件、文档、记录 | 可读上下文 |
| Prompt | 提供可复用的任务模板或上下文入口 | 任务入口 |

这里最容易混淆的是：很多人会把 MCP 直接等同于 Tool。实际上 Tool 只是 MCP 可能暴露出来的一种能力形态，Resource 和 Prompt 也可能通过 MCP 提供。

## 典型场景

* `浏览器`
  打开页面、点击、截图、验证 UI。
* `Figma`
  读取设计稿、资产和组件信息。
* `文档 / PDF`
  读取需求、规格、表格、知识库和说明文档。
* `数据库`
  查询开发或测试数据。
* `企业内部系统`
  工单、监控、发布、知识库、内部平台。

你可以把这些场景理解成一个判断题：只要任务已经超出“读本地文件和跑本地命令”的范围，就要考虑是不是需要一个连接层，而不是让模型凭空猜测外部系统状态。

## 权限与边界

MCP 最需要强调的不是“能连什么”，而是“连上以后怎么控制风险”。

在真实项目里，至少要明确这几件事：

* 读取能力和写入能力要分开。
* 测试环境和生产环境要分开。
* 密钥、数据范围和审计日志要独立管理。
* 能调用，不等于应该默认允许调用。

::: warning MCP 不是无限授权
连接能力不等于可以随便操作。权限、审计、数据范围、密钥管理和误操作恢复，都需要在工具配置和项目规则里明确。
:::

## MCP 与 Tool 的关系

Tool 解决的是“Agent 怎么做动作”，MCP 解决的是“这些动作怎么安全地连到外部系统”。

它们的关系可以这样理解：

* MCP 常常会提供 Tool。
* 但 Tool 不一定都来自 MCP。
* 本地 Shell、文件编辑、apply patch 这类工具，就不一定依赖 MCP。
* MCP 的重点不是动作本身，而是外部能力接入的标准化和边界控制。

所以如果 Tool 是“手”，MCP 更像“把手伸向外部系统时的受控连接层”。