企业官网建设流程全解析

1. 项目概述：Unity与MCP的桥梁

最近在游戏开发社区里，一个名为CoderGamester/mcp-unity的项目引起了我的注意。乍一看，这像是一个普通的GitHub仓库，但当你深入挖掘，会发现它试图解决一个非常具体且前沿的问题：如何让Unity游戏引擎与新兴的“模型上下文协议”进行高效、标准化的通信。简单来说，它想为Unity这个庞大的游戏创作工具，打开一扇通往AI大模型世界的大门，让AI能力能够像插件一样，被无缝地集成到游戏开发流程中。

这个项目的核心价值在于“连接”。Unity是实时3D内容创作的绝对王者，从独立游戏到3A大作，从手机应用到工业仿真，其应用场景无所不包。而MCP，作为一种旨在标准化应用程序与大型语言模型之间数据交换的协议，代表着AI原生应用开发的新范式。mcp-unity项目的目标，就是在这两者之间架设一座坚固的桥梁。它不仅仅是一个简单的API封装，更是一个设计精巧的适配层，让Unity编辑器乃至运行时环境，能够以MCP服务器或客户端的身份，与支持MCP的AI助手进行对话。

想象一下这样的场景：你在Unity中搭建一个复杂的关卡，可以直接用自然语言对AI说：“帮我在场景中央生成一个带有喷泉的圆形广场，周围种上五棵随机形态的橡树。” AI通过MCP协议理解你的意图，并调用mcp-unity暴露出的工具，直接在Unity场景中创建对应的GameObject、配置材质、添加动画。或者，在游戏测试时，AI可以实时读取游戏状态（如玩家位置、敌人血量），并通过MCP提供决策建议。这极大地降低了将AI能力引入游戏开发的技术门槛，将创意实现的路径从“写代码-编译-测试”的循环，部分转变为“描述-验证-微调”的更直观交互。

2. 核心架构与设计思路拆解

要理解mcp-unity，我们必须先拆解它的两个核心组成部分：MCP协议本身，以及Unity引擎独特的生态和运行模式。项目的设计思路正是基于对这两者的深刻理解。

2.1 MCP协议的精髓：工具与资源的标准化描述

MCP的核心思想是让应用程序将其内部的能力“工具化”和“资源化”，并以一种LLM能理解的标准格式（如JSON Schema）暴露出来。一个MCP服务器主要提供两种东西：

1. 工具：可以类比为函数或API。每个工具都有明确的名称、描述和参数定义。例如，一个create_cube工具，参数可能包括位置、缩放和颜色。AI助手在了解到可用的工具列表后，就可以在合适的时机调用它们。
2. 资源：可以类比为只读的数据或上下文。例如，一个current_scene_hierarchy资源，可以提供当前Unity场景中所有GameObject的列表和层级关系。AI可以读取这些资源来了解应用程序的当前状态。

mcp-unity项目的首要任务，就是将Unity引擎中那些我们日常高频操作的功能，封装成符合MCP标准的工具和资源。这不仅仅是技术实现，更是一种精心的设计。例如，“在场景中创建基本几何体”是一个显而易见的工具，但“将选中的物体批量按特定规则重命名”或“查找场景中所有未使用的材质球”这类提升效率的实用功能，同样值得被包装成工具。设计者需要权衡工具的粒度：太粗，则灵活性不足；太细，则会让AI调用变得繁琐且容易出错。

2.2 Unity集成策略：编辑器扩展与运行时组件的双模驱动

Unity的工作流主要分为两部分：编辑器模式和运行时模式。mcp-unity巧妙地采用了双模设计来适应这两种状态。

在编辑器模式下，项目通常以一个Unity Editor Window扩展或一个后台服务的形式存在。它可以直接调用UnityEditor命名空间下的强大API，实现任何你能在Unity编辑器中手动完成的操作，比如修改资产、操作场景视图、执行菜单命令等。此时，MCP服务器运行在Unity编辑器进程内，通过本地进程间通信或网络与AI助手客户端连接。这种模式功能最强大，最适合用于关卡设计、资源管理、自动化测试等开发任务。

