BytesRouter

主题

MCP 文档版本 2026-07-28 更新于 2026-10-14

架构概览

这篇 Model Context Protocol (MCP) 概览讨论了其范围与核心概念，并提供了一个示例来演示每个核心概念。

由于 MCP SDK 抽象掉了许多关注点，大多数开发者可能会发现数据层协议一节最为有用。该节讨论了 MCP 服务端如何为 AI 应用提供上下文。

关于具体的实现细节，请参阅你所使用语言对应的 SDK 文档。

范围

Model Context Protocol 包含以下项目：

NOTE

MCP 仅关注上下文交换的协议——它并不规定 AI 应用如何使用 LLM 或管理所提供的上下文。

MCP 的概念

参与者

MCP 遵循客户端-服务端架构，其中 MCP 宿主——一个像 Claude Code 或 Claude Desktop 这样的 AI 应用——与一个或多个 MCP 服务端建立连接。MCP 宿主通过为每个 MCP 服务端创建一个 MCP 客户端来实现这一点。每个 MCP 客户端与其对应的 MCP 服务端维护一条专用连接。

使用 STDIO 传输的本地 MCP 服务端通常服务于单个 MCP 客户端，而使用 Streamable HTTP 传输的远程 MCP 服务端通常会服务于许多 MCP 客户端。

MCP 架构中的关键参与者包括：

  • MCP Host：协调并管理一个或多个 MCP 客户端的 AI 应用
  • MCP Client：维护与 MCP 服务端的连接，并从 MCP 服务端获取上下文供 MCP 宿主使用的组件
  • MCP Server：向 MCP 客户端提供上下文的程序

例如：Visual Studio Code 充当 MCP 宿主。当 Visual Studio Code 与某个 MCP 服务端（例如 Sentry MCP server）建立连接时，Visual Studio Code 运行时实例化一个 MCP 客户端对象，用于维护与 Sentry MCP 服务端的连接。 当 Visual Studio Code 随后连接到另一个 MCP 服务端（例如本地文件系统服务端）时，Visual Studio Code 运行时实例化一个额外的 MCP 客户端对象来维护这条连接。

graph TB
    subgraph "MCP Host (AI Application)"
        Client1["MCP Client 1"]
        Client2["MCP Client 2"]
        Client3["MCP Client 3"]
        Client4["MCP Client 4"]
    end

    ServerA["MCP Server A - Local<br/>(e.g. Filesystem)"]
    ServerB["MCP Server B - Local<br/>(e.g. Database)"]
    ServerC["MCP Server C - Remote<br/>(e.g. Sentry)"]

    Client1 ---|"Dedicated<br/>connection"| ServerA
    Client2 ---|"Dedicated<br/>connection"| ServerB
    Client3 ---|"Dedicated<br/>connection"| ServerC
    Client4 ---|"Dedicated<br/>connection"| ServerC

请注意，MCP 服务端指的是提供上下文数据的程序，无论它运行在哪里。MCP 服务端可以在本地或远程执行。例如，当 Claude Desktop 启动文件系统服务端时，该服务端运行在同一台机器上，因为它使用 STDIO 传输。这通常被称为“本地” MCP 服务端。官方的 Sentry MCP server 运行在 Sentry 平台上，并使用 Streamable HTTP 传输。这通常被称为“远程” MCP 服务端。

分层

MCP 由两层组成：

  • 数据层：定义基于 JSON-RPC 的客户端-服务端通信协议，包括能力与版本发现，以及核心原语，例如工具、资源、提示模板和通知。
  • 传输层：定义使客户端与服务端之间能够交换数据的通信机制与通道，包括特定于传输的连接建立、消息分帧和授权。

从概念上讲，数据层是内层，而传输层是外层。

数据层

