MCP 协议详解：从原理到测试的完整指南

导语 ：作为一名在测试领域摸爬滚打多年的工程师，当我第一次看到 Agent 能自动打开浏览器、查数据库、建缺陷单时，我的第一反应是：这玩意儿到底靠不靠谱？权限怎么控？结果怎么验？ 答案就在 MCP（Model Context Protocol，模型上下文协议）。本文不堆概念，把 MCP 的架构、原语、传输、安全、测试落地一条线讲透，并给出可直接复用的实战模板。读完你不仅能讲清楚 MCP，更能回答面试官那句："AI 测试你怎么做工程化管控？"

---

一、先给结论：MCP 到底是什么

MCP（Model Context Protocol） 是 Anthropic 于 2024 年 11 月开源、现由 Linux Foundation 下 Agentic AI Foundation（AAIF） 治理的开放协议。一句话：

MCP = 让任意 AI 应用，用同一套协议，连接任意外部工具与数据源。

它的定位常被类比为：

• USB-C：统一"设备 × 外设"的连接标准
• LSP（语言服务器协议）：编辑器 × 编程语言的通用接口

技术本质是：基于 JSON-RPC 2.0 的客户端-主机-服务器协议，运行在 stdio 或 Streamable HTTP 之上，规定两端如何发现能力、读写资源、调用工具、执行提示词模板。

对测试工程师最关键的认知：

MCP 解决的不是"模型聪不聪明"，而是 "模型和企业系统之间接口的标准化" 。没有 MCP 时是 N × M 集成，有了 MCP 变成 N + M：

3 个 AI 工具 × 5 个系统 = 15 套对接代码   ← 以前
3 个 Client 实现 + 5 个 Server 实现 = 8    ← 现在

当前规范版本为 2026-07-28（最新修订），所有 Tier 1 SDK（TypeScript、Python、Go、C#）均已支持；其前版 2025-11-25 仅用于兼容旧客户端。

---

二、为什么测试同学必须懂 MCP

作为测试工程师，我关心的永远是三件事：可控、可验、可追溯。传统 AI 写测试脚本的痛点，MCP 恰好能解：

痛点	没有 MCP	有 MCP
模型不知道系统长啥样	硬编码 prompt	Server 暴露 schema，自动发现
模型点不了浏览器/查不了库	自己造工具	Playwright / DB MCP 即用
换模型/换平台	集成代码全重写	同一套协议，换 Client 即可
Prompt 塞 API 文档	token 爆炸、易幻觉	Resource 按需读取，结构化
权限与审计	几乎空白	Host 统一管控

测试自动化在 MCP 下变成清晰的分层：

AI Agent
  └── MCP Client
        ├── Playwright MCP      → 点页面、跑 E2E
        ├── Chrome DevTools MCP → Console / Network / Lighthouse
        ├── Jira MCP            → 建缺陷、查需求
        ├── DB MCP              → 校验订单状态
        ├── Git MCP             → 定位改动范围、推测试点
        └── Allure MCP          → 读测试报告、分析失败

核心心智转变：AI 不再"猜系统"，而是通过标准协议"用系统"，且每一步都可被测试工程化管控。

---

三、核心架构：Host / Client / Server

┌──────────────────────────────────┐
│ Host（Claude / Cursor / 自研 Agent）│
│  - 管用户、权限、上下文、生命周期    │
│                                  │
│   ┌────────────┐  ┌────────────┐ │
│   │ MCP Client │  │ MCP Client │ │
│   └─────┬──────┘  └─────┬──────┘ │
└─────────┼───────────────┼────────┘
          │               │
   ┌──────▼─────┐  ┌──────▼──────┐
   │ MCP Server │  │ MCP Server  │
   │ Playwright │  │ PostgreSQL  │
   └────────────┘  └─────────────┘

1. Host（宿主）

运行 LLM 的应用层，负责：

• 创建并管理多个 Client 实例
• 控制连接权限与生命周期
• 执行安全策略与用户授权
• 聚合各 Client 的上下文

典型 Host：Claude Desktop、Cursor / VS Code + Copilot、ChatGPT / Gemini CLI、自研测试 Agent。

2. Client（客户端）

Host 内的协议适配器，每个 Client 与特定 Server 是 1:1 关系。职责：

• 发送 tools/list、resources/read、prompts/get
• 双向路由协议消息
• 维护 Server 间的隔离边界

⚠️ 架构铁律：一个 Client 只连一个 Server，Server 之间互相不可见、也读不到完整对话。 隔离是 Host 的责任，不是协议自动保证------这一点对测试环境的沙箱设计至关重要。

3. Server（服务端）

真正干活的：

• 暴露"我能干什么"（能力发现）
• 接收参数 → 执行业务 → 返回结果
• 可用 Python（FastMCP）、Node、Go、Java 实现

