MCP for Beginners 课程变更史：从 changelog.md 看 MCP 2026-07-28 规范演进与课程实战化路径

• 教程
• 文档
• 人工智能

本篇技术指南以 translations/bg/changelog.md（MCP for Beginners 课程变更日志）为骨架，系统梳理该开源课程从 2025 年 4 月立项到 2026 年 9 月的全部重大变更：包括 MCP 规范从2025-11-25基线过渡到2026-07-28最终版、无状态协议核心与扩展机制、安全性加固与依赖漏洞修复、可靠性 Sidecar 模式、以及跨 .NET/Java/TypeScript/JavaScript/Rust/Python 的多语言样例持续校验。读完本文，你将掌握该课程每个模块的引入时间、演进动因与仓库内对应的源码级证据，并了解如何在仓库中定位每一处关键实现。

一、变更日志的定位与阅读方法

changelog.md是全仓库唯一的变更总账，采用倒序时间线（最新变更在前），记录每个新模块、每次规范对齐、每轮安全审计与每处链接修正。英文源文件位于仓库根目录 changelog.md，保加利亚语翻译版即本文章的主体文档 translations/bg/changelog.md。

从源码结构看，这份日志与课程演进一一对应：01-CoreConcepts承载协议概念、02-Security承载安全文档与示例、03-GettingStarted承载入门实操、05-AdvancedTopics承载进阶主题、08-BestPractices承载最佳实践、11-MCPServerHandsOnLabs承载数据库集成实验。每次条目落地的同时都会同步更新 README.md 的课程表、study_guide.md 的思维导图，以及translations/下 48+ 语言的 i18n 翻译。

二、2026-09-09：对齐 MCP 2026-07-28 最终规范（最大规模变更）

2026 年 9 月 9 日的条目是整份日志中改动面最广的一次：将英文课程从候选发布（release candidate）与2025-11-25基线全面迁移到MCP2026-07-28最终规范，横跨 38 个英文文档文件。其核心动作如下：

• 纠正方法名：Elicitation 统一为elicitation/create，Sampling 统一为sampling/createMessage，InputRequiredResult.resultType使用"input_required"；
• 替换课程内容：将原先不准确的 Root Context 对话状态课替换为协议准确的 Roots 课，覆盖信息性文件系统提示（informational filesystem hints）、当前的多轮往返流程、安全边界与迁移选项；
• 明确废弃状态：Roots、Sampling、Logging 与动态客户端注册（DCR）在2026-07-28中被标记为 Deprecated，并写明推荐替代方案与最早移除日期；
• 保留遗留示例：仍依赖2025-11-25、HTTP+SSE、初始化握手或协议会话的样例，被明确标注为 legacy compatibility examples，而非当前实现；
• 安全指南更新：独立安全指南改用基于请求的授权（per-request authorization）与显式应用状态句柄，取代被移除的协议会话 ID；Client ID Metadata Documents 成为首选注册路径，DCR 仅作兼容；
• 稳定文件名：最终规范指南与两份安全指南移除候选发布与年份后缀，统一超链接到稳定路径；
• 新增授权示例：新增经测试的 TypeScript MCP 2026-07-28 资源服务器示例，对比首选 CIMD 与弃用的 DCR 回退方案，包含 RFC 9728 发现、JWKS 校验、按工具作用域（per-tool scopes）、12 个测试与 Auth0 配置演练；
• 翻译范围限定：本轮仅编辑英文源文件，自动生成的翻译与翻译图片保持不变。

2.1 无状态协议核心：initialize 握手与 Mcp-Session-Id 的移除

要理解这次对齐为何是"破坏性"的，需要回到规范本身。仓库的权威解读在 01-CoreConcepts/mcp-2026-07-28.md，其开篇即声明2026-07-28是"自 MCP 发布以来最大的一次修订"。

旧版（2025-11-25）在 Streamable HTTP 上调用工具必须先完成initialize握手，服务器返回Mcp-Session-Id头，后续每个请求都要携带：

POST /mcp HTTP/1.1 Mcp-Session-Id: 1868a90c-3a3f-4f5b Content-Type: application/json {"jsonrpc":"2.0","id":2,"method":"tools/call", "params":{"name":"search","arguments":{"q":"otters"}}}

