协议架构与 MCP 核心对象（Host/Client/Server、Tools/Resources/Prompts）

• 理解 MCP 三层架构（Host/Client/Server）的职责
• 掌握最小特权边界
• 理解信任与权限的划分

MCP 三层架构：1) Host——用户所在的应用（如 Claude Desktop、IDE），负责编排 Agent、管理 LLM 交互、持有用户上下文与权限，是"用户信任的边界"；2) Client——Host 与单个 Server 之间的连接器，1:1 连接一个 Server，负责协议交互、能力协商、工具调用转发；一个 Host 可管理多个 Client；3) Server——提供能力（tools/resources/prompts）的独立进程/服务，是"能力提供方"。最小特权边界：Server 只获得完成其任务所需的最小权限（最小工具集、最小资源路径、最小凭据），不访问用户完整上下文；Host 持有用户权限与上下文，Server 不持有用户数据；Client 只转发授权范围内的调用，不越权。Host 管理权限与信任，Client 管理连接，Server 提供受限能力，三者各司其职，权限不越界。

三层架构的本质是"信任与权限的分层"。Host 是用户边界（持用户上下文与权限），Client 是连接器（1:1 连接、转发），Server 是能力提供方（最小权限）。最小特权边界保证 Server 只能访问授权范围，不越权读取用户数据。

• 理解三类原语的语义边界
• 掌握避免语义混用的原则
• 理解正确选型的判断

三类原语语义不同：Tools 表示"可执行的动作"（模型调用，产生副作用与结果）；Resources 表示"URI 指向的数据"（应用可读取，无副作用，可被引用）；Prompts 表示"参数化的提示模板"（组织可复用，预定义工作流）。避免语义混用：1) 动作归 Tool——凡是要执行、有副作用、产生计算结果的操作，用 Tool；2) 数据归 Resource——静态/可读取的数据（文件、配置、文档）用 URI 形式的 Resource，而不是做成 Tool；3) 模板归 Prompt——可复用的提示指令/工作流用 Prompt，而不是让模型自行组装。判断准则：是否执行动作（Tool）、是否读取数据（Resource）、是否复用模板（Prompt）。混用会导致模型误用（如把只读数据做成 Tool 让模型反复调用、把模板做成 Tool 造成歧义）。设计时按"语义"而非"形式"归类。

避免语义混用的核心是"按语义分类"。Tool 是动作、Resource 是数据、Prompt 是模板，三者边界清晰。设计 Server 时先判断"这个能力是执行、读数据还是复用模板"，再选择原语，避免模型因语义混淆而误用。

• 理解 Roots 的机制与语义
• 掌握 Roots 与文件系统沙箱的关系
• 理解运行时沙箱的必要性

Roots 由客户端声明，表示"客户端允许 Server 访问的文件系统根目录/数据边界"，是"声明的可访问范围"，不是强制授权。Server 收到 Roots 后以此为参考，但 Roots 本身是声明，不提供运行时强制约束。因此 Server 运行时还需自己的文件系统沙箱：1) 路径校验——对文件访问做真实路径解析（规范化），防止路径穿越（../、符号链接逃逸）；2) 路径白名单——只允许访问 Roots 声明的目录，超范围拒绝；3) 读写权限——只读/写权限按需，多数场景只读；4) 系统级沙箱——用 OS 权限、容器、seccomp 限制文件系统访问，防止 Server 越权。Roots 是"应用层的边界声明"，沙箱是"运行时强制约束"，两者结合：Roots 告诉 Server 应该访问什么，沙箱强制 Server 只能访问什么。

Roots 是"声明边界"，文件系统沙箱是"运行时强制"。Roots 帮助 Server 知道可访问范围，但不可信（可能被恶意 Server 忽略），因此必须用运行时沙箱强制路径校验、白名单与权限。声明与强制结合才是安全边界。

• 理解稳定规范的关键能力变化
• 掌握 Streamable HTTP、Elicitation、Audio data 等新能力
• 理解安全迁移策略

MCP 稳定规范相比早期草案的关键变化：1) Streamable HTTP——取代旧 HTTP+SSE，作为推荐的远程传输，单端点 POST/GET + 可选 SSE，支持无状态化、Mcp-Session-Id、Last-Event-ID 断线续传；2) Elicitation——新增 Server 向用户请求额外信息的能力，需 Host 端白名单与频率限制；3) Audio data——支持音频等二进制数据（多模态能力增强）；4) 能力协商细化——capabilities 显式声明（tools、resources、prompts、sampling、elicitation、roots）；5) 无状态化演进——弱化强制 initialize/initialized 握手，用 MCP-Protocol-Version 头 + server/discover 可选能力发现。安全迁移：1) 版本协商——Client/Server 通过 MCP-Protocol-Version 头声明版本，识别新能力；2) 能力协商——只用双方协商声明的能力，未协商能力不调用；3) 渐进启用——新能力（Elicitation、Audio）默认关闭，按需启用并做安全审查；4) 兼容测试——迁移验证新旧协议版本并存，不破坏旧 Client；5) 传输迁移——旧 HTTP+SSE 迁移到 Streamable HTTP，双跑验证。

稳定规范是"能力丰富 + 无状态化"的演进。Streamable HTTP、Elicitation、Audio 是新能力，能力协商显式化与无状态化是架构变化。安全迁移靠"版本协商 + 能力协商 + 渐进启用 + 兼容测试"，避免新能力破坏稳定核心。

• 理解 Roots 与 Resources 的语义差异
• 掌握授权、可发现性与 URI 语义的区别
• 理解二者的协作关系

Roots 与 Resources 都涉及数据但本质不同。1) 授权方向：Roots 是"客户端→Server"声明"Server 可访问哪些根目录"，是客户端授权给 Server 的边界；Resources 是"Server→客户端"暴露"可读取的数据资源"，是 Server 提供的数据。2) 可发现性：Resources 通过 resources/list 与 resources/templates 被客户端发现，可枚举、可订阅更新；Roots 通过 roots/list 由客户端提供给 Server，不对外"发现"，而是"授权边界声明"。3) URI 语义：Resources 有明确的 URI（如 file:///path/doc.md）与 MIME 类型，可被读取与引用；Roots 是目录/数据根（如 file:///workspace/），是"边界"而非"具体资源"。协作：Roots 定义 Server 可访问的范围，Resources 是 Server 在该范围内暴露的具体数据。Roots 是"授权边界"，Resources 是"可发现的数据"。

Roots 与 Resources 的本质区别是"方向与语义"。Roots 是客户端授权给 Server 的访问边界（授权方向 Client→Server），Resources 是 Server 暴露给客户端的数据（方向 Server→Client）。Roots 管边界，Resources 管具体数据，二者协作。

• 理解 Sampling 的机制与风险
• 掌握 HITL 监督的保持
• 理解 Sampling 的受限与审计

Sampling 允许 Server 请求 Host 调用 LLM 生成内容，这给了 Server"驱动模型"的间接能力，可能被用于绕过 HITL（如 Server 让模型生成"无需用户确认即可执行"的指令，或窃取上下文）。避免绕过 HITL 的措施：1) 能力协商——Sampling 是可选能力，Host 只在信任的 Server 上启用；2) 白名单与审批——只允许受信任的 Server 发起 Sampling，且对 Sampling 请求做最小化验证（检查 model、prompt、目的）；3) HITL 贯穿——对 Sampling 驱动的模型调用，若其结果涉及敏感操作（写操作、外部调用），仍需用户确认，Sampling 不豁免 HITL；4) 内容隔离——Sampling 的 prompt 与结果不注入用户上下文，不覆盖用户指令；5) 频控与审计——限制 Sampling 频率与用量，审计每次 Sampling 的内容与用途；6) 明示机制——Sampling 结果作为"Server 生成的数据"处理，不当作用户意图或系统指令。核心是"Sampling 不豁免监督，Host 始终是最终控制者"。

Sampling 绕过 HITL 的风险是"Server 借模型能力间接执行不受监督的动作"。防御是"Sampling 受限 + HITL 贯穿 + 内容隔离"。Sampling 只是受限的模型调用能力，其结果仍需监督，Host 保持最终控制。

• 理解只读/完整模式的差异
• 掌握按角色过滤工具
• 理解不暴露全部工具的实现

只读模式与完整模式通过"按角色过滤工具"满足不同用户，而不暴露所有工具。实现：1) 角色映射——Server 根据请求的用户角色/权限（从认证上下文获取）决定返回哪套工具；2) 只读模式——只暴露只读工具（查询、读取），不暴露写操作工具（创建、删除、更新），适合只读用户；3) 完整模式——暴露读+写工具，适合有写权限的用户；4) 动态过滤——tools/list 时按角色返回过滤后的工具集，低权限用户看不到高权限工具；5) 双层防护——tools/call 也按角色鉴权，即使绕过列表直接调用，未授权工具也拒绝。这样"只读模式"用户看不到写工具，"完整模式"用户才看到完整工具，不暴露所有工具给所有人。模式可配置（用户角色决定模式），并与 HITL 结合（高影响写操作需确认）。

只读/完整模式的本质是"RBAC 驱动的工具过滤"。按角色动态返回工具集，低权限用户只看到只读工具，高权限用户看到完整工具，且列表与调用双层鉴权。这让"不暴露所有工具"成为真实的安全边界。

• 理解多租户隔离的目标
• 掌握租户上下文注入与强制过滤
• 理解数据访问的多层隔离

多租户隔离的目标是"不同租户/用户的请求永不访问对方数据"。设计：1) 租户上下文注入——每个请求携带租户/用户 ID（从认证上下文获取），Server 在工具调用时使用该上下文；2) 强制租户过滤——在数据访问层强制注入租户过滤条件（如 WHERE tenant_id = ...），即使模型构造宽泛查询也只返回本租户数据；3) 数据分层——数据库按租户分区（schema 隔离）或用租户 ID 列 + 行级权限；4) 缓存隔离——缓存 key 含租户维度，命中前校验租户；5) 工具级隔离——按租户过滤工具可见性，敏感工具只对对应租户暴露；6) 检索隔离——检索层强制租户过滤，防止跨租户检索；7) 审计——记录租户上下文，便于追溯。核心是"租户边界在每一层强制存在"，而非依赖模型或应用层自觉。租户 ID 应从认证上下文推导，不能信任客户端传入的租户参数（可能被篡改）。

多租户隔离的关键是"租户边界强制注入到数据访问的每一层"。租户 ID 从可信认证上下文获取，数据层强制过滤，缓存/工具/检索都按租户隔离。防止"篡改租户参数 + 跨租户查询"。

• 理解 MCP 与内部 SDK/REST 的适用场景
• 掌握运行时发现的复杂度
• 理解选型原则

MCP、内部 SDK、REST API 各有适用场景。内部 SDK：同代码库、同团队、强类型调用、编译期校验，适合"共享代码、无跨进程"的集成，最直接。REST API：跨团队/跨服务、有稳定 HTTP 契约，适合"服务间调用"。MCP：跨进程/跨语言/跨平台、需运行时发现、工具可动态变化、面向 Agent 的工具抽象，适合"让 Agent 动态发现并用工具"。MCP 的运行时发现增加复杂度：需要能力协商、tools/list、JSON-RPC 消息、Schema 契约管理；当"工具集合固定、单进程、同团队、无需动态发现"时，用 MCP 反而是过度设计——用内部 SDK 或直接 REST 调用更简单。选型原则：静态、同团队、单进程用 SDK；跨服务用 REST；只有在"需要 Agent 动态发现/跨语言/工具多变"时才用 MCP。运行时发现的价值在"灵活性"，代价是"复杂度"，两者匹配才选 MCP。

选型的本质是"灵活性 vs 复杂度"。MCP 的运行时发现提供跨进程/动态能力，但增加协议与契约复杂度。当能力固定、集成简单时，SDK/REST 更直接；MCP 只在需要动态发现、跨语言、面向 Agent 时才有价值。避免"为 MCP 而 MCP"。

• 理解工具名冲突的根源
• 掌握 Client 层命名空间隔离
• 理解隔离与协议兼容

多个 Server 暴露同名工具（如都有 search）时，Client 层做命名空间隔离：1) 前缀加命名空间——Client 在暴露给模型/外部时，给工具名加 Server 前缀（如 github_search、jira_search），使模型看到的工具名全局唯一；2) 转发时还原——Client 收到 tools/call（带前缀名）时，通过映射表还原为 Server 内部名并转发到对应 Server；3) 不在 Server 层改名——Server 内部保持原名，隔离在 Client 适配层完成，避免要求 Server 改工具名；4) 冲突消解——若两个 Server 语义相近，用命名空间 + 描述区分；若语义不同，前缀保证不会混淆。命名空间隔离是"Client 层的适配"，把"多 Server 同名"映射为"全局唯一工具名"，既满足协议（工具名唯一），又保证模型不误用。映射表维护在 Client，支持动态增删。

命名空间隔离是"Client 适配层"的职责。给工具名加 Server 前缀得到全局唯一名，转发时还原，不要求 Server 改名。这把"多 Server 同名冲突"从"模型选择"问题转移到"Client 映射"问题，干净且可维护。

