目录
概览
OpenClaw 是一个多渠道 AI 助手网关，设计用于在用户自己的设备上运行。它采用单一网关 + 多客户端/节点模型，支持 WhatsApp、Telegram、Slack、Discord、Google Chat、Signal、iMessage 等多种通信渠道。
核心结构
| 组件 | 描述 |
|---|---|
| 🌐 Gateway（网关） | 长期运行的守护进程，管理所有消息平台连接和智能体通信 |
| 💻 Clients（客户端） | 控制平面应用（macOS 应用、CLI、Web 界面） |
| 📱 Nodes（节点） | 设备节点，提供硬件能力（macOS/iOS/Android/无头设备） |
整体架构
一个开放协议，旨在实现不透明的智能代理应用程序之间的通信和互操作性。
企业采用人工智能的最大挑战之一是如何让基于不同框架和供应商构建的代理协同工作。这就是我们创建开放的 Agent2Agent (A2A) 协议的原因，这是一种协作方式，旨在帮助不同生态系统中的代理相互通信。Google 正在推动这项行业开放协议倡议，因为我们相信这个协议对于支持多代理通信至关重要，它将为您的代理提供一种通用语言——无论它们构建于哪个框架或供应商之上。借助 A2A，代理可以相互展示它们的功能并协商如何与用户交互（通过文本、表单或双向音频/视频）——所有这些都在安全地协同工作的同时进行。
观看 A2A 的实际应用
观看此演示视频，了解 A2A 如何实现不同代理框架之间的无缝通信。
概念概述
Agent2Agent (A2A) 协议促进了独立 AI 代理之间的通信。以下是核心概念：
/.well-known/agent.json），描述了代理的功能、技能、端点 URL 和身份验证要求。客户端使用它进行发现。tasks/send）。tasks/send 或 tasks/sendSubscribe）来启动任务。任务具有唯一的 ID，并经历以下状态：submitted（已提交）、working（工作中）、input-required（需要输入）、completed（已完成）、failed（失败）、canceled（已取消）。role: "user"）和代理（role: "agent"）之间的通信轮次。消息包含 Parts（部件）。Message 或 Artifact（工件）中的基本内容单元。可以是 TextPart（文本部件）、FilePart（文件部件，包含内联字节或 URI）或 DataPart（数据部件，用于结构化 JSON，例如表单）。Parts（部件）。streaming 功能的服务器可以使用 tasks/sendSubscribe。客户端接收服务器发送事件 (SSE)，其中包含 TaskStatusUpdateEvent（任务状态更新事件）或 TaskArtifactUpdateEvent（任务工件更新事件）消息，提供实时的进度。pushNotifications 的服务器可以主动向客户端提供的 webhook URL 发送任务更新，该 URL 通过 tasks/pushNotification/set 配置。服务器通过MCP提供了为语言模型添加上下文的基本构建块。这些原语支持客户端、服务器和语言模型之间的丰富交互：
每个原语可以在以下控制层次结构中概括：
| 原语 | 控制方 | 描述 | 示例 |
|---|---|---|---|
| 提示 | 用户控制 | 由用户选择调用的交互式模板 | 斜杠命令、菜单选项 |
| 资源 | 应用程序控制 | 由客户端附加和管理的上下文数据 | 文件内容、Git历史 |
| 工具 | 模型控制 | 向LLM公开以执行操作的函数 | API POST请求、文件写入 |
提示词
模型上下文协议（MCP）提供了一种标准化方式，使服务器能够向客户端公开提示词模板。提示词允许服务器提供结构化消息和与语言模型交互的指令。客户端可以发现可用的提示词，获取其内容，并提供参数来自定义它们。
用户交互模型
提示词设计为用户控制的，这意味着它们从服务器暴露给客户端，目的是让用户能够明确选择使用它们。
通常，提示词会通过用户界面中的用户发起命令触发，这允许用户自然地发现和调用可用的提示词。
例如，作为斜杠命令：
然而，实现者可以自由地通过任何适合其需求的界面模式来公开提示词——协议本身不强制要求任何特定的用户交互模型。
能力
支持提示词的服务器必须在初始化期间声明prompts能力：
模型上下文协议（Model Context Protocol）由几个协同工作的关键组件组成：
所有实现必须支持基础协议和生命周期管理组件。其他组件可以根据应用程序的特定需求来实现。
这些协议层在实现客户端和服务器之间丰富交互的同时，建立了明确的关注点分离。模块化设计允许实现精确支持所需的功能。
消息
MCP 客户端和服务器之间的所有消息必须遵循 JSON-RPC 2.0 规范。协议定义了以下类型的消息：
请求（Requests）
请求从客户端发送到服务器，或者从服务器发送到客户端，用于启动操作。
{
jsonrpc: "2.0";
id: string | number;
method: string;
params?: {
[key: string]: unknown;
};
}
null。响应（Responses）
响应是对请求的回复，包含操作的结果或错误。
模型上下文协议（MCP）采用客户端-主机-服务器架构，每个主机可以运行多个客户端实例。这种架构使用户能够跨应用程序集成AI功能，同时保持明确的安全边界和关注点隔离。MCP基于JSON-RPC构建，提供专注于客户端和服务器之间上下文交换和采样协调的有状态会话协议。
核心组件
graph LR
subgraph "应用程序主机进程"
H[主机]
C1[客户端 1]
C2[客户端 2]
C3[客户端 3]
H --> C1
H --> C2
H --> C3
end
subgraph "本地机器"
S1[服务器 1<br>Files 和 Git]
S2[服务器 2<br>数据库]
R1[("本地<br>资源 A")]
// ...
主机
主机进程作为容器和协调器：
客户端
每个客户端由主机创建，并维护独立的服务器连接：
主机应用程序创建和管理多个客户端，每个客户端与特定服务器保持1:1关系。
服务器
服务器提供专门的上下文和功能：
协议修订版本：2025-03-26
Model Context Protocol（MCP）是一个开放协议，它使 LLM 应用程序与外部数据源和工具之间能够无缝集成。无论您是构建 AI 驱动的 IDE、增强聊天界面，还是创建自定义 AI 工作流，MCP 都提供了一种标准化的方式来连接 LLM 与它们所需的上下文。
本规范基于 schema.ts 中的 TypeScript 模式，定义了权威的协议要求。
有关实现指南和示例，请访问 modelcontextprotocol.io。
概述
MCP 为应用程序提供了标准化的方式来：
该协议使用 JSON-RPC 2.0 消息在以下组件之间建立通信：
MCP 部分受到 Language Server Protocol 的启发，后者标准化了如何在整个开发工具生态系统中添加对编程语言的支持。类似地，MCP 标准化了如何将额外的上下文和工具集成到 AI 应用程序的生态系统中。
关键细节
基础协议
功能
服务器向客户端提供以下任何功能：
Model Context Protocol (MCP) 入门
MCP 是一个开放协议，用于标准化应用程序向 LLM 提供上下文的方式。可以将 MCP 视为 AI 应用程序的 USB-C 端口。正如 USB-C 提供了一种将设备连接到各种外围设备和配件的标准化方式一样，MCP 提供了一种将 AI 模型连接到不同数据源和工具的标准化方式。
为什么选择 MCP？
MCP 帮助您在 LLM 之上构建代理和复杂的工作流程。LLM 经常需要与数据和工具集成，而 MCP 提供了：
一般架构
MCP 的核心遵循客户端-服务器架构，其中主机应用程序可以连接到多个服务器：
这篇文章是使用 Google Gemini Deep Research 生成的。提示词：
研究 Model Context Protocol
1. 模型上下文协议 (MCP) 导论
大型语言模型 (LLMs) 在理解和生成人类语言方面取得了显著的进步。然而，这些模型本质上是孤立的，它们的知识仅限于训练数据，并且缺乏与外部世界交互的能力 1。为了克服这些限制，将 LLMs 与外部数据源和工具集成变得至关重要 1。传统上，这种集成是通过为每个新的数据源或工具开发定制的连接器来实现的 1。这种方法导致了集成工作的重复，难以扩展，并且维护成本高昂，阻碍了上下文感知 AI 的广泛采用 1。
为了应对这一挑战，模型上下文协议 (MCP) 应运而生 1。MCP 是一种开放标准，旨在规范应用程序如何向 LLMs 提供上下文和工具 6。可以将 MCP 视为 AI 应用程序的通用连接器，类似于 USB-C 标准化了设备和外设之间的连接 6。通过提供一种标准化的方式将 AI 模型连接到各种数据源和工具，MCP 简化了集成，增强了互操作性，并促进了可扩展性 6。
本报告旨在对模型上下文协议 (MCP) 进行全面的解析，涵盖其基本原理、核心架构、通信机制、广泛的应用场景以及客户端和服务器端的创建方法。通过深入理解 MCP，开发者和组织可以更好地利用这一新兴标准，构建更智能、更具上下文感知能力的 AI 应用。