MCP 架构与 2026 Stateless Core

1. 为什么这组知识要一起学

本章以 MCP 2026-07-28 为基线。旧版 initialize/session、Roots/Sampling/Logging 只用于理解迁移，不作为 Shadow Harness 新设计目标。

这几个知识点处在同一条工程链上。如果只记单个名词，很容易在真实系统里把责任放错层：例如让模型管理程序事实、让数据库 transaction 承担外部 API 原子性，或把一个 provider SDK 的行为误认为 Agent 的通用规律。

2. Mental Model

MCP 是 AI 应用与外部能力的协议边界，不是 Agent Runtime。2026-07-28 以后协议核心是 stateless request/response。

Host → MCP Client → self-describing JSON-RPC request + headers → MCP Server → result / MRTR input_required / task handle

3. 核心机制

MCP Host / Client / Server

Host 是应用/权限与用户边界，Client 负责协议调用，Server 暴露工具/资源等能力。不要把 Server 误当成整个 Agent。

JSON-RPC Mental Model

MCP 方法基于 JSON-RPC request/result/error 语义；协议 adapter 应把 transport/protocol error 翻译成内部错误类别。

2026 Stateless Core

2026-07-28 移除了 initialize/initialized 与 Mcp-Session-Id；每个 request 在 _meta 携带版本/客户端能力，server/discover 可选。

4. 最小实现 / 伪代码

下面代码只表达边界和生命周期，不要求照抄到项目中：

class McpToolAdapter:
    async def call(self, call):
        request = self.codec.to_mcp(call)
        response = await self.client.request(request)
        return self.codec.from_mcp(response)

真正实现时应把 I/O、状态持久化、错误翻译和策略注入拆成可测试组件，而不是把示例扩成一个巨型函数。

5. 在 Shadow Harness 中怎么落地

MCP Adapter 把远程 Tool/Resource/Extension 映射到内部 contract；Runtime 不直接依赖 SDK 类型和 protocol session。

建议为本章涉及的行为留下明确的 domain object、interface 和 trace event；只要一个关键行为只能通过读日志猜测，就说明 Runtime contract 仍不够清晰。

6. Production Engineering 检查项

• 2026-07-28 不再依赖 initialize/session
• catalog 可 cache 且顺序稳定
• authorization 遵循 issuer/resource boundary
• deprecated feature 只做迁移兼容

7. Failure Modes

7.1 按 2025 session 模型设计新服务

当出现「按 2025 session 模型设计新服务」时，用 protocol trace 对照 2026-07-28 request headers/_meta/result/error/extension contract，避免拿旧 session 语义解释新协议。 这类问题通常需要修改 contract、policy、state 或 adapter，而不是只追加 Prompt。

7.2 把应用 state 藏 transport session

当出现「把应用 state 藏 transport session」时，用 protocol trace 对照 2026-07-28 request headers/_meta/result/error/extension contract，避免拿旧 session 语义解释新协议。 这类问题通常需要修改 contract、policy、state 或 adapter，而不是只追加 Prompt。

7.3 把 MCP server 当可信代码

当出现「把 MCP server 当可信代码」时，用 protocol trace 对照 2026-07-28 request headers/_meta/result/error/extension contract，避免拿旧 session 语义解释新协议。 这类问题通常需要修改 contract、policy、state 或 adapter，而不是只追加 Prompt。

7.4 忽略 tool schema/extension 版本

当出现「忽略 tool schema/extension 版本」时，用 protocol trace 对照 2026-07-28 request headers/_meta/result/error/extension contract，避免拿旧 session 语义解释新协议。 这类问题通常需要修改 contract、policy、state 或 adapter，而不是只追加 Prompt。

8. Trade-offs

标准协议提高互操作但增加 adapter/version complexity；内部 contract 可保护核心 Runtime 不受协议演进冲击。

设计记录最好明确：当前约束是什么、备选方案有哪些、为什么现在选这个、未来什么条件出现时需要重构。 这样 ADR 才能随着模型和基础设施变化被重新审视。

9. Experiment / Evaluation

用 conformance/contract test 固定 tools/list、tools/call、MRTR、task、auth/error translation；模拟多实例随机路由。

实验应固定数据集、版本和环境，至少记录 success、latency、token/cost、attempt/step 数以及失败类型；涉及随机模型时需要重复运行而不是只看一次结果。

10. 常见问题

基础：MCP Host / Client / Server 最容易被误解的点是什么？

Host 是应用/权限与用户边界，Client 负责协议调用，Server 暴露工具/资源等能力。不要把 Server 误当成整个 Agent。

机制：这些能力在一次 Run 的哪个生命周期阶段生效？

沿着 Host → MCP Client → self-describing JSON-RPC request + headers → MCP Server → result / MRTR input_required / task handle 找位置，并明确它的输入、输出、持久化事实和失败传播。

工程：如果这一层失败，应该由谁恢复？

先区分 transient failure、invalid input、permission、semantic failure 与 irreversible side effect。恢复策略属于拥有该状态与副作用的 Runtime/adapter，而不是交给模型自由决定。

设计：规模扩大 10 倍后，哪个假设最先失效？

优先检查 context/token、并发/连接池、catalog 大小、持久化吞吐、trace 体积、身份与租户隔离。不要默认“多加机器”能解决语义和一致性问题。

11. Sources

• MCP — 2026-07-28 Specification
• MCP — Release Candidate technical detail
• Model Context Protocol

12. 本文结论

掌握本文的标准不是能背定义，而是能画出数据流、写出最小 contract、解释失败恢复，并用测试或 benchmark 证明设计没有只停留在概念层。