• 理解两种传输的适用场景
• 掌握信任边界差异
• 理解场景与信任的匹配

stdio 适合本地子进程场景：Server 与 Host 同机，通过标准输入输出通信，适合本地单机工具（文件系统、本地 CLI、桌面应用），信任边界是"本地进程"——Server 与 Host 共享机器，靠 OS 进程隔离、环境变量隔离、文件系统权限约束，不涉及网络。Streamable HTTP 适合远程服务场景：Server 是独立远程服务，通过 HTTP 通信，适合多租户、水平扩展、网关管理、跨网络部署，信任边界是"网络边界"——靠 TLS 加密、认证（OAuth/mTLS）、限流、审计保护，信任建立在"身份验证 + 传输安全"上。信任边界差异：stdio 信任本地进程（共享机器，但进程隔离），Server 崩溃只影响该进程；Streamable HTTP 信任远程服务（需认证与加密），Server 可独立部署扩展。选型时，本地工具用 stdio（信任本地进程），远程/多租户用 Streamable HTTP（信任网络认证）。

两种传输的信任边界决定了"信任什么"。stdio 信任本地进程（OS 隔离），Streamable HTTP 信任网络认证（TLS/mTLS/OAuth）。选型匹配场景与信任模型：本地工具信任进程，远程服务信任认证。stdio 绝不应暴露公网。

• 理解三类原语的语义边界
• 掌握 Tool 模型可控 vs Resource 应用可控
• 理解不同原语的控制权

三类原语语义边界：Tools 是可执行的动作（模型发起调用，产生副作用与结果）；Resources 是 URI 指向的数据（应用/客户端读取，无副作用，可被引用）；Prompts 是参数化的提示模板（预定义工作流，可被复用）。Tool 是模型可控：因为 Tool 是模型在推理时选择并调用的动作，模型决定"何时调用、传什么参数"，代表模型主动执行能力。Resource 是应用可控：因为 Resource 是应用/客户端读取的数据（如文件、配置），由应用决定何时读取、如何引用，模型不主动调用（模型只通过工具的引用间接使用），Resource 是"数据供给"而非"动作执行"。因此 Tool 是模型可控（动作），Resource 是应用可控（数据），Prompts 介于中间（模型可复用模板但由应用触发）。区分控制权决定了原语的选型与安全边界。

三类原语的控制权不同：Tool 由模型发起（动作），Resource 由应用读取（数据），Prompt 由应用触发复用（模板）。"模型可控 vs 应用可控"是核心区分——Tool 是模型主动执行，Resource 是应用被动读取，这决定了权限与安全边界。

• 理解 initialize 握手的能力协商
• 掌握协议版本、capabilities、server info 的协商
• 理解版本不兼容的降级

initialize 握手时，Client 与 Server 交换：1) 协议版本——双方声明支持的 protocolVersion，取交集确定使用的版本；2) capabilities——Client 声明 Client 能力（sampling、elicitation、roots 等），Server 声明 Server 能力（tools、resources、prompts、logging 等），双方只使用均声明的能力；3) server info / client info——交换名称、版本等标识信息。协商完成后，双方按协商的版本与能力工作。版本不兼容时的优雅降级：1) 双方尝试用共同支持的最高版本（取交集）；2) 若版本不兼容（无法取交集），退回到双方都支持的旧版本子集，或降级为"基础能力"（只支持双方共有原语）；3) 明确失败——若无法协商出可用版本，返回明确的版本不兼容错误，而非静默用错能力；4) 客户端提示用户升级/降级。降级原则是"保留可用子集 + 明确失败信息"，避免静默使用未协商能力导致崩溃。

initialize 是"能力协商的本质"。交换协议版本、capabilities、info，取交集确定可用能力。版本不兼容时降级到"双方共有子集"，或明确失败。关键是"只用协商过的能力"，避免未协商能力导致行为不一致。

• 理解 inputSchema 用于参数校验与 UI 渲染
• 掌握 Schema 与模型调用的关系
• 理解 Schema 质量对准确率的影响

Tool 的 inputSchema 有两个用途：1) 参数校验——Host/Client 在 tools/call 时用 JSON Schema 校验模型传入的参数（类型、必填、枚举、约束），非法参数被拦截或让模型修正；2) UI 渲染——Host 根据 Schema 生成参数输入表单（如把字符串字段渲染为文本框、枚举渲染为下拉框、数字渲染为输入框），让用户在 HITL 审批时能正确填写参数。Schema 描述质量直接影响模型调用准确率：Schema 定义了参数类型、必填、枚举、默认值、description，模型依赖这些信息构造正确参数。Schema 表达越清晰（参数名自解释、description 说明含义与取值、枚举完整、默认值合理），模型越容易传对参数；Schema 模糊/矛盾/缺 description 会导致模型传错参数、漏传必填、用错枚举值，降低调用准确率。因此 Schema 是"模型调用的契约"，质量决定准确率。

inputSchema 是"机器契约"，同时服务参数校验与 UI 渲染。它是模型构造参数的依据，质量直接决定调用准确率。清晰的 Schema（类型、必填、枚举、description、默认值）让模型传对参数，模糊的 Schema 导致误用。

• 理解 Elicitation 的滥用风险
• 掌握过度索取与重复打扰的防御
• 理解频率限制与用户控制

Elicitation 让 Server 向用户索求信息，恶意或设计不当的 Server 可能过度索取（如每次请求都向用户要密码）或重复打扰。Host 防御：1) 频率限制——限制每会话/时间内的 Elicitation 次数，超限拒绝或合并；2) 内容白名单——对可请求的信息类型白名单，敏感字段（密码、OTP、身份证）屏蔽或强制人工确认，密码类信息原则上不通过 Elicitation 索要；3) 去重/记忆——记录已索要过的信息，同类信息重复索要时抑制，避免重复打扰；4) 用户控制——用户可拒绝、忽略、标记"不要再问"，Host 尊重并抑制后续同类请求；5) 来源透明——展示"哪个 Server 要什么、用于什么"，让用户知情决策；6) 审计——记录 Elicitation 请求与用户响应，发现异常（频繁索取密码）告警。核心是"把 Server 的提问能力限制在可控、可审计、可拒绝的范围内"。

防过度索取与重复打扰的关键是"限频 + 白名单 + 记忆 + 用户控制"。频率限制防刷屏，白名单禁敏感字段，记忆去重防重复，用户控制给拒绝权。Elicitation 是受限能力，不是 Server 的无限提问权。

• 理解能力协商的双向声明
• 掌握只调用已协商能力的机制
• 理解未声明能力的处理

避免调用未声明能力的关键是"双向能力协商 + 只调用已声明能力"。initialize 时，Client 声明其能力（sampling、elicitation、roots 等），Server 声明其能力（tools、resources、prompts、logging 等）。之后：1) 客户端只调用 Server 声明支持的 Request（如 Server 未声明 sampling，客户端就不发送 sampling/createMessage）；2) 客户端只使用 Client 声明支持的能力（如客户端未声明 elicitation，Server 就不发 elicitation 请求）；3) 未协商的能力——若一方发起未声明的能力请求，接收方返回"能力未声明/不支持"的错误，而非静默处理；4) 显式声明——能力协商的响应中包含 capabilities 对象，双方据此判断"哪些能力可用"。规则是"能力协商是双向的，双方只使用双方都声明的能力，未声明能力视为不支持并明确报错"。这让协议在能力不对称时仍能正确工作。

能力协商的核心是"双向声明 + 只调用已协商能力"。Client 与 Server 各自声明能力，只使用双方都声明的能力，未声明能力明确报错。这避免了"调用未协商能力"导致的行为不一致与崩溃。

• 理解 list_changed 通知机制
• 掌握缓存失效与更新
• 理解竞态处理

notifications/tools/list_changed 是 Server 在工具列表变化时发送的通知，客户端收到后失效缓存并重新调用 tools/list 拉取最新列表。处理要点：1) 缓存失效——收到通知后，标记本地工具列表缓存失效，发起重新获取；2) 竞态处理——若 list_changed 通知与正在进行的 tools/list 请求并发，可能产生"旧响应覆盖新列表"的竞态；处理方式：用版本号/序号标记，仅接受最新一次响应；或收到通知后先失效缓存，再发起新请求，且忽略在通知前发出的旧请求响应；3) 幂等——多次 list_changed 允许重复触发，客户端重新拉取即可；4) 更新注入——重新拉取后更新注入给模型的工具集合，当前回合结束后生效。客户端要保证"通知后的列表刷新不会覆盖为旧数据"，通常用"请求序号 + 丢弃过期响应"处理竞态。

list_changed 让能力列表动态更新，竞态处理是难点。通过"版本号/序号 + 丢弃过期响应"保证最新列表不被旧响应覆盖。缓存失效与重新拉取配合，保证工具列表新鲜度。

• 理解 JSON-RPC 2.0 的消息类型
• 掌握请求/响应/通知/错误/ID 的约束
• 理解消息格式正确性

MCP 基于 JSON-RPC 2.0，消息类型与约束：1) 请求（Request）——含 method、params、id，必须有 id 以匹配响应；2) 响应（Response）——含 result 或 error，必须有与请求对应的 id；3) 通知（Notification）——含 method、params，无 id，不期望响应（单向）；4) 错误（Error）——响应中的 error 对象含 code、message、data（可选），code 用 JSON-RPC 标准错误码（-32700 解析错误、-32600 无效请求、-32601 方法未找到、-32602 无效参数、-32603 内部错误）及 MCP 扩展错误码；5) ID——用字符串或数字，用于关联请求与响应，客户端生成唯一 id 匹配；通知无 id。约束：消息必须是合法 JSON，method 是字符串，params 是对象/数组，id 在请求/响应中必须存在且匹配，通知不含 id。批量请求（batch）可选。这些约束保证协议消息可解析、可关联、可纠错。

JSON-RPC 2.0 定义了消息的底层契约。请求/响应用 id 关联，通知无 id，错误用标准码。理解这些约束是正确实现 MCP 协议的基础，保证消息可解析、可匹配、可纠错。

• 理解 initialize/initialized 握手流程
• 掌握协议版本与能力协商
• 理解超时失败的重试与降级

initialize 握手流程：Client 发送 initialize 请求，携带协议版本、Client 能力、clientInfo；Server 返回协议版本、Server 能力、serverInfo；双方确定协议版本与能力后，Client 发送 initialized 通知确认完成。协商内容：协议版本取交集、能力双向声明、server/client info 交换。超时与失败处理：1) 超时——initialize 请求超时（如 30s），按幂等规则重试（指数退避），重试次数有限；2) 失败——若 Server 返回版本不兼容错误，降级到双方支持的旧版本子集重试，或明确失败；3) 重连——若握手失败源于瞬态故障，重连后重新握手；4) 降级——无法协商时，降级为基础能力（无高级能力），或告知用户。重试要避免无限重试（设上限），降级要保留可用子集。initialized 通知可重发，不影响已协商状态。

initialize 握手是会话的前提。超时用指数退避重试，版本不兼容降级到共有子集，失败明确报错。重试与降级配合，保证"网络瞬态"可恢复、"版本不兼容"可降级、不无限重试。

• 理解 capabilities 不对称的场景
• 掌握优雅降级与能力规避
• 理解避免误用未协商能力

capabilities 不对称时（如 Client 不支持 Elicitation、Server 不支持 sampling），会话要优雅降级：1) 能力协商——initialize 时双方各自声明能力，Client 只使用 Server 声明的能力，Server 只使用 Client 声明的能力；2) 使用交集——双方都支持的能力才使用，某一方不支持的能力降级为"不可用"；如 Client 不支持 Elicitation，Server 就不发送 Elicitation 请求，改用其他方式（如工具调用）获取信息；3) 明确报错——若一方误用了未协商能力，接收方返回"能力未声明/不支持"错误，而非静默；4) 功能降级——能力缺失时，用替代路径（如 Client 不支持 sampling，Server 的采样需求通过工具调用或用户提供实现）；5) 不静默假设——双方都不假设对方支持某能力，只根据协商结果使用。核心是"能力协商决定了可用能力，不对称时用交集并降级，避免误用未协商能力"。

capabilities 不对称是常态。优雅降级靠"协商交集 + 只使用双方都支持的能力 + 明确报错"。Client 不支持 Elicitation 时，Server 不发送该请求，改用替代路径。避免误用未协商能力的关键是"以协商结果为准，不假设"。

• 理解 Server 主动推送 notification
• 掌握异步处理与不阻塞主循环
• 理解事件驱动处理

