17 篇博文 含有标签「大语言模型」

翻译自：https://spec.modelcontextprotocol.io/specification/2025-03-26/basic/authorization/

ℹ️ 协议修订：2025-03-26

1. 引言​

1.1 目的和范围​

模型上下文协议（MCP）在传输层提供了授权能力，允许MCP客户端代表资源所有者向受限的MCP服务器发出请求。本规范定义了基于HTTP传输的授权流程。

1.2 协议要求​

MCP实施的授权是可选的。当得到支持时：

• 使用基于HTTP的传输实现应该遵守本规范。
• 使用STDIO传输的实现不应该遵循这个规范，而是应该从环境中获取凭据。
• 使用替代传输实现必须遵循其协议的既定安全最佳实践。

1.3 标准合规性​

这种授权机制基于下列已建立的规范，但实现了其特性中的选定子集，以确保在保持简单性的同时，保证安全性和互操作性：

• OAuth 2.1 IETF 草案
• OAuth 2.0 授权服务器元数据 (RFC8414)
• OAuth 2.0 动态客户端注册协议（RFC7591）

2. 授权流程​

2.1 概述​

1. MCP授权实现必须为机密客户端和公开客户端实施OAuth 2.1，并采取适当的安全措施。
2. MCP鉴权实现应该支持OAuth 2.0动态客户端注册协议（RFC7591）。
3. MCP服务器应该而MCP客户端必须实现OAuth 2.0授权服务器元数据（RFC8414）。不支持授权服务器元数据的服务器必须遵循默认的URI架构。

2.2 基础的 OAuth 2.1 授权​

当授权是必需的而客户端尚未提供证明时，服务器必须以HTTP 401 Unauthorized响应。

客户端在收到HTTP 401 未授权后启动OAuth 2.1 IETF 草案的授权流程。

以下展示了使用PKCE的公共客户端的基本OAuth 2.1流程。

2.3 服务器元数据发现​

服务器能力发现：

• MCP 客户端必须遵循在 RFC8414 中定义的 OAuth 2.0 授权服务器元数据协议。
• MCP服务器应当遵循OAuth 2.0授权服务器元数据协议。
• 不支持 OAuth 2.0 授权服务器元数据协议的MCP服务器，必须支持后备URL。

发现流程如下图所示：

2.3.1 服务器元数据发现头部​

在服务器元数据发现过程中，MCP 客户端应该包含头部 MCP-Protocol-Version: <protocol-version>，以便MCP服务器可以根据MCP协议版本进行响应。

例如：MCP-Protocol-Version: 2024-11-05

2.3.2 授权基础网址​

授权基础URL 必须 通过舍弃任何现有的 path 组件从MCP服务器URL确定。例如：

如果MCP服务器的URL是https://api.example.com/v1/mcp，那么：

• 授权基础 URL 是 https://api.example.com
• 元数据端点 必须 位于 https://api.example.com/.well-known/oauth-authorization-server

这确保了授权端点始终位于托管MCP服务器的域的根级别，无论MCP服务器URL中的路径组件如何。

2.3.3 没有元数据发现功能的服务器的备选方案​

对于不实现OAuth 2.0授权服务器元数据的服务器，客户端必须使用以下默认的端点路径，相对于授权基础URL（如第2.3.2节中定义）：

例如，如果一个MCP服务器托管在https://api.example.com/v1/mcp，那么默认的端点将会是：

• https://api.example.com/authorize
• https://api.example.com/token
• https://api.example.com/register

客户端必须首先尝试通过元数据文档来发现端点，再回退到默认路径。当使用默认路径时，所有其他协议要求保持不变。

2.3 动态客户端注册​

MCP 客户端和服务器应该支持 OAuth 2.0 动态客户端注册协议，以便 MCP 客户端可以在没有用户交互的情况下获取 OAuth 客户端 ID。这为客户端自动向新服务器注册提供了一种标准化的方式，这对于 MCP 来说至关重要，因为：

• 客户端无法提前知晓所有可能的服务器。
• 手动注册会给用户带来不便。
• 它实现了与新服务器的无缝连接
• 服务器可以实现自己的注册策略

任何不支持动态客户端注册的MCP服务器需要提供其他方法来获取客户端ID（如果适用，还有客户端密钥）。对于这些服务器之一，MCP客户端将必须选择以下方式之一：

1. 硬编码一个客户端ID（如果适用，还包括客户端密钥）专门用于那个MCP服务器，或者
2. 向用户展示一个用户界面，让他们在注册了OAuth客户端后输入这些详细信息（例如，通过服务器托管的配置界面）。

2.4 授权流程步骤​

完整的授权流程如下进行：

2.4.1 决策流概述​

2.5 访问令牌的使用​

2.5.1 令牌要求​

访问令牌处理必须符合OAuth 2.1 第5节对资源请求的要求。具体来说：