会话绑定到签发它的那个服务器实例，因此水平扩展部署不得不依赖负载均衡器的粘性路由（sticky routing）和跨实例的共享会话存储。

新版（2026-07-28）让每个请求自包含：

POST /mcp HTTP/1.1 MCP-Protocol-Version: 2026-07-28 Mcp-Method: tools/call Mcp-Name: search Content-Type: application/json {"jsonrpc":"2.0","id":1,"method":"tools/call", "params":{"name":"search","arguments":{"q":"otters"}, "_meta":{"io.modelcontextprotocol/protocolVersion":"2026-07-28", "io.modelcontextprotocol/clientInfo":{"name":"my-app","version":"1.0"}, "io.modelcontextprotocol/clientCapabilities":{}}}}

任何服务器实例都能处理该请求。关键变化包括：

• initialize/initialized握手被移除（SEP-2575）：协议版本、客户端信息、客户端能力全部移入每个请求的_meta；新增server/discover方法让客户端按需提前获取服务器能力；
• Mcp-Session-Id头与协议级会话被移除（SEP-2567）：协议层不再需要粘性路由与共享会话存储。

"无状态协议"并不等于"无状态应用"。课程给出的推荐模式与 HTTP API 一致：由一次工具调用铸造显式句柄（如basket_id），后续调用中模型把它作为普通参数传回。状态因此对模型可见、可推理，且任何实例都能处理任意调用。

2.2 可路由、可缓存、可追踪的请求

三条较小的变更让无状态流量更易运维：

• Mcp-Method/Mcp-Name头在 Streamable HTTP 上为必填（SEP-2243）：负载均衡器、网关与限流器无需解析 JSON 报文即可按操作路由；服务器会拒绝头与报文不一致的请求；
• tools/list与资源读取结果携带ttlMs/cacheScope缓存元数据（SEP-2549）：仿照 HTTPCache-Control，客户端无需长连接 SSE 即可知道列表结果的新鲜度与是否可跨用户共享；
• _meta中的 W3C Trace Context 传播被正式文档化（SEP-414）：修正traceparent、tracestate、baggage键名，分布式追踪可跨客户端 SDK、MCP 服务器与下游系统串联到 OpenTelemetry 兼容后端。

2.3 扩展机制一等公民：MCP Apps 与 Tasks

SEP-2133 将扩展正式化：扩展用反向 DNS ID 标识，通过客户端/服务器能力上的extensions映射协商，在独立ext-*仓库中由委托维护者发布、独立于核心规范版本。本版本随附两个官方扩展：

• MCP Apps（SEP-1865）：服务器可发布交互式 HTML 界面，宿主在沙箱 iframe 中渲染；工具提前声明 UI 模板，宿主在运行前即可预取、缓存与安全审查。课程基础内容见 03-GettingStarted/15-mcp-apps/README.md；
• Tasks 扩展：围绕无状态模型重塑生命周期——服务器可用任务句柄应答tools/call，客户端用tasks/get、tasks/update、tasks/cancel推进；任务创建由服务器主导，tasks/list因无法在无会话场景下安全限定作用域而被彻底移除。课程明确警告：2025-11-25的实验性 Tasks API不向后兼容，需迁移。

2.4 授权加固与 Client ID Metadata Documents

六个 SEP 将授权规范向真实 OAuth 2.0/OpenID Connect 部署靠拢：客户端必须按 RFC 9207 校验授权响应中的iss参数（缓解 MCP 单客户端多服务器模式下的混淆代理攻击，SEP-2468）；兼容性 DCR 客户端声明 OpenID Connectapplication_type（SEP-837）；兼容性注册凭据绑定到签发授权服务器的issuer（SEP-2352）；补充刷新令牌请求（SEP-2207）、升级授权中的作用域累积（SEP-2350）与.well-known发现后缀（SEP-2351）的说明。

DCR 在2026-07-28中仅保留兼容性并标记弃用，新实现应使用Client ID Metadata Documents（CIMD）——以稳定 HTTPS URL 作为client_id。仓库配套的 TypeScript 示例 02-Security/samples/cimd-dcr-auth/README.md 完整展示了两种机制的对比：CIMD 是首选路径，DCR 作为registration_endpoint广告时的回退，全部机制均不可用时才回落到预注册客户端信息。示例采用 MCP 官方 TypeScript SDK v2 与无状态2026-07-28请求模型，服务器仅校验访问令牌而不签发令牌，并通过 RFC 9728 发现、JWKS 校验、按工具作用域与 12 个测试保障正确性。