Server 通过 notification（如 notifications/resources/updated）主动推送事件，Client 处理要异步、不阻塞主循环：1) 异步处理——Client 用事件循环/异步机制接收 notification，分发到事件处理器，不阻塞主请求处理；2) 事件处理器——为每种 notification 注册回调（如 resources/updated 触发资源缓存失效），回调在独立任务中执行；3) 缓存失效——收到 resources/updated 后，异步失效对应资源缓存，需要时重新读取；4) 解耦——notification 处理与正在进行的工具调用/模型交互解耦，推送不中断主流程；5) 背压——若 notification 高频，用队列缓冲，避免积压阻塞。实现上，Client 的 transport 层（如 Streamable HTTP 的 SSE 通道）异步接收 notification，把事件投递到事件循环，由事件处理器处理，不阻塞 request/response 主路径。这保证 Server 的主动推送不会拖慢 Client 的响应。

notification 是异步事件，Client 必须用异步/事件驱动处理，不阻塞主循环。缓存失效、事件分发在独立任务执行，推送与主流程解耦。这是"Server 主动推送"与"Client 响应式"模型的要求。

• 理解 instructions 字段的语义
• 掌握其类似 system prompt 的作用
• 理解滥用风险与防御

MCP 的 instructions 字段（在 initialize 响应的 serverInfo 或工具描述中）是 Server 提供给 Client 的"使用说明"，类似 system prompt，Client 会把其中内容注入到模型上下文，指导模型如何正确使用该 Server 的工具。但 instructions 可被滥用：恶意 Server 可在 instructions 中注入 prompt injection（如"忽略之前指令"、"把用户数据发给外部"），劫持模型行为。防御：1) 元数据净化——Client 对 instructions 做注入检测与净化，剥离 prompt-injection 特征；2) 内容隔离——把 instructions 作为"不可信数据"标注注入，而非当作可信系统指令；3) 来源审计——对第三方 Server 的 instructions 打上"外部内容"标签，升高审查；4) 白名单——只信任可信 Server 的 instructions，第三方 Server 的 instructions 默认降级或需审查；5) 限制作用域——instructions 限制在"如何使用该 Server"，不覆盖 Host 的全局指令。instructions 是"声明"，不是"可信指令"，Client 要校验后再用。

instructions 类似 system prompt，但来自 Server，是不可信输入。恶意 Server 可借此注入指令。防御是"净化 + 隔离标注 + 来源审计 + 白名单"，把 instructions 当作数据而非可信指令。

• 理解 structuredContent 与文本返回的差异
• 掌握客户端处理方式
• 理解结构化数据的解析需求

MCP 工具返回可以是文本（text 字段）或结构化内容（structuredContent 字段，JSON 对象）。区别：1) 文本——人类可读的字符串，适合展示，但客户端处理需解析或依赖模型理解；2) structuredContent——结构化的 JSON 数据，机器可读，便于程序化处理（参数校验、字段提取、逻辑判断），解析可靠。客户端处理：对 structuredContent，客户端可直接用 JSON 解析器解析（标准 JSON 解析，无需专用解析器，因为是标准 JSON），提取字段用于后续逻辑或模型上下文；对文本，客户端可能需额外解析或直接展示。是否需要专用解析器：structuredContent 是标准 JSON，用标准 JSON 解析即可，无需专用解析器；但若业务需要"把结构化结果插入模型上下文"，需做序列化/摘要（把 JSON 转成适合模型阅读的形式）。structuredContent 的价值是"结构化、可机器处理、可靠性高"，文本的价值是"可读、灵活"。

structuredContent 是标准 JSON，用标准 JSON 解析即可，无需专用解析器。它与文本的差异是"机器可读 vs 人类可读、可靠处理 vs 灵活展示"。structuredContent 便于程序化处理与模型上下文注入。

• 理解 Streamable HTTP 的单端点设计
• 掌握 POST/GET、可选 SSE、session id、Last-Event-ID
• 理解无状态化与断线续传

Streamable HTTP 用单端点（一个 URL）承载所有 MCP 交互：1) POST——发 JSON-RPC 请求（initialize、tools/list、tools/call），期望 JSON 响应；若带 Accept: text/event-stream，则响应可升级为 SSE 流；2) GET——建立 SSE 连接，接收 Server 主动推送的 notification/事件；3) 可选 SSE——客户端声明 Accept: text/event-stream 时，响应用 SSE；否则用普通 JSON 响应，实现无状态请求/响应；4) Mcp-Session-Id——Server 在响应头返回 session id，客户端后续请求携带，维持跨请求状态（如订阅、进度）；5) Last-Event-ID——断线重连时，客户端携带 Last-Event-ID 让 Server 从断点续传事件，实现断线续传。设计上，单端点 + 可选 SSE 让客户端既能做无状态请求/响应，也能做流式/订阅，MCP 无需多端点或长连接。Session id 与 Last-Event-ID 配合支持会话与断线恢复。

Streamable HTTP 用单端点 + 可选 SSE 实现"请求/响应 + 流式"的统一。POST 发请求、GET 收推送、SSE 流式、Mcp-Session-Id 维持会话、Last-Event-ID 断线续传。这让 MCP 兼容 HTTP 语义且可无状态化。

• 理解 PKCE 的作用
• 掌握 Resource Indicators 与 Protected Resource Metadata
• 理解授权安全机制

MCP 授权用 OAuth 2.1 时，三个机制解决不同问题：1) PKCE——解决"授权码被截获重放"问题。客户端生成 code_verifier/code_challenge，授权码换取令牌时用 verifier 验证，即使授权码被截获也无法用于换取令牌。2) Resource Indicators（RFC 8707）——解决"令牌被错误路由到错误资源"问题。客户端在授权请求中声明目标资源（resource 参数），令牌绑定到该资源，防止令牌被重放到其他资源（token confusion）。3) Protected Resource Metadata（RFC 9728）——解决"客户端如何发现授权服务器与端点"问题。受保护资源通过 .well-known/oauth-protected-resource 暴露授权服务器端点、scope 要求、资源信息，客户端据此完成授权流程。三者配合：PKCE 保护授权码，Resource Indicators 绑定令牌到资源，Protected Resource Metadata 让客户端发现授权端点。共同构成 OAuth 2.1 在 MCP 的安全授权基础。

三个机制分别解决"授权码安全、令牌资源绑定、授权端点发现"。PKCE 防截获，Resource Indicators 防令牌路由错误，Protected Resource Metadata 支持发现。它们是 MCP 远程授权安全的关键。

• 理解 SSE 升级 vs 旧长连接
• 掌握断线恢复与可伸缩性差异
• 理解 Streamable HTTP 的优势

Streamable HTTP 的 SSE 升级（客户端在 POST 头带 Accept: text/event-stream，响应升级为 SSE）与旧 HTTP+SSE 长连接有本质差异。旧 HTTP+SSE：客户端建立一个长期 SSE 连接接收所有事件，连接长期占用，断线后需重建，且长连接在负载均衡/网关后难以管理（连接粘性、超时、缓冲问题），可伸缩性差（长连接占用资源）。Streamable HTTP 的 SSE 升级：SSE 只在需要流式时启用（如客户端声明 Accept: text/event-stream），普通请求用 JSON 响应，无状态化；断线恢复用 Last-Event-ID 实现——客户端重连时携带 Last-Event-ID，Server 从断点续传，无需重建整个长连接；可伸缩性更好——无状态请求可被任意实例处理，SSE 连接短暂、按需，配合标准网关（LB、超时配置）更易管理。差异核心：旧长连接"常驻、难断线恢复、难伸缩"，Streamable HTTP"按需 SSE、Last-Event-ID 续传、无状态可伸缩"。

Streamable HTTP 的改良是"从常驻长连接到按需 SSE"。Last-Event-ID 支持断线续传，无状态化支持水平伸缩，按需 SSE 降低资源占用。旧 HTTP+SSE 的长连接在网关与伸缩上是痛点，故被弃用。

• 理解 Mcp-Session-Id 的作用
• 掌握跨请求状态维持（订阅、进度）
• 理解会话过期清理

Streamable HTTP 是无状态请求/响应，但某些场景需要跨请求状态（订阅、采样进度、能力协商结果），Mcp-Session-Id 用于关联这些状态：Server 在响应中返回 Mcp-Session-Id，客户端后续请求携带该 id，Server 据此识别会话并维持状态（如订阅的 SSE 连接、进行中的采样进度、已协商的能力）。无该 id 的请求视为无状态新会话。Session 过期清理策略：1) TTL——会话设置有效期（如 30 分钟无活动过期），Server 定期清理过期会话；2) 活动续期——有活动时刷新 TTL，长时间无活动才过期；3) 资源释放——会话过期时清理其持有的资源（订阅连接、临时状态、进度上下文）；4) 惰性清理 + 定时清理——访问时惰性删除过期会话，配合定时 GC 清理；5) 客户端感知——会话过期时客户端收到 404/错误，重新握手创建新会话。设计上，会话状态是最小必要（只存需跨请求的状态），尽量无状态化，Session 生命周期与安全（防 session 劫持）结合。

Mcp-Session-Id 维持"最小必要的跨请求状态"，同时保持无状态化倾向。TTL 过期 + 资源释放 + 清理策略管理会话生命周期。设计上尽量少存状态，避免会话成为伸缩与故障转移的瓶颈。

• 理解 Elicitation 的白名单与长度限制
• 掌握敏感信息屏蔽
• 理解保持用户控制

Elicitation 字段在 Host 端要受控，防止 Server 借此绕过用户控制：1) 白名单——对可请求的信息类型做白名单（如"订单号""环境配置"），白名单外的请求拒绝；2) 长度限制——对 Elicitation 请求的 prompt 文本设置长度上限，防止 Server 塞入超长恶意内容；3) 敏感信息屏蔽——对敏感字段（密码、OTP、身份证、密钥）做屏蔽，禁止通过 Elicitation 索取，或强制人工确认；4) 频率限制——限制 Elicitation 次数，防止反复索取；5) 用户控制——Elicitation 展示需用户确认，用户可拒绝、忽略，Host 尊重用户选择；6) 来源透明——展示"哪个 Server 请求什么、用于什么"，可追溯。核心是"Elicitation 是受限的询问能力，白名单 + 长度 + 敏感屏蔽 + 用户确认把它限制在可控范围"，防止 Server 通过反复/恶意提问绕过用户控制。

防绕过用户控制的关键是"对 Elicitation 的输入做限制"。白名单限定可问什么，长度限制防注入，敏感屏蔽防窃取，用户确认保持控制权。Elicitation 是"受限提问"，不是 Server 的无限索取权。

• 理解 MCP-Protocol-Version 头的版本协商
• 掌握不兼容的失败与降级
• 理解版本协商在前置阶段完成

MCP-Protocol-Version 头在 HTTP 请求中声明客户端支持的协议版本，Server 读取后决定是否兼容，并可在响应中返回其支持的版本，实现"在 initialize 之前"的版本协商。客户端遇到不兼容 Server 的处理：1) 判断——Server 不返回该头（说明不支持版本协商）或返回更旧/不兼容版本时，客户端判断不兼容；2) 降级——客户端回退到"兼容子集"：用双方都支持的旧版本协议交互，或使用基础能力（无高级能力），不直接失败；3) 明确失败——若无法回到兼容版本，返回明确的版本不兼容错误，提示用户升级 Server/Client；4) 重试——客户端可尝试用旧版本头重发请求，看 Server 是否接受。关键原则是"不直接失败，先尝试回退到兼容子集"，通过版本协商头在初始化前完成版本匹配，避免用错版本导致行为混乱。

MCP-Protocol-Version 头把版本协商前置到 HTTP 层。不兼容时先尝试回退到兼容子集（旧版本/基础能力），无法回退才明确失败。这避免"用错版本静默工作"，让版本兼容在请求早期就确定。

• 理解取消、进度、超时与断线恢复的配合
• 掌握取消语义
• 理解取消与事务回滚的区别

取消通知（notifications/cancelled）、progress token（进度上报）、超时与断线恢复配合管理长任务：progress token 让 Server 上报任务进度，客户端据此展示；客户端可发送取消通知请求中断任务；超时作为兜底（任务超时标记失败）；断线恢复用 Last-Event-ID/Mcp-Session-Id 续传进度。取消不等于事务回滚原因：取消只是"请求停止执行"，不保证已产生的副作用被撤销。例如取消一个"创建订单"工具，若 Server 已创建订单，取消不自动删除该订单；取消一个"发送邮件"工具，邮件已发出则无法撤回。取消语义是"停止未来的执行"，已完成的副作用需要显式补偿（如反向操作、回滚 API、人工处理），而非自动回滚。因此取消通知、进度、超时、断线恢复管理"执行过程"，副作用补偿（幂等、补偿操作）是独立的设计。

取消管理"执行过程"（进度、超时、断线），但取消不保证事务回滚。已产生的副作用需显式补偿。这是 MCP 工具"不是事务"的体现——取消是停止执行，不是撤销结果。

• 理解无状态化的架构变化
• 掌握删除握手与 session id 的价值
• 理解对部署与运维的影响