1. MCP 客户端必须使用授权请求头字段 第5.1.1节：

Authorization: Bearer <access-token>

请注意，在客户端向服务器发送的每个HTTP请求中都必须包含授权信息，即使它们是同一个逻辑会话的一部分。

1. 访问令牌必须不能包含在URI查询字符串中。

示例请求：

GET /v1/contexts HTTP/1.1
Host: mcp.example.com
Authorization: Bearer eyJhbGciOiJIUzI1NiIs...

2.5.2 令牌处理​

资源服务器必须按照第5.2节所描述的方式验证访问令牌。如果验证失败，服务器必须根据第5.3节的错误处理要求做出响应。无效或过期的令牌必须收到HTTP 401响应。

2.6 安全考虑​

以下安全要求必须被实施：

1. 客户端必须根据OAuth 2.0的最佳实践安全地存储令牌。
2. 服务器应该执行令牌的过期和轮换。
3. 所有授权终端点必须通过HTTPS服务。
4. 服务器必须验证重定向URI以防止公开重定向漏洞
5. 重定向URI 必须 是localhost URLs或HTTPS URLs。

2.7 错误处理​

服务器必须为授权错误返回适当的HTTP状态码。

2.8 实施要求​

1. 实现必须遵循OAuth 2.1安全最佳实践
2. PKCE对所有客户端来说都是必需的
3. 为了增强安全性，应该实施令牌轮换
4. 令牌的有效期应该根据安全需求来限定。

2.9 第三方授权流程​

2.9.1 概述​

MCP服务器可以通过第三方授权服务器支持委派授权。在这个流程中，MCP服务器既是OAuth客户端（对第三方授权服务器而言）也是OAuth授权服务器（对MCP客户端而言）。

2.9.2 流程描述​

第三方授权流程包括以下步骤：

1. MCP客户端与MCP服务器启动标准的OAuth流程
2. MCP服务器将用户重定向到第三方授权服务器。
3. 用户授权第三方服务器
4. 第三方服务器带着授权码重定向回MCP服务器。
5. MCP服务器交换代码以获取第三方访问令牌
6. MCP 服务器生成了绑定到第三方会话的自有访问令牌。
7. MCP服务器完成与MCP客户端的原始OAuth流程

2.9.3 会话绑定要求​

MCP服务器实现第三方授权必须：

1. 维持第三方令牌与发行的MCP令牌之间的安全映射。
2. 在承认MCP令牌之前验证第三方令牌的状态
3. 实施适当的令牌生命周期管理
4. 处理第三方令牌过期和更新

2.9.4 安全性考虑​

在实现第三方授权时，服务器必须：

1. 验证所有重定向URI
2. 安全地存储第三方凭据
3. 实现适当的会话超时处理
4. 考虑令牌链接的安全隐患
5. 实现对第三方授权失败的适当错误处理

3. 最佳实践​

3.1 本地客户端作为公共OAuth 2.1 客户端​

我们强烈推荐本地客户端作为公共客户端实施OAuth 2.1：

1. 利用代码挑战（PKCE）进行授权请求以防止拦截攻击
2. 为本地系统实现适当的安全令牌存储
3. 遵循令牌刷新的最佳实践以维持会话
4. 正确处理令牌过期和续订

3.2 授权元数据发现​

我们强烈建议所有客户端实施元数据发现。这减少了用户手动提供端点的需求，或者客户端回退到定义的默认值。

3.3 动态客户端注册​

由于客户端事先不知道MCP服务器的集合，我们强烈推荐实施动态客户端注册。这允许应用程序自动注册到MCP服务器，并且消除了用户手动获取客户端ID的需求。

翻译自：https://spec.modelcontextprotocol.io/specification/2025-03-26/changelog/

此文件列出了自上一修订版2024-11-05以来，模型上下文协议（MCP）规范所做的更改。

重大变化​

1. 添加了一个基于OAuth 2.1的全面**授权框架**（PR #133）
2. 替换了先前的HTTP+SSE传输，采用了更灵活的**可流式HTTP传输**（PR #206）。
3. 增加了对JSON-RPC **批处理**的支持（PR #228）
4. 为了更好地描述工具行为，例如它是只读的还是具有破坏性的，我们增加了全面的工具注释（PR #185）。

其他架构更改​

• 在ProgressNotification中添加了message字段，以提供描述性的状态更新。
• 增加了对音频数据的支持，与现有的文本和图像内容类型一起使用。
• 添加了completions功能，用于明确指示对参数自动完成建议的支持。

查看更新后的Schema以获取更多细节。

完整的更新日志​

要查看自上次协议修订以来所做的所有更改的完整列表，请访问GitHub。

翻译自：https://spec.modelcontextprotocol.io/specification/2025-03-26/basic/transports/