数据层实现了一个基于 JSON-RPC 2.0 的交换协议，定义了消息结构与语义。 该层包括：

  • Discovery：让客户端通过 server/discover 请求查询服务端支持的协议版本、能力和身份
  • Server features：使服务端能够提供核心功能，包括用于 AI 操作的工具、用于上下文数据的资源，以及用于与客户端之间交互模板的提示模板
  • Client features：使服务端能够向用户征询输入。自协议版本 2026-07-28 起，采样已被弃用。
  • Utility features：支持额外能力，例如用于实时更新的通知，以及用于长时间运行操作的进度跟踪

传输层

传输层管理客户端与服务端之间的通信通道和身份验证。它处理连接建立、消息分帧，以及 MCP 参与者之间的安全通信。

MCP 支持两种传输机制：

  • Stdio transport：使用标准输入/输出流在同一台机器上的本地进程之间进行直接进程通信，提供最佳性能且没有网络开销。
  • Streamable HTTP transport：使用 HTTP POST 传输客户端到服务端的消息，并可选用 Server-Sent Events 提供流式能力。该传输支持远程服务端通信，并支持标准 HTTP 身份验证方法，包括 bearer token、API key 和自定义头。MCP 建议使用 OAuth 获取身份验证 token。

传输层将通信细节从协议层抽象出来，使相同的 JSON-RPC 2.0 消息格式能够跨所有传输机制使用。

数据层协议

MCP 的核心部分之一是定义 MCP 客户端与 MCP 服务端之间的 schema 与语义。开发者可能会发现数据层——特别是原语集合——是 MCP 中最有趣的部分。它是 MCP 中定义开发者如何将上下文从 MCP 服务端共享到 MCP 客户端的部分。

MCP 使用 JSON-RPC 2.0 作为其底层 RPC 协议。客户端与服务端相互发送请求并相应地响应。当不需要响应时，可以使用通知。

无状态性与发现

MCP 是一个 无状态协议。每个请求都在其 _meta 字段中携带协议版本以及与该请求相关的能力，因此服务端可以独立处理每个请求。除非配置为不这样做，客户端也应在同一字段中标识自身。服务端通过强制的 server/discover 请求公布其支持的版本和能力，客户端可以在任何其他请求之前发送该请求。详细信息可在规范中找到，而示例展示了逐请求元数据和发现序列。

原语

MCP 原语是 MCP 中最重要的概念。它们定义了客户端与服务端可以相互提供什么。这些原语规定了可以与 AI 应用共享的上下文信息类型，以及可以执行的操作范围。

MCP 定义了三种核心原语，可由服务端公开：

  • Tools：AI 应用可以调用以执行操作的可执行函数（例如文件操作、API 调用、数据库查询）
  • Resources：向 AI 应用提供上下文信息的数据源（例如文件内容、数据库记录、API 响应）
  • Prompts：帮助构建与语言模型交互的可复用模板（例如系统提示模板、few-shot 示例）

每种原语类型都有相关的方法用于发现（*/list）、获取（*/get），以及在某些情况下执行（tools/call）。 MCP 客户端将使用 */list 方法发现可用的原语。例如，客户端可以先列出所有可用工具（tools/list），然后执行它们。这种设计允许列表是动态的。

举一个具体的例子，考虑一个提供数据库上下文的 MCP 服务端。它可以公开用于查询数据库的工具、包含数据库 schema 的资源，以及包含与这些工具交互的 few-shot 示例的提示模板。

关于服务端原语的更多细节，请参阅服务端概念。

MCP 还定义了客户端可以公开的原语。这些原语允许 MCP 服务端作者构建更丰富的交互。

  • Elicitation：允许服务端向用户请求额外信息。当服务端作者想从用户那里获取更多信息，或请求确认某个操作时，这很有用。服务端使用 elicitation/create 方法请求用户输入。

征询请求通过多轮往返请求模式传递，详见征询概览。