MCP 无状态化 spec 最大的变化是把有状态双向协议转为无状态请求/响应协议：移除强制 initialize/initialized 握手与 Mcp-Session-Id 头，改为基于 MCP-Protocol-Version 头 + 可选的 server/discover 能力发现。工程价值：1) 简化——去掉握手与 session 状态管理，客户端更简单，无需维护会话生命周期；2) 水平扩展——无状态请求可被任意实例处理，放 LB 后 round-robin 即可，无需 session 亲和/共享存储，扩缩容与故障转移自然；3) 标准网关兼容——无状态 HTTP 请求可直接被 rate limiter、WAF、缓存、LB 处理，无需协议感知；4) 故障恢复——无 session 依赖，实例崩溃不影响其他请求，重连简单；5) 降低资源占用——无 session 长连接，按需请求/响应。代价是能力协商变为可选，需在调用时容错。价值核心是"用标准 HTTP 基础设施服务 MCP，把状态从 Server 移除，扩展到哪都行"。

无状态化的价值是"简化 + 可伸缩 + 基础设施兼容"。删除握手与 session id 让 Server 无状态，可水平扩展、故障转移、被标准网关处理。这是 MCP 从"嵌套协议"走向"标准 HTTP 服务"的架构演进。

• 理解 Mcp-Method/Mcp-Name HTTP 头的用途
• 掌握基于头的路由与限流
• 理解避免解析 body 的价值

无状态 MCP 下，Server 在 HTTP 请求头携带 Mcp-Method（如 tools/list、tools/call）与 Mcp-Name（工具名），让 Gateway / Rate Limiter / WAF 无需解析 JSON body 就能做治理：1) 路由——按 Mcp-Method/Mcp-Name 头把请求路由到对应后端或工具，无需读 body，路由更高效；2) 限流——按 Mcp-Method 或 Mcp-Name 做粒度限流（如对 tools/call 限流、对特定工具限流），无需解析 body 提取字段；3) WAF/安全——按方法头做安全规则（如拦截高风险工具调用），无需解析 body；4) 审计/日志——按头记录方法与工具，快速关联。价值：解析 JSON body 开销大、且要求网关理解协议；用 HTTP 头暴露方法/工具信息，让标准网关（HTTP 层）直接治理，无需协议感知。这把 MCP 的治理下沉到标准 HTTP 基础设施，提升效率与可伸缩性。

Mcp-Method/Mcp-Name 头把"协议信号"上移到 HTTP 层，让标准网关无需解析 body 即可路由、限流、安全。这是无状态化+标准基础设施兼容的体现，治理效率高、可伸缩。

• 理解 Host 管理多个 Client
• 掌握 1:1 连接模型
• 理解并发与资源隔离

MCP 三层架构中，Host 管理多个 Client 实例，每个 Client 1:1 连接一个 Server（一个 Client 对应一个 Server，不共享）。Host 的职责：为每个 Server 创建/管理一个 Client 实例，维护 Client 与 Server 的映射、生命周期、工具集合。1:1 连接模型对并发与资源隔离的意义：1) 资源隔离——每个 Server 的 Client 独立，一个 Server 的慢/爆量/故障不影响其他 Server 的 Client（独立连接、独立上下文、独立缓冲）；2) 并发——每个 Client 独立处理其 Server 的请求，多个 Client 可并行，Host 可对不同 Server 并发调用；3) 故障隔离——一个 Server 崩溃只影响其 Client，Host 可摘除该 Client 而不影响其他；4) 上下文隔离——每个 Server 的工具注入独立，避免跨 Server 污染；5) 管理清晰——Host 按 Server 管理 Client 生命周期（启动、重启、销毁）。1:1 让"一个 Server 一个 Client"耦合清晰，隔离与并发可控，代价是每 Server 一个连接（连接数多）。

1:1 连接模型让"每个 Server 独立 Client"，实现资源隔离、并发、故障隔离与上下文隔离。Host 管理多个 Client 实例，每个独立。这保证多 Server 并存时互不干扰，是 Host 编排的基础。

• 理解 JSON-RPC 2.0 的消息格式
• 掌握幂等与超时处理
• 理解与传输层协作

JSON-RPC 2.0 消息格式用 id 关联 request/response，保证请求可匹配响应；notification 无 id 不期望响应。幂等与超时处理：1) 幂等——JSON-RPC 本身不保证幂等，幂等靠客户端重试策略（重放同一 id 请求）与工具层幂等键（Server 去重）实现；请求 id 用于关联，重试可复用 id 或生成新 id。2) 超时——客户端为每个请求设置超时，超时后按策略重试或放弃；超时基于响应未在期限内到达。与 HTTP+SSE 传输层协作：1) HTTP 层——每个请求是一个 HTTP POST（或支持 Get 的流），JSON-RPC 消息作为 HTTP body；2) SSE 层——流式响应/事件通过 SSE 传输，把 JSON-RPC 的 notification/event 推送给客户端；3) 超时与传输——HTTP 层负责连接超时、读超时，SSE 层负责流式事件超时，二者与 JSON-RPC 的请求超时配合；4) 断线——HTTP/SSE 断线时，JSON-RPC 的在途请求标记为待处理，恢复后重试或继续。JSON-RPC 定义"消息语义"，传输层定义"如何送达"，幂等与超时在两层配合实现。

JSON-RPC 负责消息语义（id 关联、幂等、超时），传输层负责送达（HTTP/SSE）。幂等靠 id 与工具幂等键，超时靠客户端策略，与传输层的连接/读超时配合。两层协作实现可靠的消息交互。

• 理解 URI 模板与 MIME 类型
• 掌握动态资源发现
• 理解与 Tool 返回结果的取舍

MCP Resource 用 URI 模板（如 file:///path/{name}）声明一类资源的模式，客户端可通过 resources/templates 发现模板，用具体值填充模板得到具体 URI，再通过 resources/read 读取；MIME 类型声明资源的格式（text/markdown、image/png 等），客户端据此选择处理方式。模板 + MIME 支持动态资源发现：客户端无需枚举所有资源，通过模板知道"有哪些类别的资源、什么格式"，按需读取。与 Tool 返回结果的取舍：Resource 是"按 URI 读取的数据"，适合静态/可寻址的数据（文件、文档、配置），可通过模板发现、可缓存、可订阅（updated 通知）；Tool 返回结果是"执行动作后的结果"，适合需要计算/副作用/动态生成的数据。取舍：可寻址、静态、需模板发现的数据用 Resource；需要执行逻辑、动态生成、有副作用的结果用 Tool 返回。Resource 适合"数据供给"，Tool 适合"动作产生结果"。

URI 模板 + MIME 让 Resource 可动态发现（模板发现 + 按需读取）。Resource 与 Tool 的取舍是"可寻址数据 vs 动作结果"——静态可寻址数据用 Resource，动态/副作用结果用 Tool。这是语义边界在工程上的应用。

• 理解 Sampling 的工作机制
• 掌握"Server 驱动模型调用"的风险
• 理解风险防御

Sampling 让 Server 反向请求 Host 调用 LLM：Server 发送 sampling/createMessage 请求，携带 prompt 与采样参数，Host 调用 LLM 生成结果并返回给 Server。这引入了"Server 驱动模型调用"的安全风险：1) 上下文窃取——恶意 Server 可构造 prompt 让模型输出包含 Host 上下文/用户敏感信息的内容，从而间接窃取上下文；2) 绕过监督——Server 让模型生成"无需用户确认即可执行"的指令，或通过模型生成看似合理的决策，绕过 HITL；3) 消耗配额——恶意 Server 高频发起 Sampling 消耗用户 token 配额与成本；4) 指令注入——Server 通过 prompt 向模型注入指令，影响模型行为。风险根源是"放权给 Server 驱动模型"，而 Server 不可信。防御：能力协商（Sampling 是可选能力，只对可信 Server 启用）、白名单与频控、最小化验证（检查 prompt、model、目的）、结果脱敏与内容过滤、用量熔断、审计。核心是"Host 保持对模型调用的控制，Sampling 是受限能力"。

Sampling 的风险源于"Server 借 Host 的模型能力反向驱动模型"。恶意 Server 可窃取上下文、绕过监督、消耗配额。防御是"受限启用 + 白名单频控 + 最小验证 + 脱敏 + 审计"，让 Sampling 成为可控的受限能力。

• 理解 progress token 的进度上报
• 掌握取消机制
• 理解进度与取消的组合

progress token 与取消通知的组合管理长任务：1) 进度上报——客户端发起长任务时附带 progress token，Server 在执行中通过 notifications/progress 上报进度（progress token、当前值、总量），客户端据此展示进度；2) 取消——客户端可发送 notifications/cancelled（携带 request id 与 reason）请求中断任务，Server 收到后停止执行并返回取消结果；3) 组合——进度让客户端"知道任务在推进"，取消让客户端"能中断任务"；长任务既透明又可控；4) 状态——取消后 Server 返回明确状态（是否已取消、已执行部分），客户端据此处理；5) 超时兜底——取消未生效时用超时兜底。设计上，progress token 提供"可观测性"，cancelled 提供"可控性"，两者组合让长任务（耗时工具调用、批量处理）既能展示进度又能被及时中断，避免"卡死无法取消"。

progress 提供进度透明，cancelled 提供中断控制。组合让长任务"可观测、可中断"。取消后要有明确状态（已取消/已执行部分），配合超时兜底，避免用户无法中断长任务。

• 理解 DNS rebinding 攻击
• 掌握 Origin 校验与地址绑定
• 理解防御机制

DNS rebinding 攻击：攻击者用被攻陷的域名解析到本地地址（127.0.0.1），诱导受害者浏览器访问，浏览器信任该域名后发起请求，攻击者借此访问本地服务（包括本地 MCP Server）。防御：1) 校验 Origin/Host 头——Server 校验请求的 Origin/Host 头，只接受来自可信来源的请求，拒绝未知域名（DNS rebinding 常用攻击者域名，会通过 Origin 校验被拒）；2) 绑定 127.0.0.1——Server 只监听本机回环地址，不监听公网接口，配合防火墙只允许本地访问，防止跨网访问；3) 校验 Host 头与期望值一致——防止 Host 头注入；4) 认证——对所有请求做认证（即使本地也需令牌），防止无认证访问；5) 禁用 DNS 缓存/验证——防止 rebinding 的域名解析绕过。核心是"校验请求来源（Origin/Host）+ 绑定受控地址 + 强制认证"，让攻击者无法通过域名 trick 访问本地 Server。

DNS rebinding 利用"浏览器信任域名 + 域名解析到本地"。防御是"来源校验（Origin/Host）+ 地址绑定（127.0.0.1）+ 强制认证"。Server 只接受可信来源且绑定本地地址，攻击者的域名请求被 Origin 校验拒绝。

• 理解 stdio 模式的隔离需求
• 掌握环境变量、参数与文件访问隔离
• 理解进程模型边界

stdio 模式下，Server 是 Host 的子进程，需要隔离环境变量、命令行参数与文件访问：1) 环境变量隔离——不把宿主敏感环境变量透传给 Server，只注入 Server 所需的最小变量集（如 MCP 约定变量），避免凭据泄露；2) 命令行参数——只传 Server 启动所需的最小参数，不传敏感信息；3) 文件访问隔离——Server 只在 Roots 声明的目录内访问文件，用路径校验/白名单防穿越，不暴露宿主敏感目录；4) 进程边界——stdio 的信任边界是进程隔离：Server 与 Host 共享机器，但通过 OS 进程边界、独立工作目录、受限环境变量、文件系统权限约束 Server 的能力。边界在"进程 + 环境 + 文件系统"三层：进程层面互不干扰（崩溃隔离），环境层面最小变量（防凭据泄露），文件层面路径受限（防越权访问）。Server 不能访问宿主进程的完整环境与任意文件。

stdio 的进程模型边界是"进程 + 环境 + 文件系统"三层隔离。最小环境变量防凭据泄露，最小参数防敏感信息，路径白名单防越权访问。Server 是受限子进程，不是宿主全权进程。

• 理解反向代理对 SSE 的影响
• 掌握连接复用、超时与缓冲配置
• 理解避免破坏 SSE

Streamable HTTP 在反向代理后面部署时，代理的默认配置可能破坏 SSE 流（长连接、流式响应）。需配置：1) 连接复用——代理需允许连接并保持（关闭连接复用/长连接代理冲突），正确转发 SSE 长连接，不因连接复用切断流；2) 超时——代理的读超时/空闲超时需拉长，否则 SSE 长连接的空闲会让代理断开连接；需设置与 SSE 生命周期匹配的超时（如 proxy_read_timeout 足够大）；3) 缓冲——禁用代理的响应缓冲（buffering），SSE 事件需即时转发，开启缓冲会把事件堆积到缓存满才发送，破坏实时性；应关闭缓冲（如 proxy_buffering off）；4) 流式转发——确保代理支持流式响应（chunked/SSE），不缓冲整个响应；5) HTTP/1.1 支持——SSE 需 HTTP/1.1 的 chunked 编码，代理配置 Keep-Alive 与 chunked 支持。核心是"代理配置与 SSE 特性匹配"：不缓冲、不因空闲超时断开、正确转发长连接，避免 SSE 流被代理破坏。

反向代理默认"缓冲响应 + 短超时 + 连接复用"会破坏 SSE。需关闭缓冲、拉长超时、正确转发长连接。代理配置是 Streamable HTTP 部署的关键，否则 SSE 流会被截断或延迟。