ℹ️ 协议修订：2025-03-26

MCP 使用 JSON-RPC 来编码消息。JSON-RPC 消息必须使用 UTF-8 编码。

该协议目前定义了两种标准的传输机制用于客户端与服务器之间的通信：

1. 通过标准输入和标准输出进行通信
2. 可流式传输的HTTP

客户端在可能的情况下应该支持标准输入输出。

客户端和服务器也可以以可插拔方式实现自定义传输。

标准输入输出​

在 stdio 传输中：

• 客户端作为一个子进程启动MCP服务器。
• 服务器从其标准输入（stdin）读取JSON-RPC消息，并将消息发送到其标准输出（stdout）。
• 消息可以是JSON-RPC请求、通知、响应，或者是一个包含一个或多个请求和/或通知的JSON-RPC批处理。
• 消息通过换行符进行界定，并且必须不包含嵌入的换行符。
• 服务器可以将UTF-8字符串写入其标准错误（stderr）用于记录日志。客户端可以捕获、转发或忽略这些日志记录。
• 服务器绝对不可以向它的stdout写入任何非有效MCP消息的内容。
• 客户端绝不能向服务器的stdin写入任何不是有效MCP消息的内容。

可流式传输的HTTP​

ℹ️ 这替换了协议版本 2024-11-05 中的HTTP+SSE 传输。请参阅下面的向后兼容性指南。

在可流式的HTTP传输中，服务器作为一个独立的进程运行，可以处理多个客户端连接。这种传输使用HTTP POST和GET请求。服务器可以选择使用服务器发送事件（SSE）来流式传输多个服务器消息。这允许基本的MCP服务器，以及支持流式传输和服务器到客户端通知和请求的更丰富功能的服务器。

服务器必须提供一个支持POST和GET方法的单一HTTP端点路径（以下称为MCP端点）。例如，这可以是像https://example.com/mcp这样的URL。

向服务器发送消息​

每个从客户端发送的JSON-RPC消息必须是一个对MCP端点的新的HTTP POST请求。

1. 客户端必须使用HTTP POST方法向MCP端点发送JSON-RPC消息。

2. 客户端必须包含一个Accept头部，列出application/json和text/event-stream作为支持的内容类型。

3. POST请求的主体必须成为以下之一：

   • 一个单独的JSON-RPC 请求、通知或响应
   • 一个数组 批处理 一个或多个请求和/或通知
   • 一个数组 批处理 一个或多个响应

4. 如果输入仅仅包含（任意数量的）JSON-RPC 通知或响应:

   • 如果服务器接受输入，服务器必须返回HTTP状态码202 Accepted并且不包含任何内容。
   • 如果服务器不能接受输入，它必须返回一个HTTP错误状态码（例如，400错误的请求）。HTTP响应体可以包含一个没有id的JSON-RPC错误响应。

5. 如果输入包含任意数量的JSON-RPC请求，服务器必须返回Content-Type: text/event-stream以初始化一个SSE流，或者返回Content-Type: application/json以返回一个JSON对象。客户端必须支持这两种情况。

6. 如果服务器启动一个SSE流：

   • SSE流应该最终包括针对POST正文中发送的每个JSON-RPC请求的一个JSON-RPC响应。这些响应可以是批处理的。

   • 服务器可以在发送JSON-RPC响应之前发送JSON-RPC请求和通知。这些消息应该与发起的客户端请求有关。这些请求和*通知可以被批处理。

   • 服务器在发送每个收到的JSON-RPC请求的响应之前，不应该关闭SSE流，除非会话过期。

   • 在所有JSON-RPC响应发送完毕后，服务器应该关闭SSE流。

   • 断开连接可能随时可能发生（例如，由于网络条件）。因此：

     • 断开连接不应该被解释为客户端取消了它的请求。
     • 为了取消，客户端应该明确发送一个MCP CancelledNotification。
     • 为了避免由于连接断开而导致消息丢失，服务器可以使流可以恢复。

监听服务器的消息​

1. 客户端可以向MCP端点发出HTTP GET请求。这可以用来打开一个SSE流，允许服务器与客户端通信，而无需客户端首先通过HTTP POST发送数据。
2. 客户端必须包含一个Accept头部，列出text/event-stream作为支持的内容类型。
3. 服务器必须对这个HTTP GET请求返回Content-Type: text/event-stream，或者返回HTTP 405 方法不被允许，表明服务器在这个端点不提供SSE流。
4. 如果服务器启动一个SSE流：
   • 服务器可以在流上发送JSON-RPC的请求和通知。这些请求和通知 可以是批处理的。
   • 这些消息应该与客户端同时运行的任何JSON-RPC请求无关。
   • 服务器不得在流上发送JSON-RPC response，除非恢复与先前客户端请求关联的流。恢复
   • 服务器可能会在任何时间关闭SSE流。
   • 客户端可以在任何时候关闭SSE流。