在运行时模式下，即游戏打包运行后，mcp-unity则需要以MonoBehaviour组件的形式存在。它无法使用编辑器API，但可以通过游戏逻辑暴露有限的工具和资源，例如：“获取玩家当前坐标”、“生成一个敌人”、“修改天气系统参数”。这为游戏内嵌AI助手、动态内容生成或智能化测试提供了可能。项目的设计难点在于如何安全、可控地暴露运行时功能，避免被恶意利用或引入性能瓶颈。

2.3 通信层实现：Stdio与SSE的抉择

MCP协议支持多种传输方式，最常见的是Stdio和SSE。mcp-unity的实现需要在这两者间做出选择，或者提供可配置的选项。

• Stdio：通过标准输入输出进行通信。这种方式实现简单，依赖少，非常适合与本地运行的AI助手进程集成。Unity可以启动一个外部进程，并通过管道与之通信。缺点是它是单向的，服务器无法主动向客户端推送信息。
• SSE：基于HTTP的服务器发送事件。这种方式允许服务器主动向客户端推送更新，例如当Unity场景发生变化时，可以主动通知AI助手“资源已更新”。这对于需要保持状态同步的交互更为友好，但需要内嵌一个轻量级的HTTP服务器。

一个健壮的mcp-unity实现可能会同时支持两者。在编辑器模式下，优先使用SSE以获得更佳的交互性；在简单的自动化脚本场景中，则可以使用Stdio以降低复杂度。通信层的稳定性和错误处理是这里的重中之重，需要处理连接中断、消息超时、数据序列化异常等各种边界情况。

实操心得：协议设计的扩展性在设计工具和资源的Schema时，一定要预留扩展字段。例如，一个创建物体的工具，除了位置、旋转、缩放，未来可能会需要添加“物理属性”、“标签”或“自定义脚本”等参数。在最初的JSON Schema中使用additionalProperties或明确的optional字段，可以为后续的功能迭代减少很多兼容性麻烦。不要试图在第一个版本中就定义出完美的接口，而应该定义一个能够优雅演进的接口。

3. 核心功能模块深度解析

一个完整的mcp-unity实现会包含多个功能模块，每个模块都对应着Unity工作流中的一个关键环节。下面我们来深入解析几个最核心的模块。

3.1 场景与对象管理工具集

这是最基础也是最常用的工具集，旨在将Unity场景的增删改查操作AI化。

• 工具scene_object_create：创建基本几何体或预设体。

  • 参数设计：type（Cube, Sphere, Capsule等或prefab_path），position,rotation,scale,name。这里的一个关键细节是position的坐标系。是使用世界坐标还是局部坐标？通常，世界坐标对AI来说更直观。参数应支持Vector3的JSON表示{“x”: 0, “y”: 1, “z”: 0}。
  • 实现要点：在编辑器模式下，直接调用GameObject.CreatePrimitive或PrefabUtility.InstantiatePrefab。必须考虑错误处理，如提供的预制体路径不存在时，应返回清晰的错误信息给AI，而不是让Unity崩溃或静默失败。

• 工具scene_object_modify：修改已存在物体的属性。

  • 参数设计：object_path（通过资源scene_hierarchy获取的唯一标识，如“/Canvas/Panel/Button”），properties（一个键值对，如{“position”: {…}, “active”: false}）。这里最大的挑战是属性映射的通用性。不同组件有不同的属性，一个设计良好的实现可能会提供一个set_property工具，其参数包含component_type和property_name。
  • 实现要点：需要通过GameObject.Find或遍历变换层级来定位对象。修改属性时，要利用C#的反射机制，但要注意性能和安全。对于常修改的属性（位置、旋转），应提供快捷工具。

• 资源scene_hierarchy：获取当前场景的层级结构。

  • 数据格式：返回一个嵌套的JSON结构，反映Transform的父子关系。每个节点应包含名称、激活状态、可能的实例ID或稳定路径。为了减少数据量，可以设计一个lite模式，只返回名称和层级，不包含详细信息。
  • 实现要点：递归遍历SceneManager.GetActiveScene().GetRootGameObjects()。注意处理大型场景时的性能问题，这个资源的调用可能会比较频繁。

3.2 资产与资源操作接口

Unity项目本质上是资产（Asset）的集合。让AI能理解和操作资产，能解锁更强大的自动化能力。