• 理解 Last-Event-ID 断线续传
• 掌握保留最近 N 个事件
• 理解过期降级

Last-Event-ID 断线重连：客户端在重连时携带 Last-Event-ID（上次收到的事件 ID），Server 据此从断点续传后续事件，避免重复或丢失。保留最近 N 个事件：Server 维护事件缓冲（ring buffer），保留最近 N 个事件及其 ID；客户端重连时携带 Last-Event-ID，Server 若该 ID 在缓冲内则从其后续传；若该 ID 已过期（被新事件挤出缓冲），Server 无法续传，返回提示让客户端重新同步。过期降级：1) 客户端收到"事件已过期"响应时，放弃增量续传，改用全量重同步（重新获取当前状态/订阅，重新拉取最新数据）；2) 客户端重置 Last-Event-ID，重新建立订阅；3) 对关键事件，客户端可主动重放/重新查询状态，确保不因事件丢失而错失。降级原则是"续传失败则全量重同步"，保证事件的最终一致性。

Last-Event-ID 续传依赖 Server 保留事件缓冲。缓冲有限（N 个），过期后无法增量续传，客户端降级为"全量重同步"。这是"增量续传 + 全量兜底"的可靠事件同步设计。

• 理解令牌提前刷新
• 掌握避免首请求失败
• 理解刷新与能力重协商耦合

避免"首请求失败"（令牌过期导致首个请求 401）需提前刷新：1) 提前刷新——Client 在令牌即将过期（如剩余 10% 有效期或提前 TTL）时主动用刷新令牌换取新访问令牌，而非等过期后再刷新；2) 过期预估——Client 跟踪令牌过期时间，提前触发刷新；3) 并发刷新——多个请求同时发现令牌快过期时，只触发一次刷新，其他请求等待或用新令牌；4) 401 兜底——若仍遇到 401，Client 解析 error 后刷新令牌重试一次（避免无限重试）。令牌刷新与 capability 重协商的耦合：令牌刷新可能改变 scope/权限（如权限变化），刷新后应重新协商能力——重新获取工具列表（若权限变了，工具集可能变），重新 discover 或重新拉取受保护资源；若刷新后权限不变，可复用缓存能力。耦合设计：令牌刷新成功后，检查权限是否变化，变化则触发能力重协商，不变则继续。避免"令牌变了但能力还是旧的"导致调用失败。

提前刷新靠"过期预估 + 主动刷新 + 401 兜底"，避免首请求失败。刷新与能力重协商耦合是因为令牌可能改变权限，刷新后需确认能力集合是否变化。避免"令牌新、能力旧"的不一致。

• 理解旧 HTTP+SSE 的缺陷
• 掌握迁移到 Streamable HTTP 的兼容测试
• 理解迁移风险

旧 HTTP+SSE 不应写成当前标准，因为其缺陷：SSE 长连接常驻、在网关/负载均衡后难以管理（连接粘性、超时、缓冲）、断线重连困难、可伸缩性差（长连接占用资源）、与无状态化/标准 HTTP 基础设施不兼容。Streamable HTTP 用单端点 POST/GET + 可选 SSE + Mcp-Session-Id + Last-Event-ID 解决这些问题，支持无状态化、水平扩展、标准网关处理。迁移到 Streamable HTTP 的兼容测试：1) 功能等价——验证所有工具/资源/提示在 Streamable HTTP 下功能与旧版一致；2) 流式测试——验证 SSE 流式事件、进度、通知正确传输；3) 断线续传——验证 Last-Event-ID 断线重连不丢事件；4) 会话——验证 Mcp-Session-Id 的会话维持与过期；5) 认证——验证 OAuth 2.1 鉴权在两种传输下一致；6) 网关/代理——验证反代后 SSE 不被破坏；7) 新旧客户端——验证旧客户端兼容、新客户端可用；8) 并发/伸缩——验证水平扩展与并发。迁移需双跑验证后全量切换。

旧 HTTP+SSE 的长连接缺陷（网关难管理、难伸缩、难断线恢复）使其被弃用。迁移测试覆盖功能等价、流式、断线、会话、认证、网关、兼容性，确保迁移无回归。双跑验证后全量切换。

• 理解 Tasks 作为实验扩展
• 掌握实验能力隔离
• 理解产品设计的隔离策略

Tasks 等后续 draft extension 是实验能力，不在稳定核心，产品设计要隔离实验能力，避免实验能力破坏稳定核心或污染正式功能。隔离策略：1) 能力协商——实验能力通过能力协商显式声明，只有双方都支持才启用，默认关闭；2) 命名空间/分组——实验能力在独立命名空间或分组，不与稳定工具混用；3) 版本隔离——实验能力在独立版本/语义化版本域，演进不破坏稳定版本；4) 运行时开关——实验能力用 feature flag 控制，可随时关闭；5) 文档标注——明确标注"实验性、可变更、不保证稳定"，避免用户依赖；6) 独立测试——实验能力独立测试，不纳入稳定回归的门禁；7) 渐进转正——实验能力成熟后纳入稳定核心，届时才承诺兼容。关键是让实验能力"可独立演进、可随时关闭、不污染稳定核心"，产品只在用户显式启用时暴露实验能力。

隔离实验能力是"稳定核心 + 实验扩展"的架构原则。命名空间、feature flag、版本隔离、独立测试让实验能力不破坏稳定核心。实验能力成熟后才转正并承诺兼容。

• 理解 Server 无状态化的原则
• 掌握 Client 负责 ID 关联
• 理解状态管理的职责划分

不应在 MCP Server 中存储长期会话状态，原因：1) 可伸缩性——Server 如果存会话状态，就无法水平扩展（请求需路由到同一实例）或需共享 session 存储，破坏无状态化；2) 故障恢复——Server 崩溃会丢失会话状态，影响恢复；3) 资源占用——长会话状态占用 Server 资源；4) 状态一致——多副本间状态同步复杂。应让 Client 负责 ID 关联：Client 保存会话上下文（对话历史、任务状态、工具调用进度），并负责把关联（request ID、session ID、进度 token）与请求一起发送；Server 只处理无状态请求，需要状态时由 Client 提供或从外部存储读取。这样 Server 保持无状态、可伸缩、可故障恢复，Client 作为"状态的持有者"管理关联。Server 最多存短时/最小状态（如 Mcp-Session-Id 的订阅），但长期业务状态由 Client 或外部存储负责。

"Server 无状态 + Client 管状态"是可伸缩与故障恢复的关键。Server 存长期状态会破坏无状态化、影响扩展与恢复。Client 负责 ID 关联与上下文，Server 只处理无状态请求。

• 理解 401/403 的可恢复性
• 掌握自动重新授权流程
• 理解授权失败的降级

MCP 授权错误（401/403）的可恢复性设计：1) 区分——401（未认证/令牌过期）与 403（无权限）可恢复性不同：401 通常可恢复（刷新令牌/重新授权），403 通常不可恢复（用户权限不足）；2) 401 自动恢复——Client 收到 401 时，若令牌过期，用刷新令牌刷新后重试一次，避免"首请求失败"；刷新失败则触发重新授权流程（OAuth 重新授权）；3) 403 处理——403 表示权限不足，不自动重试（重试也无用），告知用户权限不足或降级；4) 自动重授权——是否自动触发取决于：401 且可刷新（自动刷新），刷新失败或需用户确认（引导用户重新授权，不静默自动）；5) 重试上限——授权重试有限次，避免循环；6) 降级——授权失败时降级（无工具可用、只读模式、提示用户）。设计上，401 走"刷新+重试+必要时重授权"，403 走"告知+降级"，重授权需用户参与（OAuth 授权码）而非全自动。

401 与 403 的可恢复性不同。401 可自动刷新重试，刷新失败转重授权；403 权限不足不自动重试，降级告知。重授权涉及用户授权，不能全自动静默执行。

• 理解公网部署的防护
• 掌握速率限制、连接数限制、IP 名单
• 理解与网关配合

Streamable HTTP Server 公网部署时，速率限制、连接数限制、IP 黑白名单与网关配合实现防护：1) 速率限制——按用户/租户/IP 做速率限制（RPM），防止滥用与资源耗尽，可在网关层（基于 Mcp-Method/Mcp-Name 头）或 Server 层实现；2) 连接数限制——限制并发连接/SSE 长连接数，防止连接耗尽（每个连接占资源），超限拒绝新连接；3) IP 黑白名单——黑名单拦截已知恶意 IP，白名单放行可信来源（企业内网/特定客户端），配合网关的 IP 过滤；4) 网关配合——把速率限制、连接数、IP 过滤放在网关（API Gateway/LB/WAF）统一处理，Server 专注业务；网关基于 HTTP 头（Mcp-Method/Mcp-Name）做工具级限流；5) 认证前置——网关先做认证（OAuth/mTLS），未认证请求直接拒绝，减少 Server 压力；6) 审计——网关记录限流/拒绝事件，供溯源。公网部署的核心是"网关+Server 多层防护"，网关做网络层防护（IP、限流、连接、认证），Server 做业务层防护（工具鉴权、审计）。

公网部署用"网关多层防护 + Server 业务防护"。速率/连接/IP 限制放网关，认证前置，Server 专注业务与工具鉴权。基于 Mcp-Method/Mcp-Name 头做工具级限流，网关无需解析 body。

• 理解两种传输的跨网络边界
• 掌握 NodePort 隔离
• 理解部署边界划分

stdio 与 Streamable HTTP 的跨网络边界差异：stdio 是本地进程通信，不允许跨网络（Server 与 Host 同机），信任边界是本地进程；Streamable HTTP 是网络服务，允许跨网络访问，信任边界是网络认证。在 K8s 部署中，用 NodePort 隔离是指：把 Streamable HTTP 的 MCP Server 暴露为 NodePort 服务（通过节点端口对外提供服务），而 stdio 的 Server 作为 Host 的 sidecar/本地进程，不暴露到网络。NodePort 隔离的要点：1) stdio Server 不建 NodePort（仅本地进程，Host 直接 spawn），其数据与进程不暴露到集群网络；2) Streamable HTTP Server 建 NodePort/ClusterIP/LB 服务，通过网络访问，用 NodePort 暴露到特定节点端口；3) 网络策略——用 NetworkPolicy 限制 Streamable HTTP 服务的入站来源，只允许可信客户端；4) 边界——stdio 的边界是"进程内/本机"，不跨网络；Streamable HTTP 的边界是"网络服务"，需网络隔离（NodePort 暴露 + 网络策略 + 认证）。NodePort 隔离让"本地工具不暴露网络、远程服务按需暴露并受控"。

NodePort 隔离体现了两种传输的边界差异：stdio 不暴露网络（本地进程），Streamable HTTP 按需暴露（NodePort 服务 + 网络策略）。用 NodePort 控制远程服务的对外暴露范围，同时不让 stdio 工具跨网络。

• 理解 Mcp-Session-Id 的角色
• 掌握 Last-Event-ID 断线续传
• 理解两者配合

Mcp-Session-Id 与 Last-Event-ID 在 Streamable HTTP 中配合支持断线续传：1) Mcp-Session-Id——标识会话，客户端在断线重连后携带 Mcp-Session-Id 让 Server 识别同一会话，恢复会话状态（订阅、进度、协商结果），而不是当成新会话；2) Last-Event-ID——标识上次收到的最后一个事件，客户端重连携带该 ID，Server 从其后续传事件，避免重复或丢失；3) 配合——重连时，客户端同时携带 Mcp-Session-Id（恢复会话）与 Last-Event-ID（续传事件），Server 恢复会话上下文并从断点继续推送；4) 过期——若会话/事件缓冲过期，Server 返回提示，客户端降级为全量重同步。核心是"Mcp-Session-Id 恢复会话状态，Last-Event-ID 恢复事件流"，两者配合让断线重连不丢状态、不重事件、无缝续传。

Mcp-Session-Id 管"会话状态恢复"，Last-Event-ID 管"事件流续传"。重连时两者并用，Server 恢复上下文并从断点推送。过期则降至全量重同步，保证事件一致性。

• 理解 OAuth 2.1 + PKCE 的授权安全
• 掌握 Resource Indicators 的资源绑定
• 理解防令牌路由错误

OAuth 2.1 + PKCE + Resource Indicators 多层防止令牌被错误路由：1) PKCE——保护授权码，防止授权码被截获重放，保证了令牌换取过程的安全；2) Resource Indicators（RFC 8707）——客户端在授权请求中声明目标资源（resource 参数），授权服务器把令牌绑定到该资源，令牌的 audience（受众）限定为声明资源；3) 防止错误路由——令牌绑定到资源 A，就不能被重放到资源 B（token confusion 攻击），因为资源 B 校验令牌的 audience 会发现不匹配而拒绝；4) 资源校验——资源服务器校验令牌的 audience/scope 是否匹配自身，不匹配则拒绝；5) OAuth 2.1 收紧——统一授权码模式、强制 PKCE、移除隐式授权，减少令牌泄露面。组合效果：PKCE 保证"授权码→令牌"安全，Resource Indicators 保证"令牌绑定特定资源"，资源校验保证"令牌不被错误路由"。这防止了"原本发给资源 A 的令牌被重放到资源 B"的令牌混淆攻击。