2.5 全量 JSON Schema 2020-12 与废弃特性清单

工具inputSchema/outputSchema提升为完整 JSON Schema 2020-12（SEP-2106）：输入模式保留type: "object"根约束但允许组合（oneOf/anyOf/allOf）、条件与引用（$ref/$defs）；输出模式不受限制，structuredContent可为任意 JSON 值；实现不得自动解引用外部$refURI，且应限制模式深度与校验时间以防 DoS。此外，资源缺失的错误码从 MCP 自定义的-32002改为 JSON-RPC 标准的-32602（Invalid Params，SEP-2164），按字面值匹配-32002的客户端需要更新。

在特性生命周期策略（SEP-2577）下，Roots、Sampling、Logging、DCR 均标记为 Deprecated，其推荐替代方案如下：

这些特性在2026-07-28中仍可兼容使用，最早可于 2027 年 7 月 28 日之后发布的首个规范修订版中移除。

三、2026-07-29：可靠性 Sidecar 与安全重试（模块 08）

2026 年 7 月 29 日的条目为课程新增供应商中立的伴随课：针对会产生真实世界影响的 MCP 工具，对齐最终2026-07-28规范，讲解稳定操作键、原子重复接纳（atomic duplicate admission）、对账（reconciliation）、证据（evidence）与 Tasks 扩展边界。并配套一个仅用 Python 标准库与 SQLite 的故障注入练习，用独立的 operation store 与 ticket store 演示"外部效果已提交但响应丢失"的场景，六个确定性测试覆盖朴素重复、受保护的崩溃重启恢复、载荷冲突、缓存结果、活跃声明与并发重复接纳。同时，模块 08 现在区分 OpenTelemetry 可观测性与已废弃的 MCP logging 特性，并将通用重试示例限定为只读操作。

3.1 为什么超时意味着"结果未知"

08-BestPractices/reliability-sidecars/README.md 的开篇用一句话点明核心命题："响应缺失并不等于动作缺失"。支持工单工具可能已创建工单T-0001，却在客户端看到结果前断开连接；客户端盲目重试就可能创建T-0002。

侧车模式的关键时序如下：客户端以操作键op-login-ticket-0001调用create_support_ticket→ 工具先在 operation store 中声明（claim）该键 → 创建工单并提交T-0001→ 回复丢失 → 客户端用同一操作键重试 → 工具读取既有声明 → 通过键在工单系统中查到T-0001→ 保存已验证结果并返回T-0001。复用操作键让工具找到并返回既有工单，而不是制造重复。

3.2 四类 ID 各司其职

侧车模式的正确性依赖对四个相关但不可互换的标识符的理解：

进度通知与追踪上下文用于观察请求，取消（cancellation）请求停止工作——但它们都无法阻止重复工单的产生。

3.3 构建防护：工具模式、声明与状态机

课程给出了完整的 MCP 工具模式。工具create_support_ticket的输入与输出模式均使用 JSON Schema 2020-12 方言，operation_key约束为 16–128 个字符、必填，且additionalProperties: false：

{ "name": "create_support_ticket", "title": "Create support ticket", "description": "Creates or recovers one support ticket for an operation key.", "inputSchema": { "$schema": "https://json-schema.org/draft/2020-12/schema", "type": "object", "properties": { "operation_key": { "type": "string", "minLength": 16, "maxLength": 128, "description": "Stable key reused for the same intended action." }, "title": { "type": "string", "minLength": 1, "maxLength": 200 } }, "required": ["operation_key", "title"], "additionalProperties": false }, "outputSchema": { "$schema": "https://json-schema.org/draft/2020-12/schema", "type": "object", "properties": { "ticket_id": { "type": "string" }, "operation_key": { "type": "string" }, "status": { "type": "string", "const": "verified" } }, "required": ["ticket_id", "operation_key", "status"], "additionalProperties": false } }

从仓库实现 08-BestPractices/reliability-sidecars/python/reliability_sidecar.py 可以看到防护的具体落地：