多重连接​

1. 客户端可以同时保持与多个SSE流的连接。

2. 服务器必须将其每一条JSON-RPC消息只发送在一条已连接的流上；也就是说，它不得在多个流中广播相同的消息。

   • 通过使流可恢复，可能可以降低消息丢失的风险。

恢复性和重传​

为了支持恢复断开的连接，并重新传送可能丢失的信息：

1. 正如在SSE标准介绍的，服务器可以附加一个id到他们的SSE事件中。

   • 如果存在，该ID 必须 在该会话中的所有流之间全局唯一——或者如果没有使用会话管理，那么在与那个特定客户端的所有流之间全局唯一。

2. 如果客户希望在连接断开后恢复，它应该向MCP端点发起一个HTTP GET请求，并包含Last-Event-ID标头用于指示它收到的最后一个事件ID。

   • 服务器可以使用此头部来重放在最后一个事件ID之后本应发送的消息，在被断开的流上，并从那个点恢复流。
   • 服务器不得重播本应在不同流上交付的消息。

换言之，这些事件 ID 应该由服务器在每个流的基础上分配，以便在特定流内充当游标。

会话管理​

一个MCP“会话”包含客户端与服务端之间逻辑上相关的交互，始于初始化阶段。为了支持想要建立有状态会话的服务器：

1. 使用可流式传输的HTTP协议的服务器可以在初始化时分配一个会话ID，通过在载有InitializeResult的HTTP响应中增加Mcp-Session-Id头传递给访问方。

   • 会话ID 应该 是全球唯一且加密安全的（例如，一个安全生成的UUID、一个JWT或一个加密散列）。
   • 会话ID 必须 只包含可见的ASCII字符（范围从0x21到0x7E）。

2. 如果一个Mcp-Session-Id在初始化期间由服务器返回，使用 Streamable HTTP 传输的客户端必须包在所有随后的HTTP请求中包含该头部。

   • 需要会话 ID 的服务器应该对没有 Mcp-Session-Id 头部的请求（初始化除外）以 HTTP 400 错误请求响应。

3. 服务器可以在任何时候终止会话，在此之后，它必须用HTTP 404未找到对包含该会话ID的请求作出响应。

4. 当客户端在包含Mcp-Session-Id的请求中收到HTTP 404响应时，它必须通过发送一个没有附加会话ID的新InitializeRequest来开始一个新会话。

5. 客户端不再需要某个特定会话时（例如，因为用户要离开该客户端应用程序）应该向MCP端点发送一个包含Mcp-Session-Id头部HTTP DELETE请求，用来明确结束会话。

   • 服务器可以使用HTTP 405方法不允许响应此请求，表明服务器不允许客户端终止会话。

时序图​

向后兼容性​

客户端和服务器可以通过以下方式与已弃用的HTTP+SSE传输（来自2024-11-05的协议版本）保持向后兼容：

想要支持旧版客户端的服务器应该：

• 继续同时托管旧传输的SSE（Server-Sent Events）和POST端点，以及为可流式HTTP传输定义的新的“MCP端点”。
  • 也可以将旧的POST端点和新的MCP端点结合起来使用，但这可能会引入不必要的复杂性。

想要支持旧服务器的客户端应该：

1. 接受用户提供的一个MCP服务器的URL，该URL可能指向使用旧传输协议或新传输协议的服务器。

2. 尝试向该URL发送一个包含有InitializeRequest和前述Accept头部的POST请求：

   • 如果成功，客户端可以假设这是一个支持新的Streamable HTTP传输的服务器。
   • 如果它失败并返回一个HTTP 4xx状态码（例如，405 方法不允许 或 404 未找到）：
     • 向服务器URL发起一个GET请求，期待这将打开一个SSE流，并将endpoint事件作为第一个事件返回。
     • 当 endpoint 事件到达时，客户端可以认为这是一个运行着旧版HTTP+SSE传输协议的服务器，并且应该使用该传输协议进行所有后续的通信。

自定义传输​

客户端和服务器可以根据其特定需求实现额外的自定义传输机制。该协议与传输方式无关，可以在支持双向消息交换的任何通信渠道上实现。

选择支持自定义传输的实施者必须确保它们保留由MCP定义的JSON-RPC消息格式和生命周期要求。自定义传输应当记录它们特定的连接建立和消息交换模式以便于对接。

翻译自：https://spec.modelcontextprotocol.io/specification/2025-03-26/

ℹ️ 协议修订：2025-03-26

模型上下文协议 (MCP) 是一个开放的协议，它使得语言模型应用程序与外部数据源和工具之间的无缝集成成为可能。无论您是在构建一个由人工智能驱动的集成开发环境（IDE），增强一个聊天界面，还是创建自定义的AI工作流程，MCP都提供了一种标准化的方式连接语言模型与它们所需的上下文。

