63 lines
3.8 KiB
Markdown
63 lines
3.8 KiB
Markdown
# 系统架构与设计模式
|
||
|
||
## 核心架构：模型-上下文-协议 (MCP)
|
||
|
||
本系统严格遵循 MCP 定义的 **Host-Client-Server** 架构，旨在实现组件的终极解耦和高可扩展性。
|
||
|
||
```mermaid
|
||
graph TD
|
||
subgraph TestRunnerApp [测试运行程序 (MCP Host)]
|
||
style TestRunnerApp fill:#e6f2ff,stroke:#b3d9ff
|
||
A[<b>run_mcp_tests.py</b><br/><i>(Host 实例)</i>]
|
||
A -- 1. 为每个测试任务<br/>创建并管理Client会话 --> B
|
||
A -- 4. 汇总所有Client的<br/>结论，生成报告 --> E[最终测试报告]
|
||
end
|
||
|
||
subgraph AgentSession [独立的Agent会话 (MCP Client)]
|
||
style AgentSession fill:#e6ffe6,stroke:#b3ffb3
|
||
B[<b>Client 实例</b><br/><i>(包含LLM的Agent核心)</i>]
|
||
B -- 2. 向Host请求<br/>使用工具 --> D
|
||
end
|
||
|
||
subgraph Toolbelt [MCP工具集 (MCP Servers)]
|
||
style Toolbelt fill:#fff0e6,stroke:#ffccb3
|
||
D[<b>APICallerServer<br/>DataGenServer<br/>AssertionServer<br/>...</b>]
|
||
D -- 3. 执行操作<br/>并将结果通过Host返回 --> B
|
||
end
|
||
```
|
||
|
||
## 组件职责详解
|
||
|
||
### 1. MCP Host (测试运行程序)
|
||
|
||
* **角色**: 整个测试流程的 **总控制器**、**安全边界** 和 **环境提供者**。它如同一个“办公室”环境，为 Agent 的工作提供场地、工具和规则。
|
||
* **职责**:
|
||
* **流程编排**: 加载 API 规范和合规规则，生成测试任务列表，并为每个任务启动一个独立的、隔离的 Client 会话。
|
||
* **生命周期管理**: 负责创建、监督和销毁 Client 实例。如果某个 Agent 会话卡死或崩溃，Host 会终止它并继续下一个任务，确保整体流程的健壮性。
|
||
* **安全与路由**: 作为所有通信的中间人，它接收来自 Client 的工具调用请求，验证其权限，然后将其安全地路由到指定的 Server。它也负责将 Server 的结果返回给正确的 Client。**Client 和 Server 之间永不直接通信**。
|
||
|
||
### 2. MCP Client (Agent 会话)
|
||
|
||
* **角色**: 承载 **LLM（大语言模型）** 的执行实体，是 Agent 的“大脑”和“身体”的结合。
|
||
* **职责**:
|
||
* **任务执行**: 从 Host 接收一个明确的测试目标。
|
||
* **推理规划**: 内部的 LLM 负责思考和规划，决定需要执行哪些步骤、调用哪些工具来达成测试目标。
|
||
* **与 Host 通信**: 将 LLM 的决策转化为对 Host 的标准 `call_tool` 请求。
|
||
* **状态保持**: 在会话内部维持短期的记忆和上下文，以完成连贯的、多步骤的测试逻辑。
|
||
|
||
### 3. MCP Servers (工具集)
|
||
|
||
* **角色**: 提供单一、原子化能力的 **功能模块**。每个 Server 都是一个独立的微服务。
|
||
* **职责**:
|
||
* **提供能力**: 封装一种特定的能力，例如：
|
||
* `APICallerServer`: 仅负责发起 HTTP 请求。
|
||
* `DataGeneratorServer`: 仅负责根据 Schema 生成数据。
|
||
* `AssertionServer`: 仅负责比较两个值是否相等。
|
||
* **无状态与隔离**: Server 本身是无状态的（或会话状态由 Host 管理），并且对其他 Server 和整个测试任务一无所知。这种设计确保了工具的高度可复用性和可独立测试性。
|
||
|
||
## 设计模式应用
|
||
|
||
* **单一职责原则**: 每个组件（Host, Client, Server）和每个 Server 内部的工具都有单一、明确的职责。
|
||
* **策略模式**: 每个合规性规则可以被看作一种“策略”，Agent 根据不同的策略（规则目标）来组织其工具调用序列。
|
||
* **外观模式**: Host 为 Client 提供了一个统一的、简化的接口来访问背后复杂的工具集，Client 无需关心工具的具体位置和实现。
|
||
* **微服务架构**: 整个工具集由一系列独立的、可独立部署的 Server 构成，体现了微服务的思想，极大地提高了系统的灵活性和可维护性。 |