• 调用者身份来自服务器上下文，而非模型提供的工具输入——Python 方法签名中的caller_id只是服务端上下文的占位，绝不能加入模型可控的 MCP 输入模式；
• 作用域绑定：每个存储的操作都绑定到调用者/租户/服务账号、工具名与版本（TOOL_ID = "create_support_ticket:v1"）、以及定义外部动作的规范化输入哈希（_input_hash用hashlib.sha256对排序键的 JSON 计算）。若同一键已被不同 title 占用，则抛出OperationKeyConflict——用旧结果回应已变更的输入会掩盖契约错误；
• 原子声明：_claim使用 SQLite 的BEGIN IMMEDIATE加INSERT OR IGNORE，主键为(caller_id, tool_id, operation_key)，保证两个并发工作者不可能同时观察到空记录并同时成为所有者——进程内锁在另一服务器实例接收重试时并不够；
• 状态机：动作以planned创建，随后持久化claimed（一个工作者保留操作）、completed（工单系统返回结果）、verified（从工单系统的读取确认结果）。崩溃可能让存储状态停留在claimed即使工单已创建，因此每个非终结声明在外部证据落定前都应视为不确定。

3.4 先恢复再重试：对账决策流

工具调用失败时，先判定已知信息再发送下一次外部写入。课程给出了决策流程：调用失败后判断是否发生在外部调用之前——若是，则用同一操作键重试未变动作；若不确定，先检查工单系统——恰好一个匹配则验证并返回；证据确凿缺失且下游契约允许另一次尝试才重试；未知或冲突则停下上报outcome unknown。这种"停止"被形象地称为failing closed：工作流拒绝猜测。"未找到"并不总是结论性的——搜索最终一致（eventually consistent）的提供商可能需要有界等待与再次检查。

3.5 证据、Tasks 与取消的边界

最强的证据来自拥有结果的系统：对本例而言，就是从工单系统读到的恰好一条匹配工单。证据要与风险匹配：提供商消息 ID 对低风险通知可能足够，而支付、部署与破坏性动作可能需要提供商状态、账本或人工审查证据。

Tasks 扩展与侧车互补但不能替代：Task ID 让客户端在断线后恢复轮询，但它不标识也不去重工单本身。二者连接关系为：

operation key -> Task ID -> ticket ID -> verification evidence

取消是协作式的而非回滚——取消被确认后工单仍可能被创建，因此不确定结果仍需要对账。

3.6 运行故障注入练习

练习使用两个 SQLite 文件：一个代表 operation store，另一个代表外部工单系统，两者之间没有跨文件事务。故障在工单提交之后、侧车记录完成之前注入。预期结果对比如下：

运行命令：

cd 08-BestPractices/reliability-sidecars/python python -m unittest discover -p "test_*.py" -v

六个测试在 test_reliability_sidecar.py 中逐一验证：盲目重试产生重复；响应丢失加重启能从持久声明恢复一张工单；已验证重试复用已存结果；变更输入或冲突外部证据被拒绝；无外部证据的既有声明安全停止；并发声明只接纳一个所有者且不回归已验证结果。实现还有意省略了陈旧声明租约（stale-claim leases），因为生产接管策略需要有界租约、原子所有权转移与执行前的另一次外部检查。

生产检查清单同样值得全文引用：在第一次外部尝试前创建并保存操作键；将键绑定到调用者、工具版本与规范化输入哈希；拒绝已有键下的变更输入；用原子共享存储操作接纳唯一所有者；当提供商支持幂等时向下游转发该键；在另一次写入前对不确定结果对账；在整个重试窗口内保留已验证结果与证据；当无法安全确立外部结果时停下审查。

四、2026-07-02：发布候选教程与前瞻指引

2026 年 7 月 2 日新增了对2026-07-28规范发布候选的覆盖（2026 年 5 月 21 日宣布，最终版定于 7 月 28 日发布）。课程基线在正式发布前仍保持2025-11-25，因此该内容以"前瞻指引"而非改写形式呈现。核心教程为 01-CoreConcepts/mcp-2026-07-28.md，覆盖：无状态协议核心（移除initialize握手与Mcp-Session-Id）、新路由头Mcp-Method/Mcp-Name、ttlMs/cacheScope缓存元数据、_meta中的 W3C Trace Context、正式扩展框架（MCP Apps 与 Tasks 扩展）、六个授权加固 SEP、Roots/Sampling/Logging 的废弃，以及工具模式转向完整 JSON Schema 2020-12。