这个规范定义了权威的协议要求，基于位于schema.ts的TypeScript Schema。

对于实施指南和示例，请访问 modelcontextprotocol.io。

本文档中的关键词“MUST”、“MUST NOT”、“REQUIRED”、“SHALL”、“SHALL NOT”、“SHOULD”、“SHOULD NOT”、“RECOMMENDED”、“NOT RECOMMENDED”、“MAY”和“OPTIONAL”应当按照BCP 14 [RFC2119] [RFC8174]所描述的意义进行解读，当且仅当它们如本文所示全部以大写字母出现时。

概览​

MCP为应用程序提供了一种标准化的方式来：

• 与语言模型分享上下文信息
• 向人工智能系统暴露工具和能力
• 构建可组合的集成和工作流程

该协议使用 JSON-RPC 2.0消息来建立以下之间的通信：

• 主机：发起连接的LLM应用程序
• 客户端：宿主应用程序内部的连接器
• 服务器：提供上下文和能力的服务

MCP 从 语言服务器协议 中获得了一些灵感，该协议标准化了如何在整个开发工具生态系统中增加对编程语言的支持。与此类似，MCP 标准化了如何将额外的上下文和工具集成到 AI 应用的生态系统中。

关键细节​

基础协议​

• JSON-RPC 消息格式
• 有状态连接
• 服务器和客户端能力协商

特性​

服务器向客户提供以下任一特性：

• 资源：上下文与数据，供用户或人工智能模型使用
• 提示：为用户提供的模板化消息和工作流程
• 工具：AI模型执行的函数

客户端可能会向服务器提供以下功能：

• 采样：服务器主动的代理行为和递归的大型语言模型交互

附加工具​

• 配置
• 进度跟踪
• 取消
• 错误报告
• 记录

安全与信任与安全保障​

模型上下文协议通过任意数据访问和代码执行路径开启了强大的功能。随着这种能力的增加，所有实现者必须仔细考虑重要的安全和信任问题。

关键原则​

1. 用户同意与控制
   • 用户必须明确同意并理解所有数据访问和操作。
   • 用户必须保留对哪些数据被共享以及采取什么行动的控制权。
   • 实施者应为审查和授权活动提供清晰的用户界面。
2. 数据隐私
   • 主机在将用户数据暴露给服务器之前，必须获得用户的明确同意。
   • 主机在未经用户同意的情况下不得将资源数据传输到其他地方。
   • 用户数据应该通过适当的访问控制来保护。
3. 工具安全
   • 工具代表任意代码执行，必须谨慎对待。
     • 特别是，工具行为的描述，如注解，应被视为不可信的，除非它们来自于一个可信的服务器。
   • 主机在调用任何工具之前必须获得用户的明确同意。
   • 用户应在授权使用每个工具之前了解它的功能。
4. LLM 采样控制
   • 用户必须明确批准任何LLM抽样请求。
   • 用户应该控制：
     • 是否会发生抽样
     • 实际将要发送的提示
     • 服务器可以看到什么结果
   • 该协议有意限制了服务器对提示的可见性。

实施指南​

虽然MCP本身不能在协议层面强制执行这些安全原则，但是实现者应该：

1. 将强大的同意和授权流程构建到他们的应用程序中
2. 提供清晰的安全隐患文档说明
3. 实施适当的访问控制和数据保护
4. 在他们的集成中遵循安全最佳实践。
5. 在他们的功能设计中考虑隐私影响。

翻译自：https://platform.openai.com/docs/guides/responses-vs-chat-completions?api-mode=responses

比较响应（Responses）API和聊天补全（Chat Completions）API。

Responses API 和 Chat Completions API 是与 OpenAI 的模型交互的两种不同方式。本指南解释了这两个 API 之间的主要区别。

为什么选择Responses API？​

Responses API是我们最新的核心API，也是一个代理性（Agentic）的API原语，它结合了聊天补全任务的简单性和执行更多能动任务的能力。随着模型能力的发展，Responses API是构建以行动为导向的应用程序的灵活基础，其内置了多种工具：

• 网页搜索
• 文件搜索
• 电脑使用

如果您是新用户，我们推荐使用Responses API。

Chat Completions API不会消失​

Chat Completions API 是构建 AI 应用程序的行业标准，我们打算无限期地继续支持这个 API。我们引入的 Responses API 旨在简化涉及工具使用、代码执行和状态管理的工作流程。我们相信这个新的 API 原语将使我们能够在未来更有效地增强 OpenAI 平台。

具有状态的API和语义事件​

使用Responses API可以使事件处理更为简单。它拥有一个可预测的事件驱动架构，而Chat Completions API在生成字符时会不断向内容字段追加，这要求您手动跟踪每个状态之间的差异。多步骤的会话逻辑和推理通过Responses API来实施会更加容易。

