The Hook:
The Hook:
你正在构建一个 AI Agent。它很聪明，会聊天。但……它被困住了。
它不能浏览网页。
它不能访问文件。
它不能调用 APIs。
它被困在自己的沙盒里——就像给一位天才一本空白笔记本，却锁上了门。
现在想象这样：
你写六行代码，给你的 agent 配备浏览器控制、文件系统访问和实时 API 查询等工具——然后它立刻生效。
欢迎使用 MCP-Use：一个看似简单的 Python 库，连接任何 LLM与任何外部工具，通过开放的Model Context Protocol (MCP) — 由***Pietro Zullo***打造
为什么这很重要（以及我为什么写这篇文章）
几个月来，像我这样的开发者一直在拼凑脆弱的工具链，只为让 ChatGPT 能搜网页，调用自定义 API。我们尝试了 LangChain agents，写了包装器，折腾插件。但所有这些都绑定于特定模型、封闭应用或复杂的黑客手段。
MCP-Use 解决了这些问题——干净、开放且强大。
这篇指南将全方位介绍：MCP-Use 的工作原理、它解决的问题，以及如何构建能思考和行动的 agent——用真实案例，比如控制浏览器、搜索 Airbnb、驱动 Blender 3D、甚至操作 IoT 设备。
如果你曾想赋予 LLM 现实世界的能力，这里是最灵活的做法。
一起深入解析 ?
什么是 MCP-Use（以及它为何改变游戏规则）
要理解 MCP-Use，首先你要了解它解决的痛点：
目前所有主流 LLM API——OpenAI、Anthropic、Cohere——都能提供出色的文本生成。但基于此行动？ 依然非常受限。
想让 GPT-4 运行网页搜索？
Claude 读取文件或查询数据库？
Llama3 控制像 Blender 3D 这样的应用？
你常常要构建定制集成，对接 API，或者依赖 ChatGPT 插件、Cursor IDE、Claude Desktop 等厂商专属平台。
这时，Model Context Protocol (MCP) 诞生——而 MCP-Use 让它真正可用。
MCP 的核心理念
MCP 是一种新的开放协议——可以理解为功能调用的增强版。
它借鉴了代码世界的 Language Server Protocol (LSP)，让 LLM 以标准化、带状态的方式发现并调用外部工具。工具通过服务器暴露，各个服务器声明自己的能力（函数、参数、返回类型）。
它开放、模型无关且可扩展——是 AI 工具的罗塞塔石碑。
但 MCP 仅是协议。要使用它，你需要一种把模型和工具服务器连接起来的方式。
这正是 MCP-Use 的作用——用 6 行 Python 代码启动一个搭载工具的智能 agent。
那么 MCP-Use 是什么？
MCP-Use 是一个 Python 库，具备 MCP 客户端功能。
它通过 LangChain 将任何 LLM 接入任何 MCP 服务器（浏览器、文件系统、API、3D 渲染器等），让你的 agent 动态且智能地使用工具。
它能：
-
• 发现服务器端公开的工具 -
• 把工具转换成可供 LLM 调用的函数 -
• 处理所有 JSON-RPC 消息，支持 HTTP 或本地 I/O -
• 管理会话、工具调用、响应和内存
且拥有清晰的抽象层——让你不用担心协议细节，专注构建更棒的 agent。
简要总结
MCP-Use = Agent + Tools + 任意 LLM
一个轻量开源的方式，构建不锁定单一平台或插件生态的工具型 agent。
MCP-Use 架构内部简析
MCP-Use 核心架构围绕两个关键组件：MCPClient 和 MCPAgent。一个负责连接工具，另一个负责agent 智能。它们协力让你的 LLM 驱动 agent 发现、调用、协调工具——通过开放 Model Context Protocol。
详解如下：
1. MCPClient：连接外部工具的桥梁
负责与外部世界连接。
你在 JSON 配置里定义工具（如浏览器、文件服务器、API 封装），MCPClient 会：
-
• 启动 MCP 服务器（本地用 CLI 如 npx，或远程用 HTTP/SSE） -
• 读取服务器暴露的工具定义（如 "search_web"、"read_file"、"render_scene"） -
• 维护活跃会话 -
• 处理消息传递(JSON-RPC 2.0)、异常、重试、超时
简单来说，MCPClient 确保所有工具随时可用、明确且可调用——无论它们在哪。
2. MCPAgent：大脑层
让魔法发生的地方。
MCPAgent 位于 LLM 和工具之间。它：
-
• 将每个工具映射成 LLM 可见并调用的函数（类似 OpenAI 的函数调用或 Claude 的工具支持） -
• 维护会话记忆（可选），跟踪 LLM 说了什么、做了什么 -
• 管理决策循环：
-
1. LLM 收到请求 -
2. 它思考：我要不调用工具？ -
3. 调用工具（如 search_web(query="MCP-Use Python")） -
4. MCPAgent 调用 MCPClient 运行工具 -
5. 工具结果返回给 LLM -
6. 循环继续，直至完成回答
无需额外编码——MCP-Use 封装了所有。传入模型和配置，调用 agent.run("查询内容") 即可。
全流程简览
[你的提问] ─▶ MCPAgent
├── 记忆与 Prompt 设计
├── 函数调用接口
▼
[LLM 思考中...]
├── 选择工具
▼
调用 MCPClient.run_tool()
├── 发送 JSON-RPC 请求
▼
MCP 服务器执行工具（如浏览器）
└── 返回结果给 MCPClient
↓
MCPAgent 将结果反馈给 LLM
↓
LLM 完成任务 → 返回最终回答重点总结
MCPClient 负责连接与能力发现。
MCPAgent 负责 LLM 智能和工具调用编排。
优势？你能同时连接 多个 MCP 服务器——agent 会智能管理它们。
快速上手 MCP-Use — 6 行代码造你的第一个工具调用 Agent
想快速打造一个能浏览网页或操作本地文件的 LLM 助手？无需大量样板，无需庞大框架。
用 MCP-Use，只需 6 行 Python 代码。
来看看具体操作。
第 1 步：安装依赖
确保 Python 3.11+。
安装 MCP-Use 和你的 LLM 提供商（这里用 OpenAI）：
pip install mcp-use langchain-openai
运行类似浏览器自动化的工具，还需要 Node.js（用于通过 npx 启动如 @playwright/mcp 的工具）。
第 2 步：创建工具配置文件
保存为 mcp-config.json：
{
"mcpServers": {
"browser": {
"command": "npx",
"args": ["@playwright/mcp@latest"]
}
}
}定义一个 MCP 服务器：基于 Playwright 的浏览器工具。MCP-Use 会通过 npx 启动它。
第 3 步：添加 API Key
在相同目录下创建 .env：
OPENAI_API_KEY=your_openai_key_here
Python 中用 dotenv 加载：
pip install python-dotenv
第 4 步：编写 Agent（6 行代码！）
from dotenv import load_dotenv
from mcp_use import MCPAgent, MCPClient
from langchain_openai import ChatOpenAI
load_dotenv()
client = MCPClient.from_config_file("mcp-config.json")
agent = MCPAgent(llm=ChatOpenAI(model="gpt-4"), client=client)
print(await agent.run("Search for best sushi places in Tokyo"))完成。
运行脚本时：
-
1. 会启动浏览器 MCP 服务器 -
2. LLM 会选择调用 search_web或click_link等工具 -
3. 工具执行，结果被返回 -
4. 你获得最终答复
示例输出
“基于最新搜索结果，东京顶级寿司店包括 Sushi Saito、Sushi Yoshitake 和 Sukiyabashi Jiro……”
✨ LLM 动态决定调用什么工具，并完成任务。
任何模型，任何工具——MCP-Use 生态系统
你不会造一部只能跑一个应用的智能手机。
那为什么构建一个只支持单一模型或工具的 AI agent？
这就是 MCP-Use 真正强大的地方。
核心不是某个模型或框架的巧妙包装——而是 LLM 和外部工具之间通过MCP 协议的开放接口，让你自由构建。
详细拆解。
兼容的模型（此处原文止）MCP-Use 支持任何可以使用 function calling 的基于聊天的 LLM——这包括大多数现代前沿模型。
以下是非详尽列表：
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
它们有什么共同点？
它们都能function-call——当它们想调用工具时，会输出结构化的 JSON，而非纯文本。
这就是 MCP-Use 所需的全部。
? 它利用 LangChain 的 chat models 来接入每个模型，使得切换提供方变得简单，无需重写逻辑。
插拔即用的工具
另一方面，MCP-Use 可以连接到任何以 MCP server 形式暴露自身的工具——社区已经构建了一些非常出色的工具。
热门 MCP Servers
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
所有这些都是开源的，主要托管在 NPM 或 GitHub。
它们遵循 MCP 规范，并用类似如下的 schema 来暴露工具：
{
"name":"search_listings",
"description":"Search Airbnb for listings",
"parameters":{
"location":"string",
"max_price":"number",
"amenities":"list"
}
}MCP-Use 会读取它，展示给模型，然后让 agent 像调用原生函数一样调用它。无需特殊代码。
混搭：你的模型，你的工具
这里才是魔力所在。
因为两边是解耦的——模型和工具——你可以随意组合。
场景：使用 Claude 3 配合 Headless Browser 和本地文件访问
{
"mcpServers": {
"web": {
"command": "npx",
"args": ["@playwright/mcp"]
},
"fs": {
"command": "npx",
"args": ["@modelcontextprotocol/server-filesystem", "/sandbox"]
}
}
}
from langchain.chat_models import ChatAnthropic
client = await MCPClient.from_config_file("tools.json")
agent = MCPAgent(llm=ChatAnthropic(), client=client)
await agent.run("Search for news about AI startups and save the headlines")搞定。你的 Claude 驱动 agent 现在拥有浏览器和文件系统。
场景：使用本地 LLaMA 模型配合自定义 API Wrapper
假设你有一个通过 Ollama 运行的本地 LLaMA 3，还有一个用 Python 实现的 MCP server，封装了你的内部 CRM API。你可以二者本地运行——无云端，无互联网——同样的 agent 逻辑仍然有效。
对于 MCP-Use，工具不依赖于模型。
它们依赖于协议。这是一个巨大的架构优势。
远程工具、WebSockets 以及云端 Agent
并非所有 MCP servers 都必须是本地的。
你也可以连接到基于 HTTP 或 WebSocket 的远程 MCP servers，意味着：
-
• 你可以把工具部署到云端（例如：全天候运行的爬虫服务器） -
• 可以拆分计算：本地运行模型，远程运行工具，或反之 -
• 可以构建多用户 Agent，共享中心化工具访问
只需替换配置：
{
"mcpServers": {
"scraper": {
"url": "https://tools.example.com/mcp/sse"
}
}
}MCP-Use 会在背后处理连接类型。只要遵守 MCP 协议，Agent 就能使用。
不信任你的模型？没问题。
你可以在运行时或配置中禁用任意工具，防止误用。
例如：
-
• 禁用 shell 命令 -
• 禁用 write_file，但允许read_file -
• 创建只读的安全沙箱
只需在创建 agent 时传入不允许的工具名列表：
agent = MCPAgent(..., disallowed_tools=["shell", "delete_file"])
你的模型可能聪明，但你更聪明。
“任意 LLM，任意工具”——核心架构概览
总结一下：
+----------------+ +----------------+ +------------------+
| Any LLM | <--> | MCP-Agent | <--> | MCP Servers |
| (Claude, GPT) | | (MCP-Use lib) | | (Browser, APIs) |
+----------------+ +----------------+ +------------------+MCP-Use 位于中间，解析工具 schema，转发调用，让模型能像调用原生功能一样使用工具。
MCP-Use 与其他方案的比较 —— 重要性何在
说实话：现在 AI 工具铺天盖地。
LangChain、OpenAI Plugins、Hugging Face Agents、ReAct、AutoGPT、CrewAI、OpenAgents……一片丛林。它们都试图推动边界，但都有一个根本问题：
? 工具使用碎片化。 每个模型有自己用工具的方式，每个框架都在重新发明轮子。大多数都与特定云模型或平台紧耦合。
我们来哲学性地对比一下 MCP-Use — 不仅仅是功能层面。
LangChain Agents
LangChain 广泛用于构建复杂的 LLM 应用。它的 agents 可通过 function calling 使用工具，支持多种提供方。
但……
-
• 工具往往与 LangChain 逻辑紧耦合 -
• 你需要用 Python 定义工具，通常还要用 wrapper -
• 多工具编排容易变脆弱（ReAct 循环调试是必经之路）
MCP-Use 优势：
-
• 工具是外部化的，不绑死你的代码 -
• 换模型不需重写工具 -
• LLM 拿到的是schema 和工具名，不是定制 wrapper
✅ LangChain 负责编排逻辑
✅ MCP-Use 负责解耦、可重用的工具接口
二者联合？威力无穷——你甚至能在 LangChain chain 内使用 MCP-Use agent。
OpenAI Plugins / Assistants API
OpenAI 的 Plugin 生态（现多属 Assistants API）允许 GPT-4 通过 OpenAPI spec 使用工具。能用，但仅限于 OpenAI 内。
但……
-
• 只能用他们的平台 -
• 插件只支持 GPT 系列模型 -
• 工具必须符合公开托管的 OpenAPI 3 规范 -
• 無法跨 Claude、LLaMA 等复用
MCP-Use 优势：
-
• 兼容任何 LLM（Claude、GPT、LLaMA、本地等） -
• 不要求工具必须公开，也可本地定制 -
• 使用MCP，更简单、更通用的协议，非 OpenAPI -
• 工具可保有状态——这是大部分 REST API 所不及的
OpenAI 插件是试验品，MCP-Use 是开放标准，无门槛。
AutoGPT / Agent 框架
AutoGPT、CrewAI、BabyAGI 等 agent 框架聚焦于规划：拆解任务，带记忆执行。
但……
-
• 工具常是预装 Python 代码或定制脚本 -
• 换模型或工具需改核心逻辑 -
• 很多 agent 用 eval+print 假装用工具
MCP-Use 优势：
-
• 真正实时的结构化工具调用，通过 function calling 实现 -
• 你能给 10 个 agent 用同一个工具，无需重复代码 -
• 工具可自动被发现，agent 看到它们能做什么
你完全可以用 MCP-Use 作为这些框架的工具后端，让 agent 委托 MCP 执行。
自定义集成
你可能想：“我直接用 requests、Selenium 或 Puppeteer 自己写工具不就行。”
当然。但你会遇到：
-
• 需要自己写、维护一堆 wrapper -
• 处理边缘情况、重试、超时、格式等细节 -
• 让模型逻辑与工具实现紧耦合
MCP-Use 优势：
-
• 工具是自包含的微服务，遵守 MCP -
• AI 说“call search()”，无视内部实现 -
• 工具可本地、远程、容器化、按需启动
你不用绑死工具如何构建，只需保证 MCP 协议。
视觉对比表
哲学变革：从“插件”到“协议”
这样理解：
OpenAI Plugins 像浏览器扩展。
MCP 是整个 Web 本身。
插件有用，但有限。协议是无限组合的。
MCP-Use 不只是“另一个工具框架”。 它是一个去中心化、标准化的生态，任何模型均可安全智能地使用任意工具。
这是 AI 未来的巨大解锁。
为什么 MCP 可能定义 AI 的下个十年
每场技术革命都会有一个被忽视的关键时刻，它奠定未来基础。
-
• URL 是互联网的关键时刻之一 -
• USB 协议是硬件的关键时刻之一 -
• HTTP 请求是 Web 的无形胶水
现在，在 AI 领域，MCP 正扮演这样的角色——低调，高效，几乎无形。但影响深远。
为什么协议比模型更重要
现在大家都沉迷于模型。
GPT-5 传闻。Claude 3 性能。Gemini 多模态演示。
但事实是：
模型不是 AI 本体。
Agent 才是。
而 agent 的定义，不是“知道什么”，而是“能做什么”。要在现实世界中行动，agent 需要工具。
要智能地使用工具，它需要结构。
而要在模型、团队、设备和领域之间扩展这种结构——它需要一个协议。
这就是 MCP。
Agent 的操作系统
MCP 不仅仅是函数调用的封装。
它是认知与能力之间的接口契约。
它包含：
-
• 工具会自我声明 -
• 模型会主动发现它们 -
• 函数调用会标准化 -
• 会话会携带状态 -
• agent 处于主控地位
这与操作系统的发展路径惊人相似：
-
• CPU ↔ 驱动 ↔ 硬件 -
• OS ↔ APIs ↔ 应用 -
• 现在：LLM ↔ MCP ↔ 工具
从这个意义上说，MCP 正悄然成为AI 操作系统的内核——让思维转化为行动的关键。
这如何改变我们的构建方式
想象这样一个未来：
-
• 你在 30 秒内启动一个新 agent -
• 你从类似 GitHub 的公开 MCP 服务器注册表中获取工具 -
• 你像更换中间件一样切换模型——今天用 Claude，明天用 GPT-5 -
• 你部署能驱动业务、科研论文、3D 管线的 agent——全部搭配安全且可组合的工具
这并不遥远。
MCP-Use 是首批让这一现实对开发者开放的库之一。它不锁定平台、模型，也不闭塞生态。它只是赋予你的 LLM 使用事物的能力。
这让它不仅是一个工具。
它是基石。
MCP-Use 的未来走向
路线图已经让人振奋：
-
• 支持 WebSocket，实现低延迟工具 -
• 增加更多工具服务器（PDF、向量数据库、IDE、API） -
• 支持具备记忆功能的 agent -
• GUI 工具使用可视化 -
• 即插即用的 UI 前端
但更重要的是：
它是开放的。它是标准的。它属于你。
你现在就可以构建工具，明天即可插入任何 agent。
你可以本地运行 agent，也可以远程、边缘设备或安全实验室中运行。
你让 LLM 去做事情——不是靠写提示，而是赋予它们能力。
而且无需任何人许可。
结束语：LLM 行动时代的到来
过去几年，我们生活在“LLM 会说话”的时代。
它们聪明、令人惊讶，有时还有诗意。
但下一个时代——我们正迈入的时代——截然不同。
这是“LLM 会行动”的时代。
当未来的开发者回头问：
“AI agent 真正开始有用是在什么时候？”
很可能答案会是：
“大概是在有人发布了一个叫 MCP-Use 的 Python 库的时候。”