• 资源project_asset_list：列出项目Assets目录下的特定类型资源。

  • 参数设计：filter（如“.prefab”, “.mat”），directory（可选，指定搜索目录）。
  • 实现要点：使用Directory.GetFiles或AssetDatabase.FindAssetsAPI。后者与Unity编辑器集成更深，能识别meta文件且效率更高。返回的资源路径应使用相对路径（如“Assets/Prefabs/Enemies/Orc.prefab”）。

• 工具material_create_or_edit：创建或修改材质球。

  • 参数设计：shader_path（如“Standard”或“Universal Render Pipeline/Lit”），properties（一个字典，键为属性名如“_MainTex”，值为纹理路径或颜色值）。这要求AI对Unity着色器属性有一定的“知识”，或者项目需要提供一份常用属性映射表。
  • 实现要点：使用new Material(Shader.Find(shaderPath))创建，使用Material.SetTexture或SetColor进行设置。最后通过AssetDatabase.CreateAsset保存。这是一个展示如何将复杂、专业的操作（材质编辑）封装成AI可理解工具的绝佳例子。

3.3 编辑器自动化与工作流增强

这部分工具旨在复制或串联编辑器内的手动操作，极大提升效率。

• 工具editor_menu_command：执行任意的编辑器菜单命令。

  • 参数设计：menu_path（如“GameObject/3D Object/Cube” 或 “Edit/Play”）。这是实现“万能操作”的捷径。
  • 实现要点：直接调用EditorApplication.ExecuteMenuItem(menuPath)。虽然强大，但需谨慎使用，因为菜单命令的执行可能带有副作用或依赖特定上下文。最好对常用的、稳定的命令进行二次封装，提供更安全的专用工具。

• 工具batch_rename：批量重命名选中的物体。

  • 参数设计：name_pattern（支持{index}、{parent}等占位符），selection（可选，指定要重命名的物体路径列表，若不提供则使用当前编辑器选中项）。
  • 实现要点：遍历Selection.gameObjects，解析命名模式，使用Undo.RecordObject记录操作以支持撤销。这个工具体现了AI如何将繁琐、重复的体力劳动自动化。

注意事项：Undo系统的集成任何通过MCP工具对Unity编辑器状态进行的修改，都必须集成Undo系统。这意味着在修改任何对象属性前，应该调用Undo.RecordObject或Undo.RegisterCompleteObjectUndo。否则，开发者将无法通过Ctrl+Z撤销AI执行的操作，这会带来极差的用户体验和潜在的数据丢失风险。这是编辑器自动化工具开发中一个至关重要且容易被忽略的细节。

4. 实战：构建一个基础的MCP-Unity服务

理论说了这么多，我们动手实现一个最精简但可工作的mcp-unity服务核心。我们将选择Stdio作为通信方式，因为它最简单。

4.1 项目结构与初始设置

首先，在Unity中创建一个新的编辑器脚本文件夹，例如Assets/McpUnity。我们需要安装或引用MCP协议的C#实现库。由于MCP相对较新，你可能需要从官方仓库或NuGet查找ModelContextProtocol相关的C# SDK。如果暂无官方SDK，我们就需要手动实现最基本的协议消息解析。

为简化，我们假设有一个简单的McpMessage类来处理JSON-RPC格式的消息。

// Assets/McpUnity/Core/McpMessage.cs using System; using Newtonsoft.Json; // 需要导入Json.NET包 namespace McpUnity { [Serializable] public class McpMessage { public string jsonrpc = "2.0"; public string id; public string method; public JObject @params; public JObject result; public McpError error; } [Serializable] public class McpError { public int code; public string message; } }

4.2 实现Stdio通信循环

创建一个主要的McpServerMonoBehaviour，它不会附加到场景物体，而是作为编辑器脚本运行。