防令牌错误路由的关键是"令牌绑定资源"。Resource Indicators 把令牌绑定到声明资源，资源服务器校验 audience 拒绝不匹配令牌。PKCE 保护换取过程，OAuth 2.1 收紧流程。三层防令牌混淆。

• 理解 Protected Resource Metadata
• 掌握与 OAuth Provider 对齐
• 理解防重定向攻击

Protected Resource Metadata 端点（.well-known/oauth-protected-resource）暴露受保护资源的授权信息（授权服务器端点、scope 要求、资源信息）。避免重定向攻击（重定向到恶意授权服务器）的关键是"端点与 OAuth Provider 对齐"：1) 来源可信——客户端从可信的 MCP Server 获取 Protected Resource Metadata，校验其来源（HTTPS、来源校验），不信任被篡改的元数据；2) 端点对齐——元数据中的授权服务器端点必须与预期 OAuth Provider 一致，客户端校验授权服务器 URL 在白名单/可信列表内，防止元数据把重定向指向恶意服务器；3) 校验签名/来源——元数据可签名或绑定可信来源，防篡改；4) 重定向校验——授权流程中，客户端校验重定向端点（redirect_uri）与授权服务器、受保护资源一致，防止重定向到攻击者；5) 状态绑定——用 state 参数绑定授权请求，防 CSRF/重定向注入。核心是"元数据来源可信 + 端点对齐校验 + 重定向校验"，防止攻击者通过篡改元数据或重定向把授权流程导向恶意服务器。

防重定向攻击的关键是"可信元数据 + 端点对齐 + 重定向校验"。Protected Resource Metadata 来源要可信，授权服务器端点要校验白名单，重定向端点要一致，state 绑定防 CSRF。

• 理解授权发现与资源服务器关系
• 掌握令牌获取与刷新
• 理解授权流程

MCP 规范中，受保护资源（MCP Server）通过 Protected Resource Metadata 暴露授权信息，客户端通过授权发现获取授权服务器端点与 scope 要求，MCP Server 作为 OAuth 2.1 资源服务器（保护资源，校验令牌）。关系：MCP Server（资源服务器）校验客户端令牌；授权服务器负责签发令牌；客户端通过授权发现找到授权服务器完成授权。客户端获取令牌流程：1) 授权发现——从 MCP Server 的 .well-known/oauth-protected-resource 获取授权服务器端点与 scope；2) 授权码流程——用 Authorization Code + PKCE 向授权服务器请求授权码，用户授权后换取访问令牌；3) 令牌获取——客户端用授权码换取 access token（+ refresh token）；4) 令牌刷新——访问令牌过期前，客户端用刷新令牌向授权服务器换取新访问令牌（token endpoint），避免重新授权；5) 令牌撤销——登出/吊销时调用 revoke endpoint。客户端把令牌作为 Bearer 头携带，访问 MCP Server 时 Server 校验令牌（资源服务器职责）。刷新要在过期前主动进行，失败时重新授权。

MCP Server 是资源服务器，授权服务器签令牌，客户端通过授权发现获取端点并完成授权码流程。获取用授权码换令牌，刷新用刷新令牌提前换新令牌，撤销用 revoke。三方协调。

• 理解三种传输的部署拓扑
• 掌握断线重连的状态处理
• 理解拓扑与状态的匹配

三种传输的部署拓扑：stdio——本地单机/进程内拓扑，Server 与 Host 同机，通过标准输入输出通信，适合本地工具、桌面应用、单机部署，无网络拓扑；Streamable HTTP——远程服务拓扑，Server 是独立网络服务，支持多租户、水平扩展、网关管理，适合跨网络部署；SSE（旧 HTTP+SSE）——历史远程拓扑，长连接推送，已被 Streamable HTTP 取代。断线重连状态处理：stdio——Server 是本地子进程，断线即进程异常，Host 重启子进程并重新 initialize，状态（上下文）由 Host/Client 管理，重启后恢复；Streamable HTTP——用 Mcp-Session-Id 恢复会话状态、Last-Event-ID 续传事件流；无状态请求可直接重放；SSE——长连接断线需重建，旧版无 Last-Event-ID 续传，状态恢复困难。状态处理原则：Server 无状态化，状态由 Client/外部存储管理；断线重连时，Client 用会话 ID/事件 ID 恢复，或全量重同步。

传输拓扑决定部署形态（本地/远程），断线重连状态处理决定可靠性。stdio 重启子进程恢复，Streamable HTTP 用会话/事件 ID 续传，SSE 长连接难恢复。Server 无状态、Client 管状态是断线恢复的基础。

• 理解会话状态机设计
• 掌握协议版本与能力变更
• 理解兼容旧客户端且不静默降级

会话状态机设计要管理"初始化、协议版本、能力变更"的状态，兼容旧客户端且不静默降级：1) 状态机——会话状态如：未初始化（NOT_INITIALIZED）→ 初始化中（INITIALIZING）→ 已初始化（INITIALIZED）/ 降级（DEGRADED）→ 已关闭（CLOSED）；2) 协议版本——握手时协商版本，取交集；旧客户端用旧版本，新客户端用新版本，状态机记录"当前生效版本"；3) 能力变更——能力协商后，能力变更（如工具列表变化）触发状态更新，但不重置会话；4) 兼容旧客户端——对旧客户端，用其支持的协议版本与能力子集工作，状态机支持"降级到兼容子集"，但同时明确标记降级状态（DEGRADED），不静默降级；5) 不静默降级——当能力/版本不可用需降级时，状态机显式记录降级原因并通知客户端，而不是静默用旧能力；客户端与用户知道"当前是降级模式"。设计上，状态机显式管理能力/版本状态，兼容旧客户端（用旧版本/子集）但同时显式标记降级，避免"静默降级"导致行为不可预期。

状态机管理"初始化、版本、能力"状态，兼容旧客户端用旧版本/子集，但显式标记降级而不是静默。这让新旧客户端都能工作，且降级是透明、可感知的，避免行为不可预期。

• 理解反代暴露的 DNS rebinding 风险
• 掌握 Origin 校验、Host 绑定、请求体限制
• 理解多层防御

远程 MCP Server 通过反向代理暴露时，DNS rebinding 攻击（攻击者域名解析到本地/内网地址，诱导浏览器访问本地服务）需多层防御：1) Origin 校验——Server/代理校验请求的 Origin 头，只接受可信来源，攻击者域名（非可信 Origin）的请求被拒绝；2) Host 绑定——校验 Host 头与期望的域名一致，防止 Host 头注入与域名欺骗；拒绝未知/异常 Host 的请求；3) 请求体限制——限制请求体大小（防止超大 payload 攻击），并校验 Content-Type，防止恶意请求体；4) 认证——所有请求强制认证（即使通过反代），未认证即拒绝；5) 地址绑定——Server 只监听回环/受控地址，反代只暴露受控端口；6) 代理配置——反代校验 Host/Origin、限制请求体、关闭非必要转发。核心是"反代 + Server 双层校验来源"：Origin/Host 校验拒绝域名欺骗，请求体限制防 payload 攻击，认证防无授权访问，共同防 DNS rebinding。

反代暴露的 DNS rebinding 防御是"来源校验（Origin/Host）+ 请求体限制 + 认证 + 地址绑定"。Origin/Host 校验拒绝攻击者域名，请求体限制防攻击，认证防未授权。多层组合防 rebinding。

• 理解超时、恢复、通知的异步设计
• 掌握不阻塞对话
• 理解解耦与并发

设计超时、恢复、通知机制不阻塞整个对话，核心是"异步、解耦、并发"：1) 超时—工具调用设超时，超时后不阻塞主对话流程，而是异步处理（重试、降级、标记失败），对话继续；2) 恢复—断线/重连在后台异步进行（指数退避重连），不阻塞对话的继续；重连成功恢复上下文，对话不中断；3) 通知—Server 推送的 notification 用异步事件驱动处理（事件队列、回调），不阻塞主请求处理；4) 解耦—超时/恢复/通知的处理与主对话逻辑解耦，用独立任务/协程/事件循环，避免阻塞主线程；5) 并发—模型生成与工具调用可并发（工具调用在模型生成后异步执行），不串行阻塞；6) 背压—高频通知用队列缓冲，避免积压阻塞。设计上，把"异步控制面"（超时、恢复、通知）与"对话主流程"分离，主流程不被这些机制阻塞，保障对话流畅。

不阻塞对话的关键是"异步处理横切机制"。超时/恢复/通知用异步事件驱动，与主对话解耦，用并发与队列缓冲。主流程专注于对话，横切机制在后台运行。

• 理解 Mcp-Session-Id 生命周期收紧与 resumption 状态
• 掌握断线后探测状态
• 理解续传 vs 重新握手的决策

后续修订收紧 Mcp-Session-Id 生命周期，新增 session resumption 中间状态（pending-resume、resuming），客户端断线重连时要探测并区分状态以决定续传还是重新握手。做法：1) 探测——重连时携带 Mcp-Session-Id 发起请求，根据 Server 响应/状态码判断会话状态；2) 区分状态——若 Server 返回"可续传"（resuming/pending-resume，会话仍有效），客户端继续用该会话（续传订阅、进度、事件）；若返回"会话不存在/过期"（session expired），客户端需重新握手（重新 initialize/创建新会话）；3) 状态码/响应头——Server 用特定响应（如 404/session 不存在、或中间态提示）告知客户端当前会话状态，客户端据此决策；4) 决策逻辑——状态可续传则续传（保留上下文、续传事件），不可续传则重新握手（重新 initialize、重新拉取能力、重置状态）；5) 过渡处理——pending-resume 表示会话正在恢复，客户端等待其进入 resuming/稳定，再继续；若超时则降级重新握手。核心是"断线后探测会话状态，可续传则续传、不可续传则重新握手，避免误用无效会话"。

session resumption 状态让断线恢复更精确。客户端通过响应/状态码探测会话状态，区分"可续传"与"需重新握手"，避免在无效会话上继续导致错误。决策逻辑保证断线恢复正确。

• 理解令牌混淆攻击
• 掌握 Resource Indicators 的绑定
• 理解资源服务器与客户端的双层校验顺序

令牌混淆（token passthrough）是指原本发给资源 A 的令牌被重放到资源 B。Resource Indicators（RFC 8707）让令牌绑定到声明资源，配合双层校验阻止。资源服务器端校验顺序：1) 校验令牌存在与格式（Bearer 头解析）；2) 校验令牌签名/来源（JWT 签名或 introspection 验证）；3) 校验令牌的 audience（aud 声明）与自身资源标识匹配——若令牌 aud 是资源 A，而当前是资源 B，则拒绝（这是 Resource Indicators 的核心，绑定资源）；4) 校验 scope 与当前操作所需 scope 匹配；5) 校验令牌未过期/未撤销。客户端校验顺序：1) 发起授权时声明目标资源（resource 参数），获取绑定该资源的令牌；2) 使用令牌时，只把令牌发送给声明资源（不把令牌转发给其他资源）；3) 收到 401/403（aud 不匹配）时，拒绝继续使用该令牌于其他资源，触发重新授权而非透传。双层校验：客户端"只发到绑定资源"，资源服务器"校验 aud 匹配"，互相配合，令牌无法被重放到不一致资源。

防令牌混淆的机制是"绑定 + 双层校验"。客户端只把令牌发给绑定资源，资源服务器校验 aud 与自身资源匹配，不匹配拒绝。这在客户端限制"令牌去向"，在资源服务器限制"令牌来源"，双向阻止重放。

• 理解 capabilities 显式声明
• 掌握优雅拒绝部分能力
• 理解区分"拒绝"与"不支持"

客户端面对 Server 声明的多个能力（tools、resources、prompts、sampling、elicitation、roots），可优雅拒绝某个能力（如拒绝 sampling 或 elicitation）同时保留其余能力：1) 逐能力协商——能力协商是逐项声明的，客户端可接受部分能力、拒绝部分能力，被拒绝的能力不启用，其余保留；2) 拒绝语义——客户端在协商结果中明确声明"拒绝某能力"，Server 据此不使用该能力，而不影响其他能力；3) 区分"拒绝"与"不支持"——拒绝（客户端有能力但选择不使用）与不支持（客户端没有能力）语义不同：拒绝是客户端主动选择，不支持是客户端无法提供；客户端应明确表达"拒绝"（如声明该能力但标记未启用/显式拒绝），Server 认识到这是"客户端选择不用"而非"客户端不支持"，从而不误判；4) 通信——若协议支持，客户端可在协商中显式列出"拒绝的能力"与"支持的能力"，Server 据此精确调整；5) 降级——拒绝某能力后，Server 用替代路径（如拒绝 sampling，Server 用工具调用代替采样），功能降级但不失败。核心是"协商结果精确表达拒绝与支持，Server 区分拒绝与不支持，保留其余能力并降级替代"。