Responses API 明确发出了语义事件，详细说明了发生了什么变化（例如，具体的文本添加），因此您可以编写针对特定发出事件（例如，文本更改）的集成，从而简化集成并提高类型安全性。

比较代码​

以下示例展示了如何对聊天补全API和Responses API进行基本的API调用。

文本生成示例​

这两个API都使我们能够轻松地从模型生成输出。一个completion需要一个messages数组，但是一个response需要一个input（字符串或数组，如下所示）。

聊天补全API

from openai import OpenAI
client = OpenAI()

completion = client.chat.completions.create(
  model="gpt-4o",
  messages=[
      {
          "role": "user",
          "content": "Write a one-sentence bedtime story about a unicorn."
      }
  ]
)

print(completion.choices[0].message.content)

响应 API

from openai import OpenAI
client = OpenAI()

response = client.responses.create(
  model="gpt-4o",
  inputs=[
      {
          "role": "user",
          "content": "Write a one-sentence bedtime story about a unicorn."
      }
  ]
)

print(response.output_text)

当你从Responses API收到回复时，字段有细微差异。你会收到一个带有独立id的类型化response对象，而不是一个message。默认情况下会存储响应。对于新账户，默认情况下会存储聊天补全信息。要在使用任一API时禁用存储，请设置store: false。

聊天补全API

[
  {
      "index": 0,
      "message": {
          "role": "assistant",
          "content": "在柔和的月光下，独角兽露娜跳舞穿梭在闪烁的星尘中，为每一个沉睡的孩子留下梦境的轨迹。",
          "refusal": null
      },
      "logprobs": null,
      "finish_reason": "stop"
  }
]

响应 API

在月光柔和的照耀下，独角兽露娜在闪烁的星尘田野中舞动，为每一个熟睡的孩子留下梦境的轨迹。

其他值得注意的差异​

• 响应返回output，而聊天补全返回一个choices数组。
• Structured Outputs API 的结构不同。使用 Responses 中的 text.format 而不是 response_format。在结构化输出指南中了解更多信息。
• 函数调用API的形式不同——这体现在请求中的函数配置以及响应中发回的函数调用上。详见函数调用指南中的完整差异。
• 推理是不同的。在聊天续写API中使用reasoning_effort，而在Responses API中使用reasoning.effort。阅读推理指南中更多的细节。
• Responses SDK 有一个 output_text 助手函数，而 Chat Completions 没有。
• 对话状态：在聊天补全中，你必须自己管理对话状态，而响应中有previous_response_id来帮助你处理长时间运行的对话。
• Responses API响应默认情况下会被存储。对于新账户，默认也会存储聊天补全接口结果。要禁用存储，请设置store: false。

这对现有的API意味着什么​

聊天补全API​

Chat Completions API 仍然是我们使用最广泛的 API。我们将通过新模型和功能继续支持它。如果您的应用程序不需要内置工具，您可以放心地继续使用 Chat Completions。

我们将继续发布新的聊天补全模型，只要它们的功能不依赖内置工具或多个模型调用。当你准备好使用为代理工作流程专门设计的高级功能时，我们推荐使用Responses API。

助手​

根据开发者对Assistants API测试版的反馈，我们在Responses API 中整合了关键的改进，使其更加灵活、快速以及易于使用。Responses API 代表了在 OpenAI 上构建代理的未来方向。

我们正在努力实现Assistants API与Responses API之间的全部功能对等，包括对助手式和线程式对象以及代码解释工具的支持。完成后，我们计划在2026年上半年前正式宣布停用助手API，并确定一个目标停用日期。

在弃用后，我们将提供从Assistants API到Responses API的明确迁移指南，该指南允许开发人员保留所有数据并迁移他们的应用程序。在我们正式宣布弃用之前，我们将继续向Assistants API提供新模型。

翻译自：https://cline.bot/blog/introducing-the-mcp-marketplace-clines-new-app-store

记得在安装新应用程序时需要在终端输入晦涩难懂的命令，手动解决依赖关系，还得祈祷不会出错吗？那正是我们现在用模型上下文协议（MCP）服务器的情况。但现在不再是这样了。今天，我很兴奋地宣布Cline的MCP市场——想象一下，它就像是你AI能力的应用商店。这是我们让每个人都能轻松获取AI超能力的答案，而不仅仅是技术精通的少数人。

为什么这很重要​

几个月前，Anthropic发布了模型上下文协议——一种高级的说法就是“嘿，让我们标准化人工智能与外部工具的交流方式。”这是个很酷的概念，但就像许多伟大的技术一样，最初的设置过程大概和报税一样有趣。在Cline，我们亲眼看到了这一点。用户喜欢MCPs的强大能力但讨厌设置过程。他们需要：