// Assets/McpUnity/Editor/McpStdioServer.cs #if UNITY_EDITOR using UnityEditor; using UnityEngine; using System; using System.IO; using System.Threading; using Newtonsoft.Json.Linq; namespace McpUnity.Editor { [InitializeOnLoad] public static class McpStdioServer { private static Thread _serverThread; private static bool _isRunning = false; static McpStdioServer() { // 可选：在Unity启动时自动运行服务器 // EditorApplication.update += CheckAndStartServer; } [MenuItem("Tools/MCP/Start Stdio Server")] public static void StartServer() { if (_isRunning) { Debug.Log("MCP Server is already running."); return; } _isRunning = true; _serverThread = new Thread(RunServerLoop); _serverThread.IsBackground = true; _serverThread.Start(); Debug.Log("MCP Stdio Server started. Listening on stdin."); } [MenuItem("Tools/MCP/Stop Stdio Server")] public static void StopServer() { _isRunning = false; if (_serverThread != null && _serverThread.IsAlive) { _serverThread.Join(1000); // 等待线程结束 } Debug.Log("MCP Stdio Server stopped."); } private static void RunServerLoop() { while (_isRunning) { try { string line = Console.ReadLine(); // 从标准输入读取 if (string.IsNullOrEmpty(line)) continue; var message = JsonConvert.DeserializeObject<McpMessage>(line); ProcessMessage(message); } catch (Exception e) { // 将错误输出到标准错误流，方便客户端捕获 Console.Error.WriteLine($"MCP Server Error: {e.Message}"); } } } private static void ProcessMessage(McpMessage message) { // 在主线程执行Unity API调用 EditorApplication.delayCall += () => { McpMessage response = new McpMessage { id = message.id }; try { switch (message.method) { case "initialize": response.result = HandleInitialize(message.@params); break; case "tools/list": response.result = HandleListTools(); break; case "tools/call": response.result = HandleCallTool(message.@params); break; // ... 处理其他方法 default: response.error = new McpError { code = -32601, message = "Method not found" }; break; } } catch (Exception e) { response.error = new McpError { code = -32000, message = e.Message }; } // 将响应写回标准输出 string responseJson = JsonConvert.SerializeObject(response); Console.WriteLine(responseJson); }; } private static JObject HandleInitialize(JObject @params) { // 返回服务器能力信息 return new JObject { ["protocolVersion"] = "2024-11-05", ["serverInfo"] = new JObject { ["name"] = "mcp-unity", ["version"] = "0.1.0" }, ["capabilities"] = new JObject() }; } private static JObject HandleListTools() { // 返回工具列表 var tools = new JArray(); tools.Add(new JObject { ["name"] = "create_cube", ["description"] = "在场景原点创建一个立方体", ["inputSchema"] = new JObject { ["type"] = "object", ["properties"] = new JObject { ["name"] = new JObject { ["type"] = "string", ["description"] = "物体名称" } } } }); // ... 添加更多工具 return new JObject { ["tools"] = tools }; } private static JObject HandleCallTool(JObject @params) { string toolName = @params["name"]?.ToString(); var arguments = @params["arguments"] as JObject; switch (toolName) { case "create_cube": string objName = arguments?["name"]?.ToString() ?? "New Cube"; GameObject cube = GameObject.CreatePrimitive(PrimitiveType.Cube); cube.name = objName; // 记录Undo操作 Undo.RegisterCreatedObjectUndo(cube, "Create Cube via MCP"); return new JObject { ["content"] = new JArray { new JObject { ["type"] = "text", ["text"] = $"Cube '{objName}' created successfully." } } }; default: throw new Exception($"Tool '{toolName}' not implemented."); } } } } #endif

4.3 与AI助手（客户端）集成测试

现在，我们需要一个MCP客户端来测试我们的服务器。我们可以使用一个简单的Python脚本模拟。

首先，确保你的Unity编辑器正在运行，并且通过菜单Tools/MCP/Start Stdio Server启动了服务。

然后，创建一个Python测试脚本test_mcp_client.py：