同时，课程在 11 个文档中埋入前瞻提示（forward-looking callouts）：01-CoreConcepts/README.md 的协议版本说明与 Sampling/Roots/Logging/Tasks 分区、02-Security/README.md 的授权加固、03-GettingStarted/06-http-streaming/README.md 的无状态传输、03-GettingStarted/14-sampling/README.md 的 Sampling 废弃、05-AdvancedTopics/mcp-protocol-features/README.md 的 Logging 废弃与 Tasks 扩展、05-AdvancedTopics/mcp-transport/README.md 的无状态/会话路由、README.md 的"Looking ahead"备注与课程表新条目 1.1、study_guide.md 的前瞻要点、03-GettingStarted/11-simple-auth/README.md 的mcp-session-id传输映射说明，以及 05-AdvancedTopics/README.md 与 05-AdvancedTopics/mcp-security/README.md 的模块级提示。

五、2026-06-16：规范对齐、样例验证与安全加固

2026 年 6 月 16 日的条目验证课程对齐MCP Specification 2025-11-25与最新官方 SDK，并修复残余的过期规范引用。

5.1 规范版本修正

将多处仍声称旧规范（2025-06-18/2025-03-26）为"当前标准"的英文内容更新为2025-11-25：包括 05-AdvancedTopics/mcp-security/README.md 的 8 处引用、05-AdvancedTopics/mcp-transport/README.md 的横幅与链接、05-AdvancedTopics/mcp-realtimesearch/README.md 的安全链接、03-GettingStarted/14-sampling/README.md 的官方文档链接，以及 03-GettingStarted/05-stdio-server/README.md 的规范引用（并保留 SSE 弃用的历史注释以保证准确性）。

5.2 SDK 验证与依赖对齐

样例经过真实构建验证：TypeScript 示例npm install解析到@modelcontextprotocol/sdk@1.29.0，tsc --noEmit无类型错误，McpServer/StdioServerTransportAPI 仍然有效；Python 示例在隔离.venv中以mcp[cli]1.27.2 验证，py_compile通过且FastMCP.list_tools()正确返回add与subtract工具。所有样例的 SDK 版本区间（>=1.26.0/^1.26.0/^1.27.0）都能干净解析到1.29.0。

依赖钉版（dependency pin）也做了对齐：03-GettingStarted/05-stdio-server/solution/typescript/package.json 将@modelcontextprotocol/sdk从^1.8.0提升到>=1.26.0；10-StreamliningAIWorkflowsBuildingAnMCPServerWithAIToolkit/lab3/code/weather_mcp/pyproject.toml 与 lab4 的 pyproject.toml 将mcp==1.23.0提升为mcp>=1.26.0，并重新生成uv.lock以解析到mcp 1.27.2。

课程空白分析确认所有2025-11-25新增/扩展的基元都有覆盖：Sampling（03-GettingStarted/14-sampling/README.md 与 05-AdvancedTopics/mcp-sampling/README.md）、Elicitation 含 URL 模式（01-CoreConcepts/README.md 与 05-AdvancedTopics/mcp-protocol-features/README.md）、Roots（00-Introduction/README.md、01-CoreConcepts/README.md 与 05-AdvancedTopics/mcp-root-contexts/README.md）、Tasks（实验性、长期运行操作）与工具注解（readOnlyHint/destructiveHint）。

5.3 npm 与 Python 依赖漏洞修复

全量审计 15 个package-lock.json文件后，npm audit在所有受检目录中报告0 漏洞。修复集中在 MCP Inspector、OpenAI 客户端与 MCP SDK 引入的传递依赖：@modelcontextprotocol/inspector从0.16.6/0.14.1提升到0.22.0（清除ajv、brace-expansion、diff、path-to-regexp、ws告警），并以 npmoverrides强制打补丁后的shell-quote@1.8.4消除concurrently携带的严重告警；qs、hono、form-data分别通过npm audit fix升级到补丁版本；11-simple-auth 的 TypeScript 方案 补生成缺失的package-lock.json。

Python 侧用pip-audit审计所有 requirements：05-AdvancedTopics与03-GettingStarted/samples/python无已知漏洞；09-CaseStudy/docs-mcp/solution/python/requirements.txt 中的传递依赖werkzeug3.1.1 因safe_join的 Windows 设备名 DoS（CVE-2025-66221、CVE-2026-21860、CVE-2026-27199，均在 3.1.6 修复）被显式钉版werkzeug>=3.1.6。

