构建AI的“手脚”

• 定义：MCP 全称为模型上下文协议 (Model Context Protocol)。它是一种标准化的方式，用于为语言模型（如 Claude）提供其自身知识范围之外的外部上下文 (external context)。
• 核心功能：它充当了模型与外部世界之间的“通用连接器”，让模型能够与互联网、API、数据库、应用程序等进行交互。
• 工作原理：默认情况下，模型只能看到对话历史。MCP 扩展了这个视野，允许模型调用外部“工具”来获取实时信息或代表用户执行操作。

生动比喻：为AI装上“手”和“脚” 如果说对话历史是模型的“大脑”，那么MCP就为这个大脑安装了可以感知和操作外部世界的“手”和“脚”。例如，它可以用“手”去互联网搜索信息，或用“脚”去旅行社网站为你预订机票。

• 内部驱动力：Anthropic 团队发现，他们正在为不同的应用（如代码助手、claude.ai 网站）重复开发相同的功能（如网页搜索）。为了“一次构建，处处配置”，他们需要一个统一的内部协议。
• 开源的战略考量：团队认识到，让模型连接外部工具是一个行业性的普遍需求。如果每家模型公司都搞一套私有标准，将会造成巨大的生态碎片化。
  • 对开发者（如 Asana）来说，他们将不得不为 Claude、OpenAI、Gemini 等每个模型都开发一套独立的连接器，这将是一场“噩梦”。
  • “水涨船高”理念：建立一个开放标准 (open standard)，让所有模型都能更容易地接入外部世界，对整个AI生态都有益。
• 惊人的成功：MCP 开源后，迅速成为历史上增长最快的开源协议之一，证明了市场的巨大需求。这种成功促使 Anthropic 推动将其转移到一个正式的开源基金会，确保其作为行业标准的长期性和中立性。

• 里程碑式更新：远程 MCP 支持 (Remote MCP Support)
  • 过去：开发者必须在本地运行所有 MCP 服务，设置过程非常“笨重”。
  • 现在：协议原生支持远程托管的 MCP 服务器。这使得像 GitHub、Asana 这样的服务提供商可以直接托管官方的、用户可即时访问的 MCP 端点（例如 `mcp.github.com`）。
• 官方 MCP 服务器注册中心 (Central Registry)
  • 为了方便发现和使用，开源项目推出了一个中央注册中心，开发者可以在此查找和分享公开的 MCP 服务器。
  • 用户现在可以直接使用由 GitHub 等官方维护的、可信赖的 MCP 服务，而无需依赖来路不明的第三方实现。

社区和官方已经涌现出许多实用且创新的MCP服务器：

• Context 7：
  • 解决问题：语言模型的知识截止日期 (knowledge cutoff) 问题，导致其无法了解最新的软件库和API。
  • 解决方案：这个MCP服务器会自动抓取和更新来自 Next.js、Anthropic API 等官方网站的最新文档（利用 llms.txt 格式），确保 Claude 总能获取到最新的技术信息。
• Playwright：
  • 解决问题：模型只能阅读代码（HTML/CSS），但无法“看到”网页的实际渲染效果。
  • 解决方案：通过集成微软的 Playwright 浏览器自动化工具，这个MCP允许 Claude 像真实用户一样操作浏览器、浏览网页并获取截图。
  • 高级应用：可以创建“自我修正”循环。例如，让 Claude 修复一个网页对齐问题，它会修改代码，然后使用 Playwright 查看结果，如果不满意，它会再次修改代码并查看，直到问题解决。

如何高效地为 Claude 设计和使用 MCP 工具？

• 核心理念：将MCP工具定义视为“提示工程”
  • 工具的名称、描述、参数名都会被整合到最终发送给模型的提示中。因此，清晰、准确、富有信息的描述至关重要。
  • 案例：一个简单的图片生成工具，如果描述中仅有“description”字段，模型只会简单填充。但如果描述为：“本工具调用 Stable Diffusion v2 模型，请使用详细的、艺术风格化的语言以获得最佳效果”，模型就会自动生成质量高得多的专业级提示。
• 避免上下文污染 (Context Pollution)
  • 反面模式：不要一次性提供大量不相关的工具。这不仅会增加成本，还会让模型感到困惑。例如，同时提供 Asana 和 Linear 的 `get_project_status` 工具，模型可能不知道该用哪一个。
  • 原则：在每次请求中，只提供与当前任务最相关的、最小化的工具集。
• 为LLM设计API，而非为人类
  • 传统API设计倾向于提供许多细粒度的接口（如 `get_projects`, `get_posts`, `get_users`）。
  • 为LLM设计时，通常更有效的是提供更少、更抽象的工具（如一个通用的 `get_info` 工具），利用模型的自然语言理解能力来解析用户的具体意图，并填充相应的参数。

MCP 的未来将走向何方？

• 个人自动化案例：
  • 工作：Michael 使用 MCP 连接公司内部的 Slack、文档库和代码库，让 Claude 自动收集信息并撰写每周的项目状态更新。
  • 生活：John 在家中部署了 MCP 服务器来控制智能家居，他可以随时问 Claude “我早上锁门了吗？”，并让 Claude 远程为他锁门。
• 涌现能力 (Emergent Properties)：
  • 当不同的 MCP 服务器被组合在一起时，会产生意想不到的协同效应。John 的一个实验中，仅提供了“创建记忆”和“连接记忆”两个简单工具，Claude 便自发地进入了“调查记者模式”，通过不断提问来构建用户的知识图谱。
  • 模糊接口的优势：与需要严格遵守契约的传统 API 不同，MCP 的“模糊性”允许模型智能地组合来自不同服务（如 Gmail 和智能家居）的能力，以创新的方式解决问题。
• 终极愿景：MCP 将变得“隐形”
  • 成功的协议最终会成为背景基础设施，用户感知不到它的存在。未来的理想状态是，MCP 就像互联网的 TCP/IP 协议一样，无处不在，默默地将所有AI应用和服务“粘合”在一起。
  • 新的竞争维度：未来，软件服务商的竞争将不再是“是否提供API”，而是“谁能提供最高效、最智能的 MCP 服务器”。一个优秀的 MCP 服务器将成为产品的核心卖点，因为它直接决定了用户通过AI与该服务互动的体验。