---

四、四大核心原语（Capability）

MCP 的精髓在于用"谁来控制"区分能力类型，这是设计测试用例时的天然分类依据：

原语	控制方	类比	测试场景	要不要写自动化用例
Tools	Model（模型）	POST/PUT 动作	点按钮、发请求、建缺陷	✅ 必测：参数校验、权限、幂等
Resources	Application（应用）	GET 数据	读用例、需求、DB 行	✅ 必测：URI 鉴权、越权
Prompts	User（用户）	模板/命令	"按回归风险生成用例"	✅ 必测：模板渲染、注入
Extensions	协商扩展	插件	Tasks 异步任务等	⚠️ 按需

Tools（模型控制）------最常用

{
  "name": "create_bug",
  "description": "在 Jira 中创建缺陷。当用户发现测试失败时调用。",
  "inputSchema": {
    "type": "object",
    "properties": {
      "title": { "type": "string" },
      "severity": { "enum": ["P0", "P1", "P2"] },
      "steps": { "type": "string" }
    },
    "required": ["title", "severity"]
  }
}

模型看到 schema 后自主决策调用：

{
  "name": "create_bug",
  "arguments": {
    "title": "登录页验证码刷新失败",
    "severity": "P1",
    "steps": "1. 打开 /login 2. 点击刷新 3. 验证码不变化"
  }
}

🔑 测试工程师注意 ：description 字段同时影响工具选择质量 和安全性 ------模型把它当作可信指令来读。微软 2026 年研究证实：篡改已批准工具的 description 即可诱导 Agent 越权。所以 tool description 变更要走代码评审流程，视同变更 system prompt。

工具还可声明 outputSchema（结构化输出）、annotations（readOnly / destructive / idempotent 提示）------注意：annotations 只是提示，不是强制，权限强制必须在 Host 层做。

Resources（应用控制）

由 Host 按需作为上下文挂载，用 URI 寻址：

{ "method": "resources/read",
  "params": { "uri": "file:///repo/tests/login.spec.ts" } }

Server 可用 file://、https:// 或自定义 scheme。关键：URI 只是命名，不授予访问权，Server 必须对每次 read 做鉴权。

Prompts（用户控制）

Server 提供的结构化模板，用户主动调用：

{ "name": "review_pr",
  "description": "带严重级评分的结构化 PR 评审",
  "arguments": [{ "name": "pr_number", "required": true }] }

能力协商（Capability Negotiation）

Client 与 Server 在连接时声明各自支持的能力，未声明即不可用------这是协议扩展性与向后兼容的基石。测试时可针对性做"能力探测"用例。

---

五、传输层：stdio 与 Streamable HTTP

规范明确定义仅两种标准传输。

1. stdio（本地）

Host ── stdin/stdout (换行分隔的 JSON-RPC) ──> MCP Server 子进程

• Host 把 Server 当子进程拉起，Client 退出子进程即销毁
• 无端口、无 TLS、无网络暴露面
• Server 以当前用户身份运行，继承你的 shell 环境

适合：文件系统、本地 Git、本地数据库。个人本地工具首选。

2. Streamable HTTP（远程）

Agent ── HTTP POST /mcp ──> Remote MCP Server
        Accept: application/json, text/event-stream

• 单一端点（通常 /mcp）
• 立即返回 → 单个 JSON；需流式 → 升级为请求作用域的 SSE 流
• 2026-07-28 起彻底无状态化

关键演进（必须知道，否则读老教程会踩坑）：

版本	变化
2024-11-05	HTTP+SSE（双端点 + 长 GET 流），已废弃
2025-03-26	引入 Streamable HTTP（单端点），但仍带 session
2026-07-28（当前）	移除协议级 session、Mcp-Session-Id、独立 GET 流、服务端发起请求、Last-Event-ID 重传

现在的状态模型：

• 每个请求自包含 ，在 _meta 里带 protocolVersion 和 clientCapabilities
• 跨调用状态 → Server 自己铸造的 handle，作为普通工具参数传递（SEP-2567）
• 断流 → 直接以新 request ID 重发，无需重协商 session
• 长连接通知 → 移到 subscriptions/listen 这条独立流

这意味着：负载均衡器不再需要粘性会话（sticky session），这是托管 MCP 平台快速跟进的主因。

版本协商

{ "_meta": {
    "io.modelcontextprotocol/protocolVersion": "2026-07-28",
    "io.modelcontextprotocol/clientCapabilities": { ... }
}}

版本不匹配 → UnsupportedProtocolVersionError，并列支持版本。Server 必须实现 server/discover 供客户端提前选型。

传输选型规则

