企业官网建设流程全解析

MCP Go SDK 路线图深度解析：SEP-1730 Tier 1 评级、Sampling With Tools 与 OAuth 授权扩展的落地路径

【免费下载链接】go-sdkThe official Go SDK for Model Context Protocol servers and clients. Maintained in collaboration with Google.项目地址: https://gitcode.com/GitHub_Trending/gosdk23/go-sdk

本篇技术指南以仓库 ROADMAP.md 为骨架，系统解读 MCP Go SDK 官方路线图：v1.4.0 时代锁定的三大焦点（SEP-1730 Tier 1 SDK 评级、SEP-1577 Sampling With Tools、客户端 OAuth 支持）、实验特性 SEP-1686 Tasks，以及 ext-auth 授权扩展（Enterprise Managed Authorization 与 OAuth Client Credentials）。读完你将掌握每个路线图条目的技术内涵、对应的源码与测试位置，以及它们在当前仓库中的实际落地状态，可用于评估 SDK 能力边界、制定依赖选型与升级计划。

路线图概览：定位与版本语境

ROADMAP.md 是 MCP Go SDK 官方维护者对短期（当前焦点）与中长期（未来工作、实验特性、扩展）技术方向的公开声明。阅读它之前，必须先建立版本坐标系：路线图中规划的 v1.4.0 条目以 2025-11-25 版 MCP 规范为基准，而仓库 README 的版本兼容表显示 SDK 已演进到 v1.7.0+（对应 2026-07-28 规范）：

（* 客户端侧 OAuth 为实验性支持；** 对 2025-11-25 仅部分支持，客户端 OAuth 与 Sampling with Tools 不可用。）

这意味着路线图中的"计划中"条目，在仓库当前状态中大多已"落地为实验支持或正式实现"，下文将逐条对照源码验证。

当前焦点：v1.4.0 的三大里程碑

SEP-1730：冲刺 Tier 1 SDK 评级

路线图将 SEP-1730（上游 issue #675）列为第一优先：目标是让本 SDK 被评为Tier 1 SDK，即对 MCP 规范的符合性达到最高级别。这一目标的工程支撑在仓库中清晰可见——SDK 维护了一整套系统化的符合性测试资产：

• conformance/everything-server/main.go 与 conformance/everything-client/main.go：一个"全功能"参考服务端/客户端，覆盖规范要求的能力面；
• conformance/baseline.yml：符合性基线配置；
• mcp/testdata/conformance/server/ 下的 txtar 测试用例集：discover.txtar（发现）、lifecycle.txtar（生命周期）、tools.txtar、prompts.txtar、resources.txtar、mrtr.txtar、version-latest.txtar/version-older.txtar（版本协商）、bad_requests.txtar（异常请求）、spec-sep-973-additional-metadata.txtar（附加元数据）；
• scripts/server-conformance.sh 与 scripts/client-conformance.sh：可直接运行的符合性验证脚本。

配合 mcp/conformance_test.go，这些资产让每个新版本都能自动回归验证协议行为。从源码结构看，这套"全功能 server + txtar 用例 + 脚本"的组合正是为 Tier 1 评级准备的合规性证据链。

SEP-1577：实现 Sampling With Tools

路线图称Sampling With Tools是"补齐 2025-11-25 MCP 规范完整范围的最后一个 SEP"。通俗地讲，它允许 server 在向 client 发起 sampling（模型采样）请求时，把可用工具及其调用策略一并传给模型，使模型能在采样过程中直接产出工具调用（Tool Use）与工具结果（Tool Result）消息。

该能力在当前仓库中已是完整实现并带全套测试的状态，核心证据集中在 mcp/sampling_test.go：

• TestSamplingWithTools_ToolUse：server 通过CreateMessageWithTools发起采样，CreateMessageWithToolsParams携带Messages（[]*SamplingMessageV2）、Tools（[]*Tool，含名称、描述、JSON Schema 输入定义）与ToolChoice{Mode: "auto"}；client 侧通过CreateMessageWithToolsHandler回调响应，返回CreateMessageWithToolsResult，其内容可包含ToolUseContent{ID, Name, Input}，并以StopReason: "toolUse"标记；
• TestSamplingWithTools_ToolResult/TestSamplingWithTools_ToolResultWithError：覆盖工具结果回传，SamplingMessageV2中可携带ToolResultContent{ToolUseID}消息，以及工具失败场景的兜底文本；
• TestSamplingToolsCapabilities：验证能力协商的三种路径——client 显式声明Capabilities.Sampling.Tools = &SamplingToolsCapabilities{}、未声明时由 handler 自动推断、以及完全不支持时禁用。

协议方法常量在 mcp/protocol.go 中定义为methodCreateMessage = "sampling/createMessage"。需要特别注意：sampling（以及 roots、logging）已自 2026-07-28 协议起被上游 SEP-2577 弃用，SDK 在至少 12 个月的弃用窗口内继续兼容支持（见 README.md 版本兼容表下方说明）。mcp/sampling_test.go 文件头部的lint:file-ignore SA1019注释即明示这些测试演练的是"已弃用但仍需保障兼容"的 API。因此，如果你是 2026-07-28 协议的新用户，应优先考虑替代方案；若运行旧协议服务，则可继续依赖本实现。

OAuth 支持：补齐规范要求的授权解决方案

路线图指出，客户端侧 OAuth是"按规范提供授权解决方案所需的最后一块功能"。仓库中这一目标的落地横跨两个包：