Deprecated：自协议版本 2026-07-28 起，以下客户端原语已被弃用。

  • Sampling：允许服务端从客户端的 AI 应用请求语言模型补全。当服务端作者希望访问语言模型，但又想保持模型无关，并且不在其 MCP 服务端中包含语言模型 SDK 时，这很有用。服务端使用 sampling/createMessage 方法请求补全，同样通过多轮往返请求模式传递。新的实现应直接与 LLM 提供方 API 集成。
  • Logging：使服务端能够向客户端发送日志消息，用于调试和监控目的。新的实现应记录到 stderr（stdio 传输）或使用 OpenTelemetry。

关于客户端原语的更多细节，请参阅客户端概念。

除了服务端和客户端原语之外，协议还支持基于核心协议构建的可选扩展。例如，Tasks 扩展让服务端为长时间运行的请求返回一个持久句柄，以便客户端可以轮询状态并在稍后获取结果。

通知

协议支持实时通知，以实现服务端与客户端之间的动态更新。例如，当服务端可用的工具发生变化时（例如当新功能可用或现有工具被修改时），服务端可以发送工具更新通知，以告知已连接的客户端这些变化。通知以 JSON-RPC 2.0 通知消息的形式发送（不期望响应）。变更通知是选择加入的：客户端打开一个长期存在的 subscriptions/listen 流，并指定它希望接收的通知类型，服务端则在该流上传递匹配的通知。

示例

数据层

本节逐步演示一次 MCP 客户端-服务端交互，重点介绍数据层协议。我们将使用 JSON-RPC 2.0 消息演示发现、工具操作和通知。

Discovery