场景	用	认证
个人、本地	stdio	继承 shell 环境
共享、托管、团队	Streamable HTTP	OAuth 2.0 + OIDC（RFC 9207 issuer 校验）

⚠️ 本地 Server 务必绑定 localhost ，远程必须 HTTPS + 短令牌。规范明确：Streamable HTTP Server 必须校验 Origin 头，无效即返回 403。

---

六、一次完整调用流程拆解

以"AI 跑登录回归，失败就建 Jira 缺陷"为例：

用户：用 Playwright 跑 /login 回归，失败就建 Jira 缺陷

1. Host 启动 Playwright MCP + Jira MCP（两个 Client）
2. Client → tools/list
   ← 拿到 browser_navigate / browser_click / create_bug ...
3. LLM 规划：打开页面 → 输入账号 → 点登录 → 检查跳转
4. Client → Playwright MCP: tools/call browser_navigate {url:"/login"}
5. Server 返回 accessibility tree（默认读 a11y 树，省 token）
6. LLM 发现"登录按钮 disabled"
7. Client → Jira MCP: tools/call create_bug {...}
8. 返回 bug key：QA-1234

几个工程要点：

• 模型不自己执行浏览器、不直接 curl Jira，全部经 MCP 调"被授权的能力"------天然形成调用链审计点
• 无状态后，步骤 4 若断流，Client 直接重发新请求即可，无需重建上下文

---

七、测试工程化：怎么把 MCP 用稳

作为高级测试工程师，我不只看"能不能跑"，更看可测性。MCP 本身就是一套高度可测试的协议：

1. 把每个能力当 API 测

MCP Server 本质是一个 JSON-RPC 服务，所有 Tools/Resources/Prompts 都有明确 schema------这是天然契约测试素材：

测试类型	做法
Schema 校验	用 JSON Schema 2020-12 校验 input/output
参数边界	必填缺失、类型错误、enum 越界
权限矩阵	readOnly 工具是否真的只读（尝试写操作断言失败）
幂等性	destructive=false 的工具重复调用结果一致
异常路径	DB 挂了、网络超时 → 是否返回规范 error
能力发现	tools/list 结果是否确定性排序（利于客户端缓存）

2. 利用确定性排序与缓存

2026-07-28 要求：tools/list、prompts/list、resources/list 等返回确定性顺序 ，并携带 ttlMs + cacheScope 缓存提示。

测试价值 ：这让你能写快照测试（snapshot test）------缓存命中率直接反映 LLM prompt cache 命中率，是成本优化的关键指标。

3. 多轮请求（MRTR）的测试

旧版的"服务端反向请求"（sampling、elicitation、roots）已被 Multi Round-Trip Requests 取代：

Server → 返回 resultType: "input_required" + inputRequests
Client → 重试原请求，附 inputResponses + requestState

测试要点：模拟 Server 索取额外信息，验证 Client 能否正确回填并继续。所有结果现在必带 resultType （complete / input_required）。

4. 异步任务走官方扩展

长耗时操作（跑全量回归套件）用官方 io.modelcontextprotocol/tasks 扩展：提交拿 handle → tasks/get 轮询 → tasks/update 客户端输入，不再用阻塞的 tasks/result。

💡 测试架构建议：不要让 Agent 同步等回归跑完，一律改异步轮询，避免超时与上下文浪费。

---

八、安全：这是 MCP 最容易翻车的地方

MCP 本身不解决 身份认证、授权、注入防护------这些必须自己补。作为测试负责人，这是我的最高优先级。

真实风险（均有公开案例）

• 工具描述投毒（Tool Description Poisoning）：微软 2025 年演示------不改工具名、只改 description，即可把正常财务操作诱导成数据外泄路径
• Git MCP 参考实现漏洞（2025-06 报、2026-01 公开，CVSS 6.3--6.5）：三个缺陷，影响最广的参考实现
• NSA / CISA 联合加固指南已专门发布 MCP 配置清单
• 统计：91.8% 的审计 MCP Server 缺少 OAuth

安全测试清单（可直接当评审表用）

控制项	措施	测试方法
最小权限	按 Agent 拆分权限，读写分离	越权用例：只读 Agent 尝试写
Roots 白名单	文件系统只开 /repo/tests	路径穿越 ../../etc/passwd
敏感操作人工确认	建单/发消息/改数据前弹确认	自动化绕过确认应失败
Audit Log	谁/何时/调了什么工具	断言日志完整可追溯
Tool Description 评审	视同代码 diff 评审	篡改描述红队测试
OAuth 短令牌	替代长寿命 API Key	令牌过期/越界用例
Origin 校验	HTTP Server 校验 Origin	伪造 Origin 应返 403
Gateway 统一鉴权	OAuth + 限流 + 审计	穿透测试

Prompt Injection 防护（核心）