import json import subprocess import sys # 假设我们通过一个虚拟进程来连接，实际上Stdio需要与Unity进程对接 # 这里我们模拟一个调用流程 def simulate_mcp_call(): # 1. 初始化请求 init_request = { "jsonrpc": "2.0", "id": "1", "method": "initialize", "params": {} } print(f"> Sending: {json.dumps(init_request)}") # （在实际中，这里会将JSON写入Unity进程的stdin，并从其stdout读取） # 模拟响应 init_response = { "jsonrpc": "2.0", "id": "1", "result": { "protocolVersion": "2024-11-05", "serverInfo": {"name": "mcp-unity", "version": "0.1.0"} } } print(f"< Received: {json.dumps(init_response)}") # 2. 列出工具 list_tools_request = { "jsonrpc": "2.0", "id": "2", "method": "tools/list", "params": {} } print(f"\n> Sending: {json.dumps(list_tools_request)}") # 模拟响应 list_tools_response = { "jsonrpc": "2.0", "id": "2", "result": { "tools": [ { "name": "create_cube", "description": "在场景原点创建一个立方体", "inputSchema": { "type": "object", "properties": { "name": {"type": "string", "description": "物体名称"} } } } ] } } print(f"< Received: {json.dumps(list_tools_response)}") # 3. 调用工具 call_tool_request = { "jsonrpc": "2.0", "id": "3", "method": "tools/call", "params": { "name": "create_cube", "arguments": { "name": "MyAwesomeCube" } } } print(f"\n> Sending: {json.dumps(call_tool_request)}") # 模拟响应 call_tool_response = { "jsonrpc": "2.0", "id": "3", "result": { "content": [ {"type": "text", "text": "Cube 'MyAwesomeCube' created successfully."} ] } } print(f"< Received: {json.dumps(call_tool_response)}") print("\n✅ 模拟调用完成！此时检查你的Unity编辑器场景，应该能看到一个名为'MyAwesomeCube'的立方体。") if __name__ == "__main__": simulate_mcp_call()

运行这个Python脚本，它模拟了完整的MCP交互流程。在真实的集成中，你需要将AI助手配置为MCP客户端，并指向你正在运行的Unity编辑器进程。一些先进的AI代码助手已经支持MCP协议，理论上可以直接与你的mcp-unity服务器对话。

5. 高级主题与性能优化

当基础功能跑通后，我们需要关注更高级的主题，以确保项目在实际生产环境中稳定、高效。

5.1 资源订阅与增量更新

最初的资源查询（如获取场景层级）是“拉”模式，即AI需要时才请求。但在复杂的交互中，“推”模式更高效。这就是SSE的用武之地。我们可以实现资源订阅功能。

例如，AI可以订阅scene_hierarchy资源。初始时，服务器发送完整数据。之后，每当场景中GameObject的激活状态、父子关系或名称发生变化时（可以通过监听EditorApplication.hierarchyChanged事件），服务器就通过SSE连接向所有订阅的客户端发送一个增量更新通知，或者直接发送变化后的那部分层级数据。这能极大减少不必要的数据传输，并保持AI上下文与Unity场景的实时同步。

实现此功能需要维护一个客户端订阅列表和一个简单的差异计算逻辑。对于频繁变化的资源，甚至可以设置一个节流机制，比如每秒最多推送一次更新。

5.2 工具调用的异步与长时任务处理

并非所有Unity操作都是瞬时的。例如，“烘焙光照”、“导入大型模型”、“运行全量单元测试”等工具可能需要数秒甚至数分钟。MCP协议支持异步工具调用。

当AI调用一个长时工具时，服务器应立即返回一个result，其中包含一个jobId或taskId，表示任务已开始。然后，服务器在后台执行任务，并通过SSE或另一个轮询接口，定期向客户端发送进度更新。任务完成后，再发送最终结果。这要求服务器端有一个任务队列和状态管理机制。

在Unity中，对于编辑器下的长时任务，可以利用EditorApplication.CallbackFunction或AsyncOperation来避免阻塞主线程。对于运行时任务，则需要更精细的协程或线程管理。

5.3 安全性与权限控制

让AI拥有直接操作Unity编辑器和游戏运行时的能力是强大的，但也危险。一个错误或恶意的指令可能导致场景破坏、资产丢失或游戏崩溃。因此，必须引入安全层。

• 操作确认：对于高风险操作（如删除资产、退出播放模式、保存场景），工具实现可以弹出一个Unity编辑器对话框，要求用户手动确认。这虽然打断了自动化流程，但提供了安全阀。
• 沙盒模式：提供一个“沙盒”场景或项目副本，让AI在其中进行实验性操作，不影响主项目。
• 操作范围限制：通过配置白名单，限制AI可以调用的工具列表和可以操作的资源路径。例如，只允许在Assets/Experiments/目录下创建和修改资源。
• 操作日志与回滚：详细记录AI执行的所有工具调用和参数，并尽可能与Unity的Undo栈绑定。这样，即使出了问题，也能清晰地追溯和撤销。

6. 常见问题与调试技巧实录

在实际开发和集成mcp-unity的过程中，你肯定会遇到各种问题。以下是我在实践中总结的一些常见坑点和解决思路。

6.1 通信连接失败