• 找到正确的GitHub仓库
• 阅读技术文档
• 手动配置JSON文件
• 交叉他们的手指并希望它能奏效

并不完全是我们所期望的“人工智能的未来”体验。

进入MCP市场​

这是我们构建的：一个清晰、简洁的界面，在这里你可以：

• 浏览可用的MCP服务器
• 查看评分、下载次数和描述
• 单击一次即可安装任何MCP。
• 获取自动设置和配置

不再需要处理JSON。不再有依赖地狱。只需点击一下，让Cline来处理剩下的。

它是如何工作的​

1. 在VS Code中打开Cline（顺便说一下，我们刚达到了70万次下载，谢谢大家！）
2. 导航到MCP市场
3. 找到一个你想要的MCP服务器（我们拥有从Figma集成到网络搜索的所有功能）
4. 点击"下载"
5. 让Cline来处理设置

就是这样。Cline 阅读安装说明，向您询问任何必要的 API 密钥，并自动配置一切。

针对MCP开发者​

如果您正在构建MCP服务器（你真是个好人），我们正在引入一项新标准：llms-installation.md 文件。这是一套专门的指导说明，可以帮助像Cline这样的AI代理可靠地安装您的MCP服务器。把它当作是为一个非常能干但思维很字面化的初级开发者编写指导说明。包括：

• 必需的依赖项
• API密钥要求（必需及可选）
• 逐步安装过程
• 常见故障排除提示

想要在我们的列表中看到你的MCP服务器吗？在我们的mcp-marketplace 仓库创建一个问题，附上：

1. 你的GitHub仓库网址
2. 一个400x400的PNG格式的标志
3. 它应该被包括在内的简要描述

接下来是什么​

这仅仅是个开始。随着我们的市场不断增长，我们看到了令人难以置信的MCPs（Marketplace Creators' Programs）被构建起来——从代码分析工具到设计集成。可能性是无限的，我们迫不及待想看到你们打造出什么。如果你已经在使用Cline（感谢你！），MCP市场更新现在正在推出。如果你还没有尝试Cline，那么现在是给你的AI赋予超能力的最好时机。想要持续了解Cline并获得新功能的早期访问权限吗？请在下面订阅我们的新闻通讯。我们正在构建AI开发的未来，我们很乐意带你一起加入这趟旅途。

PS：如果你正在用MCP打造一些酷炫的东西，我很想听听。在Twitter上联系我！

翻译自：https://cline.bot/blog/mcp-servers-explained-what-they-are-how-they-work-and-why-cline-is-revolutionizing-ai-tools

了解MCP服务器是什么以及它们是如何工作的。学习Cline是如何利用模型上下文协议（MCP）服务器来彻底改变AI工具整合和开发的。继续阅读以获取深入的见解！

周二我在旧金山的CodeGen Night活动上，有机会与一些Cline的高级用户讨论MCP（模型上下文协议）服务器。这些都是精通技术的开发者，他们听说过MCP，但因为不完全了解它的工作原理或者它为何重要，所以没有使用它。

这次对话让我意识到一点：如果连高级用户都不能完全理解MCP服务器，我们需要一个更好的方法来解释它们。那么让我一次性以最简单的方式把这个问题说明白。

什么是MCP服务器以及它们是如何工作的？​

想象一下没有MCP的Cline，就像一台没有互联网接入的电脑——功能强大但孤立无援。添加了MCP就像不仅仅是给它接入了互联网，还给它提供了一个应用商店，每个新应用都赋予了它新的功能。但有趣的是：Cline实际上能够为自己创造新应用。

MCP服务器 就像是人工智能和工具之间的智能适配器。传统的API需要按照特定的格式输入精确的命令——就像必须记住特定的咒语才能让事物运作一样。而MCP服务器，则提供了一个灵活的界面，让人工智能更自然地理解和使用工具。

底层原理​

MCP服务器就像一个工具菜单，每个工具都被仔细描述以便AI能理解如何使用它。例如，当你看一个Notion的MCP服务器时，你会发现像create_database或query_database这样的工具。每个工具包括：

• 一个名称： 它叫什么。
• 一个自然语言描述： 它的作用。
• 一个模式（一套参数）： 确切定义了它需要的信息。
• 实际代码： 发起API调用。

当Cline想在Notion中创建数据库时，这是他的过程：

1. 发现： MCP服务器告诉Cline可用的工具有哪些。
2. 选择： Cline 观察到一个像 create_database 这样的工具以及它的描述。
3. 规格说明： 服务器会明确告诉客户端它需要什么信息（例如，创建的位置、命名等）。
4. 执行： Cline以正确的格式提供那些信息，服务器则负责实际调用Notion的API。