OWASP 明确指出：没有任何方法能 100% 防注入 ，现实目标是缩小爆炸半径：

1. System Prompt 强约束角色，输出格式校验后才可信
2. 所有工具返回内容默认不可信------网页、工单、日志文本必须与 system prompt 隔离
3. 敏感操作用功能级权限边界（只读 vs 写/执行），而非依赖模型守规矩
4. 密钥绝不进 context window，走外部 Secrets Manager
5. 定期红队，把模型本身当对抗输入源

🎯 高级工程师的底线 ：把 MCP Server 当成软件供应链来管------来源、版本、tool description 变更全部走变更管理。

---

九、MCP vs Function Calling vs A2A

这张表面试高频，也是架构选型依据：

方案	优点	缺点	适用
LLM Function Calling	简单、原生	绑模型厂商，工具描述散在代码	单模型快速原型
让模型调 Bash/CLI	灵活	攻击面大、权限难控、输出非结构化	❌ 生产不推荐
自研中间件	可控	维护成本高，换 Agent 重接	特殊场景
MCP	跨模型、跨 Agent、可治理	要学协议、管 Server 生命周期	✅ 企业级标准
A2A（Agent-to-Agent）	Agent 间发现/委派/工件回流	不解决工具调用	多 Agent 协作

清晰分工：

• MCP = Agent 怎么用工具
• A2A = Agent 怎么和 Agent 说话
• 生产级多 Agent：A2A 管协作，MCP 管执行

---

十、测试场景落地路线图

从易到难，建议分四阶段推进：

阶段一：单工具试点（1--2 周）

选 Playwright MCP ，本地 stdio 接入 Cursor/Claude Code，跑登录冒烟。目标：跑通 browser_navigate → snapshot → click → type 链路。

阶段二：结果理解闭环（2--4 周）

自建 Allure MCP Server （FastMCP），暴露 get_failed_details / get_summary。让 Agent 读失败堆栈做根因分析。ROI 最高------分析是 LLM 擅长、人又费时的活。

阶段三：缺陷管理打通（4--6 周）

接入 Jira MCP，失败用例自动建单。配合人工确认门禁，P0 必人工复核。

阶段四：编排与规模化（6 周+）

用 Orchestrator + A2A 串多 Agent，加 MCP Gateway 统一鉴权审计，接 RAG（需求库/历史缺陷）提升准确率。

📌 给团队的硬建议 ：AI 不直接决定质量门禁 ------回归真值仍由 playwright test + Allure 结果决定，Agent 只做生成与分析，避免幻觉绕过门禁。

---

十一、选型清单

接入 MCP 前，逐条打勾：

• Server 来源可信、版本锁定、description 变更走评审
• 每 Agent 最小权限，读写工具分离
• 本地 stdio / 远程 HTTP 选型明确，远程必 HTTPS + OAuth
• 绑定 localhost 或校验 Origin
• Audit Log 覆盖所有 tools/call
• 敏感操作 Human-in-the-loop
• 契约测试覆盖所有 Tool schema（input/output/error）
• 快照测试验证 tools/list 确定性（缓存/成本）
• 长任务用 tasks 扩展异步轮询，非阻塞
• MRTR 路径（input_required）有专门用例
• 密钥不进 context，走 Secrets Manager
• 定期 Prompt Injection 红队

---

十二、结语

MCP 不是"让模型更强"，而是把模型与企业系统之间的接口标准化、可治理化。 对测试工程师而言，它既是"AI 测试"落地的地基，也是一套天然可测试的协议------schema 契约、能力协商、确定性列表，都是现成的测试资产。

实施建议：

1. 先 Allure MCP + 失败分析（最小闭环，ROI 最高）
2. 再 Playwright MCP 执行 + Jira MCP 建单
3. 最后 Orchestrator + Gateway 规模化

把权限、审计、门禁做扎实，AI 测试才能真正从"炫技 demo"变成"可交付的工程能力"。

---

参考资料

1. Model Context Protocol 官方规范 --- https://modelcontextprotocol.io
2. MCP Specification 2026-07-28 / Key Changes --- https://modelcontextprotocol.net/specification/2026-07-28/changelog
3. Playwright MCP 官方 --- https://github.com/microsoft/playwright-mcp
4. FastMCP（Python SDK） --- https://github.com/jlowin/fastmcp
5. OWASP Top 10 for LLM Applications --- Prompt Injection 风险
6. NSA / CISA MCP 加固指南 --- MCP 配置清单
7. Microsoft MCP Tool Description Poisoning 研究（2025--2026）
8. Agentic AI Foundation（AAIF）/ Linux Foundation --- MCP 治理

---

标签 ：#MCP #AI测试 #模型上下文协议 #Playwright #测试架构 #质量保障 #LLM安全 #高级测试工程师