5.4 代码级安全修复（OWASP A03：注入）

10-StreamliningAIWorkflowsBuildingAnMCPServerWithAIToolkit/lab4/code/github_mcp_server/src/server.py 中的open_in_vscode工具移除了shell=True：此前subprocess.run(["start", "", vscode_path, folder_path], shell=True)允许文件夹路径中的 shell 元字符被cmd.exe解释，构成命令注入向量；现在直接以参数形式启动解析后的Code.exe，功能等价且安全。

5.5 产品更名

课程内容同步反映微软产品更名：Azure AI Foundry → Microsoft Foundry（影响 05-AdvancedTopics/mcp-foundry-agent-integration/README.md 等 14 处）、AI Toolkit / AITK → Microsoft Foundry Toolkit 扩展 for VS Code（影响 10-StreamliningAIWorkflowsBuildingAnMCPServerWithAIToolkit/README.md 及其 lab1–lab4 共 7 处）。

六、2026 年更早的里程碑：新增课程与导航改进

6.1 2026-06-24：Copilot 应用中的 MCP

新增 工具章节 与 MCP in Copilot app，配套资产见 12-tooling/01-copilot-app/assets。

6.2 2026-04-11：对抗性多智能体推理（课程 5.17）

新增 05-AdvancedTopics/mcp-adversarial-agents/README.md，覆盖对抗性辩论模式：Mermaid 架构图（双智能体 → 共享 MCP 服务器 → 辩论记录 → 裁判 → 裁决）、Python/TypeScript 实现的共享工具服务器（web_search+run_python）、FOR/AGAINST/Judge 对立系统提示、Python/TypeScript/C# 辩论编排器、真实工具调用的ClientSession接线、用例表（幻觉检测、威胁建模、API 设计审查、事实核验、技术选型）与安全考量（沙箱执行、工具调用校验、限流、审计日志）。同期修复了 03-GettingStarted/05-stdio-server/README.md 中缺失的new StdioServerTransport()与server.connect(transport)。

安全修复同样落地于此：TypeScriptrun_python工具用execFile+promisify取代execSyncshell 插值，消除命令注入面（LLM 控制的代码以字面 argv 元素传入，无 shell 参与）；Python 辩论编排器改用AsyncAnthropic客户端，每个回合注入实时ClientSession，通过session.list_tools()拉取工具定义，循环用session.call_tool()派发tool_use块直至模型输出最终文本。依赖同步提升hono至 4.12.12、@hono/node-server至 1.19.13、cryptography至 46.0.7、lodash至 4.18.1。

6.3 2026-02-05：MCP Hosts、MCP Inspector 与分页

新增三个实操指南：12-mcp-hosts/README.md（Claude Desktop、VS Code、Cursor、Cline、Windsurf 配置示例、JSON 模板、传输类型对比表、连接故障排查、主机配置安全最佳实践）；13-mcp-inspector/README.md（npx/npm 全局/源码三种安装方式、stdio 与 HTTP/SSE 连接、工具/资源/提示词测试工作流、VS Code 集成、常见调试场景）；pagination/README.md（Python/TypeScript/Java 游标分页、客户端分页、不透明 vs 结构化游标设计、性能优化建议）。同期完成 24+ 文件的导航修正，修复gpt-4o-mini→gpt-4.1-mini、READMEmd→README.md等错误。

6.4 2026-01-28：2025-11-25 规范合规审查与安全文档大更新

核心概念课新增 Roots 客户端基元、工具注解（readOnlyHint/destructiveHint）、Sampling 中tools/toolChoice参数、URL 模式 Elicitation、实验性 Tasks 与图标元数据支持。安全目录（02-Security/README.md）整合 MCP Security Summit Workshop（Sherpa）与 OWASP MCP Top 10：新增风险表、将mcp-security-controls.md与 OWASP 风险（MCP01–MCP08）关联、在 mcp-best-practices.md、azure-content-safety-implementation.md 等文档中补齐资源。全课程各模块更新 SDK 列表（新增 Go、Swift、Rust SDK）并统一2025-11-25规范引用。

6.5 2025-12-18：安全文档规范版本更新