优雅拒绝部分能力的关键是"协商语义精确区分"拒绝"与"不支持""。拒绝是主动选择（保留其余能力），不支持是能力缺失。明确表达拒绝让 Server 精准调整，避免误判为不支持而影响其他能力。

• 理解两种传输的信任边界差异
• 掌握 stdio 的本地进程信任
• 理解暴露 stdio 的风险

Streamable HTTP 与 stdio 的信任边界根本差异：Streamable HTTP 是网络服务，信任边界是"网络认证"——通过 TLS、OAuth/mTLS、鉴权校验访问者身份，访问者对 Server 的影响受网络层控制；stdio 是本地进程通信，信任边界是"本地进程"——Server 与 Host 同机、共享机器环境，通过标准输入输出通信，信任建立于"同机部署、进程隔离"。把 stdio 暴露在公网或反代后等同于把宿主 shell 交给攻击者，因为：stdio 的 Server 设计为"本地可信、无网络认证"，它直接访问宿主文件系统、环境变量、进程能力（设计时假设调用者可信）；若把 stdio 暴露到网络，攻击者可通过网络发送任意 JSON-RPC 指令，让 Server 执行任意工具（包括文件读写、命令执行、数据访问），而 Server 没有网络层认证（stdio 端点无鉴权），等于攻击者直接获得宿主能力。stdio 的设计假设"调用者是宿主进程"，一旦暴露到不可信网络，这个假设被破坏，Server 的本地权限被攻击者支配，等同 shell 访问。

信任边界差异是"网络认证 vs 本地进程"。stdio 无网络认证，只信任本地调用者；暴露到公网后，攻击者借 Server 的本地权限执行任意操作，等同 shell。因此 stdio 绝不应暴露公网/反代。

• 理解 MRTR 的机制
• 掌握 resultType=input_required 的中间确认
• 理解实现边界与安全

Multi Round-Trip Requests (MRTR) 允许服务端在工具调用中发起多轮往返，通过 resultType=input_required 回到客户端请求中间确认/补充信息，实现"先在服务端处理、中途需要确认再回到客户端"。实现边界：1) 触发条件——服务端在需要用户确认（如高影响操作、参数缺失需补充）时，返回 resultType=input_required，附带请求提示（要求什么、选项），客户端据此向用户请求确认；2) 恢复——用户确认后，客户端把确认结果作为继续请求发回服务端，服务端继续执行；3) 边界——MRTR 的往返次数应有限（避免无限循环），每轮确认有超时；4) 安全——中间确认涉及高影响操作必须走 HITL，确认内容要最小披露、来源透明；防恶意 Server 用 MRTR 反复索取信息（与 Elicitation 类似，需频控与白名单）；5) 状态——多轮往返需维护请求上下文（MRTR 状态），服务端在有限范围内保存，配合超时清理；6) 降级——若客户端不支持 MRTR 或确认超时，服务端降级（默认值、取消、或改用其他方式）。实现边界是"有限往返 + 用户确认 + 超时 + 安全控制"，让 MRTR 实现"先算后确认"而不过度索取或无限循环。

MRTR 的实现边界是"有限往返 + 中间确认 + 安全控制"。resultType=input_required 让服务端中途请求用户确认，但需限制往返次数、超时、HITL 与频控，防止恶意 Server 滥用或无限循环。

• 理解 ttlMs 与 cacheScope 缓存提示
• 掌握减少重复获取
• 理解提升 prompt cache 命中率

MCP 在 list 响应加 ttlMs（缓存有效期）与 cacheScope（缓存作用域）提示，客户端据此优化：1) 减少重复获取——客户端按 ttlMs 缓存 list 结果，在缓存有效期内不重复调用 tools/list/prompts/list/resources/list，直接复用缓存，减少协议往返；根据 cacheScope 决定缓存范围（如按 server 全局缓存 vs 按会话缓存），避免过度缓存；2) 提升 prompt cache 命中率——tools/prompts 的 list 结果（含描述、Schema）是注入模型的"前缀"，若这些内容稳定（缓存作用域内不变），客户端可把工具描述/Schema 作为稳定的 prompt 前缀复用，配合上游 prompt cache（如上下文缓存）让相同前缀命中缓存，减少重复计算与 token 成本；3) 缓存失效——ttlMs 到期后重新拉取，list_changed 通知触发立即失效；4) 一致性——缓存作用域内内容一致，避免缓存与 Server 实际不一致。核心是"用 ttlMs 控制缓存有效期、用 cacheScope 控制缓存范围，减少重复获取，并让工具描述作为稳定前缀提升 prompt cache 命中率"。

ttlMs/cacheScope 让客户端"缓存 list 结果 + 控制范围"。这减少重复协议调用，且工具描述作为稳定 prompt 前缀提升上游缓存命中率（省 token 成本）。缓存失效靠 TTL 与 list_changed。

• 理解 Roots/Sampling/Logging 弃用的背景
• 掌握无状态迁移路线图
• 理解过渡期规划

从有状态迁移到无状态，弃用 Roots/Sampling/Logging 三类请求，路线图规划：1) 盘点评估——梳理现有依赖这三类请求的 Server/Client，评估使用情况与影响；2) 确立目标——明确无状态化迁移目标（移除 roots/sampling/logging 依赖、用替代机制）；3) 分阶段——阶段一：评估与双跑（新版同时支持旧能力与新无状态能力，兼容）；阶段二：替代方案落地（用 tool 替代 sampling、用 server/discover 替代能力协商、用外部日志替代 logging 请求）；阶段三：逐步切换（按 Server/Client 比例迁移到无状态）；阶段四：过渡期结束，弃用旧请求（保留短期回滚窗口）；4) 兼容性——过渡期内新旧需要并存，旧 Client 继续用旧请求，新 Client 用无状态能力；5) 验证——每个阶段验证功能等价、无回归；6) 回滚——保留回滚路径。规划要点是"分阶段 + 双跑 + 替代方案 + 兼容并存 + 逐步切 + 回滚"，避免一刀切迁移导致中断。

迁移路线图是"分阶段 + 双跑 + 替代 + 兼容 + 逐步切"。弃用 Roots/Sampling/Logging 需先规划替代方案（如 tool 替代 sampling），过渡期新旧并存，逐步切换并保留回滚。避免一刀切。

• 理解 Tasks 扩展的轮询与通知
• 掌握与 server-initiated 流的对比
• 理解设计哲学变化

MCP Tasks（SEP-2663）扩展提供 task 管理（创建、查询、更新），tasks/get 轮询与 tasks/update 通知代表设计哲学变化：1) 过去 server-initiated 流——Server 主动推送事件/进度（server-initiated push），客户端被动接收，需要长连接/SSE 维持推送通道，状态由 Server 管理，断线重连复杂；2) tasks/get 轮询——客户端主动通过 tasks/get 查询任务状态，客户端掌控拉取节奏，Server 无状态化（任务状态可查询），不依赖长连接推送，更简单、可伸缩、断线友好（重新查询即可）；3) tasks/update 通知——作为轮询的补充，Server 在任务更新时推送通知，客户端可订阅（可选），两者结合：轮询作为可靠基础，通知作为实时优化；4) 设计哲学变化——从"Server 主动推、状态在 Server"转向"客户端主动查、状态可查询、无状态化"，把状态管理从 Server 推送到客户端或外部存储，Server 更无状态、可伸缩、可靠。这反映了 MCP 从"server 驱动的有状态流"走向"client 驱动的可查询状态"的无状态化哲学。

设计哲学变化是"从 server 主动推送的新状态流"到"client 主动查询的可查询状态 + 可选通知"。轮询可靠、无状态、可伸缩，通知作为实时补充。状态从 Server 移向客户端/外部，符合无状态化。

• 理解 MCP 与 Function Calling/LangChain Tools 的层级差异
• 掌握"传输协议 vs 框架"的区分
• 理解互操作与生态

MCP 与 OpenAI Function Calling、LangChain Tools 抽象层级不同：OpenAI Function Calling 是"模型 API 的工具调用格式"（内嵌在模型接口的 schema 约定），LangChain Tools 是"框架级的工具抽象"（框架内定义工具、路由、编排），二者都绑定特定框架/厂商。MCP 是"传输/互操作协议"——定义 Client 与 Server 如何发现与调用工具（JSON-RPC、tools/list、tools/call），与特定模型、框架、厂商无关。为什么 MCP 是传输协议而非框架：1) 不绑定模型——MCP 不关心用哪个 LLM，只负责"工具如何被发现与调用"；2) 不绑定框架——MCP 是协议，任何框架（LangChain、Semantic Kernel、Spring AI）都可实现 Client/Server 桥接；3) 跨语言/跨进程——MCP 定义跨进程/跨语言的互操作契约，框架是单进程内的抽象；4) 生态中立——MCP 是开放协议，多家厂商采用，避免锁定。因此 MCP 是"传输/互操作层"，OpenAI Function Calling/LangChain Tools 是"模型/框架层"，MCP 在它们之下，提供通用工具互操作。

MCP 是传输协议，OpenAI Function Calling 是模型 API 格式、LangChain 是框架抽象。MCP 不绑定模型/框架，定义跨进程/跨语言的工具互操作契约，是通用开放协议。层级上 MCP 更底层。

• 理解 Roots 的机制
• 掌握对文件操作范围的约束
• 理解声明与强制的结合

Roots 机制让 Client 告知 Server 可访问的文件系统根目录（如 file:///workspace/project），Server 以此为参考约束文件操作范围。约束方式：1) 声明边界——Roots 声明"Server 应该访问哪些根目录"，Server 收到后把文件操作限定在这些根目录内；2) 路径校验——Server 对文件操作做路径校验，确保目标路径在 Roots 声明的根目录内（真实路径解析），超范围（如 ../ 逃逸、符号链接指向根目录外）拒绝；3) 白名单——Server 用 Roots 作为文件访问白名单，只允许访问根目录内的路径；4) 权限设置——部分 Server 可基于 Roots 设置读写权限（如只读根目录）；5) 注意——Roots 是"声明"，不是强制授权，Server 应主动遵守并用路径校验实现，但 Client 不能仅依赖 Roots 声明（Server 可能不遵守），需配合运行时沙箱/路径校验。约束本质是"Roots 声明边界 + Server 路径校验强制执行"。

Roots 约束文件操作是"声明 + 强制"。Roots 声明可访问边界，Server 用路径校验（真实路径、白名单、防穿越）强制执行。Roots 是参考，运行时校验才是真正的强制层。

• 理解 Prompts 与 Tool 的区别
• 掌握用 Prompt 的时机
• 理解模板的价值

Prompts 是参数化的提示模板（预定义提示结构、指令、占位符），Tool 是可执行的动作。区别：Prompts 是"提示"（供模型使用的工作流/指令），Tool 是"动作"（模型调用的可执行能力）。用 Prompt 模板而非让模型自行组装的时机：1) 需要稳定/标准化的提示——当提示结构需要固定（如代码审查、报告生成、特定领域工作流），用模板保证一致性，避免模型每次自行组装质量波动；2) 需要复用——预定义提示可被多个场景/用户复用，模板化便于维护与更新；3) 需要规则约束——提示包含特定规则、格式、步骤，模板把这些固化，避免模型遗漏；4) 需要安全/合规——提示模板经过审核，保证输出符合规范，比模型自由组装更可控。不用 Prompt 的时机：提示简单、无需固定结构、依赖模型灵活发挥时，让模型自行组装更灵活。取舍：Prompt 模板提供"稳定、可控、可复用"，模型自行组装提供"灵活"。关键场景（规范化、复用、安全）用模板，探索性场景用自由组装。

Prompt 模板与 Tool 的区别是"提示 vs 动作"。用 Prompt 的时机是"需要稳定/复用/规则约束/安全合规"时，模板保证一致性与可控性；简单灵活场景让模型自行组装。模板是"工程化的提示"，自由组装是"灵活发挥"。

• 理解 elicitation 的显式同意要求
• 掌握同意对话框的三项要求
• 理解阻断注入

elicitation 敏感字段展示前需用户显式同意，同意对话框设计满足三项要求：1) 最小披露——对话框只展示"要展示什么敏感字段、用于什么、给哪个 Server"，用掩码/摘要展示敏感内容，不展示完整上下文与无关敏感信息；2) 来源可追溯——明确标注"哪个 Server 发起此请求"（Server 名、来源、用途），让用户知道数据去向，可追溯；3) 阻断注入——对话框展示的 elicitation 内容作为"不可信数据"处理，不把 Server 的任意输入塞进 system prompt；用户同意后，输入的敏感字段也作为"数据"注入，用边界隔离，且对 elicitation 内容做注入检测/净化，防止 Server 借 elicit 向 system prompt 注入指令。设计上，同意对话框 = 最小披露（掩码/摘要）+ 来源透明（Server 标识）+ 输入隔离（作为数据非指令、注入检测）。用户同意后，敏感字段仅用于声明用途，不进 system prompt 或仅作为受控数据。