• auth/ 包：定义授权基础原语。auth/client.go 中的OAuthHandler接口规定：transport 若要支持 OAuth 2 授权，就应配置一个OAuthHandler，由它负责执行 OAuth 流程以获取访问令牌。具体实现包括 auth/authorization_code.go（授权码流程，其PreregisteredClient字段使用oauthex.ClientCredentials表示预注册客户端）与 auth/oidc_login.go 等；
• oauthex/ 包：OAuth 协议扩展，如 resource_meta.go（ProtectedResourceMetadata）、dcr.go（动态客户端注册）、token_exchange.go（令牌交换）、audience.go（受众声明）。

同时 go.mod 依赖golang.org/x/oauth2 v0.35.0与golang-jwt/jwt/v5，为 JWT 与标准 OAuth2 流程提供底层支撑。对照 README 兼容表（* 注：Client side OAuth 已有实验支持），可确认该路线图条目已进入"实验支持"阶段。从源码结构可以推断，transport 层挂载OAuthHandler的统一设计，正是为了让流式（Streamable HTTP/SSE）与命令式 transport 都能无差别地获得授权能力。

未来工作：等 tiering 体系就位后重绘蓝图

路线图明确表示：一旦 tiering（分级）体系落地，将起草新路线图以描述长期战略，其中可能包含下一节列出的实验特性或对 MCP 规范的扩展。这句话点出了 SDK 治理节奏的核心逻辑——路线图与规范分级体系强绑定，规范的演进（如 SEP-2577 弃用、2026-07-28 协议引入的resultType标注，见 mcp/protocol.go 中completeResultWithType相关实现）会直接改写 SDK 的优先级。这意味着读者应把本 ROADMAP 视作"阶段性快照"，长期策略以新版本发布时更新后的文档为准。

实验特性：SEP-1686 Tasks

路线图将Implement Tasks（SEP-1686，上游 issue #626）标记为实验性。Tasks 面向的是将长时间运行、可跨会话的任务作为一等公民纳入 MCP 的设想。需要如实说明：在当前仓库源码中尚未检索到 Task 相关的实现或测试文件，因此它仍处于"实验构想"阶段，未进入mcp包的可导入 API。判断依据是搜索mcp/目录下无Task相关符号，且路线图自身即将其标注为 experimental。建议关注后续 release 的 release notes，以该 SEP 正式落地为准。

扩展：Authorization extensions（ext-auth）

路线图单列"Authorization extensions"章节，指向上游 ext-auth 扩展体系。这些扩展在仓库中对应的实体是 auth/extauth/ 子目录，内含三组实现及配套测试：

Enterprise Managed Authorization（进行中）

Enterprise Managed Authorization（上游 issue #628）对应 auth/extauth/enterprise_handler.go。路线图标注其状态为In progress（关联上游 PR #770）。从命名与同目录实现模式可以推断，它旨在为"企业托管授权"场景提供专用的OAuthHandler风格实现——即授权端点、令牌端点由企业侧托管，SDK 客户端只负责按规范完成握手。配套的 auth/extauth/enterprise_handler_test.go 表明该处理器已具备可测试的稳定形态。

OAuth Client Credentials（客户端凭证）

OAuth Client Credentials（上游 issue #627）对应 auth/extauth/client_credentials.go，配套测试见 auth/extauth/client_credentials_test.go。这是 OAuth 2.0 的 client credentials 授权类型在 MCP 场景下的落地，典型用于机器对机器（M2M）的授权调用——server 以自身身份而非终端用户身份获取令牌。其类型定义oauthex.ClientCredentials同时被 auth/authorization_code.go 复用为预注册客户端的载体，说明该扩展与核心授权流程是同一类型体系内的一体化设计。

如何在当前仓库中跟进与验证

• 阅读规范映射文档：docs/ 目录（如 docs/protocol.md、docs/server.md）将 MCP 规范逐条映射到各包 API，是理解 SEP 落地细节的权威入口；design/ 下的设计文档（如 design/mrtr.md）记录了对新特性的设计推演。
• 运行符合性验证：直接执行 scripts/server-conformance.sh 与 scripts/client-conformance.sh，即可复现 Tier 1 评级所依赖的合规检查流程。
• 学习参考实现：examples/ 目录覆盖 server（basic、everything、sse、streamable 等）与 client（listfeatures、middleware 等）两侧；examples/auth/ 下的 client/enterprise/server 三个示例专门演示授权相关用法。
• 跟踪测试驱动的事实：mcp包内*_test.go文件（如 mcp/sampling_test.go、mcp/conformance_test.go）是每个能力"是否真正可用"的最直接证据，比任何文档都更及时。

综上，这份路线图既是一份"待办清单"，也是 SDK 与 MCP 规范演进的编年史：SEP-1730 与 SEP-1577 已在仓库中得到系统性实现与测试支撑，OAuth 已进入实验支持，ext-auth 扩展正在成型，而 Tasks 仍在实验构想期。依赖本 SDK 的项目可按此脉络评估：若面向 2026-07-28 协议，应优先关注规范弃用项（roots/sampling/logging）的迁移；若运行旧协议服务，则 sampling、OAuth 等路线图能力均可直接使用。

【免费下载链接】go-sdkThe official Go SDK for Model Context Protocol servers and clients. Maintained in collaboration with Google.项目地址: https://gitcode.com/GitHub_Trending/gosdk23/go-sdk