注意： 您仍然需要API密钥和适当的安全措施。MCP并不神奇；它特别之处在于它创造了一种标准方式，使AI可以发现并使用工具而无需学习每个API的具体细节。

一个令人震惊的MCP实战​

两个月前，当我们首次将MCP支持加入Cline时，我目睹了一些完全改变了我对人工智能工具可能性认知的事情。以下是发生的事情：

• 步骤1： Cline 阅读了一个自述文件，解释了如何构建一个 Notion MCP 服务器。
• 步骤2： 它实际上构建了服务器本身并将其添加到了工具包中。
• 步骤3： 第一次尝试向Notion数据库中添加内容时，它的架构设置错误了。
• 步骤4： 它没有失败，而是识别出了错误，理解了正确的模式应该是什么，并对其进行了修正。
• 步骤5： 然后它成功完成了任务。

这是我意识到MCP真正特别之处的时刻——它不仅仅是关于连接到工具；它是关于使这些连接变得足够聪明和灵活，以至于人工智能可以理解它们、使用它们，甚至调试它们。

为什么MCP服务器是游戏规则的改变者​

当Anthropic两个半月前发布MCP时，它是一个有前景的标准。但就在两个月前，当我们在Cline中增加了MCP支持时，我们不仅仅是实现了它——我们重新想象了它的潜能。

当其他人工智能助手刚刚开始增加基本的MCP支持时，Cline已经在构建它自己的MCP服务器了。想象一下：一个可以阅读文档或自然语言需求并为自己创建新工具的人工智能助手。

每新增一个MCP服务器，就好比为Cline的工具箱增添了一项新能力。与传统的集成方式不同，开发者必须手动构建一切，Cline能够自行创建这些工具。更重要的是，这些功能将成为不断增长的生态系统的一部分，所有与MCP兼容的人工智能工具都可以使用。

未来MCP为AI工具集成所启用的功能​

还记得网页浏览器刚问世时吗？它们为我们提供了一个与在线信息互动的通用方式。MCP正在为AI做同样的事情——提供一种让AI工具与软件互动的通用方式。而Cline正在促进这一运动。

想象一下可以做到以下事情的AI工具：

• 与公司内部工具集成： 允许安全、无缝地访问内部数据。
• 自动学习新应用： 通过探索并与各种API进行交互，无需人工干预。
• 即时适应工具变更： 无需不断更新。
• 与支持MCP的任何软件协作： 从Notion和GitHub到您构建的任何自定义工具。

当其他人刚开始使用MCP作为连接人工智能和工具的方法时，我们却有不同的看法。对于Cline来说，MCP不仅仅是关于连接到工具——它是关于人工智能可以创建自己的连接。Cline构建的每一个新的MCP服务器不仅增强了它自己的能力，也为整个生态系统做出了贡献。

这对你意味着什么​

如果你现在正在构建AI工具或集成，MCP服务器应该列入你的关注范围。它们不仅仅是另一种协议——它们代表了AI工具与软件交互方式的根本转变。

在Cline，我们全面投入到MCP上，因为我们相信这是AI工具集成的未来。AI能够自然地与工具交互，而不需要复杂的集成，这改变了一切关于可能性的事情。

想要了解更多吗？ 查看我们的创建自定义MCP服务器的文档，看看它有多简单——并探索无限的可能性。

常见问题解答(FAQ)​

MCP服务器是什么？​

MCP服务器是标准化、智能的适配器，它们允许AI工具发现、理解和与各种外部API和服务进行交互，无需为每一个都进行定制集成。

MCP服务器是如何工作的？​

他们提供了一系列工具的菜单，每个工具都用自然语言描述，并有一个定义好的模式。AI应用程序（如Cline）可以动态查询这些服务器来执行诸如读取文件、查询数据库或创建新集成等任务。

MCP服务器对于人工智能开发为什么重要？​

MCP服务器简化了AI与外部工具交互的方式，使AI系统能够即时适应、创建和调试集成，使它们比传统的API集成更加灵活和强大。

Cline如何使用MCP服务器？​

Cline不仅集成了现有工具（如Notion或GitHub）的MCP服务器，而且还能够通过阅读文档和自主创建新的工具连接来构建自己的MCP服务器。

结论​

MCP服务器是AI领域的一项根本性创新，它们充当AI与外部数据和工具海量世界之间的通用连接器。通过标准化AI与软件的交互方式，MCP服务器将一个静态、孤立的模型转变为一个动态的、能够感知上下文的助手——就像不仅仅给电脑提供互联网接入，而是提供了一个拥有众多能力的应用商店。

在Cline，我们正在利用MCP（主控程序）来彻底改变AI辅助开发。随着每一个新的MCP服务器的加入，我们的人工智能变得更加强大、更加适应性强，以及与您每天使用的工具更好地整合。这不仅仅是另一个协议——这是AI工具集成的未来。