# 系统架构与设计模式

## 核心架构：模型-上下文-协议 (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 构成，体现了微服务的思想，极大地提高了系统的灵活性和可维护性。