3.8 KiB
3.8 KiB
系统架构与设计模式
核心架构:模型-上下文-协议 (MCP)
本系统严格遵循 MCP 定义的 Host-Client-Server 架构,旨在实现组件的终极解耦和高可扩展性。
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 构成,体现了微服务的思想,极大地提高了系统的灵活性和可维护性。