FastMCP v4 已知缺口与上游依赖清单Known Gaps深入解析【免费下载链接】fastmcp The fast, Pythonic way to build MCP servers and clients.项目地址: https://gitcode.com/GitHub_Trending/fa/fastmcp导读FastMCP 向 MCP Python SDK 2.0 稳定线的迁移并非零成本而是一组刻意保留的兼容性边界与预期测试缺口。本文以仓库内dev-docs/v4-notes/known-gaps.md为骨架系统讲解迁移后的 xfail 预期失败清单、各兼容 shim 及其移除触发条件、2026-07-28无状态协议时代的能力核算哪些是协议结构性移除、哪些天然可用、哪些是设计空洞、十项 SDK 上游反馈档案以及 GA 发布前的核对清单。读完你将对“无状态协议下什么能做、什么不能做、为什么”有一个源码级的完整判断。背景一次带边界的迁移FastMCP v4 的核心迁移决策是全面依赖稳定的 MCP Python SDK 2.0 线fastmcp-slim的依赖声明为mcp2.0.0,3.0.0与mcp-types2.0.0,3.0.0见 pyproject.toml。SDK v2 带来的不只是字段命名从 camelCase 到 snake_case 的重命名还包括一条以2026-07-28为协商版本的无状态协议时代——每次请求独立构造Connection、无会话、无服务端到客户端的常驻流。这份known-gaps.md记录的就是这条迁移线的“诚实账本”哪些缺口是协议设计使然不该修、哪些是现有代码“不报错但不工作”的设计空洞待修、哪些需要把问题反馈给 SDK 团队上游依赖。它同时充当 beta 到 stable 过渡的核对清单。The xfail register三条预期的失败用例单元测试套件里保留着三条预期 xfail其中两条是strict标记strict xfail 一旦意外通过会直接让测试失败用于“盯住”上游修复的进展——上游一修这些用例就从 xfail 变成失败提示维护者移除标记。无状态 HTTP 上的服务端发起 elicitation用例位于 tests/client/test_streamable_http.py参数化覆盖 stateless 与 stateful 两种模式。代码中的实际分支逻辑如下pytest.mark.parametrize(streamable_http_server, [True, False], indirectTrue) async def test_elicitation_tool(streamable_http_server, request): stateless_http request.node.callspec.params.get(streamable_http_server, False) if stateless_http: pytest.xfail(Elicitation is not supported in stateless HTTP mode) # Server-initiated elicitation is handshake-era only. async with streamable_http_server.client( elicitation_handlerelicitation_handler, modelegacy ) as client: result await client.call_tool(elicit) assert result.data You said your name was: Alice!这个 xfail 是结构性的2026-07-28协议没有服务端→客户端的反向通道服务端发起的 elicitation 在无状态连接上天然不可能。注意测试在 stateless 分支 xfail 后实际断言仍运行在modelegacy握手时代连接上验证的是旧时代行为仍然正确。现代路径上支持的则是守卫模式guard-modeelicitation——工具返回InputRequiredResult、以多轮往返MRTR方式逐轮重跑这是 feature-program.md 中明确 shipped 的现代路径。MCP Apps 的能力通告sdk-feedback #2两条 strict xfail 位于 tests/test_apps.py 与 tests/test_apps.py跟踪同一问题SDK v2 在协商到 2026 之前pre-2026的握手版本时会剥离capabilities.extensions字段导致 UI 扩展MCP Appsio.modelcontextprotocol/ui无法通告给旧时代客户端。标记原因原文pytest.mark.xfail( reasonSDK v2 strips capabilities.extensions at the negotiated (pre-2026) handshake version, so the SEP-2133 UI extension is not advertised to the client (sdk-feedback #2)., strictTrue, ) async def test_capabilities_include_ui_extension(self): ... extras init_result.capabilities.model_extra or {} extensions extras.get(extensions, {}) assert UI_EXTENSION_ID in extensions这不仅是边角问题——它直接阻塞旗舰级 v4 功能io.modelcontextprotocol/tasks扩展SEP-2663见 background-tasks.md依赖在tools/call上通过 extensions 机制声明CreateTaskResult因此该缺口同时影响 tasks 与 MCP Apps 在新时代的启用。现代客户端协商到 2026可以正常收到扩展通告只有 legacy-era 客户端受影响。条件 xfail环境控制而非产品缺口文档特别澄清依赖凭据环境变量的 GitHub 集成套件也使用条件 xfail 标记但那是测试环境控制变量缺失时跳过不属于 GA 决策范围。Shims 及其移除触发条件迁移期引入的每个 shim 都是临时的或刻意永久的并带有明确的移除触发条件。完整清单Shim位置移除触发条件_compat.pycamelCase 字段桥fastmcp_slim/fastmcp/_compat.py用户迁移辅助等用户代码迁移到 snake_case 后于未来版本移除。用户可通过mcp_camelcase_compat False预览移除效果FastMCPRequestContextContextVarfastmcp_slim/fastmcp/server/dependencies.py永久。SDK 刻意以参数形式传递 context 而不提供 ContextVarFastMCP 公开的get_context()需要环境级访问shim 还额外抬升了_metaSDK 的TypedDict会丢弃它FastMCPServerMiddlewarefastmcp_slim/fastmcp/server/low_level.py永久。已是 SDK 原生ServerMiddleware路径没有更干净的钩子Clientget_session_id响应头嗅探fastmcp_slim/fastmcp/client/transports/http.pySDK 从streamable_http_client暴露 session id或on_session_created回调与sse_client对齐sdk-feedback #5_sdk_context_shim.py通用 handler 别名fastmcp_slim/fastmcp/client/_sdk_context_shim.pySDK 的ClientRequestContext不可下标not subscriptableFastMCP 保留公开的泛型SamplingHandler/RootsHandler/ElicitationHandler别名。除非 SDK 让 context 可下标sdk-feedback #7否则永久两个 shim 的源码级解读camelCase 桥的运行时开关机制_compat.py安装了一组“warn-once”的property描述符映射表覆盖Tool.inputSchema、CallToolResult.isError、InitializeResult.serverInfo等大量字段属性无条件安装但每个 getter 在读取时检查实时的mcp_camelcase_compat设置开启时警告一次并返回 snake_case 值关闭时抛出与原生缺失属性一致的AttributeError。安装有守卫绝不遮蔽类自身__dict__或 pydanticmodel_fields中已存在的 camelCase 属性作为纯描述符读取model_copy/model_validate后值仍然有效。这就是“运行时开关”的真正实现——在 import 后执行fastmcp.settings.mcp_camelcase_compat False即可关掉整座桥。session id 嗅探的现状SDK v2 的streamable_http_client不再暴露get_session_idFastMCP 通过在自有 httpx 客户端上挂事件钩子捕获响应头mcp-session-idhttp.py 的_capture_session_id与get_session_id()方法这是临时补偿等待上游提供一等公民 API。ContextVar 边界为什么是永久的SDK 把ServerRequestContext作为参数传入但 FastMCP 的get_context()、请求适配器与后台任务都需要“环境级”访问因此 dependencies.py 定义了fastmcp_request_ctx: ContextVar并由_lift_meta从原始 params 的_meta键中抬升出_meta.fastmcp版本号与分布式追踪父信息——这些是 SDK 的TypedDict类型上不携带的数据。2026-07-28 时代无状态性的诚实核算2026-07-28时代按协议构造即无状态。维护者反复追问“无状态是否要织入 FastMCP 各处”——答案是不需要但账要算清共三部分。以下全部只针对2026-07-28连接今天在线的每个客户端都协商握手时代那里一切行为照旧。SDK 的地面事实现代路径上 SDK 的Connection严格按请求实例化每次 POST 的 envelope 构造全新Connection请求返回时其exit_stack展开connection.session_id恒为Noneconnection.state是每次请求的全新 dict。管理器的stateless标志根本不进入现代路由现代路由在其之前短路。没有常驻的服务端→客户端流请求期间发出的通知搭载该 POST 自身的 SSE sinkPOST 返回后发出的通知被丢弃_NO_CHANNEL服务端→客户端的请求会抛NoBackChannelError。唯一替代品是subscriptions/listen——它只携带列表变更/resource 更新四类事件没有日志、进度或任务状态事件没有可恢复性且尚未接入 FastMCP仓库中暂无SubscriptionBus实现。现代路径上完全没有EventStore或Last-Event-ID——两者都属于 legacy 传输EventStore与SessionScopedEventStore的实现在 event_store.py 与 session_scoped_event_store.py仅供 legacy/握手时代使用。结构性 legacy-only记录别去构建这些不是 bug——协议移除了它们依赖的机制因此在 2026 时代超出范围每会话日志级别logging/setLevel不在 2026 方法注册表里_client_log_levelshandler 不可达该 dict 定义于 server.py由 mcp_operations.py 写入。没有会话就没有每会话日志级别状态。EventStore/ 可恢复性EventStore、SessionScopedEventStore与 Last-Event-ID 续传在现代路径上永远不会被构造。可恢复性预设了持久流而该时代没有。Ping keepalive服务端发起的 ping 是服务端→客户端请求在现代连接上结构性失效该传输上的 SSE 级 ping 由 SDK 负责。天然无状态在 2026 上正常工作这些功能从未依赖协议会话因此在2026-07-28上今天就能工作tasks/get轮询任务结果按task_id键控、由 Docket/Redis 支撑客户端可跨独立请求轮询无需任何会话亲和。正是这种无会话轮询让执行引擎在 SEP-1686→SEP-2663 重构中存活SEP-2663 的线上形状轮询tasks/get、用tasks/update解析任务内输入映射到同一持久存储SEP-2663 的Mcp-Name: taskId路由头在共享 Redis 部署任意副本都能服务轮询下无关紧要。OAuth bearer 校验认证是逐请求的 bearer 校验——每个 POST 自带并重新校验其凭据。请求内进度与日志通知请求仍在流式传输时发出的通知搭载该 POST 的 SSE sink正常送达。推迟到多协议工作流的设计空洞剩余项是真正的空洞全部推迟到 feature-program.md 中的“first-class 2026 client”工作流因为它们归结为一个未决问题——协议没有会话时什么是会话危险在于当前代码不报错地返回看起来“能用”实为静默降级。再次强调只影响 2026 连接握手时代全部行为正确。ctx.session_id与ctx.set_state/ctx.get_state单副本也坏现代请求上ctx.session_id铸造一次性uuid4缓存于随请求丢弃的connection.state上因此set_state/get_state跨请求静默永不往返——不报错只是丢数据。开放设计决策session_id应改为None并将set_state文档化为会话时代专用还是基于应用级键认证主体或客户端提供的头重建。该问题的完整设计走向见 stateless-session-state.md以认证主体为主键、Session/SessionId/SessionProvider双模式方案。任务推送与任务内输入——由 SEP-2663 设计解决不是无状态空洞早期框架将之视为空洞因为 SEP-1686 依赖推送反向通道通知/elicitation 中继提交请求一返回就失效。SEP-2663 移除该依赖任务内输入基于轮询——任务进入input_required在tasks/get的inputRequests映射中暴露待决的 elicit/sample/roots 请求客户端用tasks/update应答。这经持久存储往返、无会话亲和结构上无状态安全。SEP-1686 推送中继已移除fastmcp-tasks重建实现了基于轮询的通道。2026 上的前台非任务elicitation 仍是守卫模式的InputRequiredResult。有状态代理亲和降级有状态代理的_caches以逐请求的Connection为键现代连接上代理退化为无状态转发——结果仍然正确但每会话亲和保证丢失。与session_id问题同根一并决策或限制到 legacy/stdio 传输。多副本关切每进程限流桶、共享 Redis 的 state/tasks 后端、RedisSubscriptionBus属部署配置而非协议缺口不在本节范围。上游咨询档案十项 sdk-feedbackFastMCP 对 SDK 团队扮演顾问角色。迁移产出十项发现sdk-feedback.md中跟踪按优先级#1bug——SEP-1686 任务结果类型已随方法注册表发布但注册表遗漏了它们。已 mootSEP-1686 线上形状已从规范移除SEP-2663 重建通过扩展机制在tools/call上声明CreateTaskResult注册表已接受。#2bug/question——capabilities.extensions在 pre-2026 协商版本被剥离。已升级现在它阻塞io.modelcontextprotocol/tasks扩展及 MCP Apps在现代时代的启用是旗舰级 v4 功能而非边角案例值得在上游线程中优先处理。#4安全——DCR 重定向 URI 校验接受javascript:/data:scheme。#5hard edge——streamable_http_client丢弃 session id 访问且无替代对应上述 client shim。#8hard edge——自定义服务端通知被丢弃而非 tee 到message_handler。#10hard edge——2026 推送功能降级的错误质量不一致。FastMCP 侧已解决ctx.elicit/ctx.sample按时代门控在现代连接上抛出清晰错误#4448。提交filing以上游维护者对每条 issue 文本的批准为前提。另外feature-program.md 中的“SDK delegation round two”依赖三项上游功能请求——按会话的事件存储作用域、用户中间件注入钩子、lifespan 钩子——落地后 FastMCP 可把 HTTP 构建器折叠到 SDK 之上并继承 SDK 的会话所有者凭据强制一项当前缺失的安全增益。在此之前Change Register 中记录的四处 HTTP 覆盖保持现状。GA 过渡核对清单beta 到 stable 的过渡是一小组受跟踪步骤稳定 SDK 依赖——已完成。fastmcp-slim要求mcp2.0.0,3.0.0、mcp-types2.0.0,3.0.0锁文件均解析到 2.0.0。GA 前重跑全套件。确认上述三条预期 xfail 仍是完整集合若任一 strict Apps xfail 开始通过移除标记及对应兼容性说明这正是 strict xfail 的设计目的——把上游修复变成显式失败信号。显式作出扩展兼容性决策。GA 可以接受 Apps 及其他扩展为现代时代能力或等待 SDK 在 legacy 握手上保留capabilities.extensions将该选择记录进公开的协议支持文档。准备稳定版文档。移除预发布安装指引加入4.0.0: Fourmidablechangelog 与更新条目并在打 tag 前合并到main使稳定文档发布 PR 包含它们。保留 3.x 维护线——已完成。release/3.x受保护继续为 SDK v1 用户接收安全与兼容性补丁。结语把“已知缺口”当路线图读对 FastMCP v4 用户而言这份清单的实操价值在于三点一是遇到“现代连接上某些能力消失”时先对照本文的三分法判断是协议结构性移除别修、天然可用直接用还是设计空洞会静默丢数据需等待 first-class 2026 client 工作流二是升级到 SDK v2 时camelCase 兼容桥的运行时开关mcp_camelcase_compat False与各 shim 的移除触发条件决定了你的代码何时必须完成迁移三是 MCP Apps 与 tasks 扩展在现代时代的可用性受 sdk-feedback #2 直接阻塞这是判断 v4 旗舰功能何时“完全体”的关键上游信号。【免费下载链接】fastmcp The fast, Pythonic way to build MCP servers and clients.项目地址: https://gitcode.com/GitHub_Trending/fa/fastmcp创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 FastMCP v4 已知缺口与上游依赖清单（Known Gaps）深入解析
FastMCP v4 已知缺口与上游依赖清单Known Gaps深入解析【免费下载链接】fastmcp The fast, Pythonic way to build MCP servers and clients.项目地址: https://gitcode.com/GitHub_Trending/fa/fastmcp导读FastMCP 向 MCP Python SDK 2.0 稳定线的迁移并非零成本而是一组刻意保留的兼容性边界与预期测试缺口。本文以仓库内dev-docs/v4-notes/known-gaps.md为骨架系统讲解迁移后的 xfail 预期失败清单、各兼容 shim 及其移除触发条件、2026-07-28无状态协议时代的能力核算哪些是协议结构性移除、哪些天然可用、哪些是设计空洞、十项 SDK 上游反馈档案以及 GA 发布前的核对清单。读完你将对“无状态协议下什么能做、什么不能做、为什么”有一个源码级的完整判断。背景一次带边界的迁移FastMCP v4 的核心迁移决策是全面依赖稳定的 MCP Python SDK 2.0 线fastmcp-slim的依赖声明为mcp2.0.0,3.0.0与mcp-types2.0.0,3.0.0见 pyproject.toml。SDK v2 带来的不只是字段命名从 camelCase 到 snake_case 的重命名还包括一条以2026-07-28为协商版本的无状态协议时代——每次请求独立构造Connection、无会话、无服务端到客户端的常驻流。这份known-gaps.md记录的就是这条迁移线的“诚实账本”哪些缺口是协议设计使然不该修、哪些是现有代码“不报错但不工作”的设计空洞待修、哪些需要把问题反馈给 SDK 团队上游依赖。它同时充当 beta 到 stable 过渡的核对清单。The xfail register三条预期的失败用例单元测试套件里保留着三条预期 xfail其中两条是strict标记strict xfail 一旦意外通过会直接让测试失败用于“盯住”上游修复的进展——上游一修这些用例就从 xfail 变成失败提示维护者移除标记。无状态 HTTP 上的服务端发起 elicitation用例位于 tests/client/test_streamable_http.py参数化覆盖 stateless 与 stateful 两种模式。代码中的实际分支逻辑如下pytest.mark.parametrize(streamable_http_server, [True, False], indirectTrue) async def test_elicitation_tool(streamable_http_server, request): stateless_http request.node.callspec.params.get(streamable_http_server, False) if stateless_http: pytest.xfail(Elicitation is not supported in stateless HTTP mode) # Server-initiated elicitation is handshake-era only. async with streamable_http_server.client( elicitation_handlerelicitation_handler, modelegacy ) as client: result await client.call_tool(elicit) assert result.data You said your name was: Alice!这个 xfail 是结构性的2026-07-28协议没有服务端→客户端的反向通道服务端发起的 elicitation 在无状态连接上天然不可能。注意测试在 stateless 分支 xfail 后实际断言仍运行在modelegacy握手时代连接上验证的是旧时代行为仍然正确。现代路径上支持的则是守卫模式guard-modeelicitation——工具返回InputRequiredResult、以多轮往返MRTR方式逐轮重跑这是 feature-program.md 中明确 shipped 的现代路径。MCP Apps 的能力通告sdk-feedback #2两条 strict xfail 位于 tests/test_apps.py 与 tests/test_apps.py跟踪同一问题SDK v2 在协商到 2026 之前pre-2026的握手版本时会剥离capabilities.extensions字段导致 UI 扩展MCP Appsio.modelcontextprotocol/ui无法通告给旧时代客户端。标记原因原文pytest.mark.xfail( reasonSDK v2 strips capabilities.extensions at the negotiated (pre-2026) handshake version, so the SEP-2133 UI extension is not advertised to the client (sdk-feedback #2)., strictTrue, ) async def test_capabilities_include_ui_extension(self): ... extras init_result.capabilities.model_extra or {} extensions extras.get(extensions, {}) assert UI_EXTENSION_ID in extensions这不仅是边角问题——它直接阻塞旗舰级 v4 功能io.modelcontextprotocol/tasks扩展SEP-2663见 background-tasks.md依赖在tools/call上通过 extensions 机制声明CreateTaskResult因此该缺口同时影响 tasks 与 MCP Apps 在新时代的启用。现代客户端协商到 2026可以正常收到扩展通告只有 legacy-era 客户端受影响。条件 xfail环境控制而非产品缺口文档特别澄清依赖凭据环境变量的 GitHub 集成套件也使用条件 xfail 标记但那是测试环境控制变量缺失时跳过不属于 GA 决策范围。Shims 及其移除触发条件迁移期引入的每个 shim 都是临时的或刻意永久的并带有明确的移除触发条件。完整清单Shim位置移除触发条件_compat.pycamelCase 字段桥fastmcp_slim/fastmcp/_compat.py用户迁移辅助等用户代码迁移到 snake_case 后于未来版本移除。用户可通过mcp_camelcase_compat False预览移除效果FastMCPRequestContextContextVarfastmcp_slim/fastmcp/server/dependencies.py永久。SDK 刻意以参数形式传递 context 而不提供 ContextVarFastMCP 公开的get_context()需要环境级访问shim 还额外抬升了_metaSDK 的TypedDict会丢弃它FastMCPServerMiddlewarefastmcp_slim/fastmcp/server/low_level.py永久。已是 SDK 原生ServerMiddleware路径没有更干净的钩子Clientget_session_id响应头嗅探fastmcp_slim/fastmcp/client/transports/http.pySDK 从streamable_http_client暴露 session id或on_session_created回调与sse_client对齐sdk-feedback #5_sdk_context_shim.py通用 handler 别名fastmcp_slim/fastmcp/client/_sdk_context_shim.pySDK 的ClientRequestContext不可下标not subscriptableFastMCP 保留公开的泛型SamplingHandler/RootsHandler/ElicitationHandler别名。除非 SDK 让 context 可下标sdk-feedback #7否则永久两个 shim 的源码级解读camelCase 桥的运行时开关机制_compat.py安装了一组“warn-once”的property描述符映射表覆盖Tool.inputSchema、CallToolResult.isError、InitializeResult.serverInfo等大量字段属性无条件安装但每个 getter 在读取时检查实时的mcp_camelcase_compat设置开启时警告一次并返回 snake_case 值关闭时抛出与原生缺失属性一致的AttributeError。安装有守卫绝不遮蔽类自身__dict__或 pydanticmodel_fields中已存在的 camelCase 属性作为纯描述符读取model_copy/model_validate后值仍然有效。这就是“运行时开关”的真正实现——在 import 后执行fastmcp.settings.mcp_camelcase_compat False即可关掉整座桥。session id 嗅探的现状SDK v2 的streamable_http_client不再暴露get_session_idFastMCP 通过在自有 httpx 客户端上挂事件钩子捕获响应头mcp-session-idhttp.py 的_capture_session_id与get_session_id()方法这是临时补偿等待上游提供一等公民 API。ContextVar 边界为什么是永久的SDK 把ServerRequestContext作为参数传入但 FastMCP 的get_context()、请求适配器与后台任务都需要“环境级”访问因此 dependencies.py 定义了fastmcp_request_ctx: ContextVar并由_lift_meta从原始 params 的_meta键中抬升出_meta.fastmcp版本号与分布式追踪父信息——这些是 SDK 的TypedDict类型上不携带的数据。2026-07-28 时代无状态性的诚实核算2026-07-28时代按协议构造即无状态。维护者反复追问“无状态是否要织入 FastMCP 各处”——答案是不需要但账要算清共三部分。以下全部只针对2026-07-28连接今天在线的每个客户端都协商握手时代那里一切行为照旧。SDK 的地面事实现代路径上 SDK 的Connection严格按请求实例化每次 POST 的 envelope 构造全新Connection请求返回时其exit_stack展开connection.session_id恒为Noneconnection.state是每次请求的全新 dict。管理器的stateless标志根本不进入现代路由现代路由在其之前短路。没有常驻的服务端→客户端流请求期间发出的通知搭载该 POST 自身的 SSE sinkPOST 返回后发出的通知被丢弃_NO_CHANNEL服务端→客户端的请求会抛NoBackChannelError。唯一替代品是subscriptions/listen——它只携带列表变更/resource 更新四类事件没有日志、进度或任务状态事件没有可恢复性且尚未接入 FastMCP仓库中暂无SubscriptionBus实现。现代路径上完全没有EventStore或Last-Event-ID——两者都属于 legacy 传输EventStore与SessionScopedEventStore的实现在 event_store.py 与 session_scoped_event_store.py仅供 legacy/握手时代使用。结构性 legacy-only记录别去构建这些不是 bug——协议移除了它们依赖的机制因此在 2026 时代超出范围每会话日志级别logging/setLevel不在 2026 方法注册表里_client_log_levelshandler 不可达该 dict 定义于 server.py由 mcp_operations.py 写入。没有会话就没有每会话日志级别状态。EventStore/ 可恢复性EventStore、SessionScopedEventStore与 Last-Event-ID 续传在现代路径上永远不会被构造。可恢复性预设了持久流而该时代没有。Ping keepalive服务端发起的 ping 是服务端→客户端请求在现代连接上结构性失效该传输上的 SSE 级 ping 由 SDK 负责。天然无状态在 2026 上正常工作这些功能从未依赖协议会话因此在2026-07-28上今天就能工作tasks/get轮询任务结果按task_id键控、由 Docket/Redis 支撑客户端可跨独立请求轮询无需任何会话亲和。正是这种无会话轮询让执行引擎在 SEP-1686→SEP-2663 重构中存活SEP-2663 的线上形状轮询tasks/get、用tasks/update解析任务内输入映射到同一持久存储SEP-2663 的Mcp-Name: taskId路由头在共享 Redis 部署任意副本都能服务轮询下无关紧要。OAuth bearer 校验认证是逐请求的 bearer 校验——每个 POST 自带并重新校验其凭据。请求内进度与日志通知请求仍在流式传输时发出的通知搭载该 POST 的 SSE sink正常送达。推迟到多协议工作流的设计空洞剩余项是真正的空洞全部推迟到 feature-program.md 中的“first-class 2026 client”工作流因为它们归结为一个未决问题——协议没有会话时什么是会话危险在于当前代码不报错地返回看起来“能用”实为静默降级。再次强调只影响 2026 连接握手时代全部行为正确。ctx.session_id与ctx.set_state/ctx.get_state单副本也坏现代请求上ctx.session_id铸造一次性uuid4缓存于随请求丢弃的connection.state上因此set_state/get_state跨请求静默永不往返——不报错只是丢数据。开放设计决策session_id应改为None并将set_state文档化为会话时代专用还是基于应用级键认证主体或客户端提供的头重建。该问题的完整设计走向见 stateless-session-state.md以认证主体为主键、Session/SessionId/SessionProvider双模式方案。任务推送与任务内输入——由 SEP-2663 设计解决不是无状态空洞早期框架将之视为空洞因为 SEP-1686 依赖推送反向通道通知/elicitation 中继提交请求一返回就失效。SEP-2663 移除该依赖任务内输入基于轮询——任务进入input_required在tasks/get的inputRequests映射中暴露待决的 elicit/sample/roots 请求客户端用tasks/update应答。这经持久存储往返、无会话亲和结构上无状态安全。SEP-1686 推送中继已移除fastmcp-tasks重建实现了基于轮询的通道。2026 上的前台非任务elicitation 仍是守卫模式的InputRequiredResult。有状态代理亲和降级有状态代理的_caches以逐请求的Connection为键现代连接上代理退化为无状态转发——结果仍然正确但每会话亲和保证丢失。与session_id问题同根一并决策或限制到 legacy/stdio 传输。多副本关切每进程限流桶、共享 Redis 的 state/tasks 后端、RedisSubscriptionBus属部署配置而非协议缺口不在本节范围。上游咨询档案十项 sdk-feedbackFastMCP 对 SDK 团队扮演顾问角色。迁移产出十项发现sdk-feedback.md中跟踪按优先级#1bug——SEP-1686 任务结果类型已随方法注册表发布但注册表遗漏了它们。已 mootSEP-1686 线上形状已从规范移除SEP-2663 重建通过扩展机制在tools/call上声明CreateTaskResult注册表已接受。#2bug/question——capabilities.extensions在 pre-2026 协商版本被剥离。已升级现在它阻塞io.modelcontextprotocol/tasks扩展及 MCP Apps在现代时代的启用是旗舰级 v4 功能而非边角案例值得在上游线程中优先处理。#4安全——DCR 重定向 URI 校验接受javascript:/data:scheme。#5hard edge——streamable_http_client丢弃 session id 访问且无替代对应上述 client shim。#8hard edge——自定义服务端通知被丢弃而非 tee 到message_handler。#10hard edge——2026 推送功能降级的错误质量不一致。FastMCP 侧已解决ctx.elicit/ctx.sample按时代门控在现代连接上抛出清晰错误#4448。提交filing以上游维护者对每条 issue 文本的批准为前提。另外feature-program.md 中的“SDK delegation round two”依赖三项上游功能请求——按会话的事件存储作用域、用户中间件注入钩子、lifespan 钩子——落地后 FastMCP 可把 HTTP 构建器折叠到 SDK 之上并继承 SDK 的会话所有者凭据强制一项当前缺失的安全增益。在此之前Change Register 中记录的四处 HTTP 覆盖保持现状。GA 过渡核对清单beta 到 stable 的过渡是一小组受跟踪步骤稳定 SDK 依赖——已完成。fastmcp-slim要求mcp2.0.0,3.0.0、mcp-types2.0.0,3.0.0锁文件均解析到 2.0.0。GA 前重跑全套件。确认上述三条预期 xfail 仍是完整集合若任一 strict Apps xfail 开始通过移除标记及对应兼容性说明这正是 strict xfail 的设计目的——把上游修复变成显式失败信号。显式作出扩展兼容性决策。GA 可以接受 Apps 及其他扩展为现代时代能力或等待 SDK 在 legacy 握手上保留capabilities.extensions将该选择记录进公开的协议支持文档。准备稳定版文档。移除预发布安装指引加入4.0.0: Fourmidablechangelog 与更新条目并在打 tag 前合并到main使稳定文档发布 PR 包含它们。保留 3.x 维护线——已完成。release/3.x受保护继续为 SDK v1 用户接收安全与兼容性补丁。结语把“已知缺口”当路线图读对 FastMCP v4 用户而言这份清单的实操价值在于三点一是遇到“现代连接上某些能力消失”时先对照本文的三分法判断是协议结构性移除别修、天然可用直接用还是设计空洞会静默丢数据需等待 first-class 2026 client 工作流二是升级到 SDK v2 时camelCase 兼容桥的运行时开关mcp_camelcase_compat False与各 shim 的移除触发条件决定了你的代码何时必须完成迁移三是 MCP Apps 与 tasks 扩展在现代时代的可用性受 sdk-feedback #2 直接阻塞这是判断 v4 旗舰功能何时“完全体”的关键上游信号。【免费下载链接】fastmcp The fast, Pythonic way to build MCP servers and clients.项目地址: https://gitcode.com/GitHub_Trending/fa/fastmcp创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考