企业官网建设流程全解析

MCP 实战手记系列（一）· 总纲篇

这个系列的起因很朴素：MCP 火了快两年，但我发现自己一直在"会用"和"真懂"之间反复横跳。所以干脆开个系列，边动手边写，把 MCP 从协议到落地过一遍。

面向一线开发者，重实操，不写空话。每篇都会有一个我亲手跑过的东西。

系列（一）先解决一个前提问题：MCP 现在到底发展到哪一步了？9 月 9 日 Microsoft 办的 MCP Live，半天 8 场演讲，正好是最新的官方答案。

最大的变化：2026-07-28 规范，MCP 变无状态了

7 月 28 日的规范更新，是 MCP 自 2024 年底发布以来最大的一次修订。最关键的一条：去掉了 initialize 握手和 session。

之前要先握手、分配 session ID、服务器端存状态；现在这些都没了。每个请求自带协议版本、客户端身份和能力信息，发到哪个服务器实例都能处理，不需要共享存储，也不需要粘性会话。

GitHub 的 MCP Server 是最早吃上这波红利的——7 月 23 日就完成适配，直接去掉了 Redis session 读写。少一次数据库读，少一次数据库写，调用延迟降了多少没说，但方向是对的。

配套的更新还有几个：

• 工具需要用户补信息时返回input_required，客户端收集后重试，替代了原来的 elicitation 双向流
• HTTP 头带Mcp-Method和Mcp-Name，网关和 WAF 不用解析 JSON body 就能路由和鉴权
• tools/prompts/resources 列表支持ttlMs缓存，不用每次都拉
• Roots、Sampling、Logging 正式弃用，给 12 个月过渡期

四个 Tier 1 SDK（TypeScript、Python、Go、C#）已经全部支持新规范。

无状态改造要动哪些代码，我在系列（三）《把 MCP Server 改成无状态》里已经跑完了——从 session 版改到每请求自包含，配套代码随后同步放出。

授权体系大换血：DCR 不行了，换 CIMD

MCP Auth 占了两个演讲时段，说明这事分量不轻。

先说结论：DCR（动态客户端注册）正式弃用，转向 CIMD（Client ID Metadata Documents）。

DCR 的问题很实际——每次用户把客户端连到 MCP 服务器都要注册一个新client_id，数据库越涨越大，过期了客户端也不知道，同一应用在不同设备上有好几个 ID，而且未认证的注册端点本身就是 DoS 靶子。

CIMD 的思路很简单：客户端别注册了，直接用一个 HTTPS URL 当client_id。授权时服务器去 GET 这个 URL 拿 metadata（应用名、回调地址），按需获取、可缓存。一个应用一个 URL，不会因为换设备换用户就产生多个 ID，也没有注册端点被滥用的问题。

但 CIMD 只解决操作问题，不解决身份冒充。有人注册恶意回调 URI 冒充 Claude Desktop，或者在本地跑恶意应用冒充合法客户端，这些 CIMD 防不了。长期方向是平台级应用证明（macOS/Windows 的应用签名）和软件声明（客户端后端签发 JWT 证明身份）。

企业级那边EMA（Enterprise-Managed Authorization）已经稳定了。组织通过 IdP 集中管 MCP 服务器访问，用户第一次登录就能自动连上授权过的服务器，不用每个应用单独走 OAuth。Okta 是第一个支持的 IdP，Claude 和 VS Code 已经用上。

CIMD 的client_id长什么样、自己搭要几行代码，系列（四）里搭个最小可用的出来。

Foundry Toolboxes：把所有工具塞进一个 MCP 端点

Microsoft 在 Foundry 里推了 Toolboxes，定位是"统一 MCP 端点"。

Web Search、代码解释器、文件搜索、Azure AI Search、MCP servers、OpenAPI 工具、Agent-to-Agent 连接——全部聚到一个 MCP 兼容的端点后面。Agent 连一个 URL，运行时就能发现所有工具。

企业场景下价值很直接：统一配置（不用每个 Agent 各接一套）、集中治理（认证和 guardrails 统一走）、版本管理（开发者/消费者端点分离，可灰度）、运行时工具搜索。

说白了，MCP 不再只是"Agent 调工具"的协议，正在变成企业内部工具服务的统一接入层。

这种"一个端点聚合所有工具"的网关，自己能不能用开源方案搭一个？系列（六）里试试。

事件驱动 Agent：Triggers & Events 还在实验阶段

Triggers & Events 是个实验性扩展，目标是让 MCP 服务器能主动通知客户端状态变化，不用客户端一直轮询。

现在的模式要么是客户端持续 polling，要么保持 SSE 连接开着。Triggers & Events 想标准化 webhook 式的 callback，服务器有变化就主动推。

这个方向和 Tasks 扩展是配合的——任务完成时触发通知，不用客户端一直问"好了没"。对长时间运行的 Agent 工作流来说，这是从轮询转向事件驱动的关键一步。

目前还在工作组阶段，AWS 和 Anthropic 的人牵头。

这个还没定稿，我不会现在就写实操。等规范稳定后再补一篇。

FastMCP Apps：工具返回的不只是文字，还可以是 UI

MCP Apps 是第一个官方扩展，允许工具返回交互式 UI 组件——仪表盘、表单、可视化、多步工作流——直接渲染在对话里。

实现上不复杂：工具声明_meta.ui.resourceUri指向 UI 资源，宿主在沙箱 iframe 里渲染，postMessage 双向通信。ChatGPT、Claude、Goose、VS Code 都支持了。FastMCP 4 也在 8 月底发布，全面支持 2026-07-28 规范。

这个我最想动手——让工具返回能点能填的 UI，系列（五）里写个真能跑的例子。

几个实际判断

MCP Live 的内容不少，但对国内做 Agent 的团队来说，有几件事是现在就该考虑的。

MCP 已经不是玩具级协议了。无状态化、企业授权、集中治理、事件驱动，全是生产级基础设施的特征。还在手写 MCP Server 连几个工具的团队，该考虑升级架构了。

安全和治理得提前规划。国内团队接 MCP Server 时，安全普遍做得随意：API key 硬编码、权限给太大、没有审计日志。EMA、CIMD、身份断言这一套，国内 IdP 支持还需要时间，但方向是对的——MCP 安全不只是"别把 key 泄露出去"，而是身份、授权、审计、治理整套。

第三点是我自己最没底的：事件驱动大概是下一个方向。眼下多数 Agent 还是"说一句动一下"的请求响应模式，可真正值钱的企业场景——监控告警、数据同步、任务调度——全是事件驱动的。Triggers & Events 还在实验阶段，但值得提前盯着。

最后一点偏观察：国内生态会走自己的路。国外围着 Claude、ChatGPT、VS Code 转，国内 DeepSeek、智谱、通义也都在推自己的 Agent 平台。MCP 作为事实标准大概率会被兼容，但企业级授权、身份体系和合规，一定是本土化的。

8 场演讲的录播都放出来了，在 Microsoft Tech Community 搜 MCP Live 就能找到。信号挺明确：MCP 正在从"能用"走向"生产级可用"。这个过程里，越早把无状态和授权这两件事想清楚，后面返工越少。

MCP 实战手记系列路线图

这是系列（一），先把"MCP 现在到哪一步"这件事说清楚。后面每篇都会配一个我亲手跑过的实例。

后面几篇会逐步放出，关注我，更新第一时间能看到。也欢迎在评论区告诉我你最想先看哪一篇——我会根据反馈调整顺序。

参考：

• MCP 2026-07-28 规范更新
• 客户端注册演进：从 DCR 到 CIMD
• MCP Live 完整录播