• 问题：AI助手无法连接到Unity MCP服务器，或者连接后立即断开。
• 排查：
  1. 检查服务器是否真正启动：在Unity编辑器的Console中查看是否有启动日志。确保没有未处理的异常导致服务器线程崩溃。
  2. 检查传输方式：确认客户端和服务器配置的传输方式一致（都是Stdio或都是SSE+正确的URL/端口）。
  3. 防火墙/权限：如果使用SSE，确保Unity编辑器进程有权限绑定到指定端口，且防火墙没有阻止连接。
  4. Stdio管道问题：某些AI助手在启动子进程时，可能没有正确设置标准输入输出流的重定向。尝试用简单的Python脚本作为客户端进行连接测试，以排除助手客户端的问题。

6.2 工具调用无响应或报错

• 问题：AI成功列出了工具，但调用时没有效果，或者返回模糊的错误信息。
• 排查：
  1. 查看Unity编辑器日志：所有未捕获的异常和Debug.Log信息都会在这里输出。这是最重要的调试信息来源。确保在你的工具实现中，对可能出错的地方用try-catch包裹，并用Debug.LogError输出详细信息。
  2. 验证参数格式：在工具的HandleCallTool方法中，首先将接收到的参数JSON打印出来，确认其结构与你的Schema定义一致。常见的错误包括字段名拼写错误、数据类型不匹配（如字符串传成了数字）。
  3. 主线程问题：Unity的绝大多数API（尤其是编辑器API和与GameObject相关的API）都必须在主线程调用。确保你的工具处理逻辑被包裹在EditorApplication.delayCall或通过Dispatcher派发到主线程执行。我们的示例代码中已经做了这个处理。
  4. Undo注册：如果操作在编辑器下执行了但无法撤销，检查是否遗漏了Undo.RecordObject或Undo.RegisterCompleteObjectUndo调用。

6.3 AI助手不理解工具功能

• 问题：AI助手列出了工具，但在对话中从不主动使用，或者使用的方式不符合预期。
• 排查：
  1. 优化工具描述：MCP工具的description字段至关重要。它应该用自然语言清晰、无歧义地描述工具的功能、适用场景和参数含义。避免使用技术黑话。好的描述示例：“在场景中指定位置创建一个球体。” 坏的描述示例：“实例化一个球体预制件。”
  2. 提供丰富的资源：AI的决策依赖于上下文。确保你提供了足够多的、描述清晰的资源（如scene_hierarchy,selected_objects），让AI能充分了解当前Unity项目的状态。
  3. 测试提示词：不同的AI助手可能需要不同的系统提示词来引导其使用MCP工具。在客户端的系统提示中，明确告诉助手：“你是一个Unity专家，可以通过MCP工具操作Unity编辑器。在回答用户关于Unity场景修改、物体创建等问题时，请优先考虑使用可用的工具。”

6.4 性能问题

• 问题：当场景复杂或操作频繁时，服务器响应变慢，或Unity编辑器卡顿。
• 排查与优化：
  1. 资源查询优化：scene_hierarchy这类资源不要每次请求都全量生成。可以缓存结果，只在收到hierarchyChanged等事件时使缓存失效。对于大型场景，考虑实现分页或层级懒加载查询。
  2. 工具调用节流：对可能被频繁调用的工具（如连续移动物体），可以在服务器端实现一个去抖动机制，将短时间内连续的多次调用合并为一次。
  3. 避免阻塞主线程：长时间运行的工具一定要异步化。使用Task.Run将CPU密集型计算放到后台线程，但注意，回到主线程操作Unity对象时仍需通过Dispatcher。
  4. 精简数据量：在资源JSON响应中，只返回必要的字段。例如，物体的Transform信息可能包含很多小数位，可以考虑序列化时进行适当的精度取舍。

实操心得：调试是双端的调试MCP集成问题，一定要有“两端思维”。准备两个简单的调试工具：一个是最小化的MCP客户端脚本（如上面的Python示例），用于向你的Unity服务器发送原始请求，验证服务器逻辑；另一个是在Unity端，将所有进出消息都详细打印到日志文件或一个专门的调试窗口。当问题出现时，对比两端的日志，能快速定位是协议格式错误、网络问题，还是具体的工具实现bug。不要依赖AI助手这个“黑盒”作为你唯一的测试客户端。