02-Security/mcp-best-practices.md 全面更新到 2025-11-25 规范，验证 Microsoft 安全方案术语（Prompt Shields、Azure Content Safety、Entra ID、Azure Key Vault）、OAuth 2.1、OWASP Top 10 for LLMs 与 NIST AI RMF、ISO 27001:2022 等标准的时效性，并确认所有 MUST/MUST NOT 强制要求与最新规范一致。

七、2025 年下半年的课程扩张：从入门到生产

• 2025-10-06：新增 10-advanced（常规 vs 低层服务器架构对比、基于 handler 的工具/资源/提示词管理、实战模式）与 11-simple-auth（认证 vs 授权概念、Python Starlette 与 TypeScript Express 中间件实现、向 OAuth 2.1 与 RBAC 的演进路径）。
• 2025-09-29：新增 11-MCPServerHandsOnLabs 完整 13 个实验室学习路径，以 Zava Retail 分析为用例，覆盖 PostgreSQL + pgvector、Azure OpenAI embeddings、Azure Container Apps、Application Insights，含 Row Level Security、语义搜索、多租户访问、实时监控；并将全部 13 个实验室的"Module"术语统一为"Lab"。
• 2025-09-26：09-CaseStudy/README.md 大幅扩展，新增 GitHub MCP Registry 案例（问题分析、集中式注册表与 VS Code 一键安装方案、生态影响），并将全部七个案例统一格式。
• 2025-09-15：新增 mcp-transport（Azure Event Grid 与 Event Hubs 自定义传输、C#/TypeScript/Python 示例、安全与可观测性、测试框架）与 mcp-contextengineering（上下文共享、决策感知、上下文窗口管理、单线程 vs 多智能体、测量框架）；同时将05-AdvancedTopics目录统一为mcp-[主题]命名。
• 2025-08-18：安全文档全面现代化——02-Security/mcp-security-best-practices.md 重写为对齐 2025-06-18 规范的 12 项核心安全实践，mcp-security-controls.md 扩展为 9 个企业级安全域，05-AdvancedTopics/mcp-security/README.md 重写为生产就绪实现（Entra ID、Prompt Shields、Azure Content Safety、PKCE/Confused Deputy 缓解、令牌透传防护、会话劫持防护）；01-CoreConcepts/README.md 也完成现代化，引入 Hosts/客户端/服务器架构澄清、双层架构模型（数据层 + 传输层）与全套基元重构。
• 2025-07-16：彻底重做 README.md 导航（以表格取代<details>标签），新增alternative_layouts文件夹，丰富 06-CommunityContributions/README.md（图像生成 MCP 服务器、Claude in VSCode、Cline 终端客户端），并创建本变更日志。
• 2025-06-11 至 2025-04-15：课程首版发布（10 大主分区结构、可视化课程地图、多语言初始样例），随后回溯到 2025-04-15 的规划与框架阶段（学习目标、目标受众、概念框架、关键概念的初始原型）。

八、课程演进脉络总结

纵览这份日志，可以提炼出四条清晰的演进主线：

1. 规范版本驱动：2025-06-18→2025-11-25→2026-07-28（含发布候选），每次规范更新都触发全仓库引用修正、样例重建与安全标准对齐，最新状态在 README.md 中明确标注"当前协议修订版为 MCP Specification 2026-07-28"；
2. 从入门到生产：课程内容从基础概念、入门服务器逐步扩展到高级主题（自定义传输、上下文工程、对抗性智能体）、实践指南（分页、Hosts、Inspector）与 13 个数据库集成实验室，最终进入最佳实践与案例研究；
3. 安全贯穿始终：从 2025-08 的安全文档现代化，到 OWASP MCP Top 10 与 Sherpa 工作坊整合、npm/pip 依赖审计清零、代码级注入修复，再到 2026-07 的授权加固与 CIMD/DCR 示例，安全是课程迭代中最频繁的主题之一；
4. 翻译与国际化：几乎所有重大变更后都同步 48+ 语言的翻译（如 2026-04-11 条目所示），本文章所在的 translations/bg/ 目录即这一流程的产物。

对于希望跟踪 MCP 规范演进、或需要一套"规范更新 + 样例验证 + 安全加固"模板的开发者而言，这份 changelog 与仓库中的源码、测试与配置共同构成了完整的可追溯证据链。

• 教程
• 文档
• 人工智能