如[无状态性与发现](#无状态性与发现)一节所述，每个 MCP 请求都在其 `_meta` 字段中携带协议版本和客户端能力，客户端也应在其中包含其身份。希望在发出其他请求之前了解服务端支持什么的客户端会发送 `server/discover` 请求，每个服务端都必须实现该请求。发现响应通常是可缓存的，这意味着它可以被复用，因此不必为每个请求都执行发现流程。
json
{
  "jsonrpc": "2.0",
  "id": 1,
  "method": "server/discover",
  "params": {
    "_meta": {
      "io.modelcontextprotocol/protocolVersion": "2026-07-28",
      "io.modelcontextprotocol/clientInfo": {
        "name": "example-client",
        "version": "1.0.0"
      },
      "io.modelcontextprotocol/clientCapabilities": {
        "elicitation": {}
      }
    }
  }
}
json
{
  "jsonrpc": "2.0",
  "id": 1,
  "result": {
    "resultType": "complete",
    "supportedVersions": ["2026-07-28"],
    "capabilities": {
      "tools": {
        "listChanged": true
      },
      "resources": {}
    },
    "_meta": {
      "io.modelcontextprotocol/serverInfo": {
        "name": "example-server",
        "version": "1.0.0"
      }
    },
    "ttlMs": 3600000,
    "cacheScope": "public"
  }
}
#### 理解发现交换

`_meta` 字段和发现响应共同服务于多个目的：

1. **协议版本选择**：`io.modelcontextprotocol/protocolVersion` 字段声明客户端在此请求中使用的版本，而响应中的 `supportedVersions` 列出服务端接受的版本。如果服务端不支持所请求的版本，它会以 `UnsupportedProtocolVersionError` 拒绝该请求，并列出它确实支持的版本，客户端则使用双方共同支持的版本重试。

2. **能力发现**：客户端在每个请求的 `io.modelcontextprotocol/clientCapabilities` 中声明其能力，服务端则从 `server/discover` 返回自己的 `capabilities` 对象。这告诉每一方对方可以处理哪些[原语](#原语)（工具、资源、提示模板），以及变更[通知](#通知)是否可用，从而永远不会尝试不受支持的操作。

3. **身份交换**：请求 `_meta` 中的 `io.modelcontextprotocol/clientInfo` 字段和结果 `_meta` 中的 `io.modelcontextprotocol/serverInfo` 字段提供标识和版本信息，用于调试和兼容性目的。

在此示例中，该交换演示了 MCP 能力如何被声明：

**Client Capabilities**：

* `"elicitation": {}` - 客户端声明当服务端请求时，它可以从用户那里收集额外输入

**Server Capabilities**：

* `"tools": {"listChanged": true}` - 服务端支持工具原语，并可以在 [`subscriptions/listen`](https://modelcontextprotocol.io/specification/2026-07-28/basic/patterns/subscriptions) 中遵循 `toolsListChanged` 过滤器。请求该过滤器的客户端会在工具列表变化时收到 `notifications/tools/list_changed`。
* `"resources": {}` - 服务端还支持资源原语（可以处理 `resources/list` 和 `resources/read` 方法）

调用 `server/discover` 是可选的。由于每个请求都携带相同的 `_meta` 字段，客户端可以自由地直接发送任何请求，并在返回版本错误时处理它。发现是一种便捷方式，可以在单个请求中获取服务端的身份、能力和支持的版本。

#### 这在 AI 应用中如何工作

AI 应用的 MCP 客户端管理器连接到已配置的服务端，并存储其发现的能力以供后续使用。应用使用这些信息来确定哪些服务端可以提供特定类型的功能（工具、资源、提示模板），以及它们是否支持实时更新。在 Python SDK 中，发现发生在客户端连接期间。结果随后可在客户端对象上获取。

```python Pseudo-code for AI application discovery
# Pseudo Code
async with Client(stdio_client(server_config)) as client:
    if client.server_capabilities.tools:
        app.register_mcp_server(client, supports_tools=True)
    app.set_server_ready(client)
```

Tool Discovery (Primitives)

客户端可以通过发送 `tools/list` 请求来发现可用工具。该请求是 MCP 工具发现机制的基础：它允许客户端在尝试使用工具之前了解服务端上有哪些可用工具。
json
{
  "jsonrpc": "2.0",
  "id": 2,
  "method": "tools/list",
  "params": {
    "_meta": {
      "io.modelcontextprotocol/protocolVersion": "2026-07-28",
      "io.modelcontextprotocol/clientInfo": {
        "name": "example-client",
        "version": "1.0.0"
      },
      "io.modelcontextprotocol/clientCapabilities": {
        "elicitation": {}
      }
    }
  }
}
json
{
  "jsonrpc": "2.0",
  "id": 2,
  "result": {
    "resultType": "complete",
    "tools": [
      {
        "name": "calculator_arithmetic",
        "title": "Calculator",
        "description": "Perform mathematical calculations including basic arithmetic, trigonometric functions, and algebraic operations",
        "inputSchema": {
          "type": "object",
          "properties": {
            "expression": {
              "type": "string",
              "description": "Mathematical expression to evaluate (e.g., '2 + 3 * 4', 'sin(30)', 'sqrt(16)')"
            }
          },
          "required": ["expression"]
        }
      },
      {
        "name": "weather_current",
        "title": "Weather Information",
        "description": "Get current weather information for any location worldwide",
        "inputSchema": {
          "type": "object",
          "properties": {
            "location": {
              "type": "string",
              "description": "City name, address, or coordinates (latitude,longitude)"
            },
            "units": {
              "type": "string",
              "enum": ["metric", "imperial", "kelvin"],
              "description": "Temperature units to use in response",
              "default": "metric"
            }
          },
          "required": ["location"]
        }
      }
    ],
    "ttlMs": 300000,
    "cacheScope": "public"
  }
}
#### 理解工具发现请求

除了伴随每个 MCP 请求的标准 `_meta` 字段之外，`tools/list` 请求不需要任何参数。它还接受一个可选的 `cursor` 参数用于[分页](https://modelcontextprotocol.io/specification/2026-07-28/server/utilities/pagination)，上面的示例省略了该参数。

#### 理解工具发现响应

响应包含一个 `tools` 数组，提供关于每个可用工具的综合元数据。这种基于数组的结构允许服务端同时公开多个工具，同时保持不同功能之间的清晰边界。

响应中的每个工具对象都包含几个关键字段：

* **`name`**：工具在服务端命名空间内的唯一标识符。它充当工具执行的主键，并应遵循清晰的命名模式（例如 `calculator_arithmetic` 而不仅仅是 `calculate`）
* **`title`**：工具的人类可读显示名称，客户端可以向用户展示
* **`description`**：关于工具做什么以及何时使用它的详细说明
* **`inputSchema`**：定义预期输入参数的 JSON Schema，支持类型验证，并提供关于必需和可选参数的清晰文档

结果被标记为 `"resultType": "complete"`，并携带两个缓存字段。`ttlMs` 是以毫秒为单位的新鲜度提示，因此此工具列表可以缓存五分钟。`cacheScope` 指示谁可以复用该响应。规范的[缓存实用工具](https://modelcontextprotocol.io/specification/2026-07-28/server/utilities/caching)定义了完整规则。

#### 这在 AI 应用中如何工作

AI 应用从所有已连接的 MCP 服务端获取可用工具，并将它们组合成一个语言模型可以访问的统一工具注册表。这允许 LLM 理解它可以执行哪些操作，并在对话期间自动生成适当的工具调用。

```python Pseudo-code for AI application tool discovery
# Pseudo-code using MCP Python SDK patterns
available_tools = []
for client in app.mcp_clients():
    tools_response = await client.list_tools()
    available_tools.extend(tools_response.tools)
conversation.register_available_tools(available_tools)
```

联邦多个服务端的客户端可以使用[渐进式工具发现](https://modelcontextprotocol.io/docs/2026-07-28/develop/clients/client-best-practices#progressive-tool-discovery)，而不是预先加载每个工具。

Tool Execution (Primitives)

客户端现在可以使用 `tools/call` 方法执行工具。这演示了 MCP 原语在实践中如何使用：在发现可用工具之后，客户端可以使用适当的参数调用它们。

#### 理解工具执行请求

`tools/call` 请求遵循结构化格式，确保类型安全以及客户端与服务端之间的清晰通信。请注意，我们使用的是发现响应中的正确工具名称（`weather_current`），而不是简化名称：
json
{
  "jsonrpc": "2.0",
  "id": 3,
  "method": "tools/call",
  "params": {
    "name": "weather_current",
    "arguments": {
      "location": "San Francisco",
      "units": "imperial"
    },
    "_meta": {
      "io.modelcontextprotocol/protocolVersion": "2026-07-28",
      "io.modelcontextprotocol/clientInfo": {
        "name": "example-client",
        "version": "1.0.0"
      },
      "io.modelcontextprotocol/clientCapabilities": {
        "elicitation": {}
      }
    }
  }
}
json
{
  "jsonrpc": "2.0",
  "id": 3,
  "result": {
    "resultType": "complete",
    "content": [
      {
        "type": "text",
        "text": "Current weather in San Francisco: 68°F, partly cloudy with light winds from the west at 8 mph. Humidity: 65%"
      }
    ]
  }
}
#### 工具执行的关键要素

请求结构包含几个重要组成部分：

1. **`name`**：必须与发现响应中的工具名称完全匹配（`weather_current`）。这确保服务端能够正确识别要执行哪个工具。

2. **`arguments`**：包含由工具 `inputSchema` 定义的输入参数。在此示例中：
   * `location`："San Francisco"（必需参数）
   * `units`："imperial"（可选参数，如果未指定则默认为 "metric"）

3. **`_meta`**：携带标准的逐请求字段：每个 MCP 请求都必须包含的协议版本和客户端能力，以及客户端的身份，除非配置为不这样做，客户端应包含该身份。

4. **JSON-RPC Structure**：使用标准 JSON-RPC 2.0 格式，带有唯一的 `id` 用于请求-响应关联。

#### 理解工具执行响应

响应演示了 MCP 灵活的内容系统：

1. **`content` Array**：工具响应返回一个内容对象数组，允许丰富、多格式的响应（文本、图像、资源等）

2. **Content Types**：每个内容对象都有一个 `type` 字段。在此示例中，`"type": "text"` 表示纯文本内容，但 MCP 支持各种内容类型以用于不同用例。

3. **Structured Output**：响应提供可操作的信息，AI 应用可以将其用作语言模型交互的上下文。

这种执行模式允许 AI 应用动态调用服务端功能，并接收可集成到与语言模型对话中的结构化响应。

#### 这在 AI 应用中如何工作

当语言模型在对话期间决定使用工具时，AI 应用会拦截该工具调用，将其路由到适当的 MCP 服务端，执行它，并将结果作为对话流的一部分返回给 LLM。这使 LLM 能够访问实时数据并在外部世界中执行操作。
```python
# Pseudo-code for AI application tool execution
async def handle_tool_call(conversation, tool_name, arguments):
    client = app.find_mcp_client_for_tool(tool_name)
    result = await client.call_tool(tool_name, arguments)
    conversation.add_tool_result(result.content)
```

Real-time Updates (Notifications)

MCP 支持实时通知，使服务端能够告知客户端变化，而无需被轮询。这演示了通知系统，这是保持客户端同步和响应性的关键特性。

#### 订阅变更

变更通知是选择加入的。要接收它们，客户端通过发送一个 [`subscriptions/listen`](https://modelcontextprotocol.io/specification/2026-07-28/basic/patterns/subscriptions) 请求来打开一个长期存在的通知流，该请求带有一个 `notifications` 过滤器，指定它想要的事件类型。这里客户端请求工具列表变更：

```json Listen Request
{
  "jsonrpc": "2.0",
  "id": 4,
  "method": "subscriptions/listen",
  "params": {
    "_meta": {
      "io.modelcontextprotocol/protocolVersion": "2026-07-28",
      "io.modelcontextprotocol/clientInfo": {
        "name": "example-client",
        "version": "1.0.0"
      },
      "io.modelcontextprotocol/clientCapabilities": {
        "elicitation": {}
      }
    },
    "notifications": {
      "toolsListChanged": true
    }
  }
}
```

每个客户端请求都在 `_meta` 中携带 `io.modelcontextprotocol/protocolVersion` 和 `io.modelcontextprotocol/clientCapabilities` 字段，通常还携带 `io.modelcontextprotocol/clientInfo`，因此服务端可以在不依赖连接状态的情况下识别客户端。

服务端通过 `notifications/subscriptions/acknowledged` 确认订阅，这是第一条在 `_meta` 中携带该订阅 ID 的消息（在此之前，服务端不会为该订阅发送其他通知）。其 `notifications` 字段反映服务端同意遵循的所请求过滤器的子集，不支持的通知类型会被省略：

```json Acknowledgment
{
  "jsonrpc": "2.0",
  "method": "notifications/subscriptions/acknowledged",
  "params": {
    "_meta": {
      "io.modelcontextprotocol/subscriptionId": 4
    },
    "notifications": {
      "toolsListChanged": true
    }
  }
}
```

#### 理解工具列表变更通知

在确认之后，当服务端可用的工具发生变化时（例如，当新功能可用、现有工具被修改，或工具暂时不可用时），服务端会在该流上传递一个通知：

```json Notification
{
  "jsonrpc": "2.0",
  "method": "notifications/tools/list_changed",
  "params": {
    "_meta": {
      "io.modelcontextprotocol/subscriptionId": 4
    }
  }
}
```

#### MCP 通知的关键特性

1. **No Response Required**：注意通知中没有 `id` 字段。这遵循 JSON-RPC 2.0 通知语义，即不期望也不发送响应。

2. **Opt-In Based**：此通知仅发送给在其 `subscriptions/listen` 过滤器中请求了 `"toolsListChanged": true` 的客户端，并且仅从在其工具能力中声明了 `"listChanged": true` 的服务端可用（如步骤 1 所示）。

3. **Subscription-ID Tagging**：流上的每个通知都在 `_meta` 中携带 `io.modelcontextprotocol/subscriptionId`。该值是打开该流的 `subscriptions/listen` 请求的 JSON-RPC ID（在此示例中为 `4`），因此客户端可以将每个通知与产生它的订阅关联起来。

4. **Event-Driven**：服务端根据内部状态变化决定何时发送通知，使 MCP 连接动态且响应迅速。

5. **Best Effort**：不保证每个通知都会被发送或接收，尤其是在传输重连期间。客户端还应依赖轮询来保持结果的新鲜度。

#### 客户端对通知的响应

收到此通知后，客户端通常通过请求更新后的工具列表来做出反应。这创建了一个刷新周期，使客户端对可用工具的理解保持最新：

```json Request
{
  "jsonrpc": "2.0",
  "id": 5,
  "method": "tools/list",
  "params": {
    "_meta": {
      "io.modelcontextprotocol/protocolVersion": "2026-07-28",
      "io.modelcontextprotocol/clientInfo": {
        "name": "example-client",
        "version": "1.0.0"
      },
      "io.modelcontextprotocol/clientCapabilities": {
        "elicitation": {}
      }
    }
  }
}
```

#### 通知为何重要

此通知系统至关重要，原因有几个：

1. **Dynamic Environments**：工具可能会根据服务端状态、外部依赖或用户权限而出现和消失
2. **Efficiency**：客户端不需要轮询变更；当更新发生时它们会收到通知
3. **Consistency**：确保客户端始终拥有关于可用服务端能力的准确信息
4. **Real-time Collaboration**：支持能够适应变化上下文的响应式 AI 应用

此通知模式不仅限于工具，还扩展到其他 MCP 原语，从而实现客户端与服务端之间全面的实时同步。

#### 这在 AI 应用中如何工作

AI 应用为其关心的变更保持一个通知流打开。当通知到达时，它会立即刷新其工具注册表，并更新 LLM 的可用能力。这确保正在进行的对话始终可以访问最新的工具集，并且 LLM 可以在新功能可用时动态适应。
```python
# Pseudo-code for AI application notification handling
async def follow_tool_changes(client):
    async with client.listen(tools_list_changed=True) as sub:
        async for _event in sub:
            tools_response = await client.list_tools()
            app.update_available_tools(client, tools_response.tools)
            if app.conversation.is_active():
                app.conversation.notify_llm_of_new_capabilities()
```

友情链接

  • Agents.md面向 AI 编码助手的仓库说明文件规范
  • LangChainLangChain 是一个开放的Agent平台
  • LangSmithAgent 工程平台：可观测与评估、部署、Fleet、Engine 等
  • EmbabelEmbabel 是一个JVM平台Agent框架
  • SpringAISpringAI 是一个基于 Spring 的 AI 框架
  • MCPModel Context Protocol，连接 AI 应用与外部数据/工具的开放标准
  • LangChain4jJava 生态的 LLM 应用开发框架
  • LlamaIndex把数据接入 LLM 的框架与文档平台
  • LlamaParse智能体式 OCR 文档解析：把 PDF、扫描件变成 LLM 可用的文本与结构化数据
  • LiteParse本地优先、轻量的文档解析库，不需要 API key
  • CrewAI多智能体编排框架：以 Crew/Flow 组织自主协作的 AI Agent
  • MAFMicrosoft Agent Framework，企业级 .NET/Python 智能体框架

BytesRouter 是社区翻译站点，所有译文仅供参考，一切以官方英文原文为准。

© 2026 BytesRouter · 译文采用 CC BY 4.0 许可