同意对话框三项要求对应"披露最小化、来源可追溯、输入隔离"。最小披露掩码敏感内容，来源透明标注 Server，注入隔离把 elicitation 内容当数据而非指令。这让用户知情同意且 Server 无法注入。

• 理解 MCP-Protocol-Version 头版本协商
• 掌握不兼容的回退
• 理解兼容子集降级

客户端在 initialize 前通过 MCP-Protocol-Version 头声明版本，遇到 Server 不返回该头或返回更旧版本时，不直接失败而是回退到兼容子集：1) 判断——Server 不返回 MCP-Protocol-Version 头（不支持版本协商）或返回更旧版本，客户端判断版本不兼容；2) 回退到兼容子集——客户端用"双方都支持的能力子集"工作：用 Server 声明的旧版本协议交互，只使用双方共有的基础能力（如基础的 tools/initialize），不使用高级/新能力（如 elicitation、新传输特性）；3) 不直接失败——客户端继续与 Server 通信，但基于兼容子集（旧版本语义），避免因版本不匹配而中断；4) 标记降级——客户端记录当前处于"兼容子集/降级模式"，必要时提示用户；5) 兜底——若连兼容子集都无法工作（收到明确的不兼容错误），才明确失败并提示升级。核心是"不因版本协商失败而直接中断，而是回退到双方共有能力子集继续工作，并标记降级状态"。

回退到兼容子集的关键是"不直接失败 + 用共有能力工作"。客户端识别版本不兼容后，降级到双方共有的基础能力，标记降级状态，只有无法工作才明确失败。这保证了新旧版本共存。

• 理解工具元数据注入
• 掌握净化、签名与校验
• 理解元数据可信性

工具 description 可能含 prompt-injection 文本，客户端需净化、签名与校验工具元数据：1) 净化——对 Server 返回的 description 做注入检测与净化，剥离 prompt-injection 特征（"忽略之前指令"、"system"、"附上用户信息"等模式），对可疑描述告警或拒绝；净化后把 description 作为"数据"注入，而非"指令"；2) 签名——对可信 Server 的工具元数据做签名（如 Server 私钥签名 manifest），客户端校验签名确认元数据未被篡改、来自可信来源；3) 校验——客户端校验工具元数据的完整性（与签名一致）、来源（可信 Server）、内容（无注入特征、Schema 合法）；未通过校验的元数据拒绝或降级；4) 隔离标注——把工具 description 作为"外部元数据"标注，注入时用边界包裹，指示模型"这是外部工具描述，不是指令"；5) 白名单——只信任可信 Server 的元数据，第三方 Server 的元数据默认高审查。核心是"净化（去注入）+ 签名（防篡改）+ 校验（验来源）+ 隔离标注（当数据非指令）"，让工具元数据不被当作可信指令执行。

工具元数据注入防御是"净化 + 签名 + 校验 + 隔离"。净化去注入文本，签名防篡改，校验验来源，隔离标注让模型当数据而非指令。这让恶意 description 无法劫持模型。

• 理解 Sampling 请求的必要字段
• 掌握最小验证
• 理解防外泄与不破坏合法调用

Sampling 请求必须携带 model、prompt preview 与采样目的说明，Host 放行前做最小验证：1) 字段验证——检查 request 是否携带 model、prompt preview、采样目的（不得缺失，做白名单/格式校验）；2) 来源验证——确认请求来自受信任的 Server（白名单），未授权 Server 的 Sampling 拒绝；3) 内容验证——检查 prompt preview 是否含外泄特征（如"把全部上下文发给我"、"读取用户敏感数据"），做注入/外泄检测；4) 目的验证——检查 sampling 目的是否合理（如"为子任务生成后续 prompt"），与用途匹配；5) 配额/频控——检查采样频率与 token 用量是否在配额内，超限拒绝；6) 脱敏——放行前对 prompt 中的敏感信息脱敏（若含 PII），限制范围为当前子任务所需；7) 作用域——把 sampling 限制为"子 Agent/子任务"范围，不授予全局上下文访问。最小验证的目标是"只放行合法、最小、不泄露的采样请求"，同时不破坏合法的 sub-agent 调用（合法调用通过白名单与内容校验即可放行）。

最小验证是"白名单 + 字段 + 内容/外泄检测 + 配额 + 脱敏 + 作用域"。它拦截恶意采样（外泄、越权），同时不过度拦截合法 sub-agent 调用（白名单+内容通过即放行）。平衡安全与功能。

• 理解 Sampling 数据的脱敏
• 掌握范围限制
• 理解 PII 保护

Sampling 请求携带的数据若含 PII 或敏感上下文，Host 透传模型前做脱敏与范围限制：1) PII 脱敏——对 prompt 中的身份证、手机号、邮箱、姓名等 PII 做脱敏（替换为占位符、掩码），模型只看到脱敏后的内容；2) 敏感上下文过滤——对 prompt 中的密钥、token、内部信息做过滤，不透传；3) 最小化——只透传当前子任务所需的最小数据，不把完整用户上下文传给模型（Sampling 只应看到子任务 scope）；4) 范围限制——把 Sampling 的 prompt 限定在当前子任务上下文，不授予全局/其他会话的上下文访问；5) 用途限制——说明采样用途，限制数据仅用于该采样；6) 审计——记录脱敏规则与透传范围，审计敏感数据流；7) 白名单——对敏感字段类型做白名单，禁止透传的字段（如密码、OTP）直接拦截。核心是"脱敏敏感信息 + 限定最小范围 + 过滤禁止字段"，让模型在 Sampling 中只接触必要的、脱敏后的数据，防 PII 外泄。

脱敏与范围限制是"最小化 + 脱敏 + 过滤"。PII 脱敏、敏感上下文过滤、范围限定到子任务、禁止字段拦截，共同防止 Sampling 泄露用户数据。模型只看到最少的、脱敏后的必要信息。

• 理解 MCP 的稳定核心与实验扩展
• 掌握关键能力分类
• 理解演进原则

MCP 协议演进中，稳定核心是最基础、被广泛实现、承诺兼容的能力；实验扩展是新增、未稳定、可能变更的能力。稳定核心包括：Tools（工具发现与调用）、Resources（资源读取与模板）、Prompts（提示模板）、initialize/能力协商、JSON-RPC over stdio/Streamable HTTP 传输、通知机制（list_changed、updated 等）、Roots（客户端声明可访问边界）。实验扩展（draft，可能变更）：Tasks（SEP-2663，任务管理）、Multi Round-Trip Requests（MRTR，SEP-2322）、Audio data（多模态扩展）、以及部分无状态化相关的新特性（如 server/discover 的演进、session resumption 的细化）。演进原则：稳定核心承诺向后兼容、变更需走版本；实验扩展在独立命名空间/能力协商下演进，成熟后才转正纳入稳定核心。产品设计要区分两者——稳定核心可靠依赖，实验扩展谨慎采用并隔离。

稳定核心（Tools/Resources/Prompts/基础传输/协商/通知）承诺兼容，实验扩展（Tasks/MRTR/Audio/无状态新特性）在 draft 中演进。区分两者让产品能可靠依赖核心、谨慎采用实验功能。

• 理解 OpenTelemetry GenAI span
• 掌握结构化工具结果映射
• 理解调用链关联

把 MCP 结构化工具结果映射到 OpenTelemetry GenAI span 并关联调用链：1) 建 span——为每次工具调用创建 OTel span（语义约定），工具名作为 span 名，记录工具参数（脱敏）、结果状态、耗时、错误；2) 结构化结果映射——把 structuredContent 的字段映射到 span 属性（如提取关键字段、结果大小、token 数），按 OTel 语义约定（如 gen_ai.tool 相关属性）记录；3) 关联 LLM——把工具调用 span 作为 LLM 推理 span 的子 span（模型调用工具时，工具 span 是模型 span 的 child），通过 trace context 传播关联；4) 端到端调用链——一次用户请求作为 trace 根，其下的 LLM 推理 span 与工具调用 span 组成子树，用 trace id 关联日志与指标；5) 导出——span 导出到 OTLP 后端（Jaeger/Tempo），按 trace id 回溯一次请求的完整调用链（模型推理 + 工具调用 + 结果）。关键是把"结构化工具结果"提取为 span 属性，并作为 LLM span 的子树，让运维能看到"模型为何调用工具、结果如何、耗时成本"。

映射的关键是"工具 span 作为 LLM span 子span + 结构化结果提取为属性 + trace id 关联"。这让一次请求的模型推理与工具调用编织成可回溯的调用链，支撑排障与成本分析。

• 理解认证加硬（RFC 9207、CIMD）
• 掌握工作量与兼容性评估
• 理解转型风险

MCP 认证加硬（RFC 9207 iss 校验、弃用 DCR 转向 CIMD）提升安全，但企业落地要评估工作量与兼容性风险。RFC 9207（iss 校验）：授权请求强制携带 iss 并校验，防止跨授权服务器重定向攻击；工作量：客户端/授权服务器需实现 iss 参数生成与校验，改动授权流程。CIMD（Client Instance Metadata Document，替代 DCR）：用客户端元数据文档替代动态注册，提供更可控的客户端注册；工作量：需建立客户端元数据文档的发布与校验机制，迁移现有 DCR 注册。兼容性风险：1) 旧客户端不支持 iss/CIMD——强制加硬会破坏老旧客户端，需双跑/过渡期；2) 授权服务器兼容——需验证授权服务器支持新版规范，否则不可用；3) 迁移成本——DCR→CIMD 的迁移涉及现有已注册客户端，需重新注册；4) 回滚——加硬失败需回滚路径。评估方法：盘点现有客户端/授权服务器兼容性、评估改动范围、分阶段实施（先支持后强制）、双跑验证、保留回滚。工作量取决于现有体系复杂度，兼容性风险最高在旧客户端迁移。

认证加硬提升安全但带来迁移成本。评估要"盘点现有兼容性 + 分阶段 + 双跑 + 回滚"。RFC 9207 与 CIMD 的改动集中在授权流程与注册机制，旧客户端迁移是主要风险。

• 理解 MCP Apps 与 EMA 扩展
• 掌握协同应用场景
• 理解落地边界

MCP Apps 与 Enterprise Managed Authorization（EMA）是 MCP 的两个新扩展。MCP Apps 定义"应用"抽象——把一组 MCP Server/能力打包为可安装、可管理的应用，面向用户/企业提供应用级能力（如"销售应用"包含 CRM、邮件等工具）。EMA 定义"企业托管授权"——由企业集中管理对 MCP Server 的授权（统一策略、scope、审批、审计），而非逐用户授权。协同应用场景：SaaS 平台中，企业通过 MCP Apps 安装/管理应用（能力包），EMA 提供企业级统一授权（谁能用哪个应用/工具、scope、审批），两者结合——Apps 定义"能力清单"，EMA 定义"谁能用"；平台管理者集中治理。落地边界：MCP Apps 负责"能力打包与分发"，EMA 负责"授权治理"；EMA 适合企业统一管控（合规、审计、集中策略），Apps 适合应用化管理；未用 EMA 的租户用逐用户授权，用了 EMA 的租户用企业托管授权。落地时需区分"能力分发"（Apps）与"权限治理"（EMA）的边界，避免重复。

MCP Apps 管"能力打包分发"，EMA 管"企业授权治理"。协同时 Apps 定义能力清单、EMA 定义谁能用，SaaS 平台集中治理。边界是"分发 vs 授权"，避免职责重叠。

• 理解 MCP 与 gRPC/REST 的对比
• 掌握 stdio/SSE 与 HTTP 的适配
• 理解选型原则

Agent 工具集成场景下，MCP、gRPC、REST 各有取舍：gRPC——高性能、强类型、二进制、适合内部高性能服务间调用，但需 proto 定义、跨语言生成、不适合作业外工具发现；REST——通用、简单、生态成熟，适合公开 API 与跨服务，但无运行时工具发现、schema 弱；MCP——面向 Agent 的工具发现与调用，JSON-RPC、多传输（stdio/SSE/Streamable HTTP）、Schema 描述、跨语言跨进程。为何 JSON-RPC over stdio/SSE 适合本地工具：stdio 是本地进程通信（无网络、简单、低延迟），适合本地单机工具（文件系统、CLI），SSE 支持流式返回；本地工具无需网络路由与序列化开销，stdio 最高效。为何 HTTP 适合远程：远程工具需跨网络访问，HTTP 提供标准路由、认证、负载均衡、限流、网关治理，适合远程服务、多租户、水平扩展；Streamable HTTP 兼容 HTTP 语义、可无状态化、可被标准网关处理。选型原则：本地工具用 stdio（JSON-RPC 本地通信），远程服务用 HTTP（Streamable HTTP），MCP 提供统一协议抽象覆盖两者。

选型对比是"协议适配场景"。gRPC 内部高性能、REST 通用、MCP 面向 Agent 工具发现。本地工具用 stdio（进程内、低延迟），远程用 HTTP（标准路由/认证/网关）。MCP 统一抽象两者。